12

In order to be more secure in my external transmissions, I tried to use https://serverfault.com and found that I could not login.

Actually I get a 403/HTTP Authentication request, but its not like going to http://serverfault.com site.
Is there a reason https browsing is not enabled for ServerFault and the other Stack Exchange sites?

  • 4
    You may also have noticed that the SSL certificate is for *.stackauth.com - not serverfault.com. Nice to see that people actually pay attention to and read SSL warnings from their browsers. – Mark Henderson Jul 21 '11 at 20:24
  • They did actually think about enabling SSL at one point in time (not too long ago actually) but decided not to for the reasons cited in Chopper's answer and Mark's comment thereto (referring to the expensive crypto accelerators necessary for a high traffic SSL site). – Chris S Jul 21 '11 at 20:25
  • I have the same response every time someone asks - we are working on it: meta.stackexchange.com/questions/69171/… – Zypher Mar 23 '12 at 20:27
  • So if you are working on it, the accepted answer is out of date. – Basil Mar 26 '12 at 16:26
  • After all the notes/comments to the contrary, I notice that my request has actually been fulfilled. Thanks! – mdpc Mar 26 '15 at 19:53
  • You can use https now. – Michael Hampton Oct 11 '16 at 20:48
  • still on some of sites, I get non-ssl redirect for meta... this one works, but I visited several today, mostly just to get one of the easiest "Holidays hats," but true !! – bourneN5years Dec 24 '16 at 20:32
6

But everything on StackExchange is publicly searchable and the actual OpenID authentication is secured over TLS - so there would be no point handling regular site traffic securely.

  • But why not allow it? Maybe I don't want my sessions to be eavesdropped on. – mdpc Jul 21 '11 at 20:11
  • 5
    But your "sessions" (i.e. new questions, answers, comments, chats etc.) are public domain, you don't get privacy with SE, at all (apart from login stuff) - so it'd be unnecessary load on the platform. – Chopper3 Jul 21 '11 at 20:18
  • 2
    Additionally, adding SSL to a website as highly trafficed as the Stack Exchange network is not nearly as simple as just installing a certificate. – Mark Henderson Jul 21 '11 at 20:25
  • 1
    +1 - To implement SSL on a site that doesn't pass sensitive auth data (you sign in with OpenID, right?) makes little sense. The overhead of doing SSL on front-end web servers (or the astronomical cost of hardware SSL accelerators) would be pretty hard to justify. – voretaq7 Jul 21 '11 at 20:34
  • Interesting point is that gmail allows for both http:: and https:: access (in fact, I believe https:: is the default access mode). Anyway, thanks for taking the time to more thoroughly discuss the reasoning involved. – mdpc Jul 21 '11 at 20:39
  • 4
    gmail deals with data you don't want other people to see (your email) :-) – voretaq7 Jul 21 '11 at 20:49
  • As an indication our hardware SSL/TLS boxes cost over £250k for around 65,000 SSL transactions per second - so quite expensive. – Chopper3 Jul 21 '11 at 20:50
  • 4
    @voretaq7 Session hijacking is the risk that SSL would prevent - while's it's obviously not nearly the level of value that someone's facebook or email session cookie would be, I don't think the "there's no need" reasoning really works in that context - the "it isn't worth it" reason is plenty valid, though! – Shane Madden Jul 21 '11 at 21:45
8

The biggest barrier standing in the way is that Gravatar doesn't support HTTPS, and Gravatars are a big part of StackExchange as a whole. There are a variety of other items that are included from 3rd party sites which would also prevent full SSL "green-bar" support. Until such items are fixed or engineered around (such as building an HTTPS-enabled Gravatar proxy-server), StackExchange will stay S-free.

  • 3
    I'd suggest that Gravatar likely isn't the issue here (although, other 3rd party items may well be a factor). Gravatar has supported SSL since 2008. Just use https://secure.gravatar.com instead of http://www.gravatar.com. For example: your gravatar over SSL. – cyberx86 Mar 25 '12 at 0:31
  • @cyberx86 Good to know about Gravitar. Looking at what these pages load, it seems they're pulling in some .js files from Places Not Here for a few reasons. – sysadmin1138 Mar 25 '12 at 0:34
  • You got me curious. As far as I can tell, all the sources appear to support SSL (with a green icon) 1) cdn.sstatic.com - SE's CDN (I was a bit surprised) - (https://cdn.sstatic.com) 2) www.gravatar.com - Gravatar - (https://secure.gravatar.com) 3) ajax.googleapis.com - JS library CDN - (https://ajax.googleapis.com) 4) www.google-analytics.com - Google Analytics - (https://ssl.google-analytics.com/) 5) http://edge.quantserve.com - QuantCast Metrics - (https://secure.quantserve.com) 6) http://pixel.quantserve.com - QuantCast Metrics - (https://pixel.quantserve.com). – cyberx86 Mar 25 '12 at 1:41
  • Check out Zypher's comment (meta.serverfault.com/questions/1792/…). They are working on it, and gravatar has nothing to do with it. – Basil Mar 26 '12 at 16:40
