6
$\begingroup$

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: enter image description here

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.)

$\endgroup$
1
  • 3
    $\begingroup$ Thank you for taking the time to document this. $\endgroup$
    – whuber Mod
    Commented Jan 28, 2014 at 15:24

1 Answer 1

Reset to default
6
$\begingroup$

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.

$\endgroup$
22
  • $\begingroup$ 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? $\endgroup$
    – gung - Reinstate Monica
    Commented Jan 29, 2014 at 15:34
  • $\begingroup$ @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. $\endgroup$
    – Livid
    Commented Jan 29, 2014 at 15:57
  • $\begingroup$ @gung From what I can tell, that should indeed be the case. Bug me if you discover differently. $\endgroup$
    – hairboat
    Commented Jan 29, 2014 at 15:57
  • $\begingroup$ @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? $\endgroup$
    – Livid
    Commented Jan 29, 2014 at 16:24
  • $\begingroup$ @AbbyT.Miller This question/answers on security.stackexchange appears to ask a similar question. $\endgroup$
    – Livid
    Commented Jan 29, 2014 at 16:41
  • 2
    $\begingroup$ @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. $\endgroup$
    – Oded
    Commented Jan 29, 2014 at 17:29
  • $\begingroup$ @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. $\endgroup$
    – Livid
    Commented Jan 29, 2014 at 19:17
  • $\begingroup$ @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. $\endgroup$
    – Oded
    Commented Jan 29, 2014 at 19:25
  • $\begingroup$ 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. $\endgroup$
    – Livid
    Commented Jan 29, 2014 at 19:30
  • $\begingroup$ @AbbyT.Miller I forgot to notify when posting my above comment. Https everywhere is still blocking the captcha. $\endgroup$
    – Livid
    Commented Jan 29, 2014 at 23:55
  • $\begingroup$ @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? $\endgroup$
    – Oded
    Commented Jan 30, 2014 at 14:28
  • $\begingroup$ @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. $\endgroup$
    – Livid
    Commented Jan 31, 2014 at 15:04
  • 1
    $\begingroup$ @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 $\endgroup$
    – Oded
    Commented Jan 31, 2014 at 15:07
  • $\begingroup$ @Oded That is actually something I failed to mention. Mathjax is also not working. I did not connect the two. $\endgroup$
    – Livid
    Commented Jan 31, 2014 at 15:19
  • 1
    $\begingroup$ @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. $\endgroup$
    – Oded
    Commented Feb 3, 2014 at 14:31

You must log in to answer this question.

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