4 ms·

> the shared host did nothing wrong as well I'm not so sure about that. Is it really a good idea to let customers configure security settings (e.g. the TLS cer

> the shared host did nothing wrong as well I'm not so sure about that. Is it really a good idea to let customers configure security settings (e.g. the TLS cert used) for domains they don't own? I suppose as long as they're only doing it for invalid domains it shouldn't be an issue, but what if a customer were to set a cert for sitea.example (which they don't own) and then later the real owner of sitea.example comes along and wants to set up their site on the same host? Just doesn't seem like good practice to me. Maybe the solution here is to make the domain name sent by the SNI challenge a subdomain of the domain being validated? If a shared hosting site allows customers to set TLS certs for subdomains of a _completely different customer's_ domain name, that's most definitely a security issue regardless of whether or not TLS-SNI validation exists.

Ajedi32 9y ago
> Maybe the solution here is to make the domain name sent by the SNI challenge a subdomain of the domain being validated? FWIW, Matthew Hardeman just made an excelent post on the mozilla.dev.security.policy which discusses this solution and some potential problems with it in detail: https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/rS50Pft4AQAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/...
- ploxiln 9y ago
  This is an interesting detail from Ryan Sleevi > So I don't think this buys any improvement over the status quo, and actually makes it considerably more complex and failure prone, due to the cross-sectional lookups, versus the fact that .invalid is a reserved TLD. So it should be more likely for shared hosting services to recognize that .invalid is an explicitly reserved TLD, vs correctly walking subdomains and recognizing "effective TLDs" (which vary in number of dot-separated elements).
  - mdhardeman 9y ago
    Indeed that the hosting providers do neither is a strong sign that both TLS-SNI-01 and TLS-SNI-02 and the mechanism I proposed would all be deficient to really address the issue of making this mechanism secure again.
    - ploxiln 9y ago
      Agreed. It may be necessary to abandon TLS-SNI. Maybe ALPN will work out.

Ajedi32 9y ago

> Maybe the solution here is to make the domain name sent by the SNI challenge a subdomain of the domain being validated? FWIW, Matthew Hardeman just made an excelent post on the mozilla.dev.security.policy which discusses this solution and some potential problems with it in detail: https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/rS50Pft4AQAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/...

ploxiln 9y ago
This is an interesting detail from Ryan Sleevi > So I don't think this buys any improvement over the status quo, and actually makes it considerably more complex and failure prone, due to the cross-sectional lookups, versus the fact that .invalid is a reserved TLD. So it should be more likely for shared hosting services to recognize that .invalid is an explicitly reserved TLD, vs correctly walking subdomains and recognizing "effective TLDs" (which vary in number of dot-separated elements).
- mdhardeman 9y ago
  Indeed that the hosting providers do neither is a strong sign that both TLS-SNI-01 and TLS-SNI-02 and the mechanism I proposed would all be deficient to really address the issue of making this mechanism secure again.
  - ploxiln 9y ago
    Agreed. It may be necessary to abandon TLS-SNI. Maybe ALPN will work out.