# Problem with log-in and posting when using https://

I am unable to ask questions or post when accessing https://stats.stackexchange.com/. When I attempted to access the meta site it was also not possible for me to log in.

Edit: Screenshot:

Edit: Also it appears to be auto-logging me in without needing to enter a password sometimes but not others. Finally, shouldn't the log-in page always be https://? Seems insecure to me.

Also, visiting https://stats.meta.stackexchange.com/ gives invalid cert:

meta.stats.stackexchange.com uses an invalid security certificate. The certificate is only valid for the following names: *.stackexchange.com , stackexchange.com , meta.stackexchange.com , *.meta.stackexchange.com , *.stackoverflow.com , stackoverflow.com , serverfault.com , stackauth.com , sstatic.net , meta.serverfault.com , superuser.com , meta.superuser.com , stackapps.com , openid.stackauth.com (Error code: ssl_error_bad_cert_domain)

Part of the issue seems to be that getting logged into the https:// version does not mean you are logged into the normal version of the site.

Unless the user is using add-on like https everywhere it appears their password is being sent in plain text by default every time they log in. If my understanding is correct, anyone who is not using "https everywhere" can have their pass stolen over wifi. I think it is not such a big deal for CV but this can be a major problem for those who reuse passwords. The cookies are also not being deleted upon log-out. It is not possible to log in to the meta site using https at all without making an exception for an invalid cert, which is why I don't wish to post there any longer.

(Copied from a comment on our main site.)

• Thank you for taking the time to document this. – whuber Jan 28 '14 at 15:24

The issue with the captcha should be fixed already, as of a few hours after this question was posted.

As for the rest of your question... check out our developer Nick Craver's excellent blog post on Stack Exchange's road to SSL for full details. The long and the short of it is that child metas do not support SSL yet due to certification problems with our subdomains. (The URL formats *.*.stackexchange.com or meta.*.stackexchange.com are what specifically is giving us trouble.) The eventual goal, if we go full SSL, will be to move child metas to *.meta.stackexchange.com to get around this problem (as mentioned here). (Read Nick's blog post - it's interesting and more informative than this answer.)

Also, it is worth mentioning that the whole "password is being sent in plain text" is misleading. When you're logging in through the openid provider either no passwords are sent at all, or, if you're using Stack Exchange's openid, all traffic is via SSL.

tl;dr: SSL is a work in progress, and you've hit a kink that hasn't been worked out yet.

• Is the upshot of this that the problem only exists if you try to login via meta, but that this problem doesn't occur if you login via the main site? – gung - Reinstate Monica Jan 29 '14 at 15:34
• @Abby T. Miller I have made an exception for the meta cert for now, does this make sense to do? Do I understand correctly that there is no way for the user's browser to tell if the pass is sent plain text or not when using the stack exchange openid? The default login page is not SSL but the openid widget encrypts the data in the background? Sorry I am no expert in these matters. Also, there is still the problem that "logging out" does not appear to really log me out since the session cookies remain. This is misleading to the user and could cause trouble if they are at a library, etc. – Livid Jan 29 '14 at 15:57
• @gung From what I can tell, that should indeed be the case. Bug me if you discover differently. – hairboat Jan 29 '14 at 15:57
• @AbbyT.Miller This is bringing up more questions for me on how this all could be working under the current circumstances. When forcing the https:// page my browser is signing the log-in info with the public key of the "invalid" (due to syntax problems) cert and your servers are decrypting with the private key of the "invalid" cert? If I do not force https:// and there is no certificate to provide a public key, how/where is encryption occurring? – Livid Jan 29 '14 at 16:24
• @AbbyT.Miller This question/answers on security.stackexchange appears to ask a similar question. – Livid Jan 29 '14 at 16:41
• @Livid - where exactly are you posting a password in the site (meta or main)? The openId email/password comes through an IFrame that is served over SSL (https) and the domain has a valid certificate (for openid.stackexchange.com) - this is served in both meta and main sites, so communication of your password are fully encrypted with a valid certificate. I will note that this is going to change soon - we are reworking the login pages to come directly over https. – Oded Jan 29 '14 at 17:29
• @Oded I havent seen a way to enter a pass into the meta site. I believe I understand what is happening now. So three problems remain: 1) Logging out is not really logging out since the cookies are not being deleted, this must be done manually. 2) The user needs to dig through the source to know they are actually sending the data over SSL, there is no way for the browser to detect this 3) If the user logs into CV using SSL, they will not be able to use the meta site unless they accept the "invalid" certificate, or log out, manually delete cookies, and log back in using the http address. – Livid Jan 29 '14 at 19:17
• @Livid - 1) logging out with openId requires to log out both the openId provider (say Google) and the site in order to be properly logged out - this is by far not something limited to Stack Exchange sites. 2) Yes, which is one reason these pages will become SSL only soon. 3) Until we resolve the certificate problem, that's the unfortunate reality at the moment. – Oded Jan 29 '14 at 19:25
• Also I have just attempted to post an answer to my original post and came across the same problem that I get a captcha for no reason and it will not load. So it appears I need to deactivate https everywhere to use stack exchange currently. – Livid Jan 29 '14 at 19:30
• @AbbyT.Miller I forgot to notify when posting my above comment. Https everywhere is still blocking the captcha. – Livid Jan 29 '14 at 23:55
• @Livid - can you provide more details? I have https everywhere on FireFox 26.0 and can see the captcha at both stats and stats-meta (needed to add an exception on meta due to the invalid certificate, but otherwise it is OK). Can you outline the exact steps you took (what page you were on, what you clicked etc) and what browser and operating system you are using? – Oded Jan 30 '14 at 14:28
• @Oded I just attempted to answer my own question here: stats.stackexchange.com/questions/83612/…. I logged in using https everywhere, navigated to that question by clicking the link in my achievements drop down list, then clicked "answer" question and posted "test" and a link to this page. The captcha failed to load as in the OP. I'm using W7 , FF 25.1, HttpsE 3.4.5. Also, I can see the captchas on the pages you linked. – Livid Jan 31 '14 at 15:04
• @Livid - looks like the problem may be with MathJax - currently, it will not load when using https. There is work in progress towards getting it working properly over https – Oded Jan 31 '14 at 15:07
• @Oded That is actually something I failed to mention. Mathjax is also not working. I did not connect the two. – Livid Jan 31 '14 at 15:19
• @Livid - I don't know how that would work. Unfortunately, trying to fix this has uncovered some of the ways in which we are still not https ready - some things deep in our infrastructure which will take time to resolve. As things stand right now, I fear that https is not fully supported on our sites. – Oded Feb 3 '14 at 14:31