5

All the reasons @Chopper3 gave are still valid ones:

  • The actual authentication process is secured over SSL/TLS.
    (at least if your OpenID provider isn't made of suck)

  • Everything else you do on ServerFault is public*

  • Adding SSL to StackExchange sites is computationally expensive
    (Good enterprise SSL accelerators range in cost from about as much as a pony to about as much as a house!)

*Possible Exception: Associating email addresses with your account & subscribing/unsubscribing to site newsletters.
I agree that these things should probably be happening over SSL if they aren't already.

  • 4
    ..and the day that someone steals a moderator's session on one of the currently 84(?) StackExchange sites, causes enormous damage (Perma-ban everyone? Migrate every question in history to other SE sites at random? Merge every user account into each other, down to a user singularity? Ditto for tags?), and costs a large chunk of employee time to clean up.. well, these reasons not to do it will start to look pretty insignificant. – Shane Madden Mar 24 '12 at 5:49
3

Related discussion, though the OP is a bit of a .. pill .. so you'll have to filter the content a bit.

Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?

3

Maybe I'm not as paranoid as some but I just don't see the need for a secure connection to a site like SF. If you have a real concern about someone impersonating you then perhaps you need to address the underlying problem instead.

3

The funny thing is that now a proper SSL certificate is installed, the problem is that it only has names stackexchange.com and *.stackexchange.com. It should be simple to get serverfault.com, stackoverflow.com, etc added as alternative names. Update: but most still redirect to http, except for stackexchange.com itself.

1

An SSL certificate is important when the StackExchange API is used with JavaScript. Any website that wants to display items relevant to user private data, on a page protected with SSL will show errors about unsecure content.

And as Yuhong Bao mentioned, https://www.serverfault.com does have a cerificate, but that certificate is invalid as it only covers *.stackexchange.com. Would be nice if https://serverfault.stackexchange.com was an alias for serverfault.

1

So, fast forward to 2014, Stackexchange can now be accessed via https (Yay! And rightly so: Wikipedia is "public" too, still I don't want my employer/wifi sponsor/isp/... to eavesdrop on the connection) - but only with mixed content (Imgur? Quantcast?) and with TLS 1.0 only. Are there any plans to fix this as well?

  • 1
    I'm not sure this is a good answer, but I think it would make a good question. Why not ask it as a new question, including a link that references the whole of this old answer? – MadHatter Jan 23 '14 at 7:06
  • Plus, a number of links (everything which is linked in the inbox or the recent reputation changes dropdown) are still hard-coded to http://. And Imgur/Cloudflare even has a https:// service, although this is using TLS 1.0 and even RC4. There still is some work to do. – the-wabbit Jan 23 '14 at 7:18
  • chat is still http and doesn't load correctly at all with https; it's probably safest to say that the https isn't really here yet – Iain Jan 24 '14 at 11:49
  • The official line is that https isn't supported too meta.stackexchange.com/questions/217341/… – Iain Jan 24 '14 at 13:32
  • I will point out that on corporate devices, your employer can eavesdrop on anything, even with SSL enabled. Cisco IronPorts can MITM SSL by design. – MDMarra Jan 24 '14 at 17:27
  • 1
    You realize that I was NOT trying to make a point about the security of SSL in general but about bored admins/neighbors/bosses eavesdropping on HTTP traffic, right? – ckujau Jan 24 '14 at 22:47

You must log in to answer this question.

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