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

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)
– RobotHumansJun 11 '12 at 16:36

1

Wait, which sites support SSL? I tried it on Information Security and it failed. Same for Security.BlogOverflow.
– IsziJun 27 '12 at 15:43

15

@KirkWoll: Is https ever not desirable? The lack of it just makes me feel vulnerable.
– BoannDec 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.
– ShadeApr 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?
– Shadow WizardApr 12 '13 at 7:41

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 :-).
– GlyphMar 7 '14 at 19:30

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.

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.

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

@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-sushiJul 26 '13 at 3:13

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 JonesJan 16 '14 at 14:16

You should probably update the part on HTTP/2
– NemoOct 12 '15 at 19:23

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

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

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.
– msh210Mar 2 '14 at 19:07

@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 BrownMay 12 '15 at 2:04

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

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.

What content here do you believe needs securing so badly?
– OdedMay 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.
– GillesMay 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.
– TravenMay 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).
– TravenMay 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.
– GillesMay 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.
– TravenMay 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.
– GillesMay 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.
– XanderMay 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.
– TravenMay 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?
– XanderMay 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.
– TravenMay 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 AlsopMay 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.
– TravenSep 21 '14 at 1:13