10 ms·

Update Regarding ACME TLS-SNI and Shared Hosting Infrastructure

116 points by okket 9y ago

rgbrenner 9y ago
Happy to see this. I was very critical of their plan to re enable Tls-sni and I’m happy to see they reconsidered. They made the right call here.
mdhardeman 9y ago
It looks like Let's Encrypt has come up with the best plan possible for the goal of balancing mitigation of the security risks with compatibility for users. If their plan works out as they've laid out, and as certain recent commits in the boulder source code would suggest... It would seem they intend to: 1. Allow renewal of already-issued certificates to same account holder to revalidate via TLS-SNI-01 for some limited time period. 2. Whitelist certain shared infrastructure providers who have lots of LE certs in force and who have demonstrated that they are not vulnerable. I'm betting especially for those that manage the whole certificate retrieval and deployment process. It's not clear if this is temporary but longer than #1 or "temporary" but very long term or "temporary" until we come up with another inband process. 3. Otherwise TLS-SNI-01 is gone. Meanwhile, they'll work with the ACME WG to see if they can't figure out a better TLS-SNI method which would not be vulnerable. That looks less and less workable absent some special TLS extensions or ALPN and server support for those. For those who have options, it's worth pointing out that the purely DNS based validation methods are literally closest to the facts that the CA's validation process wishes to prove. Domain Control validated means that you're showing effective control of the domain. Nothing says I control the domain like the ability to add and remove data from the authoritative DNS servers for the domain label (and children thereof) in question.
- bproven 9y ago
  Agreed - looks like a good plan. It definitely must have been a busy few days to a week for them : First Meltdown/Spectre to consider and now this to deal with - however I am glad to see the update and the total transparency each step of the way!
- BillinghamJ 9y ago
  I think a similar process, but built off of ALPN rather than SNI, seems like the clear solution. Nobody at LE seems to have spoken about this or acknowledged it as a possible option yet though.
  - mdhardeman 9y ago
    Ryan Sleevi of Google has discussed (specifically) such a possibility on the m.d.s.p group. Today's update from Let's Encrypt did allude under "ACME Protocol Updates" that there might be further work done to the protocol to attempt to remediate the risks. Probably they don't want to get specific because even if a concrete proposal were ready to begin coding today, it would take time to build the reference client, time to build server infrastructure, test, etc. Then before that work would have any benefit to the various websites needing validation, it would require server software upgrades to facilitate those extensions or ALPN negotiations. My utter speculation is that they're thinking it would likely take long enough that everyone will have to be off TLS-SNI-01 before its replacement becomes available.
    - BillinghamJ 9y ago
      Ah thank you - I have found that now. A link to that discussion, for reference: https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/iXyaHh2DAQAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/...
    - Titanous 9y ago
      Work has already started on a new challenge using ALPN: https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxbt3A1XtLFJM https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxb...
      - mdhardeman 9y ago
        Let's Encrypt has also just added a new post in which they've been working tirelessly on a new nginx and apache plugin to certbot utilizing HTTP-01 validation: https://community.letsencrypt.org/t/help-test-certbot-apache-and-nginx-fixes-for-tls-sni-01-outage/50207 https://community.letsencrypt.org/t/help-test-certbot-apache... It seems they are predicting TLS-SNI-0x going away for a lengthy period of time. That said, the ALPN proposal is a start. Though rather than just having it as a mere marker, it should incorporate features to securely indicate which domain label it is attempting to validate and achieve consensus on part of validator and the endpoint being validated. I am hopeful such a scheme may be useful for future deployments down the road. I think it is likely before there is infrastructure in place utilizing a new mechanism of that kind that current needs will need to be met with one of the other mechanisms. The speed and resource with which Let's Encrypt is working on solutions to migrate users to non-TLS-SNI validations might well be a signal.
