On Apr 19, 2010, at 6:54 AM, Florian Weimer wrote:
* Patrick W. Gilmore:
Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that.
Agreed.
When do you expect Windows XP & earlier versions to be a small enough segment of the userbase that businesses will consider DoS'ing those customers? My guess is when the cost of additional v4 addresses is higher than the profit generated by those customers.
Put another way: Not until it is too late.
I'm not so sure. Name-based virtual hosting for plain HTTP was introduced when Windows NT 4.0 was still in wide use. It originally came with Internet Explorer 2.0, which did not send the Host: header in HTTP requests.
NT4 was never heavily adopted by users. Also, not nearly as many billions were being sold on e-commerce sites.
Anyway, I think the TLS thing is a bit of a red herring. It might be a popular justification for IP space at the formal level, but real-world requirements are a bit more nuanced. FTP and SSH/SFTP do not support name-based virtual hosting, so if you're a web hoster and structured things around "one IPv4 address per customer", then there might be another obstacle to collapsing everything on a single IPv4 address. It's also difficult to attribute DoS attackers at sub-HTTP layers to a customer if everything is on a single IPv4 address, making mitigation a bit harder.
Since the vast majority of non-SSL HTTP is served off shared IP addresses, I would have to disagree. Also, it is trivial to dump FTP/SSH sessions into the correct directory on a shared backend system. So SSL does seem to me to be the big problem with the hosting side of the house. But end of day, we do agree. I do not see the growth in certs being the limiting factor here. There are far more users than websites, so even if we could wave a magic wand and get back all HTTP/SSL IP addresses, we would still have a large problem. -- TTFN, patrick