3 ms·

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 fi

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.

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.