What it sounds like is happening is that the login cookies are being set as secure, but the forceHTTPS cookie isn't being set so reloading doesn't result in a redirect to https.

I suspect this may have been fixed with Gerrit change 85776, which will be deployed along with 1.22wmf19 (see https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule). Unless Chris is going to include it with his CentralAuth deploy later today, in which case it might go out sooner.

I just hit this bug myself. I was logged in via HTTPS, but every time I go to http://meta.wikimedia.org/ it leaves me on the HTTP site and logs me in via Central login.

I have both the metawikiforceHTTPS and forceHTTPS cookies set to true.

Here are all the headers from the Request and Response:

Response Headers
Accept-Ranges bytes
Age 30292
Cache-Control private, s-maxage=0, max-age=0, must-revalidate
Connection keep-alive
Content-Encoding gzip
Content-Language en
Content-Length 16558
Content-Type text/html; charset=UTF-8
Date Wed, 25 Sep 2013 22:24:33 GMT
Last-Modified Wed, 25 Sep 2013 13:59:37 GMT
Server Apache
Vary Accept-Encoding,Cookie
Via 1.1 varnish, 1.1 varnish
X-Cache cp1054 hit (15), cp1068 frontend hit (2123)
X-Content-Type-Options nosniff
X-Powered-By PHP/5.3.10-1ubuntu3.6+wmf1
X-Varnish 2043118996 3533212360, 1488879432 1469275617
X-Vary-Options Accept-Encoding;list-contains=gzip,Cookie;string-contains=metawikiToken;string-contains=metawikiLoggedOut;string-contains=metawikiSession;string-contains=centralauth_Token;string-contains=centralauth_Session;string-contains=centralauth_LoggedOut;string-contains=mf_useformat;string-contains=stopMobileRedirect;string-contains=forceHTTPS

Request Headers
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control no-cache
Connection keep-alive
Cookie metawikiforceHTTPS=1; forceHTTPS=1; stopMobileRedirect=true; centralnotice_bucket=0-4.2; mediaWiki.user.sessionId=ox79ZiUXx2F4mdQgHKLUS2NBGB34Iut6; uls-previous-languages=%5B%22en%22%5D; optin=beta
Host meta.wikimedia.org
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0

Change 86044 had a related patch set uploaded by CSteipp:
Vary on forceHTTPS cookie

https://gerrit.wikimedia.org/r/86044

Change 86044 merged by jenkins-bot:
Vary on forceHTTPS cookie

https://gerrit.wikimedia.org/r/86044

Actaully, it looks like MobileFrontend has already setting forceHTTPS in the XVO list. So it seems like Varnish isn't respecting that?

I talked with Mark about this. Since varnish ignores XVO, we need a specific VCL rule for varying on forceHTTPS.

Mark added https://gerrit.wikimedia.org/r/#/c/86268/1 to do that.

Varnish ignores XVO, so the solution is to try to reproduce XVO in static Varnish configuration? So does that mean it's also ignoring other cookies specified in XVO, such as metawikiLoggedOut, centralauth_LoggedOut, mf_useformat, and stopMobileRedirect that are in the header quoted in comment 2?

That is my understanding of it.

I confirmed with mark that Varnish is handling all non wikipedia (and non ipv6/https) traffic, and I haven't seen anyone complaining about this issue again. So I think the varnish change successfully prevents the issue. Please reopen if anyone sees this happening again.