23

Here I am with http://meta.tor.stackexchange.com/questions/ask loaded, writing my question. When I click "post", it's going to send my stackexchange credential cookie, yet again, over cleartext.

In this case I happen to be using Tor, so some exit relay, and anybody on the network between that exit relay and the website, gets to see my cookie and log in as me if they want.

Even if I weren't using Tor, exactly the same issue applies when I'm at a hotel network, conference network, coffeeshop network, or even on my cablemodem at home where my neighbors can listen in on all my traffic.

There are some questions here in meta already about getting SE to set up a Tor hidden service. That's a fine backup plan. But I think we should encourage them to make the whole site (that is, Tor's part of it -- but I recognize that it should go broader than that) https-enabled. Does anybody know the right steps, and/or the right people, for making this happen?

  • 3
    This has come up many times in the past. I believe this is status-deferred. – asheeshr Sep 26 '13 at 1:10
  • The actual OpenID authentication is handled over SSL (there's a hidden iframe holding the auth); but that's about all you get I think. It's been discussed before, but I can't find the issues at the moment. – Sam Whited Sep 26 '13 at 1:21
  • 3
    It's only handled over SSL if somebody didn't run SSLStrip on my traffic. :/ And in any case that doesn't resolve the issue with the cookie itself. – Roger Dingledine Sep 26 '13 at 1:45
  • https://stackexchange.com/ – Sklivvz Sep 27 '13 at 15:39
  • 2
    Community bot's edit should be reverted because this question was meant to link to HTTP. As I can't suggest it, can a moderator please do that? – Harry Apr 13 '18 at 17:19
14

This is currently in progress by the Stack Exchange team; they've done numerous tests on TLS (not SSL; that's the insecure one that was broken years ago), and they hit a few snags.

More info on it: Better HTTPS support for Stack Exchange sites

Nick Craver also has a blog post about the challenges associated with using a CDN complete with cloudflare and an ad network and getting them all to use TLS. There's also issues with new sites; many (pretty much all of them but stackoverflow) of SE's sites are loadbalanced from a server or two, and they cannot get wildcard certificates for meta.*.stackexchange.com thanks to some idiot getting a *.com certificate (and SAN/SNI certificates can only have up to 255 (~100 realistically) entries, and make the initial payload quite huge, while individual certificates can be horrible to manage)

tl;dr they're working on it.

