• The site has now migrated to Xenforo 2. If you see any issues with the forum operation, please post them in the feedback thread.
  • An addendum to Rule 3 regarding fan-translated works of things such as Web Novels has been made. Please see here for details.
  • RIP @Silver Swallow
  • The issue with logging in with email addresses has been resolved.
  • Due to issues with external spam filters, QQ is currently unable to send any mail to Microsoft E-mail addresses. This includes any account at live.com, hotmail.com or msn.com. Signing up to the forum with one of these addresses will result in your verification E-mail never arriving. For best results, please use a different E-mail provider for your QQ address.
  • For prospective new members, a word of warning: don't use common names like Dennis, Simon, or Kenny if you decide to create an account. Spammers have used them all before you and gotten those names flagged in the anti-spam databases. Your account registration will be rejected because of it.
  • Since it has happened MULTIPLE times now, I want to be very clear about this. You do not get to abandon an account and create a new one. You do not get to pass an account to someone else and create a new one. If you do so anyway, you will be banned for creating sockpuppets.
  • Due to the actions of particularly persistent spammers and trolls, we will be banning disposable email addresses from today onward.
  • The rules regarding NSFW links have been updated. See here for details.

Bug: HTTPS session is fragile

Ampersandwich

Ampersandwich

Outl&ish Gr& Panj&rum
Joined
Mar 5, 2014
Messages
1,021
Likes received
2,146
When you're logged in using https://, if you click an http:// link, your login session is invalidated.

This isn't just "you have to log in again to use HTTP", but "your HTTPS login session is trashed also". As many links in signatures and the like have http:// hardcoded into them, this is problematic, to say the least. (It would be nice to promote these to https:// when under https anyway, though.)
 
Hmm.

I'm tempted to make http redirect to https for everyone by default, because more TLS is always better. But I'd need to figure that out.

I find that when logged in via http, I can follow https links without problem. So there's that.
 
Can these at least be https when you're already on an https page?

96ga3kP.png
 
All forum-created links should now point to https by default. I can't do anything about links manually specified in posts, at least not from the XF end. Maybe I'll look into rewrite rules or something tomorrow.
 
I keep getting an error at the https url.

Secure Connection Failed
An error occurred during a connection to forum.questionablequesting.com. The OCSP server suggests trying again later. (Error code: sec_error_ocsp_try_server_later)
 
I had that as well. A workaround is to go into Firefox about:config and disable OCSP stapling. I have no idea of the deeper significance; that error message is truly unhelpful. However, since it's OCSP, it seems likely to be somehow related to the server TLS cert.
 
alethiophile said:
I had that as well. A workaround is to go into Firefox about:config and disable OCSP stapling. I have no idea of the deeper significance; that error message is truly unhelpful. However, since it's OCSP, it seems likely to be somehow related to the server TLS cert.
Click to expand...
Click to shrink...

Yeah, that fixed it.

What's weird is that it was working fine with it enabled and browsing in https then it just started throwing the error message out of the blue.
 
Yeah. OCSP is the protocol used to check for revocation of a TLS cert, so the obvious answer is that something's wrong with its registration. But the error message is just...what? "Suggest you try again later?" How the hell does that help?

If this goes on too long I'll probably set the defaults back to HTTP. I like the idea of having it be HTTPS in the long run, though. Where was the current certificate acquired from?
 
Hmm, with my dorm connection I got OCSP error, but with Campus there's no error.

The cert is signed by StartCom Ltd.
 
alethiophile said:
Yeah. OCSP is the protocol used to check for revocation of a TLS cert, so the obvious answer is that something's wrong with its registration. But the error message is just...what? "Suggest you try again later?" How the hell does that help?

If this goes on too long I'll probably set the defaults back to HTTP. I like the idea of having it be HTTPS in the long run, though. Where was the current certificate acquired from?
Click to expand...
Click to shrink...

As weepingman points out, StartCom was the issuer of the certificate. It was free, so.
 
Yeah, confirmed. I got OCSP error on dorm, but no error on campus. Maybe it is a matter of old HTTPS certificate? Hmm, gonna try deleting it and try again.

EDIT: I still got the same error when I delete QQ's old certificate.
 
Last edited:
For me, only the 'Home' button on the top bar and the QQ logo actually seem to use HTTPS, and when I click on those I get the error.
Everywhere else I click I get Forum.Questionablequesting.com
 
Plotvitalnpc said:
For me, only the 'Home' button on the top bar and the QQ logo actually seem to use HTTPS, and when I click on those I get the error.
Everywhere else I click I get Forum.Questionablequesting.com
Click to expand...
Click to shrink...
Internal links would be targeting http not https. Those have to be manually changed.
 
