As I suddenly figured out, there is plain HTTP used on log-in form to http://reverseengineering.stackexchange.com

No SSL\HTTPS implemented, and password in login form transferred in clear text. As You may see, this is not secure at all.

Workaround I found for myself - log in at https://stackexchange.com/ and then - use Login button on reverseengineering.stackexchange.com to extend login session to subdomain as well. It's not 100% secure also, but at least not credential but session passed in clear text here.

So - question is, is there any option to enable secure login directly to project website, without workarounds?

UPDATE: well, always re-check results before You ask questions. Actual OpenID form URL is https://openid.stackexchange.com/affiliate/form So - problem is partially solved.

Anyway - site with information related to InfoSec IMHO should at least have SSL available for all traffic, even if it not default.

  • 1
    Reverse Engineering the Reverse Engineering site. I like you! By the way, this is a network-wide thing. You can also try Meta Stack Exchange for this, you'd get a way faster response.
    – user187
    Apr 7, 2013 at 18:02
  • 2 years later, has there been any change? I find it curiously targeted, if intentional and not just negligence, etc..
    – dyasta
    Dec 30, 2016 at 14:46

1 Answer 1


HTTPS connections to the questions and answers site have been requested for a long time but are currently not supported.

If you're using Stack Exchange as your OpenID provider, you can connect to https://stackexchange.com/ and log in there. Even if you connect to http://stackexchange.com/, assuming you haven't been redirected to another site by an active man-in-the-middle, your credentials are not sent in cleartext — the login form does use HTTPS. That still leaves your session cookie exposed to potential hijacking.

Some prior requests and discussions on the topic:

  • Well, it is right. Actual FORM URL redirected to openid.stackexchange.com/affiliate/form Apr 7, 2013 at 19:18
  • There's other practical reasons to use SSL, and it's something we're working on. For instance, caching proxies kill web sockets, so going over 443 is the best fix - and if you're going to 443, you might as well have SSL. I just don't know when it's going to finally happen.
    – Tim Post
    Jun 11, 2013 at 10:25

You must log in to answer this question.

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