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":

Security warning

  • 11
    the answer is don't do that ...because we don't support https:// on the sites.
    – Zypher
    Commented Dec 21, 2011 at 21:51
  • 20
    @Zypher That's why this is tagged [feature-request] :P Commented Dec 21, 2011 at 21:52
  • 1
    To supplement @Zypher's comment, see this answer.
    – Tim Stone
    Commented Dec 21, 2011 at 21:52
  • 4
    Why is accessing stackexchange over https desirable? I really want to know!
    – Kirk Woll
    Commented Dec 21, 2011 at 22:23
  • 19
    @KirkWoll Things like Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?
    – Tim Stone
    Commented Dec 21, 2011 at 22:28
  • 12
    status-deferred -- deferred until when? The original hyperbolic request to help avoid firesheep was over a year ago... seems like now would be a good time to address it.
    – sarnold
    Commented Dec 22, 2011 at 2:53
  • 2
    It's my understanding that with a valid reason, some certificate authorities can be persuaded to issue signing certificates. I think something as vast as the stackexchange network should entertain the idea of getting a signing certificate (also due to rapid changes in domain names for forward compat) Commented Jun 11, 2012 at 16:36
  • 1
    Wait, which sites support SSL? I tried it on Information Security and it failed. Same for Security.BlogOverflow.
    – Iszi
    Commented Jun 27, 2012 at 15:43
  • 15
    @KirkWoll: Is https ever not desirable? The lack of it just makes me feel vulnerable.
    – Boann
    Commented Dec 11, 2012 at 15:37
  • 4
    @Zypher what is the status of this feature? I get the feeling that this is not really being considered at all - the state of SSL (from my point of view) is the same as in 2011.
    – Shade
    Commented Apr 10, 2013 at 15:24
  • 4
    Not expert on this but won't this also help bypass company Firewalls that block JS files for more and more users who come here complaining they can't add comments and such stuff? Commented Apr 12, 2013 at 7:41
  • 1
    Ooh, I spoke too soon. Nice one, folks!
    – halfer
    Commented Jun 24, 2013 at 22:28
  • 9
    – Ry-
    Commented Dec 17, 2013 at 20:05
  • 2
    Note that quick links (the short ones with /a/ in them, and so on) redirect from HTTPS to HTTP. It would be good to go the other way, or at least not degrade security automatically :-).
    – Glyph
    Commented Mar 7, 2014 at 19:30
  • 1
    @Zypher Google is about to start using HTTPS support in their ranking algorithm: googleonlinesecurity.blogspot.ca/2014/08/…
    – Stijn
    Commented Aug 7, 2014 at 11:52

