
If You Can Read This, You're SNIing - mmastrac
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
======
mmastrac
One of the more interesting facts from this was that Python2 _will_ be
supporting SNI out-of-the-box, and some of the related discussion on what will
now be pushed into the 2.7 release:

[http://legacy.python.org/dev/peps/pep-0466/](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.

~~~
jccooper
I say hurrah! There is an awful little dance you can do to make SNI work in
2.7 with requests but it is way too complicated for most deployments:

[https://github.com/kennethreitz/requests/blob/master/request...](https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/contrib/pyopenssl.py)

I've actually done this once. Took all day.

~~~
Lukasa
Yeah, we're not delighted about how complicated this is, but it's really the
best we could do. =( To be clear though, Requests only requires the three
packages be installed, it'll do everything else automatically.

Actually, is there interest in this being an installable add-on? Meaning you'd
run: pip install requests[SNI] to get it?

~~~
jccooper
I'm just glad it exists at all. Saved my bacon wrt backend toolchain when I
set up SSL through App Engine.

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.

------
agwa
It looks like browsers basically all support SNI now, but unfortunately it
also looks like that if you require SNI, you'll be giving up traffic from a
fair number of RSS readers and search engine spiders, which makes this a non-
starter for me. I'm surprised the author is OK giving up those 263 NewsBlur
subscribers. I hope these RSS readers and spiders get fixed soon.

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.

~~~
eli
All people using browsers on a modern OS support it. I've still got about 9%
of traffic on Windows XP.

~~~
icebraining
Using Chrome or Firefox on Windows XP also works. It's only Internet Explorer
that's screwed up.

~~~
eli
Good point! That looks like it cuts it in half -- 4 or 5%.

------
liotier

      > == Unknown
      > Not sure about these. shrug
      > - Gregarius/0.6.0 (+http://devlog.gregarius.net/docs/ua)
    

This is from Gregarius - my long favorite RSS/Atom aggregator, written in PHP:
[http://sourceforge.net/projects/gregarius/](http://sourceforge.net/projects/gregarius/)
(a bit dead nowadays... I'll have to migrate to day)

~~~
mbi
Author of Gregarius here, have a hug. But yes: that project _is_ dead.

~~~
pas
After the notorious shutdown of Google Reader I hoped to just resurrect my old
Gregarius deployment and was forced to face the projects death; so, what are
you using instead nowadays? (Or, are you using any RSS/Atom reader at all?)

~~~
tprynn
Not the author, but if you want to host your own you should consider goread
([https://github.com/mjibson/goread](https://github.com/mjibson/goread)) or
ttrss ([http://tt-rss.org/redmine/projects/tt-rss/wiki](http://tt-
rss.org/redmine/projects/tt-rss/wiki)). Goread.io is the hosted version of
goread if you don't mind paying the $3 per month. Otherwise you have feedly,
newsblur, theoldreader, ..., but goread is really the closest to Google Reader
(clean/fast UI, keyboard shortcuts are the reason I pay).

~~~
liotier
After much consideration, after using Lilina and then Gregarius with the
Lilina theme when Lilina itself could not handle the number of inbound feeds
anymore, I'm inclined to choose tt-rss... But I have not migrated yet.

------
abritishguy
SNI is the default for Google App Engine - as market share of SNI sites
increases the few RSS readers that don't currently support it will be forced
to update or be ditched in favour of ones that do.

We shouldn't let old code hold back the web.

~~~
tombrossman
Agreed. You can probably drop SSL connections in favour of TLS only if you do
this, too. I've done this on my work and personal sites and everything works
fine for modern browsers.

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.

~~~
markuskobler
I have taken exactly the same stance which has the added benefit you can also
drop the vulnerable RC4 cyphers.

[https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weakne...](https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses)

------
msiebuhr
One.com uses SNI in order to sell SSL-enabled websites for somewhere around
$2.5/month.

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.)

~~~
smw
Why is it impossible to buy web hosting from you without buying or
transferring a domain?

~~~
msiebuhr
I believe it is possible, if you beg the support enough.

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.

------
stesch
You can have SNI on Windows XP if you use a browser instead of Internet
Explorer.

------
danielsju6
FYI it's not just IE and some oddballs you have to worry about.

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.

------
Scramblejams
Am I the only one deeply disappointed by SNI? Having the domain going out over
plaintext is a major step down in privacy from the way it was before.

(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.)

~~~
oakwhiz
Wouldn't it be possible to engineer the protocol in such a way that the domain
that you want to go to is not publicly identifiable?

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

~~~
icebraining
Using DNS, you can usually find all the domains a certain IP hosts[1], so the
attacker could just do the same as the server to find the target domain.

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...](http://www.ietf.org/mail-
archive/web/tls/current/msg11823.html)

[1] [http://reverseip.domaintools.com/](http://reverseip.domaintools.com/)

------
bigdubs
.net running on windows 7+ System.Net.WebRequest should support TLS SNI, the
test I just ran on my machine worked fine (windows 7, .net 4.5)

    
    
      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());
      }
    

As far as I know System.Net.Security.SslStream does NOT support TLS+SNI
though.

------
Corrado
I really, really hope SNI takes off soon. Amazon just added SNI capability to
their load balancers and it allows us to avoid spending $600/month in fees.
Apparently, when you host a normal TLS connection on an ELB they have to
provision an IP address for every endpoint in their network, which costs a lot
of money. Using SNI allows them to use a single ELB endpoint for multiple
domains, which saves us a ton of money. :)

------
tedchs
Looks like the web crawlers for Bing and Yahoo are not sending SNI, according
to this reporting. Can anybody corroborate?

------
snw
rawdog/2.19 from the "Unknown" category is an RSS aggregator [1] that should
hopefully get fixed with the mentioned python update...

[1] [http://offog.org/code/rawdog/](http://offog.org/code/rawdog/)

------
kachnuv_ocasek
I find it ironic that when I try REDbot the page, I get 403 "TLS SNI
Required."

~~~
fhars
That is not ironic, that is the point of the page: identify broken clients.

~~~
BrandonM
Perhaps you missed that redbot.org is now one of the sites using SNI? That
means that the tool can no longer connect to itself:
[https://redbot.org/?uri=https%3A%2F%2Fredbot.org](https://redbot.org/?uri=https%3A%2F%2Fredbot.org)

------
jacquesm
Why would you host a blog on a https url at all?

~~~
MichaelGG
Why not? Why shouldn't everything be encrypted? Yes, you're probably only
leaking the specific page you visit, but the principle stands.

~~~
rlpb
I like the idea of information that is public (eg. a blog, as opposed to your
activity in your favorite webapp) being easily cached.

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.

~~~
icebraining
It'd be nice if we had a signing mechanism; it could reuse most of the
mechanics of SSL encryption (same certs, same algorithms) and it'd provide
tampering-proof communications would hindering caching. And it could even be
done statically, without requiring more servers resources per request (e.g. as
a step during static site generation).