Also, OpenID forces SSL/TLS. Your credentials are never sent over cleartext. (there's a network-wide auth iframe on stackexchange sites)

  • 5
    There are also the isssues of having to deal with websockets over https, etc. – Sklivvz Sep 26 '13 at 9:11
  • 1
    To me, this smacks of an issue that will sit unresolved for many years due to seemingly intractable (or cost- and performance-prohibitive) problems. "Working on it" could mean that 2020 could easily come and go and, assuming SE is still around, we could still be using regular HTTP. Not cool, but that's the reality of it. I'd personally be perfectly content with URLs delineating sites instead of domains, which would make most of the headache go away. stackexchange.com/meta/tor, stackexchange.com/superuser, etc. – allquixotic Sep 26 '13 at 16:02
  • @allquixotic it's not a matter of will. it's a matter that it's a big change: nickcraver.com/blog/2013/04/23/… – Sklivvz Sep 27 '13 at 13:47
  • 1
    @Sklivvz I read that blog post the day it was posted. All I get from it is "we'd like to do this, but, excuses excuses excuses; oh, and by the way, this will either take an extremely long time (several years) or will never happen". If the SSL certs are such a big deal, what's so hard about making everything a URL behind stackexchange.com like reddit does? Sure, it's less characters to type "superuser.com" than "stackexchange.com/superuser", but that doesn't change the fact that their entire platform has a big gaping security hole, namely that users can act on others' behalf. Also, bookmarks. – allquixotic Sep 27 '13 at 13:59
  • 1
    Speaking of which, I'd love to meet you (or any other diamond mod) in an internet cafe, Starbucks, or other area where we can bring our laptops, socialize, and use an unencrypted wifi network! I promise not to run Firesheep, steal your authentication cookie, and do bad things with it. Although I'm sure some other people wouldn't make the same promise, or uphold it even if they did. – allquixotic Sep 27 '13 at 14:02
  • @allquixotic logins are secure in that regard. Auth is over SSL via iframes and then oauth takes over from there. Also we're too cool for internet cafes. – Amelia Sep 27 '13 at 14:07
  • 2
    I know that logins are secure. But your authentication token is not secure. Meaning, someone won't be able to recover your username and password, which is fine, but they will trivially be able to do anything with your account that you can do -- that is, act on your behalf -- if they can MITM you. The MITM problem isn't going away, and on some networks it's nearly impossible to mitigate without re-architecting the infrastructure (and a mere user doesn't always have the ability to do that), so you always have to design a site assuming MITM on your users is possible. SE doesn't do that. – allquixotic Sep 27 '13 at 14:32
  • 1
    Also, even though most/all operations you perform on the SE network involve entering content that gets published to the general public under a creative commons license, that still doesn't excuse the fact that an attacker could act on your behalf, potentially ruining your reputation, getting you banned, or, in the case of moderators' accounts being compromised, the moderator could ban others. Also, there are a few things on SE, such as private beta sites, that are not supposed to be open to the public; plain HTTP effectively makes them so. Corporate networks are one big MITM most of the time. – allquixotic Sep 27 '13 at 14:58
  • 4
    @allquixotic certificates are not the issue, we've had those in place (look at the cert for stackauth.com for example). We are working with the author of HAProxy to quash an SSL performance bottleneck which absolutely prevents us from rolling it out across the network. As for excuses and other assertions you're making about how easy stuff is, e.g. changing the URLs...you have no idea what you're talking about. SSL will be an option, but not the default - there is a very non-trivial performance penalty we won't inflict on all users. – Nick Craver Sep 27 '13 at 15:43
  • 1
    I didn't mean to imply that it's easy to change what must be a mountain of code to host the different SE sites on URL paths instead of domains. Just that, based on the things I have read so far, from you and others, it seemed to me that SSL would be feasible sooner if you only had one or a small handful of domains to worry about, because it would alleviate your immense pain over the certs situation. If that's no longer the case, and the latest bugbear has shifted to performance, then my suggestion is not needed. Maybe an updated blog post with the latest status is in order? – allquixotic Sep 27 '13 at 19:38
  • Here's a possibly really dumb and naive question, but I wonder if there's any way to add a nonce to the auth token that will enhance gracefully for users who choose to browse SE with Javascript. Or do so without Javascript at all. So, the auth token is only good for 1 request-response cycle, and the server gives out a challenge and gets a response back as part of the auth token. No coffee yet, but, it's a thought. – Gordon Morehouse Sep 29 '13 at 17:38
  • @NickCraver Seriously? That sounds like a bad excuse. Read the Performance Concerns section of eff.org/https-everywhere/deploying-https. – nyuszika7h Apr 7 '15 at 18:48
4

I've just noticed that the site now loads over HTTPS. Even https://check.torproject.org/ links to us on HTTPS.

Some browsers throw an error that not all content is encrypted, but this actually makes sense since we display externally hosted images within questions/answers which might only be available over HTTP.

  • Unfortunately there are unencrypted parts on the web page. At least I see unencrypted favicons: area51.stackexchange.com/favicon.ico and stackexchange.com/favicon.ico – pabouk Dec 13 '13 at 8:44
  • That's what I mean - external content will still be unencrypted but it's at least a step closer. – Andrew Lott Dec 13 '13 at 9:00
  • I noticed that my browser sends Google __utma cookie and then after redirection it sends CloudFlare __cfduid cookie in clear HTTP. Could not these help to identify the user? I guess that yes. --- I did not test the web page in TBB yet. (There the cookies could be possibly blocked.) – pabouk Dec 13 '13 at 9:25

You must log in to answer this question.

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