Slashdot Mirror
Malvertising Campaign Used a Free Certificate From Let's Encrypt (csoonline.com)
itwbennett writes: On Wednesday, Trend Micro wrote that it discovered a cyberattack on Dec. 21 that was designed to install banking malware on computers. The cybercriminals had compromised a legitimate website and set up a subdomain that led to a server under their control, wrote Joseph Chen, a fraud researcher with Trend. The subdomain used an SSL/TLS (Secure Sockets Layer/Transport Layer Security) certificate issued by Let's Encrypt, the first large-scale project to issue free digital certificates. which is run by the ISRG (Internet Security Research Group) and is backed by Mozilla, the Electronic Frontier Foundation, Cisco, and Akamai, among others. The incident has sparked disagreement over how to deal with such abuse, writes Jeremy Kirk.
.
Unlike most other CA's, Let's Encrypt has a very short lifetime on their certs (60 days, I believe) so that an abused cert quickly falls out of the eco-system. I've read that Let's Encrypt eventually wants to shorten that lifetime even more, to 30 days.
Most other CAs have cert lifetimes of a year (or longer). Then the question surfaces - how useful is cert revocation? Do all TLS clients check for cert revocation?
This article looks like a really good response to the issue: https://unmitigatedrisk.com/?p=552
The lifetime at launch is actually 90 days (https://letsencrypt.org/2015/11/09/why-90-days.html)
The rest is correct.
Most SSL/TLS clients do not check for a relevant CRL. The few that do (such as Firefox and other web browsers) typically require configuration and won't check for revocation by default out of the box.
In contrast, nearly all SSL/TLS clients that I am aware of (certain MTAs being an exception) will refuse to use an expired certificate unless specifically instructed to do so by the end user. So expiration is more likely to have an effect than revocation.
I don't see why this is news at all. Let's Encrypt is a great way to allow any webmaster to offer a TLS-protected connection between his users and his server.
As a user, seeing a website using a Let's Encrypt or StartSSL certificate does not tell me anything about the legitimacy of that website. All it does is guarantee that my connection won't be intercepted through a MITM attack. Personally, I never "just trust" the little lock icon in my address bar: I click it and see who signed it. Then I make a decision on whether or not I trust that website with my information.
If they were able to create a subdomain, that means the attackers controlled all traffic to that subdomain.
Since most certificate authorities only verify via email to the domain for which the certificate is requested, the attackers would have gotten a certificate from virtually any CA.
There are additional verification steps required for EV certificates that should thwart this sort of attack, but singling out Let's Encrypt for issuing a certificate in this case is disingenuous.
The real problem lies with the DNS registrar that accepted an unauthorized subdomain registration request. (Or maybe the client's account was compromised, in which case the victim is to blame.)
Either way, the submission titles makes it seem this is a problem with Let's Encrypt when it most certainly is not.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
The original model was meant to facilitate online commerce. Netscape invented SSL and was pushing it despite the opposition from IPsec proponents — because SSL-certificates were to provide assurance, that the remote end is a legitimate business. One may argue, the encryption aspect was secondary.
If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.
In Soviet Washington the swamp drains you.
CRL's are of limited usefulness anyway. There is no guarantee that the attackee will be able to contact the CRL site and everyone defaults to trusting the revoked cert in this case.
Posted AC to preserve mods
If it is only a small part of data, that actually needs encryption — the password and the credit card number — you can do that (using the well-known and studied protocols) in JavaScript.
What you describe is similar to what Tloz proposes in the question "How to replace SSL/TLS?". But using client-side script to encrypt passwords has three drawbacks:
If it is only a small part of data, that actually needs encryption â" the password and the credit card number â" you can do that (using the well-known and studied protocols) in JavaScript.
No you can't do that, no stop right right WRONG.
The JavaScript itself must be delivered on a authenticated encrypted channel because if it isn't how will my browser know its not supposed to run that XMLHttpRequest call to post a second plan text copy of that info to evil-hacker.com after you main in the middle my amazon session in the coffee shop.
Same goes with forms that are delivered over http but post https, this wrong and dangerous for the same reason. You can do authentication and encryption in the application layer if its a fat client and the client already has a static copy of trusted code form elsewhere but in the case of web site where the 'application' is being downloaded from the server the client needs a way authenticate and ensure transport integrity while obtaining the application itself otherwise its game over, your pwnd before you begin. The network layer is the correct place.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
The cert wasn't issued fraudulently. The domain validation is totally legit seeing as the attackers had control of the domain.