tehelgee said:
Internal links would be targeting http not https. Those have to be manually changed.
Click to expand...
Click to shrink...
*shrugs*
As long as a complete switchover fixes the whole set of problems, I'd be fine with it.
The moment an attempt to improve something makes things worse, I'll become a reactionary trying to bring back the days where everything was insecure, but did what it said it would without you having to make concessions to it.
 
The issue seems to relate to any loading anything over HTTPS. My change made the home links automatically target HTTPS; however, the generated internal links (all the stuff like list of threads in a forum, &c.) choose protocol based on what they were loaded through. The wild card is links hard-coded in posts, which are whatever they were written as, and the site can't really change them. (Okay, there could be a dynamic link rewriter, but I don't think XF has that.)
 
Curious. HTTPS now works on dorm connection, too. Not sure why. The only change I remember is deleting QQ old certificate, but there's no immediate effect for doing that...
 
theweepingman said:
Hmm, with my dorm connection I got OCSP error, but with Campus there's no error.
Click to expand...
Click to shrink...
Different browsers? Or different security settings on the same browser?

theweepingman said:
Curious. HTTPS now works on dorm connection, too. Not sure why. The only change I remember is deleting QQ old certificate, but there's no immediate effect for doing that...
Click to expand...
Click to shrink...
Huh. Seems to be working for me now, too. ... I guess 'try again later' really was the solution~
 
macdjord said:
Different browsers? Or different security settings on the same browser?


Huh. Seems to be working for me now, too. ... I guess 'try again later' really was the solution~
Click to expand...
Click to shrink...

Nah, I don't change browser. I do need to login with my Student ID*, but it is otherwise identical.

*well, it is technicallly some other poor smuck's Student ID, not mine. But still!
 
TL;DR: Server admins, disable OCSP stapling in the server software. End-users, disable OCSP stapling in your browser. The full explanation goes like this:

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Section 2.3. Exception Cases said:
In case of errors, the OCSP responder may return an error message. These messages are not signed. Errors can be of the following types:
- malformedRequest
- internalError
- tryLater
Click to expand...
Click to shrink...

OCSP Error Code 3: Try Again Later. The most annoying OCSP error to ever exist.

Some background information: The OCSP protocol is used to check whether or not a certificate has been revoked. This is done in real time - whenever your browser makes a secure connection to a website, it also connects to an OCSP responder server to check the current validity of a certificate. The OCSP server then returns a response (the certificate is/is not valid) or an error code (something went wrong).

These servers are run by the Certificate Authority that issued the certificate. As you can imagine, they get a lot of requests. OCSP servers are notoriously unreliable - they go down all the time just due to the sheer load they have to deal with. tryLater, or "sec_error_ocsp_try_server_later" means that the OCSP server is overloaded and can't be contacted at the moment. This is such a common problem that browsers will ususally just ignore this error.

"OCSP Stapling" was designed to fix this problem. Instead of every user asking the OCSP server if a certificate is valid, the website contacts the OCSP server. Then, it stores the OCSP response in a cache, and presents the (digitally signed) cached response to every client that tries to connect to the website. The OCSP response is "stapled" to the SSL certificate that QQ presents. This reduces the load on the OCSP server massively.

Unfortunately, QQ is not stapling an OCSP response (your certificate is valid/invalid). Instead, QQ is stapling an OCSP error code (try again later). So when QQ asks the OCSP server "Hey, has my certificate been revoked?", the OCSP server's response is "Gah! I'm way too busy right now, ask me again later!" QQ then says "Hmm, okay." and stores that "try again later" error code in its cache. QQ then naively presents the error code to the user as though it were a valid OCSP response. This, naturally, trips up the user's browser and causes an error to appear.

This seems like a bug - either the QQ server shouldn't store and staple an error code, or browsers should ignore the error code if it's stapled to a certificate. Browsers already ignore the "try again later" error code if it's received from the OCSP server directly.

End-user workaround: In Firefox, go to about:config, and temporarily set security.ssl.enable_ocsp_stapling to false. I don't know how to do something similar in other browsers.

Caveat: I think this is how it works, but I may not fully understand the protocol or the situation. I am not a systems/networking engineer. Or any kind of engineer, for that matter.

References:

https://tools.ietf.org/html/rfc6960#section-2.3
https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
https://en.wikipedia.org/wiki/OCSP_Stapling
 
QQ now redirects all HTTP requests to HTTPS, which should resolve the issue for which this thread was actually started.
 
You must log in or register to reply here.

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top