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?

5
  • 3
    This has come up many times in the past. I believe this is status-deferred.
    – asheeshr
    Commented Sep 26, 2013 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.
    – user5
    Commented Sep 26, 2013 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
    Commented Sep 26, 2013 at 1:45
  • https://stackexchange.com/
    – Sklivvz
    Commented Sep 27, 2013 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?
    – habs
    Commented Apr 13, 2018 at 17:19

2 Answers 2

Reset to default
15

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)

12
  • 5
    There are also the isssues of having to deal with websockets over https, etc.
    – Sklivvz
    Commented Sep 26, 2013 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
    Commented Sep 26, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 27, 2013 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
    Commented Sep 29, 2013 at 17:38
  • @NickCraver Seriously? That sounds like a bad excuse. Read the Performance Concerns section of eff.org/https-everywhere/deploying-https.
    – user7146
    Commented Apr 7, 2015 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.

3

You must log in to answer this question.

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