3 ms·
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 browse
by 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 agoYou 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.