Trend Micro: Internet scum grab Let's Encrypt certs to shield malware It was inevitable. Trend Micro says it has spotted crooks abusing the free Let's Encrypt certificate system to smuggle malware onto computers. The security biz's fraud bod Joseph Chen noticed the caper on December 21. Folks in Japan visited a website that served up malware over encrypted HTTPS using a Let's Encrypt-issued cert …
Certificates don't certify that the site you're connecting to is legitimate. They don't certify that the people using it are who they are claiming to be. And they definitely don't certify that the server you're connecting to is secure (unless by that you mean it supports TLS/HTTPS, period).
Certificates only certify that the people that were in control of the domain when the CA performed the check are the same people that are running the server you're connecting to now.
But if you don't read T&C of CAs that may come to you as a surprise...
so, please, tell me, where exactly is the failure on Let's Encrypt part?
The other certificate issuers have your payment information which tends to deter criminals from using their services since payment information can help determine their actual identity.
Let's Encrypt doesn't have that.
Really, what is the point of a certificate system if the certificate system declares it is wide open to undocumented criminal use?
It is glib to say security and identification is someone else's business, when your sole business is providing security and identification.
>It is glib to say security and identification is someone else's business, when your sole business is providing security and identification.
But they have fulfilled their role. They have identified the content as coming from the certificate site owner and allowed the owner to securely deliver the content.
What you (and trend) are suggesting is having ca's arbitrate relationships. That is not their role. Trend know this but it doesn't stop a good publicity stunt.
There's a standard mechanism to specify (at a DNS domain level) which certificate authorities are authorised to issue certificates, and LetsEncrypt complies with this (as all good CAs should). The check is done at time of issue, so this doesn't let you revoke certs but it'll stop an individual using a CA that the organisation does want to use.
The service they provide is no worse than every other CA that does domain authentication as their basic SSL cert level. Most of the low-value sites I use that just need SSL for logging in or protecting a small amount of content seem to have the $10 domain certificates. If you want the browser bar to turn green, you're still going to need a verified certificate, which costs much more, and isn't offered by LE.
Essentially they're saying that SSL is a basic of the web (good and bad) these days, and are bringing the lowest level of certification, domain, to anyone for free. If you want to know who the website is run by, check that it's got an actually verified certificate.
One of the points of LE's setup is that SSL is a basic element of the web, and it's all automated. They are pointedly not verifying the identity of the requester, simply making sure that encryption to a particular server that is controlled by the requester is secure. We need to educate users to look for actual verification if they don't trust the source.
"the attackers compromised an unnamed web server, created their own subdomain for the server's website"
For them to create a sub-domain they would need to also compromise the authoritative name server, unless the DNS was hosted on that same web server that they rooted - which is a bad idea anyway. The DNS should be separate and independent.
Many domains have wildcard entry in zone file, pointing to some HTTP server sending 302 redirect to proper domain. If HTTP server has been compromised (as obviously it has), it should not be difficult to create one more website matching hostname that the crooks are wishing to hijack. No need to hack DNS server, just use what's already in place.
Wow, I had forgotten about the wildcard RR. So the fact that Let's Encrypt was the CA is really nothing to do with it; it could have happened to Verisign or any other CA given that the redirector for the RR was the compromised server.
There seems to be a lesson here that wildcards can be dangerous. If there was no wildcard RR then even though the server was hacked, the fake certificate would not be possible. Yes?
That's almost correct. Two points:
1) I have never dealt with Verisign but I assume they do not give certificates for hostname only and they also do require payment. Which means that identity of crooks would have to be revealed when applying for the certificate, or at least they would have to hide behind someone else's identity. Let's Encrypt does not take payment and does not perform any other check than hostname only, making it ideal to keep one's identity secret.
2) this works for crooks when either of DNS server or HTTP server (to which a wildcard points) is hacked. Given past state of BIND DNS, the former option is unfortunately quite possible.
Unfortunately the knee jerk reaction to lack of privacy by demanding everything is encrypted, is leading to overall poorer security.
Is the potential of unencrypted web traffic being snooped better or worse than having sites appearing to be trusted by using freely available unverified certificates issued to malware writers?
Obviously it would be best if legacy unencrypted HTTP ceased to exist.
Extended validation (fat green bar) is the new secure. Over time browsers will downplay (visually) mere domain only validation, which will become the new normal. Unencrypted is being depreciated out as we speak, for example not granting access to new web APIs from unsecured origins.
By carrot and stick, the unencrypted web is on the way out.
You could look at it like that. Or it could be that a side-benefit of Let's Encrypt's process is highlighting the already existing flaws and failures of the Certificate Authority model when it comes to issues like trust and identity.
It is not like we did not know that the CA architecture is rather limited.
Trend Micro probably relies on unencrypted HTTP connection to spy on your internet connection to detect malware. Until now, TLS encrypted connection were used for well-known non-bad sites and could be disregarded by virus scanners. Now that TLS is available for the masses everything gets encrypted, including bad things and Trend Micro can't easily check it anymore.
The malware problem is not a problem that has anything to do with Let's Encrypt. It has to do with webservers being easily hacked, badly secured advertising networks, DNS policies, leaky browsers, unpatched Windows machines, etc.
Let's keep on encrypting people.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
