187

This question already has an answer here:

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

marked as duplicate by Jason C, ShaWiz feature-request May 24 '17 at 10:15

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 11
    the answer is don't do that ...because we don't support https:// on the sites. – Zypher Dec 21 '11 at 21:51
  • 20
    @Zypher That's why this is tagged [feature-request] :P – NullUserException อ_อ Dec 21 '11 at 21:52
  • 1
    To supplement @Zypher's comment, see this answer. – Tim Stone Dec 21 '11 at 21:52
  • 4
    Why is accessing stackexchange over https desirable? I really want to know! – Kirk Woll Dec 21 '11 at 22:23
  • 19
  • 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 Dec 22 '11 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) – RobotHumans Jun 11 '12 at 16:36
  • 1
    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
  • 15
    @KirkWoll: Is https ever not desirable? The lack of it just makes me feel vulnerable. – Boann Dec 11 '12 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 Apr 10 '13 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? – ShaWiz Apr 12 '13 at 7:41
  • 1
    Ooh, I spoke too soon. Nice one, folks! – halfer Jun 24 '13 at 22:28
  • 9
    It’s on it’s on STACK OVERFLOW WITH HTTPS – Ry- Dec 17 '13 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 Mar 7 '14 at 19:30
  • 1
    @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
70
+550

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 – 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
  • 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 Jul 26 '13 at 3:13
  • 10
    @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. – Ry- 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 Jones Jan 16 '14 at 14:16
  • You should probably update the part on HTTP/2 – Nemo Oct 12 '15 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/… – Christopher Jan 9 '16 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 Sep 12 '16 at 12:41
7

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. – 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 '15 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 '15 at 2:04
7

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.

0

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

-4

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 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
  • 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. – 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
  • 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. – 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
  • 3
    @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
  • 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 May 12 '14 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 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

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