18

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.

14
  • 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 Mod
    Commented Jan 11, 2011 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 Commented Jan 11, 2011 at 22:09
  • 2
    "the account creation page is loaded via http" -- uhm, no.
    – balpha StaffMod
    Commented Sep 14, 2011 at 15:05
  • @balpha, see screenshot. Please note: I am not talking about the target of the form. Commented Sep 14, 2011 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 StaffMod
    Commented Sep 14, 2011 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. Commented Sep 14, 2011 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 StaffMod
    Commented Sep 14, 2011 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). Commented Sep 14, 2011 at 18:32
  • I reworded the question to be more clear. Commented Sep 14, 2011 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 Mod
    Commented Sep 15, 2011 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 StaffMod
    Commented Sep 15, 2011 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 Mod
    Commented Sep 15, 2011 at 21:10
  • Despite the secure login, session hijacking is possible in the entire StackExchange network because they don't use full https. Commented May 11, 2014 at 16:53
  • I guess this should be status-planned now? (Or status-completed in a week or so when it's done?)
    – Ajedi32
    Commented Mar 10, 2017 at 21:11

1 Answer 1

3

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.

7
  • 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
    Commented Jan 1, 2011 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. Commented Jan 1, 2011 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
    Commented Jan 1, 2011 at 21:58
  • 1
    @ventral well you'd still want to dig out and display the userid, along with the cookie.
    – nealmcb
    Commented Jan 2, 2011 at 2:07
  • 2
    Doesn't make sense "yet". 14 months later is a different story. Commented Apr 22, 2012 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 Commented Apr 22, 2012 at 21:20
  • It's time now, guys. Commented Sep 8, 2016 at 14:32

You must log in to answer this question.

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