5 Answers 5


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.
  • 30
    When someone says "there's no excuse", it usually means they don't know what it actually takes to setup SSL on a specific platform. It isn't as simple as you are laying out here, have a read on what we have to do Commented Jun 27, 2013 at 23:30
  • Hi Nick. Brilliant! I didn't know any of that was going on. That's really cool, thanks for doing it. Commented Jun 27, 2013 at 23:36
  • 4
    @NickCraver Your blog-post reads "Now let’s say we do all of that and it all works, what happens to our google rank when we start sending everyone to HTTPS, including crawlers? We don’t know, and it’s a little scary…" Now, why didn't you just ask your own community? I mean — that's what it's for, isn't it? I know there are ample people around here who could have provided a relaxing answer to those worries, based on experiences shifting alike site sizes towards HTTPS. I'm really wondering why you didn't simply ask…
    – e-sushi
    Commented Jul 26, 2013 at 3:13
  • 10
    @e-sushi They did ask on Webmasters Commented Jul 26, 2013 at 8:42
  • @MadScientist Darn, I missed that. My bad — thanks for the heads-up… much appreciated!
    – e-sushi
    Commented Jul 26, 2013 at 9:14
  • No staff member gave an official response, so I'm awarding you the bounty.
    – Ry-
    Commented Dec 25, 2013 at 18:48
  • -1 I don't understand the purpose of this answer. It doesn't address the question at all. This answer only makes sense if the question is "Hmmm, should we use SSL? Are there any benefits or drawbacks associated with it?" Commented Jan 16, 2014 at 14:16
  • You should probably update the part on HTTP/2
    – Nemo
    Commented Oct 12, 2015 at 19:23
  • Cool. Unfortunately, this is still a problem causing mixed content warnings on a lot of pages (or broken images for users who disable mixed content entirely): meta.stackexchange.com/questions/221304/… Commented Jan 9, 2016 at 19:15
  • 2
    @NickCraver Your blog post was enlightening at the time, but 3 years have passed since. Would you consider an update after you've completed your current series of blog posts?
    – Mast
    Commented Sep 12, 2016 at 12:41

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.

  • Chat doesn't work: it's linking to some Javascript over plain HTTP, which is a mixed-content error if you access the chat sites over HTTPS.

  • 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 (http://cdn.sstatic.net/italian/img/icon-48.png).

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. //cdn.sstatic.net/foo).

Some remaining certificate errors:

  • Community blogs, e.g. https://security.blogoverflow.com/2014/01/qotw-49-how-can-someone-go-off-web-and-anonymise-themselves-after-a-life-online/
  • Meta sites for those sites that use subdomains of stackexchange.com, such as https://meta.apple.stackexchange.com/, 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).
  • Regarding the meta sites, alas, they don't. See Nick Craver's blog post for more details. Commented Feb 23, 2014 at 17:15
  • The "Meta sites for those sites that use subdomains of stackexchange.com" issue is a biggie (in the sense that it affects many people). When I log in on a main site using SE as my OpenID site, it brings me to https://...; if I then follow the link to the meta site, it gives me the error.
    – msh210
    Commented Mar 2, 2014 at 19:07
  • Subdomains seem to work now, but not sub-subdomains: discuss.area51.stackexchange.com NET::ERR_CERT_COMMON_NAME_INVALID Subject: ssl8217.cloudflare.com Issuer: GlobalSign Organization Validation CA - G2 Expires on: 17/ott/2015
    – Nemo
    Commented May 2, 2015 at 7:21
  • @Nemo That's because CloudFlare, who is issuing the certificates, is only generating a wildcard certificate for the root (*.stackexchange.com) and that doesn't apply to *.*.stackexchange.com. Commented May 12, 2015 at 2:04

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.

Adding forced 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.

Overall Summary

I think it should be a requirement, without a second though, as the future of the web is at stake.

  • 3
    What content here do you believe needs securing so badly?
    – Oded
    Commented May 12, 2014 at 11:36
  • @Oded An active MITM can inject JS content — this is a concern to the .001% of people who only ever use signed software (and who have more confidence than they should on their hardware) (and these people know how to use HTTPS Everywhere, so this is an argument for allowing HTTPS, not for mandating it). Also the identity of posters, but a MITM (even a passive one) can easily deduce it by timing correlation. Net neutrality is irrelevant since traffic to SE can be detected by IP. Commented May 12, 2014 at 13:12
  • @Oded, then you think that StackExchange is going to actually pay all of the ISPs to be on the "Fast Lane" when this isn't taken care of? I doubt that, so you being able to do your Moderation and using the site is going to be near impossible.
    – Traven
    Commented May 12, 2014 at 22:52
  • @Gilles If you have read the article, they are going to be doing this to all of the computers that they can, and as we know, the easiest way to spread their malware is through advertisements on websites, which are not secured (usually).
    – Traven
    Commented May 12, 2014 at 22:53
  • 4
    @Fluorocarbon What makes you think that NSA doesn't have access to SE's servers? Methinks there is a hole in your tinfoil hat. Commented May 12, 2014 at 22:55
  • @Gilles We already know that SSL/TLS is not compromised because they had to foce Lavabit to give the private keys for their email service. That takes that issue out of the equation easily.
    – Traven
    Commented May 12, 2014 at 23:03
  • 2
    @Fluorocarbon That's the point: you have no way to know that NSA doesn't have SE's private keys, which would make SSL irrelevant. Commented May 12, 2014 at 23:05
  • As to the net neutrality argument, it's completely specious. Either traffic to/from a host is throttled, or it isn't. HTTPS doesn't factor into this equation at all. HTTPS traffic to a host can be throttled as easily as HTTP traffic.
    – Xander
    Commented May 12, 2014 at 23:07
  • @Gilles Then that allows us to question the trust of the people who are running StackExchange and if they are working or not working with the NSA.
    – Traven
    Commented May 12, 2014 at 23:07
  • 3
    @Fluorocarbon Err...And if you "question the trust" of the people running StackExchange, doesn't that make HTTPS irrelevant?
    – Xander
    Commented May 12, 2014 at 23:10
  • 1
    Almost all major websites have given their views regarding what has happened with Edward Snowden. The team who runs StackExchange has not (I am looking on Google regarding it as we speak). I think they should give their stance on it also so we know for sure instead of us debating about this.
    – Traven
    Commented May 12, 2014 at 23:13
  • 1
    ...almost all major websites? Or in reality, a fraction (<0.01%) have given their views. To be honest, I can't think of any reason to care about SE views on Snowden. It doesn't affect my interactions with SE one iota. It is a public site - data leakage (a la Snowden) is not an issue.
    – Rory Alsop
    Commented May 13, 2014 at 8:08
  • There is a famous quote, which is going to be proven true soon. "They came for the jews, I said nothing. They came for the poor, I said nothing. Then they came for me. There was no one to speak for me." This situation is getting worse month by month, not better. We do need to still force HTTPS on StackExchange and help fight net neutrality and the NSA sniffing in our privacy.
    – Traven
    Commented Sep 21, 2014 at 1:13

Not the answer you're looking for? Browse other questions tagged .