I don't think anyone can disagree with the tremendous amount of progress that has been made in deploying web encryption over the last year or so and Let's Encrypt have played a monumental part in that. Recently though I've seen some negative comments about the CA and some concerns over how they operate.
Let's Encrypt
If you don't know of Let's Encrypt they are a free CA setup to issue certificates for quite literally anyone that wants them. Any website on the web can now setup HTTPS and the cost barrier of buying a certificate has been removed. They also completely automate issuance of certificates so a lot of the technical and maintenance overhead is removed too. I've talked about them a lot and use them across all of my online services except report-uri.io (because they don't do wildcard certs). You can check out their site and should seriously consider donating if you use them or value encryption on the web. My recent analysis of the Top 1 Million sites on the web, Alexa Top 1 Million Analysis - Feb 2017, showed that not only has the adoption of HTTPS continued to soar, but Let's Encrypt have played an enormous role.
Enabling the bad guys
The problem with making something freely available to anyone that wants to use it, something like free certificates, is that in short order you can be sure that there will be some unsavoury characters wanting to use it. As you'd expect this was exactly the case and the bad guys very quickly started encrypting their websites too. This is a testament to just how easy and painless Let's Encrypt have made the process of obtaining certificates. This problem has been discussed in the wider community and I welcome constructive and open discussions around these problems, but there has also been a little less constructive pointing of fingers too. One of the very well reasoned arguments put forward came from Eric Lawrence in his blog Certified Malice. In it he outlines how your typical PayPal phishing domain now has HTTPS setup with certificates provided by Let's Encrypt and how that makes them look in the browser. You should take time to read the article as it sets out the problem nicely and has a few ideas on what we can do to try and solve it. There's also a really good post from Josh Aas at Let's Encrypt titled The CA's Role in Fighting Phishing and Malware which explains their stance and how they currently operate. I think a lot of the problem boils down to this though.
Security indicators are overloaded
If we take the security indicator in any browser and think about what it actually means, at a core, technical level, then this whole conversation doesn't really need to take place. The "Secure" indicator means that the browser has connected to a server which has presented a valid certificate for the domain name we were connecting to that was issued by a CA that the browser trusts and an encrypted connection has been established. That's it. That all the green HTTPS in the address bar means. The problem is that many people believe that it means a lot more than that and that it affords the site some kind of credibility. Perhaps this is poor education on our part in the industry or that historically only genuine websites could afford and would spend money on setting up HTTPS, but the Secure indicator means nothing more than that, a secure connection.
source: Certified Malice
The two sites above are a great example. On the left is the genuine PayPal site (let's ignore EV for now) and on the right is a phishing site using www.paypal.com as subdomains, you can just about make out the hyphen at the end of .com there. Now, I do think that the window size has been made pixel perfect here to make this look as convincing as possible, but the point still stands that this is a very convincing phishing page. The argument here being that the Secure indicator gives the phishing page more credibility shows where we've gone wrong.
Solving the problem
One of the common suggestions here is that the CA, Let's Encrypt in this case, should be doing something about it. They should be actively trying to prevent the issuance of certificates to bad actors. I do see the case for that, and I understand what the goal here is, but it makes me really uncomfortable. On a purely technical level this should be completely irrelevant. A CA issues a certificate to someone who can prove that they own a given domain name, there's no other criteria. The other aspect here that concerns me is that in our push to a 100% encrypted web, this effectively makes the CA a powerful censor for content that can go online. Who decides what the criteria for issuing a certificate is? The CA? Some governing body? One idea put forward was that the CA should check for substring matches for common phishing domains like paypal in the certificate being requested. So PayPal now own the string paypal and no one else can get a certificate with that substring in?! Furthermore all of these measures could be circumvented with a wildcard certificate. If I get *.secure-login.com then I'm quite free to create paypal.secure-login.com without hitting any problems.
To me it feels like the argument we've seen a lot in the UK recently about encrypted messenger applications like Signal. These apps provide end-to-end encrypted communications that no 3rd party can access. The app is free and widely available so that as many people as possible can use it. With this comes the unfortunate situation that there are undoubtedly some unpleasant characters using this to communicate about unsavoury things. If we want encryption to be freely available to all then that includes the fraction of a percent of people who will use it in ways we'd rather not see. I don't think it's for Signal, or Let's Encrypt, to decide who should have access to encryption.
Other solutions
I'm a big fan of the Google Safe Browsing project where you can report phishing sites that result in them being blocked by the browser. The problem with that approach is the delay between the phishing site being put online and someone reporting it to be blocked, it's usually still enough time for some harm to occur. Another way to try and combat this will be the rise of Certificate Transparency, so brand owners can monitor for certificates that may be used against their users and then seek to have them revoked. Of course, that's riddled with problems around revocation but we are working on that with OCSP Expect-Staple and OCSP Must-Staple. The truth is it's a tough issue to crack but I think we need to be careful about where and how we resolve it. If we want encryption to be freely available to everyone on the web, that's always going to include the bad guys.