7

I'm currently using EFF's HTTPS Everywhere plugin to favor HTTPS whenever it is available.

Due to a wrong Common Name being used for the Meta website certificate, the first connection is a bit funky: requires to disable the plugin, manually trust the certificate, then re-enable the plugin. Afterwards, the Meta is accessed through HTTPS flawlessly.

At least it was so until the recent StackExchange major updates bringing us the new profile etc. During about a week, I began to have CloudFlare error pages telling me the back-end certificate was wrong, but refreshing the page one or two times was sufficient to access the Meta website anyway. A bit dirty, but working.

Now, since a week (so it is not a temporary issue), when trying to access the Meta website through HTTPS my request is systematically rejected by a "403 Forbidden" raised by "cloudflare-nginx".

Am I the only one who feel quite uncomfortable to discuss best security practices through plain HTTP? While not perfect, at least it was working until now, why drop it?

I thought the general tendency was to move from HTTP toward HTTPS, not the other way around :( ...

Well, the issue is even a bit worse than I thought :(

I guess the better option is to abandon HTTPS altogether on Security SE...

When logging-in from the HTTPS version of Security SE, the StackExchange session cookies are created with the secure flag enabled, so are incompatible with the HTTP version of Meta.

But what is worse is that it becomes impossible to login on the Meta website, since the login page being in HTTPS detects that we are already logged-in but does not remove the secure flag from the already created cookies, in other words the "log in" link does not work any more.

So it becomes mandatory to log-off from the HTTPS version of Security SE, and login back again on the HTTP version to be able to access Meta.

7
  • 3
    The TLS outage is unrelated to the new profile reaching sec.SE, it's a Cloudflare problem that affects all meta.*.stackexchange.com.
    – Gilles 'SO- stop being evil'
    Commented Sep 12, 2015 at 11:30
  • You don't need to disable the plugin to reach the meta site. It's a Chromium deficiency: it doesn't look for the TLS extension that contains the site name. Firefox copes.
    – Gilles 'SO- stop being evil'
    Commented Sep 12, 2015 at 11:31
  • @Gilles I'm on Firefox, so not affected by Chromiom deficiencies. I suppose the initial procedure with HTTPS Everywhere was the expected behavior: seeing that that the Meta site hasn't a valid certificate it does switch to HTTPS automatically, it does so only when a exception has been manually set for the certificate. I see that the issue is actually bigger than I thought, I will update my post :(
    – WhiteWinterWolf
    Commented Sep 12, 2015 at 12:39
  • I noticed this as well, but got zero real responses from the community.
    – RoraΖ
    Commented Sep 14, 2015 at 12:54
  • 3
    @RoraΖ: As ChrisF highlighted in your linked thread, "HTTPS isn't fully supported yet", I don't wan't to talk in his name (or any other name), but as a future ex support team employee I used to explain people that when something was not supported from the start, it can't be considered broken, and there is therefore no reason to complain. In other words: we can be lucky it worked for so long. I just hope that when Let's Encrypt will open publicly they will enrol...
    – WhiteWinterWolf
    Commented Sep 14, 2015 at 13:20
  • @WhiteWinterWolf yeah that's a really good point.
    – RoraΖ
    Commented Sep 14, 2015 at 13:27
  • CloudFlare is currently disabled, metas are working through TLS, thank goodness.
    – Deer Hunter
    Commented Oct 6, 2015 at 19:51

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .