Starting a new Certificate Authority is a time-consuming, expensive, and difficult task. It is also annoying to set up and maintain SSL/TLS certificates. So I completely understand what Let's Encrypt is trying to do. Their goal? Free, functional SSL/TLS certificates that are easy to create, install/deploy, and even keep up-to-date. What's not to like about that? Well, it turns out there are some serious problems with this up-and-coming Certificate Authority (CA). I'm going to list the issues in order of concern:
For the first issue, even though it is all we have got (Update Aug 2017: See the end of this post!), SSL/TLS is fundamentally broken. Let's Encrypt builds upon broken technology and is therefore also fundamentally broken. Instead of fixing the core problem, it merely obscures it. We need to scrap the current mess and start over, using the understanding of what we have learned over the years, not bury broken technology with more broken technology - see the spam in your in-box to learn how well that's worked out for you. Distributed authorities and/or trusted peering, sensible user-presentations (instead of today's scary-looking warning dialog boxes), NOT distributing default roots (we shouldn't even have root certificate stores - it should be root-per-domain), and web of trust are better steps in the right direction and lets people do things with certificates currently not possible (e.g. issuing their own signed cert chains without raising warnings), and possibly redesigning portions of TLS from the ground-up. Ultimately, each individual and company should be able to be their own CA free and clear on the Internet for true Internet security.
For the second issue, Let's Encrypt is a U.S.-based company. They proudly display that information when they say they are a non-profit 501(c)(3) organization. This is a HUGE problem because being a U.S.-based company makes that company susceptible to secret FISA rulings. As a result, a FISA court could order them to turn over their root certificates AND not say a word to the public with severe penalties if they violate the ruling. FISA courts are in cahoots with the NSA, CIA, and FBI and rarely rule in favor of companies or citizens. Until this relationship is resolved amicably (e.g. dissolve/neuter FISA and reset all root certs), it is extremely dangerous to have a Root Certificate Authority operate within U.S. borders.
For the third issue, Let's Encrypt has a huge uphill battle to get added to the root certificate store of every major browser and OS. StartCom, an Israeli-based company which also offers free domain validated certificates today via StartSSL, took years to get through the process to be added to browser and OS root certificate stores, and then even longer to get enough market share to be deemed viable for use. Let's Encrypt has to go through the same process that StartCom did, which means they are about 5 years away from viability. The only positive side to Let's Encrypt is they plan to offer free certificate revocation, whereas StartCom does not. Again, all of this process is required because, as the first issue pointed out, SSL/TLS is broken technology. Instead of fixing SSL/TLS, they opted to adopt it.
For the fourth issue, Mozilla appears to be the primary sponsor. Mozilla makes Firefox and they now basically own Let's Encrypt. It smacks of collusion and that can be quite dangerous. It certainly will be extremely suspicious if Mozilla is the first to adopt the Let's Encrypt root into the root certificate store of Firefox. Browser/OS vendors seem to wait until someone else includes the root first, so this is highly advantageous for Mozilla because they can artificially accelerate the process. If they pull such a stunt, it could result in a lawsuit from other CAs who had to go through the extended process and/or extremely ironic antitrust litigation against Let's Encrypt and Mozilla by the Department of Justice. I say ironic because Mozilla used to be Netscape, who was the source of antitrust litigation against Microsoft when they bundled Internet Explorer with Windows back in the day. Mozilla getting slapped with antitrust litigation would be the most entertaining thing for us tech watchers that could happen - if that happens, grab your popcorn and sit back and enjoy the show!
For the fifth issue, while I understand that a public Root Certificate Authority is expensive to start (estimated initial costs are at least $50,000 USD) and that corporate sponsors have that kind of money, it is rather inappropriate. There needs to be complete, full transparency with regards to the money here. It is extremely important during the setup phase of a CA like this. As far as I can tell, the project is distinctly missing that information. Also their financials aren't readily available online on their website despite being a non-profit organization that claims to increase web friendliness. According to Charity Navigator, they have collected about $100,400 to date, which is on par for starting up a CA.
For the sixth issue, the ACME protocol is a draft specification that I assume will eventually be sent to the IETF. However, it forms the basis of Let's Encrypt. It's a beta protocol and subject to change. As a software developer, I also feel like it is overly and unnecessarily complex as most IETF documents are wont to be. There are a number of issues with the ACME protocol that I feel are vague and therefore open to interpretation. As a counter-example, JSON-Base64 is NOT open to interpretation - it is an extremely clear file format and defers entirely to the TWO nearly identical, official public domain implementations of the library if there is any doubt as to how an implementation MUST implement JSON-Base64. As a result, there is no doubt about how JSON-Base64 works. This, of course, leads me to the next issue...
For the seventh issue, additional clients in other programming languages and libraries to talk ACME may come. Eventually. I have a serious problem with writing a spec before writing an implementation: Real implementations reveal flaws in the spec and updating the spec after it is written is always a low priority. Whereas writing the spec afterwards results in a clean, clear document that can defer to the implementations. Always write general guidelines for the implementation, THEN develop a couple of nearly identical implementations in a couple of different languages, hammer out the bugs, and FINALLY write the final specification based on the implementations BUT defer to the implementations. As usual with IETF related cruft that gets dumped into the wild, the reverse has been done here and this annoying habit results in inevitable problems later on. Again, see the spam in your in-box - you can thank the IETF for that. Tightly-controlled implementations first, specification second.
For the last issue, I give a great, big sigh with gentle facepalm. The authors claim a Windows Powershell solution is coming but that ignores, well, pretty much everything rational. Are they going to support Portable Apache + PHP + Maria DB too? People who develop first for Linux almost always leave cross-platform development as an afterthought and up to other people to resolve because they are too lazy to do the right thing. It's a shameful practice and there should be great amounts of public humiliation heaped on anyone who does it. Windows still dominates the desktop market share, which is where local corporate development boxes live. To choose to ignore the platform users actually work on is just plain stupid. The more critical issue is that supporting only web server software is going to result in headaches when people want it to work for EVERY piece of SSL-enabled software (e-mail servers, chat servers, etc) and supporting just a few products has opened a can of worms they can't close. The Let's Encrypt developers will forever be running around getting nothing of value done.
At the end of the day, Let's Encrypt solves nothing and creates a lot of unnecessary additional problems. It's also a long way off from being viable and there are plenty of legal landmines they have to navigate with extreme care. In short, I'd much rather see a complete replacement for the disaster that is SSL/TLS. Also, people need to stop getting so excited about Let's Encrypt, which simply builds upon fundamentally broken technology.
Update Aug 2017: Since writing this post, I discovered DNSSEC DANE TLSA. Specifically, "Certificate Usage 3", which allows for running a private CA that is automatically trusted publicly since the certificate is protected by DNSSEC. While I consider the Internet Engineering Task Force (IETF) to be generally inept (e.g. not replacing SMTP and thus allowing spam to reign in our in-boxes, MIME for its general awfulness, etc), DANE TLSA solves the problem of public CAs once and for all. The only problem is this: No web browser supports it even though people have been trying to get browser vendors to implement DANE TLSA for the last six years! So, instead of integrating DANE TLSA support into Firefox, Mozilla and the EFF fund Let's Encrypt - an approximately $1.1 million USD per year operation! Mozilla developers even went out of their way to close the ticket with a WONTFIX. They only reopened the ticket AFTER supplying a paltry $20K USD in a grant project to a third-party, which hasn't seen any results so far. Frankly, the behavior of Mozilla is utterly appalling regarding this critical security issue that Netscape created and Mozilla is now propagating. Has no one learned ANYTHING in the last 20 years?!
Some people will note that I use Let's Encrypt certificates on my websites. I switched only because there isn't another free option. Mind you, I have NEVER trusted ANY data encrypted with certificates signed by ANY public CA. After all, you've got a root certificate from China(!) in your web browser's root trust store and so we might as well not even have SSL/TLS. Since website security doesn't actually matter for the vast majority of users, I don't care which public CA I use as long as they are domain-validated certs signed by something the browser trusts. Until I can run my own private CA that I control under DANE TLSA that is supported by all major web browsers, then this is a security vulnerability in our infrastructure that can't be resolved and I'll not trust any data sent/received. Don't fool yourself: The U.S. government doesn't back down from strict crypto export law and purchase expensive hardware appliances like these unless they are useful. The only way that such appliances are useful is if SSL/TLS has been totally compromised somewhere fundamental - e.g. root CA private keying material handed over via FISA court order with gag order directives (and that's just one creative way I can come up with) - with hundreds of public root CAs to choose from and your web browser trusts ALL of them, you can't legitimately tell me that absolutely none of them have been compromised.
- Doesn't solve the problems of storing roots in the browser or global trust issues.
- A U.S.-based company.
- Browser support/acceptance.
- Sponsored by Mozilla.
- Other, publicly traded, corporate sponsors.
- A brand-new, relatively untested, and complex issuance protocol (ACME).
- Limited clients (Python bindings only) and no libraries.
- Linux only.
For the first issue, even though it is all we have got (Update Aug 2017: See the end of this post!), SSL/TLS is fundamentally broken. Let's Encrypt builds upon broken technology and is therefore also fundamentally broken. Instead of fixing the core problem, it merely obscures it. We need to scrap the current mess and start over, using the understanding of what we have learned over the years, not bury broken technology with more broken technology - see the spam in your in-box to learn how well that's worked out for you. Distributed authorities and/or trusted peering, sensible user-presentations (instead of today's scary-looking warning dialog boxes), NOT distributing default roots (we shouldn't even have root certificate stores - it should be root-per-domain), and web of trust are better steps in the right direction and lets people do things with certificates currently not possible (e.g. issuing their own signed cert chains without raising warnings), and possibly redesigning portions of TLS from the ground-up. Ultimately, each individual and company should be able to be their own CA free and clear on the Internet for true Internet security.
For the second issue, Let's Encrypt is a U.S.-based company. They proudly display that information when they say they are a non-profit 501(c)(3) organization. This is a HUGE problem because being a U.S.-based company makes that company susceptible to secret FISA rulings. As a result, a FISA court could order them to turn over their root certificates AND not say a word to the public with severe penalties if they violate the ruling. FISA courts are in cahoots with the NSA, CIA, and FBI and rarely rule in favor of companies or citizens. Until this relationship is resolved amicably (e.g. dissolve/neuter FISA and reset all root certs), it is extremely dangerous to have a Root Certificate Authority operate within U.S. borders.
For the third issue, Let's Encrypt has a huge uphill battle to get added to the root certificate store of every major browser and OS. StartCom, an Israeli-based company which also offers free domain validated certificates today via StartSSL, took years to get through the process to be added to browser and OS root certificate stores, and then even longer to get enough market share to be deemed viable for use. Let's Encrypt has to go through the same process that StartCom did, which means they are about 5 years away from viability. The only positive side to Let's Encrypt is they plan to offer free certificate revocation, whereas StartCom does not. Again, all of this process is required because, as the first issue pointed out, SSL/TLS is broken technology. Instead of fixing SSL/TLS, they opted to adopt it.
For the fourth issue, Mozilla appears to be the primary sponsor. Mozilla makes Firefox and they now basically own Let's Encrypt. It smacks of collusion and that can be quite dangerous. It certainly will be extremely suspicious if Mozilla is the first to adopt the Let's Encrypt root into the root certificate store of Firefox. Browser/OS vendors seem to wait until someone else includes the root first, so this is highly advantageous for Mozilla because they can artificially accelerate the process. If they pull such a stunt, it could result in a lawsuit from other CAs who had to go through the extended process and/or extremely ironic antitrust litigation against Let's Encrypt and Mozilla by the Department of Justice. I say ironic because Mozilla used to be Netscape, who was the source of antitrust litigation against Microsoft when they bundled Internet Explorer with Windows back in the day. Mozilla getting slapped with antitrust litigation would be the most entertaining thing for us tech watchers that could happen - if that happens, grab your popcorn and sit back and enjoy the show!
For the fifth issue, while I understand that a public Root Certificate Authority is expensive to start (estimated initial costs are at least $50,000 USD) and that corporate sponsors have that kind of money, it is rather inappropriate. There needs to be complete, full transparency with regards to the money here. It is extremely important during the setup phase of a CA like this. As far as I can tell, the project is distinctly missing that information. Also their financials aren't readily available online on their website despite being a non-profit organization that claims to increase web friendliness. According to Charity Navigator, they have collected about $100,400 to date, which is on par for starting up a CA.
For the sixth issue, the ACME protocol is a draft specification that I assume will eventually be sent to the IETF. However, it forms the basis of Let's Encrypt. It's a beta protocol and subject to change. As a software developer, I also feel like it is overly and unnecessarily complex as most IETF documents are wont to be. There are a number of issues with the ACME protocol that I feel are vague and therefore open to interpretation. As a counter-example, JSON-Base64 is NOT open to interpretation - it is an extremely clear file format and defers entirely to the TWO nearly identical, official public domain implementations of the library if there is any doubt as to how an implementation MUST implement JSON-Base64. As a result, there is no doubt about how JSON-Base64 works. This, of course, leads me to the next issue...
For the seventh issue, additional clients in other programming languages and libraries to talk ACME may come. Eventually. I have a serious problem with writing a spec before writing an implementation: Real implementations reveal flaws in the spec and updating the spec after it is written is always a low priority. Whereas writing the spec afterwards results in a clean, clear document that can defer to the implementations. Always write general guidelines for the implementation, THEN develop a couple of nearly identical implementations in a couple of different languages, hammer out the bugs, and FINALLY write the final specification based on the implementations BUT defer to the implementations. As usual with IETF related cruft that gets dumped into the wild, the reverse has been done here and this annoying habit results in inevitable problems later on. Again, see the spam in your in-box - you can thank the IETF for that. Tightly-controlled implementations first, specification second.
For the last issue, I give a great, big sigh with gentle facepalm. The authors claim a Windows Powershell solution is coming but that ignores, well, pretty much everything rational. Are they going to support Portable Apache + PHP + Maria DB too? People who develop first for Linux almost always leave cross-platform development as an afterthought and up to other people to resolve because they are too lazy to do the right thing. It's a shameful practice and there should be great amounts of public humiliation heaped on anyone who does it. Windows still dominates the desktop market share, which is where local corporate development boxes live. To choose to ignore the platform users actually work on is just plain stupid. The more critical issue is that supporting only web server software is going to result in headaches when people want it to work for EVERY piece of SSL-enabled software (e-mail servers, chat servers, etc) and supporting just a few products has opened a can of worms they can't close. The Let's Encrypt developers will forever be running around getting nothing of value done.
At the end of the day, Let's Encrypt solves nothing and creates a lot of unnecessary additional problems. It's also a long way off from being viable and there are plenty of legal landmines they have to navigate with extreme care. In short, I'd much rather see a complete replacement for the disaster that is SSL/TLS. Also, people need to stop getting so excited about Let's Encrypt, which simply builds upon fundamentally broken technology.
Update Aug 2017: Since writing this post, I discovered DNSSEC DANE TLSA. Specifically, "Certificate Usage 3", which allows for running a private CA that is automatically trusted publicly since the certificate is protected by DNSSEC. While I consider the Internet Engineering Task Force (IETF) to be generally inept (e.g. not replacing SMTP and thus allowing spam to reign in our in-boxes, MIME for its general awfulness, etc), DANE TLSA solves the problem of public CAs once and for all. The only problem is this: No web browser supports it even though people have been trying to get browser vendors to implement DANE TLSA for the last six years! So, instead of integrating DANE TLSA support into Firefox, Mozilla and the EFF fund Let's Encrypt - an approximately $1.1 million USD per year operation! Mozilla developers even went out of their way to close the ticket with a WONTFIX. They only reopened the ticket AFTER supplying a paltry $20K USD in a grant project to a third-party, which hasn't seen any results so far. Frankly, the behavior of Mozilla is utterly appalling regarding this critical security issue that Netscape created and Mozilla is now propagating. Has no one learned ANYTHING in the last 20 years?!
Some people will note that I use Let's Encrypt certificates on my websites. I switched only because there isn't another free option. Mind you, I have NEVER trusted ANY data encrypted with certificates signed by ANY public CA. After all, you've got a root certificate from China(!) in your web browser's root trust store and so we might as well not even have SSL/TLS. Since website security doesn't actually matter for the vast majority of users, I don't care which public CA I use as long as they are domain-validated certs signed by something the browser trusts. Until I can run my own private CA that I control under DANE TLSA that is supported by all major web browsers, then this is a security vulnerability in our infrastructure that can't be resolved and I'll not trust any data sent/received. Don't fool yourself: The U.S. government doesn't back down from strict crypto export law and purchase expensive hardware appliances like these unless they are useful. The only way that such appliances are useful is if SSL/TLS has been totally compromised somewhere fundamental - e.g. root CA private keying material handed over via FISA court order with gag order directives (and that's just one creative way I can come up with) - with hundreds of public root CAs to choose from and your web browser trusts ALL of them, you can't legitimately tell me that absolutely none of them have been compromised.
Comments
Post a Comment