Discusses how letsencrypt enables cybercriminals by issuing certificates to phishing sites. Although it has always been possible to create domain validated SSL for any domain under your control the low cost of entry is what makes letsencrypt stand out.
I have read a number of posts about phishing sites and it appears to me that letsencrypt abdicates its responsibility in this arena. At least I could not find any information that specifies proactive action.
One of the most important things to remember or know if you don’t already, about phishing sites is that they are not long lived, they are quick hit sites. so “normal” reactive methods are already too late. Certificate cancellation or relying on browsers safe site settings kicking in is too late.
Its important to realise a site does not make it onto the lack list until after damage has been done.
The last thing anyone wants is letsencrypt to be tainted by such activity as has happened to TOR.
To make it harder for phishing site operators to perform their bad deeds it is far better to be proactive rather than reactive.
One way to do this is to add a mechanism that inspects the request and automatically refuses anything that may be too similar to a high profile website like paypal.attack.moc or even poypal.attack.moc or just poypal.moc detecting such similar names is not hugely difficult.
The difficult part is a manual review process. When a legitimate site is blocked enabling a method to override the block so the certificate can be issued.
Have you read Let's Encrypt's post on the subject?
The amount of responsibility a CA has can be, and has been, debated.
I'm a minor Tor operator.
Aside from the Safe Browsing thing, and any other measures, Let's Encrypt restricts issuance for high-risk domains. (I believe this is required, but vaguely defined, by the rules.)
There is already a sort of keyword screening process for certificate issuance. One user posted a few months ago about an issue with issuing a certificate for aa.edu, which was blocked because it was so similar to aa.com.
The manual review process isn’t that hard, that’s part of my job description where I work. However, the whole point of Let’s Encrypt is the automatic issuance process.
Cool its good to see there is some efforts in blocking domains. What I suggest is lookalike domains though, using spelling errors and the like.
I have successfully used a soundex library in the past to trap soundalike type names.
With respect to the article I linked in my post and ignoring the fact that domain validated domains have almost always been available, how accurate is it?
For example the line…
“Let’s Encrypt issued over around 15,000 security certificates containing the term PayPal for phishing sites”
Is that accurate and if so why did they get through keyword screening?
As far as using Googles safe browsing API that is entirely reactive. My point here is LetsEncrypt should be proactive. LetsEncrypt is a whole lot more than a CA. Its a movement and its goal is to change the mindset of web developers owners and users.
@mnordhoff Sorry for the TOR Reference but in the public’s eye TOR is a network used by criminals. Imagine how that would reflect on a website that used LetsEncrypt as its issuer if that same level of tainting entered the public’s mind?
If that was to happen I for one would stop using LetsEncrypt.
I would say that that goal is to change that mindset in such a way that certificates are completely ubiquitous and totally invisible, so that people say "of course this web site offers me a secure connection—like every other web site in the world, because that's the normal behavior for every web site, every time". Like "of course this web site uses HTML" and "of course this web site uses DNS".
Did you read the article that mnordhoff linked? It explains Let's Encrypt's position on being a gatekeeper for domain names.
Well, it's a lot of guesses in the article. In practice, I don't think it will make a huge difference as it's just as easy to get a single wildcard as it is multiple single domains, and I don't see that a scammer would want to run a bunch of scams on a single parent domain.
My understanding is that the list is mostly for "high risk" domains with different TLDs. It likely wouldn't catch "paypal.example.com," for example.
The more work Let's Encrypt has to handle manually, the more expensive it will be to keep the service running and the harder it will be to keep it up and running, especially at no cost to the end user (and managing payments is expensive too).
One thing to note is that Chrome will be soon dropping the padlock for DV secured websites and reserving the notification for EV, where the actual end entity is verified. The browser UI should change as DV (and OV) certificates only prove that you're talking to the domain you are at and no intermediate is listening in.
You're welcome to pay the fee at a different provider, if you want. The system still exists and those companies are still making decent money.
Ultimately, catching a fraudulent domain should be the responsibility of the domain registrar, not an external service.
Yes I read the linked article. I also spoke about its contents.
We can safely ignore the wildcard part of that article. It does not apply to the article and while it may have attributed to the reason why the article was written apart from that it is not relevant. Those SSL Certs were all issued under the current infrastructure not under the as yet not available wildcard infrastructure.
So my question remains.
A flippant answer which really does not warrant a thought out response.
While I agree with that sentiment. It is an unrealistic goal. Both you and I know that SSL is only as strong as the CA. Hence Symantec's current predicament.
Until and if we ever get a proper WOT the CA will always remain important. My colleague basically had the same argument as you. As I pointed out. The average Joe does not check the CA. But as a web developer I am often asked. If there is doubt about the CA I recommend don't go with it. If LetsEncrypt was tainted I would advise against it as I currently do with anything to do with StartCom et al.
Therefore its not the user I am talking about when I said I wouldn't use it. Its about the website owner.
Lastly if LetsEncrypt was tainted due to the unreasonably high number of phishing sites using it and the likes of Google decided to drop the root CA where is LetsEncrypt then?
If this happened before encrypt by default becomes mainstream then the battle is lost before it has started. and the web will return to where it was. Those who can afford it use SSL and those smaller sites not.
TOR is used by journalist and activists in countries such as China to stop censorship - saying it’s just used by criminals is akin to saying bitcoin is used by criminals only. TOR is an anonymous network designed to prevent government snooping
Keyword blocking is a stupid idea. Sorry to be blunt but you really haven’t thought it through at all. Review the AIM of the ACME protocol and CA Browser Forum Requirements.
It is very unlikely that Let’s Encrypt will not be trusted for issuing certificates to fake sites. The major reason why CAs become untrusted is to do with breaches of baseline requirements. Review why google recently chose to stop trusting symantec certificates.
Overall the CAs job is not to fight Spammers or Fishing sites and the number of false positives and manual review would add to the cost of running an ACME CA.
If you are interested in doing research I suggest you look in to certificate transparency which allows you to review all certificates published by Let’s Encrypt. As you did not request certificates you will not be able to revoke them but it will give you an idea of the difficulty in blocking keywords.
On a last note - limiting a users ability to use words such as visa or paypal in their sub domains doesn’t make sense at all. As long as I have a way of proving that I own that domain that is all that is required to get a certificate. This is true for all CAs not just Let’s Encrypt. In fact I don’t know any CA that does what you describe for domain validation (due to the low cost of DV certificates). I may have valid reasons for using paypal keywords in my domains. I may have paypal portals or visa portals.
also any security expert worth their salt will teach their users to only trust financial sites that use organisational or extended validation certificates (green bar)
I am not sure what your background is but it’s sounding much like the ideas about net neutrality that are being thrown around.
Blaming CAs for doing what they are supposed to do (issue a certificate based on a number of checks) seems like the easy way out. Educating users is the way forward on fighting phishing
Well heck, i had one CA that was unhappy i wanted a certificate for a domain with a "0" in it, because the similar "o" domain was registered -- by a series of parking services that have done nothing with it for years...
Thanks for ignoring all my other replies in that message.
Symantec had a huge failure in controls and was issued certificates against major domains without any kind of approval from the domain owners. Some sub-registration authorities issued EV certificates without being verified to do so. That's a huge failure in the basic trust that signed certificates from a trusted CA will only be issued to a valid owner of a domain. You can read all about the issues here.
StartCom was okay (more or less) until they got caught backdating SHA1 certificates. They also misissued certificates for domains that did not request certificates. They then lied about the relation between WoSign and StartCom, claiming that WoSign didn't own StartCom. It was a huge mess. They blatantly violated Baseline Requirements and then lied about it.
Probably in the same boat as the other CAs that have run into issues. However, I have yet to see any CA get into trouble for issuing a certificate to someone who can control a domain name. The Baseline Requirements don't require Let's Encrypt or any other CA to act as some kind of enforcer as to what DNS names are deserving of a certificate.
The requirements from the Baseline Requirements are that CAs can flag requests as "high risk" by reference to internal criteria including domains at higher risk for fraudulent usage and can incluse the Miller Smiles phishing list, Google Safe Browsing, or domains the CA identifies using internal systems. The CA "shall" develop a procedures to identify these high risk requests and perform additional verification. (Section 4.2.1 of version 1.4.8 of the CAB Forum Baseline Requirements)
If Google decided to start de-trusting any CA that issued certificates used in a phishing campaign, then nearly all commercial CAs would be in serious risk as they all have allowed such certificates to be issued. (Google's Chrome is currently listed as a Platinum sponsor of Let's Encrypt.)
Until the CAB Forum requires CAs to start acting as arbitrators of who is deserving of what certificates, I think the methods used by Let's Encrypt will be fine. In my opinion, it's a decent trade-off of blocking key names while keeping the manual and very expensive verification work down.
I believe the Let’s Encrypt stance on phishing sites & certificates has been adequately communicated (Thanks all!). This discussion has also occurred before and I don’t believe there is any new ground to break in this thread. With the replies tending towards an increasingly hostile style of discourse I’ve elected to close this thread. Thanks for understanding.
