3 ms·

"This means you cannot have multiple HTTPS sites hosted from the same IP address." Is that some kind of joke? Yes you can, unless you want to support very old

by zwetan 10y ago

"This means you cannot have multiple HTTPS sites hosted from the same IP address." Is that some kind of joke? Yes you can, unless you want to support very old browsers [0] which would defeat the whole purpose of using SSL/TLS in the first place. Maybe have a look at Mozilla Security/Server Side TLS [1] Also SSL certs are issued for FQDN, not IP addresses (unless the IP is public and owned but still it is considered deprecated now [2]). [0]: https://blogs.msdn.microsoft.com/ieinternals/2009/12/07/understanding-certificate-name-mismatches/ https://blogs.msdn.microsoft.com/ieinternals/2009/12/07/unde... [1]: https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS [2]: https://www.digicert.com/internal-names.htm https://www.digicert.com/internal-names.htm

ClashTheBunny 10y ago
The article explains that SNI isn't working: > But while this is widely supported, it is not supported ubiquitously. I've personally had a hell of a time fighting with mobile browsers when relying on SNI. On the other hand, IP addresses are cheap. Like, $1/mo or less, cheap. So buck up and grab an distinct IP for your HTTPS sites. Avoiding the headache of some device/browser combos not working will pay for itself 100 times over.
- zwetan 10y ago
  So that means you will use pre TLS v1.0 to support those browsers that can not deal with SNI. You must feel very smart to be able to support old Android browsers like Gingerbread which represent 1% of the Android market share [0], and iOS pre v4.0 browsers which represent less than 0,1% of the iOS market share [1]. Now according to TLS/SSL support history of web browsers [2] your server is vulnerable to BEAST, POODLE, CRIME, etc. Congrats your SSL cert is useless. [0]: https://developer.android.com/about/dashboards/index.html https://developer.android.com/about/dashboards/index.html [1]: https://david-smith.org/iosversionstats/ https://david-smith.org/iosversionstats/ [2]: https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo...
  - liquidise 10y ago
    You are making incorrect assumptions and running with them. As i stated in the article, and on this HN comment page, my issues were not with antiquated browsers. Safari on my iPhone 7 was failing to connect to sites other browsers were handling fine. I went down this rabbit hole of IP-based differentiation specifically because of that issue. There seems to be some sense that i published an article about the hardest way to achieve this. I promise had relying on SNI worked liked i expected it to, the IP-based section of the article would be absent. But it didn't and, like i said, IP's are cheap. Adding 1 step to a process of ubiquitous support seems like a reasonable approach to me.

by zwetan 10y ago

ClashTheBunny 10y ago

The article explains that SNI isn't working: > But while this is widely supported, it is not supported ubiquitously. I've personally had a hell of a time fighting with mobile browsers when relying on SNI. On the other hand, IP addresses are cheap. Like, $1/mo or less, cheap. So buck up and grab an distinct IP for your HTTPS sites. Avoiding the headache of some device/browser combos not working will pay for itself 100 times over.

zwetan 10y ago
So that means you will use pre TLS v1.0 to support those browsers that can not deal with SNI. You must feel very smart to be able to support old Android browsers like Gingerbread which represent 1% of the Android market share [0], and iOS pre v4.0 browsers which represent less than 0,1% of the iOS market share [1]. Now according to TLS/SSL support history of web browsers [2] your server is vulnerable to BEAST, POODLE, CRIME, etc. Congrats your SSL cert is useless. [0]: https://developer.android.com/about/dashboards/index.html https://developer.android.com/about/dashboards/index.html [1]: https://david-smith.org/iosversionstats/ https://david-smith.org/iosversionstats/ [2]: https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo...
- liquidise 10y ago
  You are making incorrect assumptions and running with them. As i stated in the article, and on this HN comment page, my issues were not with antiquated browsers. Safari on my iPhone 7 was failing to connect to sites other browsers were handling fine. I went down this rabbit hole of IP-based differentiation specifically because of that issue. There seems to be some sense that i published an article about the hardest way to achieve this. I promise had relying on SNI worked liked i expected it to, the IP-based section of the article would be absent. But it didn't and, like i said, IP's are cheap. Adding 1 step to a process of ubiquitous support seems like a reasonable approach to me.