WTF. is telling me my clock is ahead and needs to be corrected (wrong), rather than that the site's certificate is invalid.
Conversation
This is a standard Chromium feature but maybe they changed it to using an HTTPS server not providing a reliable time. IIRC, it's permitted to return a randomized value in the time value, so you really need to use a server that's explicitly going to keep supporting giving time.
1
1
Why would they trust the server's reported time over yours? This seems like a very broken attitude towards authority/trust.
1
1
You're misunderstanding what I'm saying. I'm not talking about the server you're connecting to but rather a server (or multiple) for sanity checking the local system time. Essentially, a time server, but with the time fetched via TLS.
1
1
The most common source of HTTPS errors in Chrome was determined to be an out of sync local clock, so when it encounters a certificate with an invalid date (expired or issued in the future), it has support for sanity checking the local system time via TLS to provide a notice.
1
1
Brave might have changed the domain from a Google server to one that didn't offer a strong guarantee of providing a correct TLS handshake time value. The server they used might have ended up having the wrong time, or it might randomize the field, which I think became permitted.
1
1
It's important because instead of training the user to accept invalid certificates, they are informed that their system clock is wrong, which they can check themselves, as you did. So, it seems Brave broke this feature, but the feature itself is a useful and important one.
2
They broke it even worse because, due to the wrong determination that system time is incorrect, it won't allow overriding the cert error.
1
1
It's also not possible to override those errors via the standard UI when a site using HSTS. There's a secret way to bypass the screen, which might work for you. You need to type a secret string for bypassing it. I don't know the string for current releases off the top of my head.
2
I wonder if better UX would be allowing easy bypass of the error, but:
1. showing site as insecure
2. disabling all cookies/localstorage for the site
3. disabling form entry/submission for the site
4. severe warning or blocking [executable] file download from site
2
Try typing "thisisunsafe". It's the current bypass for certificate errors on sites with HSTS:
chromium.googlesource.com/chromium/src/+
I think it's part of the HSTS standard that it prevents bypassing certificate errors, but I think most browsers include a secret way to bypass it for devs.
They have this as a last resort mechanism, but they've intentionally used a phrase that discourages doing it. They also rotated the phrase, because the top results for the errors would end up telling people how to bypass it without explaining the risks of doing that.
1
They also started base64 encoding the phrase, which I guess is to make people think twice about it. Sites using HSTS are committing to always using HTTPS and keeping it working. See tools.ietf.org/html/rfc6797#s ("No User Recourse"). They do have the secret escape hatch though.
Yes, I don't have configured any way to bring up a keyboard when not in a text entry field though, so no luck there.
1
1
FWIW, Hacker's Keyboard can do this. I don't like it as a default keyboard but it has a few nice features. I think long pressing the menu button does it for the AOSP keyboard and Gboard but phones don't include physical buttons anymore, let alone the menu button.
1
1
Show replies