If You Can Read This, You're SNIing
mnot.net
mnot.net
http://legacy.python.org/dev/peps/pep-0466/
Since there's no other commentary yet, I'd just like to point out how much of a pain SNI has turned out to be for us in the release of the product I was just working on. Sure, major browsers all support it, but you get bit on things like automated testing tools (ie: Python2-based ones using old version of the requests library), third-party load-testing services (one we've contracted with did not support SNI but it's "on their roadmap"), Charles Proxy (we use this a lot for remote debugging on devices but SNI support is hit-and-miss), and all of the little things like old versions of cURL etc used in monitoring.
In the end we ended up moving back to virtual-IP-based SSL to support the tooling. I was a little sad when this happened.
https://github.com/kennethreitz/requests/blob/master/request...
I've actually done this once. Took all day.
Actually, is there interest in this being an installable add-on? Meaning you'd run: pip install requests[SNI] to get it?
I think my problems were with getting pyOpenSSL compiled for Windows and/or my way-too-old Ubuntu. Or maybe it was pycrypto as a deeper dependency. Something like that. I'm sure an add-on would be nice, though I'm not sure it would solve what I ran into. But with Python 2.7.7 coming up pretty soon, may not be worth the effort.
I don't think there's a point trying to send back an error document to clients that don't support SNI, since the client will get a certificate error before seeing any error that you send it. On the other hand, the clients that don't support SNI also look like just the type of clients that don't properly check certificates. If that's true, you're better off winging it without SSLStrictSNIVHostCheck and hoping that these old clients will ignore the certificate error and then be routed to the correct vhost anyways via the Host: header.
Because they're using Requests this should be a fairly trivial fix for them.
> == Unknown
> Not sure about these. shrug
> - Gregarius/0.6.0 (+http://devlog.gregarius.net/docs/ua)
There appears to be a fork on Github https://github.com/jphpsf/gregarius
May I ask why you decided to stop development ?
We shouldn't let old code hold back the web.
For example, the config for your Nginx server block can go like this, with no need to support SSL at all.
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
I realise this excludes some traffic and I'm okay with it.
https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weakne...
Edit: We have around 1.-something million websites, though I don't know how many of those have SSL enabled.
(Disclosure: I happen to work there.)
Some technical stuff wrt. SNI:
We waited a long time for the SNI-support to be widespread enough for us to provide to the customers. Despite we have a lot of users in the 'mom-and-pops' demographic, which typically tend to have older equipment, I'm not aware of widespread complaints about it.
It also turned out that most webservers can't handle being loaded with a few thousand SSL-certificates...
Finally, we were somewhat nervous about the rumored 'SSL/TLS has lots of CPU usage', but it didn't turn out to be an issue AFAIK.
I do know we strongly discourage it though, as it makes some parts of shared hosting hard for us; ex. quickly move your website to another IP in case of a DDoS attack.
Last time I experimented I found that Android's Downloads manager ([yes even KitKat] and probably some other popular Java clients while you're at it) have trouble with SNI. Worth noting if anyone else is thinking of switching.
(Yes, there's an additional leak in the form of a DNS lookup that has to happen, but as a client that's usually easy to address if you care.)
Edit: Actually now that I think about it, could they just sniff the certificate offered by the server and get the same info? If so that's unfortunate, but plenty of firewalls don't seem to be doing that, as I noted above with my youtube example.
The sites in question will likely be blocked soon enough, but it won't be because of SNI being less secure, it will be because more and more traffic will default to TLS - a development helped along by SNI, certainly - and the operators will notice and the gateway providers will add the required sniffing, covering both "old school" certts and SNI.
Something like this, perhaps?
1. Server sends a salt
2. Client sends hash of salt + target domain
3. Server computes hash of salt + target domain for all possible domains that it serves and compares to find out which one the client is requesting
That said, there's an argument going at the IETF list about encrypting SNI and the rest of the TLS handshake: http://www.ietf.org/mail-archive/web/tls/current/msg11823.ht...
using System.Net;
string url = "https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing";
var request = (HttpWebRequest)WebRequest.Create(url);
var response = (HttpWebResponse)request.GetResponse();
var resStream = response.GetResponseStream();
using(var sw = new System.IO.StreamReader(resStream))
{
Console.WriteLine(sw.ReadToEnd());
}
You might appreciate your ISP's web proxy cache if you live in New Zealand, for example.
It would be nice if everything magically worked in this case, but I don't think we're really there yet. And I'll admit there's a downside - SSL also buys you data integrity (eg. was the blog post modified in transit?) and you don't get that here.
Still, I'm not convinced about SSL-by-default for general public information websites (with an obvious exception for sensitive health or political sites, etc).
I also don't buy the "protect your readers' privacy" angle. To me, that's "provide your readers an illusion of privacy", since they still have to trust $random_website to not leak the logs they are able to gather. Readers who want identity privacy should use Tor or similar, and not be misled by https-everywhere.