9 ms·

I think this issue can be described as a form of confused deputy problem. Is not the real solution to have the confused deputies stop acting in a confused mann

I think this issue can be described as a form of confused deputy problem. Is not the real solution to have the confused deputies stop acting in a confused manner? If this issue were confined to a handful of small hosting companies almost no one uses, then I don't think this would be described as a problem with Let's Encrypt - it would be described as a problem with those hosting companies. The only party that can truly fix the issue of the incorrect user being granted access (directly or indirectly) to a domain pointed at shared infrastructure is the operator of that infrastructure.

deleted 9y ago
[deleted]
e_d_e_v 9y ago
I came here to say this. What's more, the spec was agreed upon, in relatively public forums, with a voice from the community. Crappy shared hosting providers are going to mostly ignore their customers and perpetuate insecure scenarios while they continue to bill exorbitant rates that exploit the customers' ignorance or inertia. That has been the case for some time, and will continue to be the case, this is just another symptom.
- rgbrenner 9y ago
  What's more, the spec was agreed upon, in relatively public forums, with a voice from the community. It was agreed upon and no one caught this issue. Now we know the issue. There's nothing wrong with using a protocol you think is correct. There is something wrong with using a protocol you know is incorrect, but continue to use it anyway. The entire internet should not be required from now to forever to workaround LE's mistake. LE should fix their protocol. And worse, this protocol isn't even needed for LE. They could remove it, and everyone could use one of the two others that are secure, and LE would be just fine, and everyone -- even those crappy shared hosting providers -- would be perfectly secure. LE created this issue all by itself, and is capable of fixing it all by itself. LE should do that.
  - DanielDent 9y ago
    LE "created" this issue in the sense that they were the first to formalize an implementable specification for automated verification of authorized domain name use. In comparison to the prior relatively unspecified approach to verification, it's still an improvement. "The last person who touched needs to take ownership over anything anyone can blame on the change" is the management style which leads to enterprise IT being unable to get anything done. Because at that point, the safest thing is to never change anything - regardless of how bad things currently are. Sometimes the world changes, and other parts of the technology ecosystem need to adapt. [Editing to add since I can't reply to you]: The fundamental "flaw" here is that it's possible for people to get self-signed certificates served for domains where they haven't validated ownership of the domain. Hosting companies can't be simply adjusting their routing tables for anyone who asks. If you are pointing a domain name at an IP address which will accept routes from any untrusted party, that's simply not a secure situation. A signed certificate might be good evidence of some authority for a domain, but a self-signed certificate used in a challenge process most assuredly is not.
    - deleted 9y ago
      [deleted]
rgbrenner 9y ago
In TLS-SNI-01/02 there's SAN-A and SAN-B (added in 02). These are random values. Those random values are all known to the attacker. Importantly, they contain no information on which (real) domain these random values correspond to. These random values are the only values sent and used by LE to verify domain ownership. How would a provider map random values to a domain? Only LE knows what random values correspond to which domains.
- DanielDent 9y ago
  This spec may only be usable by provider issuing certificates they manage on behalf of their customers. It's possible the protocol is unusable on a shared IP address for customer-managed certificates. Even today, there are many hosting companies where you can go ahead and setup an account for "gmail.com" - and they will happily direct messages from their customers intended for "gmail.com". And there are hosting control panels where their "solution" to this problem is to have a hardcoded list of high value targets for which end customers cannot create accounts. But the general issue is that providers need to be mindful of what changes they make to their routing tables. Not all inputs to the system are trustworthy.
mdhardeman 9y ago
The difficulty is the comparative security posture. The HTTP-01 and DNS-01 challenges really don't require the web hosts to get their $h1t together to improve security. (Technically, HTTP-01 could for some attack scenarios, but that would still be more difficult than this TLS-SNI-01 attack.) The TLS-SNI-01 mechanism does. Maybe it's the method that's deficient, rather than the web host. (In truth both are, but one of those can be fixed timely, albeit with a bullet.)

deleted 9y ago

[deleted]

e_d_e_v 9y ago

I came here to say this. What's more, the spec was agreed upon, in relatively public forums, with a voice from the community. Crappy shared hosting providers are going to mostly ignore their customers and perpetuate insecure scenarios while they continue to bill exorbitant rates that exploit the customers' ignorance or inertia. That has been the case for some time, and will continue to be the case, this is just another symptom.

rgbrenner 9y ago
What's more, the spec was agreed upon, in relatively public forums, with a voice from the community. It was agreed upon and no one caught this issue. Now we know the issue. There's nothing wrong with using a protocol you think is correct. There is something wrong with using a protocol you know is incorrect, but continue to use it anyway. The entire internet should not be required from now to forever to workaround LE's mistake. LE should fix their protocol. And worse, this protocol isn't even needed for LE. They could remove it, and everyone could use one of the two others that are secure, and LE would be just fine, and everyone -- even those crappy shared hosting providers -- would be perfectly secure. LE created this issue all by itself, and is capable of fixing it all by itself. LE should do that.
- DanielDent 9y ago
  LE "created" this issue in the sense that they were the first to formalize an implementable specification for automated verification of authorized domain name use. In comparison to the prior relatively unspecified approach to verification, it's still an improvement. "The last person who touched needs to take ownership over anything anyone can blame on the change" is the management style which leads to enterprise IT being unable to get anything done. Because at that point, the safest thing is to never change anything - regardless of how bad things currently are. Sometimes the world changes, and other parts of the technology ecosystem need to adapt. [Editing to add since I can't reply to you]: The fundamental "flaw" here is that it's possible for people to get self-signed certificates served for domains where they haven't validated ownership of the domain. Hosting companies can't be simply adjusting their routing tables for anyone who asks. If you are pointing a domain name at an IP address which will accept routes from any untrusted party, that's simply not a secure situation. A signed certificate might be good evidence of some authority for a domain, but a self-signed certificate used in a challenge process most assuredly is not.
  - deleted 9y ago
    [deleted]

rgbrenner 9y ago

In TLS-SNI-01/02 there's SAN-A and SAN-B (added in 02). These are random values. Those random values are all known to the attacker. Importantly, they contain no information on which (real) domain these random values correspond to. These random values are the only values sent and used by LE to verify domain ownership. How would a provider map random values to a domain? Only LE knows what random values correspond to which domains.

DanielDent 9y ago
This spec may only be usable by provider issuing certificates they manage on behalf of their customers. It's possible the protocol is unusable on a shared IP address for customer-managed certificates. Even today, there are many hosting companies where you can go ahead and setup an account for "gmail.com" - and they will happily direct messages from their customers intended for "gmail.com". And there are hosting control panels where their "solution" to this problem is to have a hardcoded list of high value targets for which end customers cannot create accounts. But the general issue is that providers need to be mindful of what changes they make to their routing tables. Not all inputs to the system are trustworthy.

mdhardeman 9y ago

The difficulty is the comparative security posture. The HTTP-01 and DNS-01 challenges really don't require the web hosts to get their $h1t together to improve security. (Technically, HTTP-01 could for some attack scenarios, but that would still be more difficult than this TLS-SNI-01 attack.) The TLS-SNI-01 mechanism does. Maybe it's the method that's deficient, rather than the web host. (In truth both are, but one of those can be fixed timely, albeit with a bullet.)