Hacker News Reader

Comment by y0ghur7_xxx | Hacker News Reader

> What about the shared hosting providers that are "affected" that decide to do nothing to "fix" this?

The problem is that I can upload a self signed certificate on a shared host for a domain I don't own.

This, in and for itself, should not be a problem. I did nothing wrong, and the shared host did nothing wrong as well: it only allowed me to upload a self signed cert for an inexistent domain. IMHO, those two actions should not allow someone to get a valid cert for a domain they don't control, and whose only fault is that they pointed their A record to the shared domain host.

I don't think TLS-SNI is sufficient proof of Domain Control. IMHO it should be sacked.

View on HN

As someone with a long history in shared hosting, I have to agree. Basically requesting that ".acme.invalid" SNI proves ownership only of the ".acme.invalid" name and not the actual domain name in any way. I don't see any way this scheme can work.

The only way I can see this working is having to pre-install a self-signed certificate with the same private key as the requested certificate to sign, on the actual domain name. I think that can work, can't it? I'd have to try it with openssl..

They may be able to fix it for larger providers but you'll forever have many smaller providers that will never mitigate the issue.

The obvious problem with that is temporarily killing the real SSL certificate during initial setup. Though in theory they could re-use the private key.

> 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.

> 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/...

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).

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.

Agreed. It may be necessary to abandon TLS-SNI. Maybe ALPN will work out.

Reply on news.ycombinator.com