[e_d_e_v]

> You're assuming you can scour the internet and find every shared hosting provider affected, and add them to a list. And then you're also going to keep that list updated. That's crazy.. an impossible task.

I think you underestimate the capabilities of modern infosec tooling. Essentially the whole of the internet can be scanned in some ways in durations measured in hours. What is more, some systems are being constantly updated (such a certificate transparency), and there are relatively easy ways to identify bad actors via whitelists and behavioral monitoring. All that being said, if you have a legitimately better idea, voice it in a meaningful way, and I am sure they will at least listen. That was the part _in_their_post_ about "taking community feedback" you must have missed.

[rgbrenner]

The underlying assumption of TLS-SNI-01/02 is that IP ownership = ownership of all domains using that IP. But as long as SNI is part of the TLS standard, that is an incorrect assumption.

So the affected hosts that need to be in this list is every shared hosting IP -- not just those that use LE, but all of them. They can then remove IPs once they verify LE-specific workarounds have been applied.

But they need to scan IPv6 as well.. since, although SNI is less necessary with IPv6, it can still be used with IPv6. So they need to scan the entire IPv4 and IPv6 address space (regularly.. to keep the list updated) looking for shared IPs. And we'll assume their scanner won't be blocked or interfered with in any way, so they'll actually be able to determine which IPs are being shared.

As far as a solution, I think I've been very clear in my other posts. The underlying assumption in this protocols is incorrect, and that makes them fatally flawed. They should be discontinued entirely (at least until we've all moved to IPv6 and SNI has been removed from the TLS standard).

[e_d_e_v]

I think IP ownership does = stewardship of all domains using that IP from a DV certificate perspective. The moral of the story is don't point a domain you value at a sketchy host's IP. The list of the things that need to happen to work around poorly managed hosting providers in this scenario is overblown. No one should host anything they think is important on shared hosting. Full stop. That is about as much of a reality as the above statements around SNI, but it is something individuals can actually act upon.

[dec0dedab0de]

Since the issue is only domain based, Could they start with a list of domain names instead of every IP?

[rgbrenner]

They would need to resolve all of the domains, and compile a list of IPs.. but one problem that jumps out to me is geodns/round robin policies/etc. If LE makes a dns request, they can't be guaranteed that they're seeing all of the IPs for a domain.

For example.. if a number of domains are at a CDN (that does not use anycast)... they may all resolve to a single IP (to LE, from the location they're requesting from)... but really that CDN may have hundreds of IPs that are all valid for those domains. LE would then add that single IP to the list as a shared IP, but LE verification requests sent to those other IPs would still be vulnerable.

[e_d_e_v]

So would a whitelist of providers/ip's be sufficient? Whitelists can be much easier to maintain.

[mdhardeman]

It may make sense as a stopgap measure.

Even then, you have a CA sticking out its neck on the assurances of a web host that isn't accountable to the root programs and isn't accountable to the CAB Forum.

If that web host swears they don't have the issue, LE tests them, whitelists them, and then subsequently... at a customer request or just to be nasty the web hosts reverts and allows this exploit, the web host won't be held accountable. The CA will.

[e_d_e_v]

Ok, in this scenario, we have a web host with an adversarial entity on its server, that commits a crime.

By the same token, if that web host were hacked and used to obtain a nefarious certificate, would the CA be accountable? It seems to me that, as a customer, if you point your domain (which you must do somehow) at a hosting provider, then any DV issued with that hosting providers' infrastructure should be considered to be the responsibility of the hosting provider and domain owner. I think you and rgbrenner are making perfectly valid points for high-value infrastructure, which has in my view very little to do with these hosting providers. The fact that people can upload certificates at all for domains which they have not proved (to the hosting provider) ownership of is disturbing in and of itself, even if it is quite common.

[mdhardeman]

Even if you could find them all and make automatic determinations as to whether or not they facilitate the vulnerability. (You really can't automate that as you need to be a customer of the host to really attempt to pull off the exploit.)

Even if... You would only know for the set of web hosts for the time period you checked each one.

New ones come and old ones die every day.

[zeroimpl]

You don't need to keep a master list of IP addresses up to date, you only have to test an IP when a request for a cert comes in from that IP.