So it looks like Stack Exchange now supports HTTPS (to some extent). Which is awesome! But there are a few problems, the main one being that some content is delivered over the CDN, which is plain HTTP. This causes browsers to complain about "unsecured content":
Update May 2017: Stack Overflow is now https by default throughout and not just for login. Thank you, and well done.
The SSL Labs server test scores stackoverflow.com grade A+.
HTTPS should be universal. Why? The status quo of 'http except for ecommerce sites' is dire:
- Intelligence agencies are conducting mass survillance (NSA's Prism, GCHQ's Tempora) against everyone.
- Malicious/compromised networks can steal accounts. (Should you trust your ISP, your mobile network, the wireless at the cafe? No, no, no!)
Again, HTTPS should be universal. There's consensus.
- Facebook, Twitter, Google are all HTTPS. Their reputation depends on their users' security.
- HTTPS is made mandatory by the http 2.0 draft specification
Yet many sites are reluctant to adopt HTTPS. They say:
- It's expensive
- It's difficult
Google refute the expense https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
The ‘S’ in HTTPS stands for ‘secure’ and the security is provided by SSL/TLS. SSL/TLS is a standard network protocol which is implemented in every browser and web server to provide confidentiality and integrity for HTTPS traffic.
If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.
And encourage every site to shore up their security https://www.imperialviolet.org/2011/02/06/stillinexpensive.html
All sites should deploy HTTPS because attacks like Firesheep are too easy to do. Even sites where you don't login should deploy HTTPS (imagine the effect of spoofing news websites at a major financial conference to headline “Market crashes”). And you should use HSTS to stop sslstrip.
SSL is just not that computationally expensive any more. Here are the real costs of HTTPS deployment these days:
- Virtual hosting still doesn't work in the real world because Microsoft never put support into Windows XP.
- Sorting out mixed content issues on your website.
HTTPS basically works now on all of the main sites; most certificate errors seem to be resolved. But I found a few glitches, besides the CDN issue already mentioned.
Automatic re-login (on sites that you have an account on but haven't visited in a while) probably isn't working (not certain if this is related).
The site logos on the list of sites don't show up, because the links to the CDN are HTTP (
The issues seem to be mainly due to explicit
http:// links to the Stack Exchange CDN (
foo.sstatic.net), to images hosted on stack.imgur, and to a copy of JQuery hosted by Google at http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js. All of these now apparently support HTTPS. So hopefully, these could be fixed without too much effort by using protocol-relative URLs (e.g.
Some remaining certificate errors:
- Community blogs, e.g.
- Meta sites for those sites that use subdomains of
stackexchange.com, such as
https://meta.tex.stackexchange.com/. Note that the certificate claims to cover the nonexistent
*.meta.stackexchange.com; it should be
meta.*.stackexchange.com(not sure if certificates allow using wildcards like that though).
Update 2017-05-22: All Stack Exchange Q&A sites are now delivered over HTTPS. If you're very curious about the details, I wrote up a fairly detailed description here.
Chat and secure cookies are up next.
It's taken a long time to prep, but the HTTPS transition for all of our properties is now underway.
HTTPS still doesn't work right for per-site metas.
One way to fix this might be to extend the list of domains covered to include all the SE sites. Another would be to have different security certificates for each site (see Information Security.SE where things work better, for example). It seems like the work to maintain this would be dull but definitely feasible. One person could knock it out in a matter of hours, and it doesn't even have to be a very highly skilled person especially after a couple training examples. Or, perhaps, someone could write a script. Oldmud0 suggested that SE develop an intermediate CA.
The suggestions above were deleted from here, which was on a question closed as a duplicate of this, which was closed as a duplicate of the present question as apparently that's what is supposed to happen for all requests to improve HTTPS support (as opposed to e.g. asking about reasons behind certain SSL implementation decisions).
The Issues with the NSA
I say that this is now a requirement with more and more information from leaks with Edward Snowden. Thing's are not getting better in that aspect, it seems like the more information comes out, the more it is getting worse.
An example of this is the NSA wanting to infect millions on computers with Malware.
Adding support for
https:// and forcing all content can help security and keep this from happening, because they can't tamper with the content which is being served up to us.
Issues with Net Neutrality
Also, with net neutrality being a major issue within the United States, StackExchange can be throttled down for users who are on it quite a bit posting questions, answering questions, commenting, and viewing questions.
https:// here will also keep them from discriminating against what sites we are viewing, what we are doing on those sites, and everything we do online.
I think it should be a requirement, without a second though, as the future of the web is at stake.