Also a wrong one. LE could impersonate your site, but it will be visible via Certificate Transparency. If you have opted out of getting a cert entirely, then any CA will be able to do this.
I used “impersonate” as a shorthand for “issue a valid X.509 certificate for your site”, but yeah - it wouldn’t be useful unless LE could get on-path somehow, e.g. MITM or DNS
they would need to MITM let’s encrypt’s proof mechanisms (the machines that do the HTTP or DNS challenges)
then of course they’d need to MITM the person they’re attacking too… just seems infeasible. on the other hand if you lose control of DNS all bets are off
Meaning that if you want to avoid USA based CAs, your only option is Buypass. If you want to obtain certificates through other means than ACME, I think ZeroSSL is the only option (I know the other two don’t allow it), but they have encumbered this feature with a reCaptcha tracker, so I’ve opted not to try it.
This really feels like the author has a series of (not so good IMO) complaints about WebPKI and then decides that since it isn’t perfect for their situation, throw it all away rather than accepting even incremental improvements.
We do not need to have perfect security, just slightly better than yesterday’s.
Also, the reasons why the earlier free certificate authorities were never trusted was because they were awful at security. StartSSL had major problems that were only revealed by forced audits to continue to be trusted. Before they were accepted though, it was completely trusted by a huge swath of software. The security requirements that browsers and other maintainers mandate to be part of their trusted root programs meant that these free programs didn’t measure up. (Good or bad thing? I think net good, but it does limit the CA industry to only those that can support the ongoing financial burden. That generally precludes those without money from participating.)
If you want a free certificate that is not issued by a US firm, check out ZeroSSL. They are an Austrian company, so now you then have EU’s rules to deal with instead.
(NB: I’m a former Let’s Encrypt employee. I do have a bias here.)
I’ll ignore the rant which is mostly “I want my techno-utopia and ignore we live in a society”, but just wanted to raise some things which are just wrong:
What people want for? Encryption? Then enable it by pointing to https://!
Also privacy, but both have next to no guarantees, with a self-signed certificate because anyone can replace it if they can interact with the traffic on the wire.
Possibly we use some overlay network like Yggdrasil, where TLS is just pointless.
This is mixing up network layers. Whether the routing to your network is encrypted is separate from whether you’re authenticating your service endpoint. Those may be handled on the same server next to each other, but that’s the closest they get.
Some browsers used OCSP, that literally leaks your intentions about visiting different entities to third-parties in real time.
Browser-side OCSP querying is dead. Turn on the must-staple option you can handle it completely server-side with no information leak.
and now we expect them to regularly synchronize CT’s Merkle Trees from various independent sources?
CT is not for the end user. It’s for audits and holding the CA accountable by parties which care about the trust network.
Yggdrasil does “authenticate” the endpoint, that’s a feature of the overlay it provides: the public key is derived from the IPv6 address of the server, so if the endpoint can decrypt the traffic, it means you reached the correct server.
This doesn’t account for virtualhosts though, so it’s more limiting than HTTPS.
I mean endpoint as in service endpoint, not as in IP. But even for IPs, yggdrasil allows you to advertise a prefix and authenticate it at the router. What actually happens within that prefix, or on specific ports of a host is outside of yggdrasil’s authority.
So the network auth loses visibility of ports, hostnames, and potentially actual machines handling the requests. We tried to go hard on network separation for security some time ago - there are good reasons we’re pushing for zero-trust these days instead
I believe you have that backwards, the IPv6 address is derived from the public key not the other way around.
Depending on how you use it, it only derives 64 bits of the IPv6 address (since it assigns you a /64), or I suppose actually only 57 bits (because all IP’s in the network share the first 7 bits) - which probably isn’t enough to provide secure authentication.
There’s not much you can do about this. If you want to support SLAAC, then you need to hand out /64s for a LAN. The prefix takes out the remaining 7bits so you have 57 bits. Given an equal choice (which I realize isn’t the case here), I’d much rather have IP-level encryption than the complicated handshake/dance of HTTPS.
I think a lot of the issues that commenters here and on HN have with the author’s viewpoint can be more easily explained by the author being a (patriotic) citizen of the Russian Federation. The “threat model” is different than from a website publisher in the West.
But do you remember that any of CA authorities included in OS can MitM my domains anyway (by definition)? Well, partly you can prevent that for some software by using CAA DNS records, where you explicitly tell which CA authorities are authorized to issue certificates for given domains. Specifying LE in CAA means that I authorize noone to issue certificates for my domains, except for US-based forces. That is something I will never do, being the citizen of completely independent jurisdiction. I am not a traitor.
The implicit assumption here is: you have a threat model that includes nation-state actors and, specifically, the US as a nation-state actor.
Here’s the brutally honest solution to this problem: Give up. If the US government decides that you are a person of interest, you have much worse problems than their ability to MITM your web site. If the NSA is attacking your client devices, for example, then they are going to be able to compromise your infrastructure. If you have another nation state on your side then you may be able to find some hardened infrastructure but otherwise LE is not likely to be the weakest link in your chain.
LE, CAA records, and DNSSEC between them give you solid protection against passive adversaries and restrict the set of people that can do active MITM attacks significantly. It’s not perfect but nothing is in cybersecurity. It at least restricts the set of people who can attack your connections to:
People that can compromise either endpoint, including compromising the device(s) that you log into your server with.
People with access to the LE signing key.
People who find a weakness in the TLS implementation that you or a client is using.
Of the three, the people with access to the LE signing key are probably the ones I would worry about the least. Especially since any attempt to do this will likely show up in the CT log: either they won’t put the certificates in there (if Chrome sees a cert issued by LE that isn’t in the CT log, that’s grounds for LE to be removed as a trusted root, so that’s a very high risk for LE), or they will any you have an auditable log documenting the attack. Again, this is assuming a nation-state adversary that uses legal or extra-legal means to compromise LE.
It’s likely to be more of a problem for availability but if the US decides that you’re a person of interest then they have far easier ways of taking your site offline. A DDoS from a botnet is harder to attribute accurately than a LE-based compromise. So is bribing someone in the datacenter that hosts your server to connect a USB stick full of malware to your machine (or, if it’s a VM, just adding it directly to your disk).
TL;DR: If the kinds of attackers who can attack you via LE are in your threat model and attacking you via LE is their easiest path, then you must have amazing security already. For those of us who don’t work for intelligence agencies, this is an incredibly misplaced priority.
Oh, and if you think having something controlled in a foreign jurisdiction in your TCB makes you a traitor, then I have news for you: You are a traitor. It is pretty much impossible to be connected to the Internet and not have at least one part of your hardware / software supply chain that comes from a jurisdiction that isn’t your own, whatever country you’re from.
I think the threat isn’t the US government taking interest in him specifically, it’s the US and its allies using their political and economic clout to deny access to services to people living in certain jurisdictions, which has happened many times before.
Whatever your political beliefs, if you happen to live in one of the countries that’s on the state department’s list of bad actors, you have to anticipate trouble, and I can imagine a certain degree of cynicism towards a “safe” authentication infrastructure that can be taken away at a moments’ notice.
I think the threat isn’t the US government taking interest in him specifically, it’s the US and its allies using their political and economic clout to deny access to services to people living in certain jurisdictions, which has happened many times before.
If they want to do this, then there are much easier ways for them to do so than attacking Let’s Encrypt. Unless he has deep pockets or is behind someone like CloudFlare, a DDoS on his systems is by far the easiest attack. If they don’t care about attribution then leaning on allies to tamper with routes, block DNS entries, and so on are all much easier than compromising Let’s Encrypt. If you have mitigations against all of these things, then start worrying about Let’s Encrypt.
This is not how US trade embargoes have worked in the past, as you can see from GitHub’s adventures with users from Iran and the Crimea. The State department doesn’t order a DDOS. But it threatens companies with severe repercussions if they continue trading with these areas. And suddenly your Github account is blocked, and you find that Let’s Encrypt no longer wants to renew your certificates.
Why would you make your operations dependent on an entity that might suspend your service at a moment’s notice?
I actually think this is extraordinarily bad advice, especially for people not strongly connected to the US (edit: I say this with the greatest respect for your opinions and I’m a fan of your comments here on the red site). The US (and other nation state actors) even though well resourced do not operate without constraints.
The purpose of security is to raise the cost of an attack beyond the level at which the actors in your threat model actually want to do it.
If we assume that Let’s Encrypt (LE) is very much in the pocket of a threat actor with the abilities of a major government, and that actor is not the Russian Federation or one of their buddies, and our principals are roughly speaking SME-level resourced actors, with a normal relationship to the Russian state; then -
LE/our threat actor have at least some capabilities that can be cheaply deployed in the sense that it consumes very little human resources and has very little opportunity cost. The question is really what those capabilities are, what costs the threat actor is willing to bear, and which threat actors you’re worried about.
For example, our threat actor if they are the US probably has the ability on some time scale to get a certificate fake signed by almost any CA at a certain level of effort and cost.
Our law abiding Muscovite businessman is much more exposed to the Russian Federation’s capabilities than those of the US, so choosing a Russia-based CA probably doesn’t increase their exposure to moderately motivated Russian state action; but it might increase their exposure to local criminal action at the risk of increasing their exposure to US state and US-based actors. Which is worse is for them to decide.
Edit: Also, LE have deep visibility into what exists even on private networks if those machines are directly using LE; and visibility into common control.
Edit: to be clear even if we assume Let’s Encrypt is owned by the NSA it’s not necessarily a bad idea to use it in place of no encryption.
LE/our threat actor have at least some capabilities that can be cheaply deployed in the sense that it consumes very little human resources and has very little opportunity cost
There are three things LE can do:
Refuse to respond to ACME requests for you and prevent you from getting a certificate.
Issue a false cert and not put it in the CT log.
Issue a false cert and put it in the CT log.
The first of these is fairly low cost but even with a differently trusted CA any adversary that can attack the route between you and your CA can do this. If Let’s Encrypt is seen to be doing this then there’s a big risk to their reputation if they’d be caught.
The second of these is very dangerous for Let’s Encrypt. Anyone who is attacked will have (at least transiently) a copy of the certificate signed by Let’s Encrypt. Anyone who records this cert can present it as evidence of tampering. The existence of this certificate is sufficient to have the Let’s Encrypt root certificate being removed from the trusted set (issuing a cert without adding it to the CT log is sufficient grounds for this). Doing this even once is an existential risk to Let’s Encrypt.
The third is probably more dangerous for Let’s Encrypt. There’s a public log of the certs that are signed and if they’ve signed a cert for your domain that wasn’t yours then it’s easy to see. Again, if you can demonstrate that a cert was issued by someone else then this can cause LE to be dropped from the trusted root set. Again, this is an existential risk to Let’s Encrypt.
So, of the three things that a malicious Let’s Encrypt can do to you, the only one that wouldn’t directly risk LE’s continued existence is limited to a DoS. If you’re doing weekly renewals of your cert then you get three weeks notice that this is happening. That should be sufficient to move to an alternative provider. Again, if you’re worried about denial of service then you need to think about all of the other ways that someone else could impact availability and there are many of these. You can purchase an off-the-shelf botnet that will run a DDoS that can take out most cheap VPS for a few dollars.
I think that’s fair and disposes of low cost attacks. I still don’t think it means people shouldn’t bother including nation state actors (even the US) in their threat model.
I have had the growing feeling that the “encrypt everything” push of the past few years has done nothing to improve safety for the average human being, while increasing centralization and making censorship easier than ever. How long before the next “huh, half the internet is down again” is caused not by a DDoS or a borked configuration at AWS but by a certificate revocation which everyone will claim is accidental, but which will just so happen to disrupt a major political rally in Western Morgravia? How long before I have to have my ID on file before any CA will talk to me?
It feels to me like stargrave’s perspective is internally inconsistent, with bias accounting for those inconsistencies. Overall I don’t agree with what he wrote.
But I have had some similar thoughts and feelings regarding x.509 and ACME / Let’s Encrypt. I once attended a talk by one of the main Let’s Encrypt contributors, I think it was Matt Holt maybe?
At the end I tried to ask them a question, if they had any plans to enhance the security of ACME versus adversaries who can leverage their position on the network to issue fraudulent certificates. As an example, say I could send my domain name and a public key to them, and then they store that in a database with a 1 week or 1 month TTL. Until it expires, they refuse any certificate issuance request which is not signed by the corresponding private key which I hold. Such a thing could allow me to create & continuously renew my own “certificate issuance key” which could help prevent fraudulent certificate issuance on my domain by a cloud service provider, ISP, or DNS authority.
But when I explained this idea, either I didn’t explain it very well, or they just didn’t understand why anyone would want that; why anyone would worry about central infrastructure operators leveraging their position on the network to misbehave, why anyone would want to try to defend against that.
If they did have such a feature, combined with a CAA record saying that Let’s Encrypt is the only ACME CA allowed to sign certificates for my domain, then it should be “sealed” right? There’s no way for a fraudulent certificate to be issued as long as everybody plays by the rules. Non-LE ACME CAs wont issue because of the CAA record, and LE themselves wont issue because the fraudster doesn’t have the required private key.
Right. As long as everybody plays by the rules. But that’s just the thing, and this is a problem that pre-dates Let’s Encrypt and ACME CAs: x.509 is ultimately an authority based system like the banking / financial system. Your account can be frozen. Money can be printed. Ultimately someone else is in charge and there’s nothing you can do about that. Certificate Transparency can help, but there’s no process I’m aware of which ensures that everyone follows the certificate transparency rules as well.
This problem is pretty much the same thing as Zooko’s triangle. I know stargrave doesn’t like cryptocurrency stuff, but as far as I know, cryptocurrency is the first solution we ever had for Zookos Triangle where we can have all 3 things, decentralized, human-meaningful, and secure. Namecoin is a great technical example of that, and the Namecoin client software / wallet software has really come a long way in the past couple of years.
Everyone loves to hate cryptocurrency and they kinda have a point, no one has ever found a truly satisfying alternative to proof-of-work mining, and proof-of-work mining is headed for disaster if cryptocurrency continues to become more and more valuable. Trading energy for money, and the money keeps getting more and more valuable, hmm, what could go wrong?
But I still really hope that in the future we get to keep our Zookos Triangle solution. Even if it’s not something that everyone gets pre-installed on their phone, I think the world can benefit from a system that truly guarantees “no lying/cheating” and treats everyone the same regardless of how much money or power they have.
You’re mostly right on proof of work sort of solving zooko’s triangle. That said in fact we see that Bitcoin and ethereum mining are centralized enough to support hard forks; and the cost of proof of work is massively beyond the reasonable benefits.
I’m sorry, but this is stupid. The reasoning you give doesn’t make going TLS’less better. Serving LE TLS from a shared box is still much better than not using TLS at all, for a bunch of reasons.
E.g., now connections to you are open for attack from all points it goes through, rather than just a single (?) point. You can’t assume ISPs will just take care of link security.
I think the author is just forgetting why LE took off. Companies were exploiting their power and charging high prices and generally made certificates annoying to get. HTTPS may not be perfect, but now it is easy to setup and provides a lot more protection than before. I moved to LE as a move away from a feeling I was dealing with exploitative companies for my certs.
This seems like a very baseless accusation.
Also a wrong one. LE could impersonate your site, but it will be visible via Certificate Transparency. If you have opted out of getting a cert entirely, then any CA will be able to do this.
How could LE impersonate your site without control over DNS? Or are you assuming a bad actor that circumvents the challenges
I used “impersonate” as a shorthand for “issue a valid X.509 certificate for your site”, but yeah - it wouldn’t be useful unless LE could get on-path somehow, e.g. MITM or DNS
is it MITM or DNS or MITM AND DNS?
they would need to MITM let’s encrypt’s proof mechanisms (the machines that do the HTTP or DNS challenges)
then of course they’d need to MITM the person they’re attacking too… just seems infeasible. on the other hand if you lose control of DNS all bets are off
Especially since there are at least 3 or 4 free/gratis certificate providers using the ACME protocols.
Could you point to one or two? Are they broadly supported by major browser vendors?
As of now, I know of:
Meaning that if you want to avoid USA based CAs, your only option is Buypass. If you want to obtain certificates through other means than ACME, I think ZeroSSL is the only option (I know the other two don’t allow it), but they have encumbered this feature with a reCaptcha tracker, so I’ve opted not to try it.
Thanks!
This really feels like the author has a series of (not so good IMO) complaints about WebPKI and then decides that since it isn’t perfect for their situation, throw it all away rather than accepting even incremental improvements.
We do not need to have perfect security, just slightly better than yesterday’s.
Also, the reasons why the earlier free certificate authorities were never trusted was because they were awful at security. StartSSL had major problems that were only revealed by forced audits to continue to be trusted. Before they were accepted though, it was completely trusted by a huge swath of software. The security requirements that browsers and other maintainers mandate to be part of their trusted root programs meant that these free programs didn’t measure up. (Good or bad thing? I think net good, but it does limit the CA industry to only those that can support the ongoing financial burden. That generally precludes those without money from participating.)
If you want a free certificate that is not issued by a US firm, check out ZeroSSL. They are an Austrian company, so now you then have EU’s rules to deal with instead.
(NB: I’m a former Let’s Encrypt employee. I do have a bias here.)
I’ll ignore the rant which is mostly “I want my techno-utopia and ignore we live in a society”, but just wanted to raise some things which are just wrong:
Also privacy, but both have next to no guarantees, with a self-signed certificate because anyone can replace it if they can interact with the traffic on the wire.
This is mixing up network layers. Whether the routing to your network is encrypted is separate from whether you’re authenticating your service endpoint. Those may be handled on the same server next to each other, but that’s the closest they get.
Browser-side OCSP querying is dead. Turn on the must-staple option you can handle it completely server-side with no information leak.
CT is not for the end user. It’s for audits and holding the CA accountable by parties which care about the trust network.
Yggdrasil does “authenticate” the endpoint, that’s a feature of the overlay it provides: the public key is derived from the IPv6 address of the server, so if the endpoint can decrypt the traffic, it means you reached the correct server. This doesn’t account for virtualhosts though, so it’s more limiting than HTTPS.
I mean endpoint as in service endpoint, not as in IP. But even for IPs, yggdrasil allows you to advertise a prefix and authenticate it at the router. What actually happens within that prefix, or on specific ports of a host is outside of yggdrasil’s authority.
So the network auth loses visibility of ports, hostnames, and potentially actual machines handling the requests. We tried to go hard on network separation for security some time ago - there are good reasons we’re pushing for zero-trust these days instead
I believe you have that backwards, the IPv6 address is derived from the public key not the other way around.
Depending on how you use it, it only derives 64 bits of the IPv6 address (since it assigns you a /64), or I suppose actually only 57 bits (because all IP’s in the network share the first 7 bits) - which probably isn’t enough to provide secure authentication.
There’s not much you can do about this. If you want to support SLAAC, then you need to hand out /64s for a LAN. The prefix takes out the remaining 7bits so you have 57 bits. Given an equal choice (which I realize isn’t the case here), I’d much rather have IP-level encryption than the complicated handshake/dance of HTTPS.
I think a lot of the issues that commenters here and on HN have with the author’s viewpoint can be more easily explained by the author being a (patriotic) citizen of the Russian Federation. The “threat model” is different than from a website publisher in the West.
This comes across here:
The implicit assumption here is: you have a threat model that includes nation-state actors and, specifically, the US as a nation-state actor.
Here’s the brutally honest solution to this problem: Give up. If the US government decides that you are a person of interest, you have much worse problems than their ability to MITM your web site. If the NSA is attacking your client devices, for example, then they are going to be able to compromise your infrastructure. If you have another nation state on your side then you may be able to find some hardened infrastructure but otherwise LE is not likely to be the weakest link in your chain.
LE, CAA records, and DNSSEC between them give you solid protection against passive adversaries and restrict the set of people that can do active MITM attacks significantly. It’s not perfect but nothing is in cybersecurity. It at least restricts the set of people who can attack your connections to:
Of the three, the people with access to the LE signing key are probably the ones I would worry about the least. Especially since any attempt to do this will likely show up in the CT log: either they won’t put the certificates in there (if Chrome sees a cert issued by LE that isn’t in the CT log, that’s grounds for LE to be removed as a trusted root, so that’s a very high risk for LE), or they will any you have an auditable log documenting the attack. Again, this is assuming a nation-state adversary that uses legal or extra-legal means to compromise LE.
It’s likely to be more of a problem for availability but if the US decides that you’re a person of interest then they have far easier ways of taking your site offline. A DDoS from a botnet is harder to attribute accurately than a LE-based compromise. So is bribing someone in the datacenter that hosts your server to connect a USB stick full of malware to your machine (or, if it’s a VM, just adding it directly to your disk).
TL;DR: If the kinds of attackers who can attack you via LE are in your threat model and attacking you via LE is their easiest path, then you must have amazing security already. For those of us who don’t work for intelligence agencies, this is an incredibly misplaced priority.
Oh, and if you think having something controlled in a foreign jurisdiction in your TCB makes you a traitor, then I have news for you: You are a traitor. It is pretty much impossible to be connected to the Internet and not have at least one part of your hardware / software supply chain that comes from a jurisdiction that isn’t your own, whatever country you’re from.
I think the threat isn’t the US government taking interest in him specifically, it’s the US and its allies using their political and economic clout to deny access to services to people living in certain jurisdictions, which has happened many times before.
Whatever your political beliefs, if you happen to live in one of the countries that’s on the state department’s list of bad actors, you have to anticipate trouble, and I can imagine a certain degree of cynicism towards a “safe” authentication infrastructure that can be taken away at a moments’ notice.
If they want to do this, then there are much easier ways for them to do so than attacking Let’s Encrypt. Unless he has deep pockets or is behind someone like CloudFlare, a DDoS on his systems is by far the easiest attack. If they don’t care about attribution then leaning on allies to tamper with routes, block DNS entries, and so on are all much easier than compromising Let’s Encrypt. If you have mitigations against all of these things, then start worrying about Let’s Encrypt.
This is not how US trade embargoes have worked in the past, as you can see from GitHub’s adventures with users from Iran and the Crimea. The State department doesn’t order a DDOS. But it threatens companies with severe repercussions if they continue trading with these areas. And suddenly your Github account is blocked, and you find that Let’s Encrypt no longer wants to renew your certificates.
Why would you make your operations dependent on an entity that might suspend your service at a moment’s notice?
I actually think this is extraordinarily bad advice, especially for people not strongly connected to the US (edit: I say this with the greatest respect for your opinions and I’m a fan of your comments here on the red site). The US (and other nation state actors) even though well resourced do not operate without constraints.
The purpose of security is to raise the cost of an attack beyond the level at which the actors in your threat model actually want to do it.
If we assume that Let’s Encrypt (LE) is very much in the pocket of a threat actor with the abilities of a major government, and that actor is not the Russian Federation or one of their buddies, and our principals are roughly speaking SME-level resourced actors, with a normal relationship to the Russian state; then -
LE/our threat actor have at least some capabilities that can be cheaply deployed in the sense that it consumes very little human resources and has very little opportunity cost. The question is really what those capabilities are, what costs the threat actor is willing to bear, and which threat actors you’re worried about.
For example, our threat actor if they are the US probably has the ability on some time scale to get a certificate fake signed by almost any CA at a certain level of effort and cost.
Our law abiding Muscovite businessman is much more exposed to the Russian Federation’s capabilities than those of the US, so choosing a Russia-based CA probably doesn’t increase their exposure to moderately motivated Russian state action; but it might increase their exposure to local criminal action at the risk of increasing their exposure to US state and US-based actors. Which is worse is for them to decide.
Edit: Also, LE have deep visibility into what exists even on private networks if those machines are directly using LE; and visibility into common control.
Edit: to be clear even if we assume Let’s Encrypt is owned by the NSA it’s not necessarily a bad idea to use it in place of no encryption.
There are three things LE can do:
The first of these is fairly low cost but even with a differently trusted CA any adversary that can attack the route between you and your CA can do this. If Let’s Encrypt is seen to be doing this then there’s a big risk to their reputation if they’d be caught.
The second of these is very dangerous for Let’s Encrypt. Anyone who is attacked will have (at least transiently) a copy of the certificate signed by Let’s Encrypt. Anyone who records this cert can present it as evidence of tampering. The existence of this certificate is sufficient to have the Let’s Encrypt root certificate being removed from the trusted set (issuing a cert without adding it to the CT log is sufficient grounds for this). Doing this even once is an existential risk to Let’s Encrypt.
The third is probably more dangerous for Let’s Encrypt. There’s a public log of the certs that are signed and if they’ve signed a cert for your domain that wasn’t yours then it’s easy to see. Again, if you can demonstrate that a cert was issued by someone else then this can cause LE to be dropped from the trusted root set. Again, this is an existential risk to Let’s Encrypt.
So, of the three things that a malicious Let’s Encrypt can do to you, the only one that wouldn’t directly risk LE’s continued existence is limited to a DoS. If you’re doing weekly renewals of your cert then you get three weeks notice that this is happening. That should be sufficient to move to an alternative provider. Again, if you’re worried about denial of service then you need to think about all of the other ways that someone else could impact availability and there are many of these. You can purchase an off-the-shelf botnet that will run a DDoS that can take out most cheap VPS for a few dollars.
I think that’s fair and disposes of low cost attacks. I still don’t think it means people shouldn’t bother including nation state actors (even the US) in their threat model.
I would be interested to read an explanation of this threat model – can you point at one?
[Not an explanation of threat models in general, I’ve got that.]
I think GOST rings more of the NOBUS bells for me than LE does…
How, with Certificate Transparency, does LE raise NOBUS alarms?
I was expecting a coherent argument against Let’s Encrypt. This… wasn’t it.
I have had the growing feeling that the “encrypt everything” push of the past few years has done nothing to improve safety for the average human being, while increasing centralization and making censorship easier than ever. How long before the next “huh, half the internet is down again” is caused not by a DDoS or a borked configuration at AWS but by a certificate revocation which everyone will claim is accidental, but which will just so happen to disrupt a major political rally in Western Morgravia? How long before I have to have my ID on file before any CA will talk to me?
That’s an extraordinary and non-obvious claim, based on what?
It feels to me like stargrave’s perspective is internally inconsistent, with bias accounting for those inconsistencies. Overall I don’t agree with what he wrote.
But I have had some similar thoughts and feelings regarding x.509 and ACME / Let’s Encrypt. I once attended a talk by one of the main Let’s Encrypt contributors, I think it was Matt Holt maybe?
At the end I tried to ask them a question, if they had any plans to enhance the security of ACME versus adversaries who can leverage their position on the network to issue fraudulent certificates. As an example, say I could send my domain name and a public key to them, and then they store that in a database with a 1 week or 1 month TTL. Until it expires, they refuse any certificate issuance request which is not signed by the corresponding private key which I hold. Such a thing could allow me to create & continuously renew my own “certificate issuance key” which could help prevent fraudulent certificate issuance on my domain by a cloud service provider, ISP, or DNS authority.
But when I explained this idea, either I didn’t explain it very well, or they just didn’t understand why anyone would want that; why anyone would worry about central infrastructure operators leveraging their position on the network to misbehave, why anyone would want to try to defend against that.
If they did have such a feature, combined with a CAA record saying that Let’s Encrypt is the only ACME CA allowed to sign certificates for my domain, then it should be “sealed” right? There’s no way for a fraudulent certificate to be issued as long as everybody plays by the rules. Non-LE ACME CAs wont issue because of the CAA record, and LE themselves wont issue because the fraudster doesn’t have the required private key.
Right. As long as everybody plays by the rules. But that’s just the thing, and this is a problem that pre-dates Let’s Encrypt and ACME CAs: x.509 is ultimately an authority based system like the banking / financial system. Your account can be frozen. Money can be printed. Ultimately someone else is in charge and there’s nothing you can do about that. Certificate Transparency can help, but there’s no process I’m aware of which ensures that everyone follows the certificate transparency rules as well.
This problem is pretty much the same thing as Zooko’s triangle. I know stargrave doesn’t like cryptocurrency stuff, but as far as I know, cryptocurrency is the first solution we ever had for Zookos Triangle where we can have all 3 things, decentralized, human-meaningful, and secure. Namecoin is a great technical example of that, and the Namecoin client software / wallet software has really come a long way in the past couple of years.
Everyone loves to hate cryptocurrency and they kinda have a point, no one has ever found a truly satisfying alternative to proof-of-work mining, and proof-of-work mining is headed for disaster if cryptocurrency continues to become more and more valuable. Trading energy for money, and the money keeps getting more and more valuable, hmm, what could go wrong?
But I still really hope that in the future we get to keep our Zookos Triangle solution. Even if it’s not something that everyone gets pre-installed on their phone, I think the world can benefit from a system that truly guarantees “no lying/cheating” and treats everyone the same regardless of how much money or power they have.
You’re mostly right on proof of work sort of solving zooko’s triangle. That said in fact we see that Bitcoin and ethereum mining are centralized enough to support hard forks; and the cost of proof of work is massively beyond the reasonable benefits.
I’m sorry, but this is stupid. The reasoning you give doesn’t make going TLS’less better. Serving LE TLS from a shared box is still much better than not using TLS at all, for a bunch of reasons.
E.g., now connections to you are open for attack from all points it goes through, rather than just a single (?) point. You can’t assume ISPs will just take care of link security.
I think the author is just forgetting why LE took off. Companies were exploiting their power and charging high prices and generally made certificates annoying to get. HTTPS may not be perfect, but now it is easy to setup and provides a lot more protection than before. I moved to LE as a move away from a feeling I was dealing with exploitative companies for my certs.