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?

8
  • 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 Mod
    Commented Jul 21, 2011 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
    Commented Jul 21, 2011 at 20:25
  • meta.stackexchange.com/questions/69171/…
    – Zypher Mod
    Commented Jul 21, 2011 at 20:40
  • I have the same response every time someone asks - we are working on it: meta.stackexchange.com/questions/69171/…
    – Zypher Mod
    Commented Mar 23, 2012 at 20:27
  • So if you are working on it, the accepted answer is out of date.
    – Basil
    Commented Mar 26, 2012 at 16:26
  • After all the notes/comments to the contrary, I notice that my request has actually been fulfilled. Thanks!
    – mdpc
    Commented Mar 26, 2015 at 19:53
  • 1
    You can use https now.
    – Michael Hampton Mod
    Commented Oct 11, 2016 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
    Commented Dec 24, 2016 at 20:32

8 Answers 8

Reset to default
4

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.

8
  • 1
    But why not allow it? Maybe I don't want my sessions to be eavesdropped on.
    – mdpc
    Commented Jul 21, 2011 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 Mod
    Commented Jul 21, 2011 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 Mod
    Commented Jul 21, 2011 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
    Commented Jul 21, 2011 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
    Commented Jul 21, 2011 at 20:39
  • 4
    gmail deals with data you don't want other people to see (your email) :-)
    – voretaq7
    Commented Jul 21, 2011 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 Mod
    Commented Jul 21, 2011 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
    Commented Jul 21, 2011 at 21:45
9

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.

4
  • 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
    Commented Mar 25, 2012 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 Mod
    Commented Mar 25, 2012 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
    Commented Mar 25, 2012 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
    Commented Mar 26, 2012 at 16:40
4

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.

1
  • 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
    Commented Mar 24, 2012 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

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.

2

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.

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?

6
  • 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
    Commented Jan 23, 2014 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
    Commented Jan 23, 2014 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
    – user9517
    Commented Jan 24, 2014 at 11:49
  • The official line is that https isn't supported too meta.stackexchange.com/questions/217341/…
    – user9517
    Commented Jan 24, 2014 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
    Commented Jan 24, 2014 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
    Commented Jan 24, 2014 at 22:47

You must log in to answer this question.

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