<ocdtrekkie>
Does anyone know how to turn HSTS entirely off, preferably in Firefox?
larjona has quit [Ping timeout: 265 seconds]
larjona has joined #sandstorm
larjona has quit [Client Quit]
larjona has joined #sandstorm
<isd>
I do not. Why do you want this?
<ocdtrekkie>
Because it's sole apparent purpose appears to be to disable user agency. Aka, I know why the website I'm going to doesn't have a valid cert, my browser should still let me go there.
<ocdtrekkie>
And it's particularly annoying when browsers say, you know, let the site's admin know... and I'm the site admin and it's interfering with my ability to fix it.
<ocdtrekkie>
I ended up changing the date on my PC... and then just turning off HTTPS requirements on this entirely until I can figure out how to extricate the HSTS setting specifically.
<ocdtrekkie>
My other plan was to use Internet Explorer since it's dumb enough (or enlightened enough?) to ignore HSTS but the app doesn't support IE anyways.
<ocdtrekkie>
(HSTS is a particularly dumb idea on solutions where all HTTPS config is in the browser interface.)
<isd>
The point of HSTS is to prevent MITM downgrade attacks, not to "disable user agency." It's a way for sites to tell browsers "if anybody claims to be me but says they don't support HTTPS, it's a trap."
<isd>
Does the HTTPS warning for this not give you the option of clicking through and viewing the site anyway?
<ocdtrekkie>
Correct, that is a key part of this awful standard.
<ocdtrekkie>
It's codified in the spec that browsers must not allow users to bypass the security warning if HSTS is enabled.
<isd>
Is the issue that the site doesn't have a cert, or that the cert is somehow not valid?
<ocdtrekkie>
It's expired.
<ocdtrekkie>
Hence me changing the date to get around this.
<isd>
In any case, I don't know if there's a way to get around it.
<ocdtrekkie>
Apparently the only thing I could find was a Firefox setting that tells it to offset it's idea of time, which seems likely to break other things.
<ocdtrekkie>
So once again, a Google employee has codified into the Internet standards something that has torched my day. \o/
<isd>
I hadn't realized the second part of HSTS, that it dictated not allowing users to click through. I'm kindof of two minds about it. On the one hand, I think you're being overly dismissive/cynical of the motivation; the thing is, if you do provide that click through thing, people will use it. Instead of pestering the site operator to fix their cert. Having site operators be able to say, "really, I'd rather my site break than let the security lapse,"
<isd>
and then take responsibility for it, seems useful. I kinda feel like this is on the site operator for turning on HSTS and then not actually keeping their cert up to date. That said, it's always annoying to be in the pisition of Knowing What You're Doing and not be able to do it. I kinda wish there was more diversity among browsers; leaving that click-through there seems like a defensible design choice in spite of what the spec says, but it's
<isd>
probably not the right one if your browser is for "everyone"
<isd>
Too bad implementing a browser is too damn complicated.
<isd>
There is something conceptually off about a MUST that pertains to a user interface in the spec of a network protocol.
<isd>
kentonv: I think it should be ok.
<ocdtrekkie>
Also, in my case, I believe this software turned on HSTS itself in a software update. I would not have done it myself.
<isd>
Ah, so you are the server operator in this case? I think the real issue there then is that the server probably shouldn't just do that unless it can also make the necessary guarantees about keeping the cert up to date.
<ocdtrekkie>
Which it can't. :| But yeah, I updated our open issue about why I'd now be disinclined for HSTS to be decided upon by a software update instead of being automatically enabled.
xet7 has quit [Remote host closed the connection]
* garrison
wonders how Caddy deals with HSTS. Of course, it's not configured through a web interface, so you don't exactly get locked out of administration if the certificate expires.
xet7 has joined #sandstorm
<isd>
We don't exactly have a good story wrt. doing anything cert related in the UI right now.
<isd>
kentonv: iirc, there was some issue with websockets that cropped up trying to use the web UI with an invalid cert, even after clicking through the usual warnings?
<isd>
If that's the case, then in practice we're probably hosed as far as the UI is concerned if a cert expires or something anyway.
<isd>
I cannot remember the details.
<kentonv>
yeah clicking through the cert warning doesn't necessarily allow WebSockets to work IIRC
<isd>
And because meteor's stuff all uses websites..yeah.
<isd>
griff: ^
<isd>
Yeah, iirc I tried it and some of the icons were weird sizes.
<isd>
So I think that's not done yet.
<ocdtrekkie>
The idea of not having to install an ancient Meteor to generate icons though... it's a very appealing PR to solve, lol.
<isd>
Especially since said old version of meteor includes verison of openssl which is now broken on a bunch of sites... it's why CI is seeing so many failures.
<kentonv>
whoa, my test run just now only had two failures
<isd>
Oh?
<kentonv>
I mean, locally on my machine... but yeah
<kentonv>
I haven't seen fewer than three failures in a long time
<kentonv>
last update it was like 20 failures
<kentonv>
the only failures are tests/account and apps/web-publishing. The latter is the one that's been broken forever because the mechanics of grain shutdown changed in a way that broke the test's assumptions
<isd>
I will have to try this.
<kentonv>
I did push the new meteor-spk and merged your testapp change