What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 144 Stack Exchange communities.

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

enter image description here

share|improve this question
the answer is don't do that ...because we don't support https:// on the sites. –  Zypher Dec 21 '11 at 21:51
@Zypher That's why this is tagged [feature-request] :P –  NullUserException อ_อ Dec 21 '11 at 21:52
To supplement @Zypher's comment, see this answer. –  Tim Stone Dec 21 '11 at 21:52
Why is accessing stackexchange over https desirable? I really want to know! –  Kirk Woll Dec 21 '11 at 22:23
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 Dec 22 '11 at 2:53
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) –  hbdgaf Jun 11 '12 at 16:36
Wait, which sites support SSL? I tried it on Information Security and it failed. Same for Security.BlogOverflow. –  Iszi Jun 27 '12 at 15:43
@KirkWoll: Is https ever not desirable? The lack of it just makes me feel vulnerable. –  Boann Dec 11 '12 at 15:37
@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 Apr 10 '13 at 15:24
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? –  Shadow Wizard Apr 12 '13 at 7:41
Ooh, I spoke too soon. Nice one, folks! –  halfer Jun 24 '13 at 22:28
It’s on it’s on STACK OVERFLOW WITH HTTPS –  minitech Dec 17 '13 at 20:05
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 Mar 7 '14 at 19:30
@Zypher Google is about to start using HTTPS support in their ranking algorithm: googleonlinesecurity.blogspot.ca/2014/08/… –  Stijn Aug 7 '14 at 11:52

5 Answers 5

up vote 47 down vote

Update 2015: stackoverflow.com scores rating A on the SSL Labs server test, as does say security.stackexchange.com. That's in the top 13% of sites according to the SSL Pulse survey. Thank you Stack Overflow, and well done.

Known issues:

  1. https://www.stackoverflow.com should redirect to https://stackoverflow.com rather than http://stackoverflow.com

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.
share|improve this answer
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 –  Nick Craver Jun 27 '13 at 23:30
Hi Nick. Brilliant! I didn't know any of that was going on. That's really cool, thanks for doing it. –  Colonel Panic Jun 27 '13 at 23:36
@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 Jul 26 '13 at 3:13
@e-sushi They did ask on Webmasters –  Mad Scientist Jul 26 '13 at 8:42
@MadScientist Darn, I missed that. My bad — thanks for the heads-up… much appreciated! –  e-sushi Jul 26 '13 at 9:14
No staff member gave an official response, so I'm awarding you the bounty. –  minitech Dec 25 '13 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?" –  Duncan Jan 16 '14 at 14:16

I just want to point out that once you've setup one SSL certificate, it becomes the default certificate (at least in my experience). So even though they may not even have SSL setup for other domains, the default is still creeping over onto them when you attempt to access them via HTTPS.

They did say they're still working on it not too long ago (and it hasn't even been 6 - 8 weeks). I believe we're just seeing the default certificate bleeding through onto other sites which aren't even setup for HTTPS yet. If I attempt to access some random website on my server via HTTPS that isn't setup with a certificate, it attempts to use a certificate from another site (the first one which was defined) and the browser throws a fit because the domains don't match.

Just thought I'd throw that out there.

share|improve this answer
So 2 years ago, we got a 6-8 weeks, and a status-planned. WHAT NOW? –  Cole Johnson Jan 27 '14 at 0:15
@Cole patience, it will all be ready in 6-8 years. Or decades. –  Shadow Wizard Feb 10 at 21:06

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).
share|improve this answer
Regarding the meta sites, alas, they don't. See Nick Craver's blog post for more details. –  Ilmari Karonen Feb 23 '14 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 Mar 2 '14 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 May 2 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. –  Kevin Brown May 12 at 2:04

Dear Stack Exchange, if you have confidence in your https sites, consider deploying HSTS (Strict Transport Security). It defends against the sslstrip attack.

In order to stop SSL stripping, we need to make HTTPS the only protocol. We can't do that for the whole Internet, but we can do it site-by-site with HTTP Strict Transport Security (HSTS). HSTS tells browsers to always make requests over HTTPS to HSTS sites.

Paypal, Gmail, Twitter all do HSTS to protect their users.

Browser support is pervasive (it's even coming to Internet Explorer). Chrome and Firefox actually ship with a preloaded list of sites, making it impossible to browse to http://gmail.com rather than https://gmail.com.

A second reason to do HSTS is because browsers understand it as a badge from the web developer 'I know https' and take a stance on mixed content issues and certificate problems. Browser developers deeply regret ever allowing these, but they have to continue, because so many websites are flawed. Recall the user guide for your office intranet site that actually teaches people to click past certificate errors:

You may get a message saying 'There is a problem with this websites security certificate'. If you do, this is normal. Just click 'Continue to this website'.

No no no! If you see a certificate error on https://gmail.com, it is a real possibility you are being attacked. In the case of HSTS, browsers remove the bypass button and stop users from shooting themselves in the foot (as they've been taught to do).

More HSTS advocacy:

share|improve this answer
It's on the roadmap. (As an aside, in theory I could imagine that people who bring their own device into some corporate environment that does not like HTTPS, won't be too happy their browser is set to stick to HTTPS if they ever use Stack Exchange with HTTPS elsewhere. But even if that would happen in real life, I don't really care about those users.) –  Arjan Sep 22 '14 at 18:52

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.

share|improve this answer
What content here do you believe needs securing so badly? –  Oded May 12 '14 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. –  Gilles May 12 '14 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 May 12 '14 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 May 12 '14 at 22:53
@Fluorocarbon What makes you think that NSA doesn't have access to SE's servers? Methinks there is a hole in your tinfoil hat. –  Gilles May 12 '14 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 May 12 '14 at 23:03
@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. –  Gilles May 12 '14 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 May 12 '14 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 May 12 '14 at 23:07
@Fluorocarbon Err...And if you "question the trust" of the people running StackExchange, doesn't that make HTTPS irrelevant? –  Xander May 12 '14 at 23:10
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 May 12 '14 at 23:13
...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 May 13 '14 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 Sep 21 '14 at 1:13

You must log in to answer this question.

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