- will_hughes 9y ago
  > Nothing says I control the domain like the ability to add and remove data from the authoritative DNS servers for the domain label (and children thereof) in question. Unfortunately this makes life difficult for us. We run a whitelabelled platform with tens of thousands of users - it's hard enough to get many people to understand setting a CNAME record (vs just setting an A record). Requiring them to update a TXT record once would be a big enough challenge, but doing it every 30-90 days is never going to happen. The smaller customers would probably be happy with us hosting their DNS, but we're not going to do that - the larger ones wouldn't. TLS-SNI being gone and DNS being unworkable means we're left with HTTP only.
  - mdhardeman 9y ago
    But if you're a web post with 10k+ users, what's the problem with the HTTP-01 challenge? You just allow .well-known/* to be passed on to reflect the challenge responses you've generated for the client, while 301 redirecting everything else to their https:// https:// site. I'm confused how that would be harder for a web host at that scale? EDIT: I get people trying to run a server off their cable modem / rtr public IP, and 80 might be taken by something other than the target the port forward for 443 is going to -- and that's a problem for those use cases -- but that kind of concern wouldn't exist in a significant hosting infrastructure.
    - will_hughes 9y ago
      > what's the problem with the HTTP-01 challenge? Nothing, yet. But who's to say that another similar bug won't be found in common shared-hosting platforms that forces LE to turn that challenge off too?
      - mdhardeman 9y ago
        True. Because almost all of the CAs utilize a web control mechanism, with many of them probably having processes not as rigorous as HTTP-01, it is likely that there would be significant backlash and a lengthier migration away from the method for that case. That said, anyone who can would be well advised to figure out how their DNS based mechanism would work if it were ever needed. As I and others have pointed out, there are clever and fully supported hacks for validating dns-01 without dynamic control of the full domain zone. (CNAME to another zone for the _acme-challenge labels, NS delegation to refer each _acme-challenge label as an independent zone at a different NS, etc.)
zalmoxes 9y ago
RIP I have a few services which were using Go’s acme/autocert package. I now need to update them to the HTTP challenge.
- mholt 9y ago
  xenolf/lego arguably has the widest support in the sense of ACME verification methods, but autocert might get other methods too: https://github.com/golang/go/issues/21890 https://github.com/golang/go/issues/21890
mholt 9y ago
For the record, I am pretty sure Caddy will be unaffected by this. Any programs using xenolf/lego as their ACME client should be fine as well, as long as one other validation method is still available. (lego also uniquely supports a wide variety of DNS providers for automated negotiation of the DNS challenge. Caddy supports them too, as long as they are plugged in and configured.) I've been asked if we'll turn off TLS-SNI in Caddy and the answer is no; as their announcement says, some accounts will still be able to use TLS-SNI for a limited timeframe until it is turned off completely. Caddy won't try the TLS-SNI challenge as long as the ACME server doesn't advertise it in an exchange.
- mdhardeman 9y ago
  One would think that most of the Caddy users who previously used TLS-SNI-01 could also avail themselves of HTTP-01 validation.
  - mholt 9y ago
    Yeah, I imagine so. Many sites still have port 80 open to redirect to 443.
niftich 9y ago
The tls-sni challenges rest on the assumption that a hosting provider will somehow ensure that a self-signed cert uploaded by the user contains "truthful" information, even though the second half of the cert is blatantly fake and is being abused to carry data. This is a bold assumption to make, considering the entire point of CAs is to say that the information being presented in a cert has been vetted, so why presume that anyone will vet any claims in a self-signed cert? That aside, Let's Encrypt had an exemplary response to this issue throughout, and has made the right call here. A best-effort whitelist will enable a smoother transition for those on some known-good hosts, while mitigating this vulnerability and keeping their cert ecosystem uncompromised. The work will now begin to add support to the other validation methods in ACME software that's lacking them, and to engage with the other custodians of the ACME protocol to rectify this particular flaw in design. While the http-01 challenge is the recommended migration path, and likely the easiest to automate with greenfield software, the dns-01 challenge is the one with the fewest amount of intermediate assumptions -- such as the ones made when designing tls-sni-*, which in this case turned out to be faulty -- and represents the one most likely to be futureproof. After all, what better way to prove you own a domain itself than being able to add arbitrary records to it that all nameservers then echo back?
- mdhardeman 9y ago
  I completely agree on the dns-01 challenge. Those who are migrating off of TLS-SNI-01 and have a capability to standardize on dns-01 will be better off in the long run. As you point out, domain control validation is best performed by having the application demonstrate control of the domain.
  - regecks 9y ago
    The problem with dns-01 is that it much of the time, it requires granting far too much privilege to the system that requests the certificate. This is because the great majority of DNS hosts do not provide sufficiently granular permissions to only allow changes to _acme-challenge RRs. e.g. Cloudflare, as far as I can tell, only gives you one API key which grants all access to all zones. e.g. Most domain registrars who offer DNS hosting who provide an API grant access to all sorts of management functions, not just DNS zone changes. e.g. Route53 IAM doesn't let you restrict to a single RR, you expose modifications to the entire zone. I am really not comfortable giving my web application these kinds of powers. TLS-SNI was useful because it was relatively protocol agnostic, so some of that flexibility is now gone.
AdamJacobMuller 9y ago
I don't understand why TLS-SNI can't work fine if you just have the response certificate be entirely distinct from the server name. EG: LE sends a challenge of a.b.c.acme.invalid You must reply with a certificate of d.e.f.acme.invalid Doesn't that entirely mitigate the shared hosting issue since any shared hosting setup will require SNI to match the certificate name that you reply with?
- mdhardeman 9y ago
  No, that’s the problem. A lot of shared hosts will allow any customer to board a new website — as long as it’s not already taken on that hosting provider — then allow you to upload any TLS cert for that. So attacker requests to validate for a name that you have pointed via DNS to that hosting infrastructure. The names that you need to respond on and have certs for are then calculated by attacker. Attacker, who is also a customer of same hosting service creates the necessary “sites” and uploads the matching challenge response certs, and successfully receives a cert for your domain.
  - AdamJacobMuller 9y ago
    None of what you're saying is an issue in my outline. If I'm able to upload a certificate for a.b.c.acme.invalid, the validation TLS-SNI request for a.b.c.acme.invalid will reply with a certificate for a.b.c.acme.invalid and thus fail. If I'm able to upload a certificate for d.e.f.acme.invalid, the validation TLS-SNI request for a.b.c.acme.invalid will not match my uploaded certificate and the challenge will thus fail. I may well be misunderstanding the situation, but, I just don't see how.
    - mdhardeman 9y ago
      It is still an issue, actually. You misunderstand how the TLS balancer chooses which certificate to present. When the TLS connection comes in and presents a SNI name of "a.b.c.acme.invalid", the balancer checks its configuration to see if the host has a "website" called "a.b.c.acme.invalid". It discovers that it does. It looks at what certificate in the database was uploaded for that website configuration. It doesn't actually check the certificate details at all.... It presents the certificate that was uploaded by the "owner" of the "website" a.b.c.acme.invalid. And if that name needs to present a certificate that says "d.e.f.acme.invalid" then that is the certificate that the attacker will have uploaded for his "a.b.c.acme.invalid" site. There are numerous web hosts who would permit this and it would work just like that. The mechanism you're describing is similar to the changes in TLS-SNI-02. It has already been determined that TLS-SNI-02 is deficient as it is vulnerable to the attack I've parroted here. The trouble is that the people who wrote both TLS-SNI-01 and TLS-SNI-02 apparently had little knowledge of the vast breadth of behaviors exhibited by a plethora of shared web hosts. The assumptions they made, upon which all the current TLS-SNI-0x protocols rely to provide security, simply are not upheld and honored by the real world marketplace of web hosts.
jo909 9y ago
From my point of view the big advantage of TLS-SNI is that it uses the same protocol and port as 90%+ of certificate users want to use with the issued certificate: HTTPS. That is especially useful for webserver plugins. Also this is much better when there are security policies that (for maybe misguided but well-intentioned reasons) completely block or redirect all HTTP traffic. What would be insecure about a https-01 challenge, that esentially works identical to the http-01 challenge but allows any certificate?
- pfg 9y ago
  > What would be insecure about a https-01 challenge, that esentially works identical to the http-01 challenge but allows any certificate? There's a specific reason http-01 is HTTP-only, and it's actually quite similar to the tls-sni-01 situation. In many of the major web servers, including apache and nginx, the web server will use the first HTTPS vhost in its configuration for any unmatched domains, unless you explicitly specify a default vhost. In practice that means an attacker on the same hosting environment used by the victim could get themselves in a position where they control this default vhost and obtain a certificate for their domain. The vhost order is often based on the alphabetic order of the domain, so that's fairly easy to pull off. http-01's predecessor did allow HTTPS, but this attack came up during the IETF ACME standardization process and, IIRC, was fixed before Let's Encrypt entered public beta[1]. http-01 does permit the CA server to follow redirects to HTTPS, including to ones with self-signed, expired or otherwise invalid certificates, so common setups with HSTS and redirects to HTTPS are fine, you'll only be in trouble if you can't use HTTP on port 80 at all. [1]: https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE_LNhnt0d8U https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE...
  - jo909 9y ago
    But that behavior is true and exploitable for HTTP as well, isn't it? It is a risk if there is no specific vhost config for the validated domain, which means a customer pointed the DNS to the shared host without also configuring that host to serve content for his domain from his account. I realize in current real-world setups you would normally start with a HTTP-only config and only later or maybe never configure HTTPS for that domain, or configure both protocols simultaneously. And almost never the opposite where you configure HTTPS only and someone else would be able to grab your HTTP traffic. So that's still a good argument to do HTTP only, thank you for explaining it. I did not know http-01 would follow redirect to HTTPS, that is also really good to know and should be a good way for some setups.

116 points by okket 9y ago

Happy to see this. I was very critical of their plan to re enable Tls-sni and I’m happy to see they reconsidered. They made the right call here.

mdhardeman 9y ago

It looks like Let's Encrypt has come up with the best plan possible for the goal of balancing mitigation of the security risks with compatibility for users. If their plan works out as they've laid out, and as certain recent commits in the boulder source code would suggest... It would seem they intend to: 1. Allow renewal of already-issued certificates to same account holder to revalidate via TLS-SNI-01 for some limited time period. 2. Whitelist certain shared infrastructure providers who have lots of LE certs in force and who have demonstrated that they are not vulnerable. I'm betting especially for those that manage the whole certificate retrieval and deployment process. It's not clear if this is temporary but longer than #1 or "temporary" but very long term or "temporary" until we come up with another inband process. 3. Otherwise TLS-SNI-01 is gone. Meanwhile, they'll work with the ACME WG to see if they can't figure out a better TLS-SNI method which would not be vulnerable. That looks less and less workable absent some special TLS extensions or ALPN and server support for those. For those who have options, it's worth pointing out that the purely DNS based validation methods are literally closest to the facts that the CA's validation process wishes to prove. Domain Control validated means that you're showing effective control of the domain. Nothing says I control the domain like the ability to add and remove data from the authoritative DNS servers for the domain label (and children thereof) in question.

bproven 9y ago
Agreed - looks like a good plan. It definitely must have been a busy few days to a week for them : First Meltdown/Spectre to consider and now this to deal with - however I am glad to see the update and the total transparency each step of the way!
BillinghamJ 9y ago
I think a similar process, but built off of ALPN rather than SNI, seems like the clear solution. Nobody at LE seems to have spoken about this or acknowledged it as a possible option yet though.
- mdhardeman 9y ago
  Ryan Sleevi of Google has discussed (specifically) such a possibility on the m.d.s.p group. Today's update from Let's Encrypt did allude under "ACME Protocol Updates" that there might be further work done to the protocol to attempt to remediate the risks. Probably they don't want to get specific because even if a concrete proposal were ready to begin coding today, it would take time to build the reference client, time to build server infrastructure, test, etc. Then before that work would have any benefit to the various websites needing validation, it would require server software upgrades to facilitate those extensions or ALPN negotiations. My utter speculation is that they're thinking it would likely take long enough that everyone will have to be off TLS-SNI-01 before its replacement becomes available.
  - BillinghamJ 9y ago
    Ah thank you - I have found that now. A link to that discussion, for reference: https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/iXyaHh2DAQAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/...
  - Titanous 9y ago
    Work has already started on a new challenge using ALPN: https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxbt3A1XtLFJM https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxb...
    - mdhardeman 9y ago
      Let's Encrypt has also just added a new post in which they've been working tirelessly on a new nginx and apache plugin to certbot utilizing HTTP-01 validation: https://community.letsencrypt.org/t/help-test-certbot-apache-and-nginx-fixes-for-tls-sni-01-outage/50207 https://community.letsencrypt.org/t/help-test-certbot-apache... It seems they are predicting TLS-SNI-0x going away for a lengthy period of time. That said, the ALPN proposal is a start. Though rather than just having it as a mere marker, it should incorporate features to securely indicate which domain label it is attempting to validate and achieve consensus on part of validator and the endpoint being validated. I am hopeful such a scheme may be useful for future deployments down the road. I think it is likely before there is infrastructure in place utilizing a new mechanism of that kind that current needs will need to be met with one of the other mechanisms. The speed and resource with which Let's Encrypt is working on solutions to migrate users to non-TLS-SNI validations might well be a signal.
will_hughes 9y ago
> Nothing says I control the domain like the ability to add and remove data from the authoritative DNS servers for the domain label (and children thereof) in question. Unfortunately this makes life difficult for us. We run a whitelabelled platform with tens of thousands of users - it's hard enough to get many people to understand setting a CNAME record (vs just setting an A record). Requiring them to update a TXT record once would be a big enough challenge, but doing it every 30-90 days is never going to happen. The smaller customers would probably be happy with us hosting their DNS, but we're not going to do that - the larger ones wouldn't. TLS-SNI being gone and DNS being unworkable means we're left with HTTP only.
- mdhardeman 9y ago
  But if you're a web post with 10k+ users, what's the problem with the HTTP-01 challenge? You just allow .well-known/* to be passed on to reflect the challenge responses you've generated for the client, while 301 redirecting everything else to their https:// https:// site. I'm confused how that would be harder for a web host at that scale? EDIT: I get people trying to run a server off their cable modem / rtr public IP, and 80 might be taken by something other than the target the port forward for 443 is going to -- and that's a problem for those use cases -- but that kind of concern wouldn't exist in a significant hosting infrastructure.
  - will_hughes 9y ago
    > what's the problem with the HTTP-01 challenge? Nothing, yet. But who's to say that another similar bug won't be found in common shared-hosting platforms that forces LE to turn that challenge off too?
    - mdhardeman 9y ago
      True. Because almost all of the CAs utilize a web control mechanism, with many of them probably having processes not as rigorous as HTTP-01, it is likely that there would be significant backlash and a lengthier migration away from the method for that case. That said, anyone who can would be well advised to figure out how their DNS based mechanism would work if it were ever needed. As I and others have pointed out, there are clever and fully supported hacks for validating dns-01 without dynamic control of the full domain zone. (CNAME to another zone for the _acme-challenge labels, NS delegation to refer each _acme-challenge label as an independent zone at a different NS, etc.)

zalmoxes 9y ago

RIP I have a few services which were using Go’s acme/autocert package. I now need to update them to the HTTP challenge.

mholt 9y ago
xenolf/lego arguably has the widest support in the sense of ACME verification methods, but autocert might get other methods too: https://github.com/golang/go/issues/21890 https://github.com/golang/go/issues/21890

mholt 9y ago

For the record, I am pretty sure Caddy will be unaffected by this. Any programs using xenolf/lego as their ACME client should be fine as well, as long as one other validation method is still available. (lego also uniquely supports a wide variety of DNS providers for automated negotiation of the DNS challenge. Caddy supports them too, as long as they are plugged in and configured.) I've been asked if we'll turn off TLS-SNI in Caddy and the answer is no; as their announcement says, some accounts will still be able to use TLS-SNI for a limited timeframe until it is turned off completely. Caddy won't try the TLS-SNI challenge as long as the ACME server doesn't advertise it in an exchange.

mdhardeman 9y ago
One would think that most of the Caddy users who previously used TLS-SNI-01 could also avail themselves of HTTP-01 validation.
- mholt 9y ago
  Yeah, I imagine so. Many sites still have port 80 open to redirect to 443.

niftich 9y ago

The tls-sni challenges rest on the assumption that a hosting provider will somehow ensure that a self-signed cert uploaded by the user contains "truthful" information, even though the second half of the cert is blatantly fake and is being abused to carry data. This is a bold assumption to make, considering the entire point of CAs is to say that the information being presented in a cert has been vetted, so why presume that anyone will vet any claims in a self-signed cert? That aside, Let's Encrypt had an exemplary response to this issue throughout, and has made the right call here. A best-effort whitelist will enable a smoother transition for those on some known-good hosts, while mitigating this vulnerability and keeping their cert ecosystem uncompromised. The work will now begin to add support to the other validation methods in ACME software that's lacking them, and to engage with the other custodians of the ACME protocol to rectify this particular flaw in design. While the http-01 challenge is the recommended migration path, and likely the easiest to automate with greenfield software, the dns-01 challenge is the one with the fewest amount of intermediate assumptions -- such as the ones made when designing tls-sni-*, which in this case turned out to be faulty -- and represents the one most likely to be futureproof. After all, what better way to prove you own a domain itself than being able to add arbitrary records to it that all nameservers then echo back?

mdhardeman 9y ago
I completely agree on the dns-01 challenge. Those who are migrating off of TLS-SNI-01 and have a capability to standardize on dns-01 will be better off in the long run. As you point out, domain control validation is best performed by having the application demonstrate control of the domain.
- regecks 9y ago
  The problem with dns-01 is that it much of the time, it requires granting far too much privilege to the system that requests the certificate. This is because the great majority of DNS hosts do not provide sufficiently granular permissions to only allow changes to _acme-challenge RRs. e.g. Cloudflare, as far as I can tell, only gives you one API key which grants all access to all zones. e.g. Most domain registrars who offer DNS hosting who provide an API grant access to all sorts of management functions, not just DNS zone changes. e.g. Route53 IAM doesn't let you restrict to a single RR, you expose modifications to the entire zone. I am really not comfortable giving my web application these kinds of powers. TLS-SNI was useful because it was relatively protocol agnostic, so some of that flexibility is now gone.

AdamJacobMuller 9y ago

I don't understand why TLS-SNI can't work fine if you just have the response certificate be entirely distinct from the server name. EG: LE sends a challenge of a.b.c.acme.invalid You must reply with a certificate of d.e.f.acme.invalid Doesn't that entirely mitigate the shared hosting issue since any shared hosting setup will require SNI to match the certificate name that you reply with?

mdhardeman 9y ago
No, that’s the problem. A lot of shared hosts will allow any customer to board a new website — as long as it’s not already taken on that hosting provider — then allow you to upload any TLS cert for that. So attacker requests to validate for a name that you have pointed via DNS to that hosting infrastructure. The names that you need to respond on and have certs for are then calculated by attacker. Attacker, who is also a customer of same hosting service creates the necessary “sites” and uploads the matching challenge response certs, and successfully receives a cert for your domain.
- AdamJacobMuller 9y ago
  None of what you're saying is an issue in my outline. If I'm able to upload a certificate for a.b.c.acme.invalid, the validation TLS-SNI request for a.b.c.acme.invalid will reply with a certificate for a.b.c.acme.invalid and thus fail. If I'm able to upload a certificate for d.e.f.acme.invalid, the validation TLS-SNI request for a.b.c.acme.invalid will not match my uploaded certificate and the challenge will thus fail. I may well be misunderstanding the situation, but, I just don't see how.
  - mdhardeman 9y ago
    It is still an issue, actually. You misunderstand how the TLS balancer chooses which certificate to present. When the TLS connection comes in and presents a SNI name of "a.b.c.acme.invalid", the balancer checks its configuration to see if the host has a "website" called "a.b.c.acme.invalid". It discovers that it does. It looks at what certificate in the database was uploaded for that website configuration. It doesn't actually check the certificate details at all.... It presents the certificate that was uploaded by the "owner" of the "website" a.b.c.acme.invalid. And if that name needs to present a certificate that says "d.e.f.acme.invalid" then that is the certificate that the attacker will have uploaded for his "a.b.c.acme.invalid" site. There are numerous web hosts who would permit this and it would work just like that. The mechanism you're describing is similar to the changes in TLS-SNI-02. It has already been determined that TLS-SNI-02 is deficient as it is vulnerable to the attack I've parroted here. The trouble is that the people who wrote both TLS-SNI-01 and TLS-SNI-02 apparently had little knowledge of the vast breadth of behaviors exhibited by a plethora of shared web hosts. The assumptions they made, upon which all the current TLS-SNI-0x protocols rely to provide security, simply are not upheld and honored by the real world marketplace of web hosts.

jo909 9y ago

From my point of view the big advantage of TLS-SNI is that it uses the same protocol and port as 90%+ of certificate users want to use with the issued certificate: HTTPS. That is especially useful for webserver plugins. Also this is much better when there are security policies that (for maybe misguided but well-intentioned reasons) completely block or redirect all HTTP traffic. What would be insecure about a https-01 challenge, that esentially works identical to the http-01 challenge but allows any certificate?

pfg 9y ago
> What would be insecure about a https-01 challenge, that esentially works identical to the http-01 challenge but allows any certificate? There's a specific reason http-01 is HTTP-only, and it's actually quite similar to the tls-sni-01 situation. In many of the major web servers, including apache and nginx, the web server will use the first HTTPS vhost in its configuration for any unmatched domains, unless you explicitly specify a default vhost. In practice that means an attacker on the same hosting environment used by the victim could get themselves in a position where they control this default vhost and obtain a certificate for their domain. The vhost order is often based on the alphabetic order of the domain, so that's fairly easy to pull off. http-01's predecessor did allow HTTPS, but this attack came up during the IETF ACME standardization process and, IIRC, was fixed before Let's Encrypt entered public beta[1]. http-01 does permit the CA server to follow redirects to HTTPS, including to ones with self-signed, expired or otherwise invalid certificates, so common setups with HSTS and redirects to HTTPS are fine, you'll only be in trouble if you can't use HTTP on port 80 at all. [1]: https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE_LNhnt0d8U https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE...
- jo909 9y ago
  But that behavior is true and exploitable for HTTP as well, isn't it? It is a risk if there is no specific vhost config for the validated domain, which means a customer pointed the DNS to the shared host without also configuring that host to serve content for his domain from his account. I realize in current real-world setups you would normally start with a HTTP-only config and only later or maybe never configure HTTPS for that domain, or configure both protocols simultaneously. And almost never the opposite where you configure HTTPS only and someone else would be able to grab your HTTP traffic. So that's still a good argument to do HTTP only, thank you for explaining it. I did not know http-01 would follow redirect to HTTPS, that is also really good to know and should be a good way for some setups.