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.
