Are there plans to support https?

I think it is very ironic to have a site about IT security which itself has such a huge security issue.

Edit: In the mean time the situation got worse: Now accounts can be created directly on the login dispatch page. Since that page is loaded via http, an attacker may be able to modify it, to send a copy of the password elsewhere.

Edit 4: The Login/Creation page loads an iframe via a https connection, so a passive attacker cannot sniff the password. The ability to manipulate the http-traffic of the login-page is required in order to get rid of this https-iframe and do malicious things.

  • 2
    not using https isn't necessarily a security issue. For my use of the site I have no need for strong encryption, and the authentication mechanism through OpenID is fine for my purposes. I mean this isn't a transactional site - we aren't risking our bank accounts :-) – Rory Alsop Jan 11 '11 at 20:06
  • 8
    @Rory Alsop, says a ♦-moderator, with lots of tools to create huge scale damage and angry users. It may not risk your bank account, but you are risking your reputation (i don't mean XP). And the whole stackexchange.com site is risking bad press coverage. Keep in mind that the press loves those "hacked security site" stories, especially since those "press releases" are often written in a very funny way – Hendrik Brummermann Jan 11 '11 at 22:09
  • 2
    "the account creation page is loaded via http" -- uhm, no. – balpha Sep 14 '11 at 15:05
  • @balpha, see screenshot. Please note: I am not talking about the target of the form. – Hendrik Brummermann Sep 14 '11 at 17:25
  • 1
    The account creation page comes from openid.stackexchange.com and comes via https, no matter how much you deny that. Just look at the src attribute of that iframe. – balpha Sep 14 '11 at 17:31
  • @balpha, the page is http://security.stackexchange.com/users/login. In addition to the page itself, it includes a number of JavaScript files which are loaded via http connections. It does not help that the real page includes an iframe which is loaded via https. It is very easy for an attacker, who can manipulate http, to define style attributes via JavaScript that moves that iframe out of the way and replace it with his own malicious form that sends him a copy of the username and password. – Hendrik Brummermann Sep 14 '11 at 18:13
  • That is true (and in that area I'm not even disagreeing with you), but is a totally different issue than the one you previously talked about (and still claim to be true in your post). I appreciate your concerns and am very sympathetic about them, but let's still talk about facts. – balpha Sep 14 '11 at 18:18
  • As far as I understand you, you have a understanding of the word "page", that only refers the content of an iframe instead of the complete web page. From my point of view a page is identified by the url that is visible in the address bar (without knowing anything about html code and iframes). – Hendrik Brummermann Sep 14 '11 at 18:32
  • I reworded the question to be more clear. – Hendrik Brummermann Sep 14 '11 at 18:56
  • @balpha, clarifying Hendrik's previous comment - loading the contents of an iframe over HTTPS indeed helps with the confidentiality of the page - but that's not all that SSL provides. Particularly, in this scenario, there would be no practical (i.e. usable - see AviD's Theorem of Usability Correlation) way to validate the server's identity. – AviD Sep 15 '11 at 20:29
  • @AviD I understand that very well, and as I said, don't disagree. All I objected to was the (now redacted) claim that "the account creation form is loaded over an insecure connection". – balpha Sep 15 '11 at 21:06
  • @balpha - that claim is not wrong, it's just inaccurate. The problem is in the definition of "insecure connection"... What makes a connection secure? One aspect is also being able to verify the identity... If I cannot verify the server's identity, it is not a secure connection, even if a 3rd party cannot access the connection. (Of course, it does make sense to discuss what the security attributes are required, for any given scenario...) – AviD Sep 15 '11 at 21:10
  • Despite the secure login, session hijacking is possible in the entire StackExchange network because they don't use full https. – Hello World May 11 '14 at 16:53
  • I guess this should be status-planned now? (Or status-completed in a week or so when it's done?) – Ajedi32 Mar 10 '17 at 21:11

This is discussed here:

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

The short answer is, we don't think it makes sense yet.

  • 4
    A nice reminder that security involves weighing up risk and taking appropriate action based on risk and cost. Obviously I'd rather have HTTPS but then again it's free at my end :) – Ventral Jan 1 '11 at 11:04
  • 1
    I am wondering how long it takes until the first security conference replaces the public projection of sniffed username/password pairs with session cookies. – Hendrik Brummermann Jan 1 '11 at 11:22
  • 2
    @nhnb Yeah that's bound to happen. I'd be impressed if anyone recognises their session id on the T-shirt though. – Ventral Jan 1 '11 at 21:58
  • 1
    @ventral well you'd still want to dig out and display the userid, along with the cookie. – nealmcb Jan 2 '11 at 2:07
  • 2
    Doesn't make sense "yet". 14 months later is a different story. – Major Major Apr 22 '12 at 19:05
  • @old I think SPDY is a big part of this story and we're on a Microsoft platform which makes SPDY adoption.. uh.. difficult – Jeff Atwood Apr 22 '12 at 21:20
  • It's time now, guys. – Jonah Benton Sep 8 '16 at 14:32

You must log in to answer this question.

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