disabling HSTS [LWN.net]

disabling HSTS

Posted Apr 18, 2017 13:42 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: disabling HSTS by linuxrocks123
Parent article: Tor exit node operator arrested in Russia (TorServers.net blog)

Yes, the comment takes a very long-winded way to achieve something simple (download a single resources, ignoring all error conditions) which could be accomplished with curl or similar. I don't know why, proof of concept maybe ?

The site's administrator specifically doesn't want you reading their site without HTTPS, that's the purpose of the HSTS setting. A web browser seems like exactly the right place to put that behaviour choice, if you want to subvert it through technical means you can, as shown, but there's no reason it would be the default.

Now, doubtless you'll protest that clicking through a warning isn't "the default", but alas because of a human cognitive defect it is. Anything that gets in the way of the task is dismissed. This isn't something special about the web, or computers, it happens in the real world too, most of those "low bridge" crashes happen that way, the driver is intellectually able to process the fact that their vehicle is too tall for the bridge, but their plan says they're going to drive under the bridge, only hitting the bridge will finally undo that plan.

The overarching philosophy is also important to a browser as opposed to something like curl that just fetches a single resource. What happens if an image link leads to an HSTS site with a defective certificate? Does the image load anyway? How is it indicated to you, the end user, that the image isn't actually trusted after all despite it seeming to be from an HTTPS URL? What if instead of an image it's Javascript? What if it's an Ajax endpoint?

In practice humans aren't interested in taking on the tremendous work implied by letting them, as you would, take the decision. So, they're just going to click "Yes / ignore / I don't care / fuck it, in for a penny in for a pound" and in practice the browser's policy becomes "We don't actually have security, we decided users would prefer to go without". So long as there are only a tiny minority opting out this even looks superficially safe - it's not worth targeting a few thousand Pale Moon users.

to post comments

disabling HSTS

Posted Apr 18, 2017 23:46 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (19 responses)

My assumption was he did it that way because CURL didn't work, but maybe he just didn't try it. In any case, it was genuinely cool.

I said in the comment I replied to to make it a hidden option in about:config. That takes a lot more doing to override than clicking through a warning, and it's SOP for the Mozilla projects to use about:config to hide "dangerous" settings.

The bottom line is it's my machine, and the software on it is there to do my bidding. Software that intentionally goes against what I want to do is repugnant when it's because of DRM and is just as repugnant when it's because it thinks it knows better. FLOSS was founded on the principle of liberating users. Taking away users' agency is not what our community is about.

disabling HSTS

Posted Apr 19, 2017 0:02 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (14 responses)

> Taking away users' agency is not what our community is about.

Indeed. That's why you have the source code, the right to modify that source code and the right to share your changes with others. But the authors of the upstream code have made a decision that offering the option that you want will hurt other users more than it will help them (eg: a large company manages to break SSL on an HSTS site. Support advises users to change something under about:config while it's being fixed. These users don't end up making an informed decision about security, and are now vulnerable to being MITMed in situations where they'd otherwise be protected), and that's a justifiable position for them to take.

disabling HSTS

Posted Apr 19, 2017 2:31 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (13 responses)

Yeah, I get that, and I think that's against the spirit of what our community is about. Saying "download the source code and make the change yourself" is fine when the project is trivial to compile, but I know from experience that getting Mozilla-based browsers to compile, while many things, is not a trivial exercise. A web browser that intentionally makes it so users can't visit certain websites effectively cripples their ability to visit those sites unless they have the technical expertise to compile a browser on their own or find someone else willing to step into the developer's shoes, create a custom build, and distribute it themselves. That isn't guaranteed, and Googling turns up several instances of poor souls trying to hack around with about:config and internal Firefox data files just to get their browser to visit the websites they want, mostly unsuccessfully. Those users are just stuck, so intentionally distributing crippled builds as the official builds is going way, way too far.

But, hey, I guess this will lead to more Pale Moon users, which would be a happy result. I'll even help by directing them to it in those help forums.

I still say shame on Firefox, though.

disabling HSTS

Posted Apr 19, 2017 2:47 UTC (Wed) by pabs (subscriber, #43278) [Link]

It could also lead to more Tor Browser users, where killing your HSTS entries is one 'New Identity' click away :)

disabling HSTS

Posted Apr 19, 2017 3:29 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (11 responses)

The website owner explicitly requested that browsers impose this policy. Doing so is entirely within the spirit of our community.

disabling HSTS

Posted Apr 19, 2017 6:36 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (10 responses)

I guess we should get some patches to ffmpeg, mplayer, vlc, and friends to abort with error when an input has the broadcast flag or CGMS-A on it then. After all, some random remote party involved in the content's creation or distribution is requesting those programs not to function when that data is present. By your logic, we should listen.

disabling HSTS

Posted Apr 19, 2017 6:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (9 responses)

Like the patches to the kernel that cause wireless hardware to listen to the region provided by the access point and disable certain frequencies? Whatever decisions upstream makes, having the source means that you can make your own choices. That's the contract the community has, nothing more.

disabling HSTS

Posted Apr 19, 2017 22:37 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (8 responses)

I have mixed feelings even about cryptographically verifying CRDA uploads, but wireless frequency regulation is a unique situation.

"Directing the hardware to do something blatantly unethical and illegal" != "Directing a browser to visit a website that's misconfigured"

You didn't answer my question about patching media players.

disabling HSTS

Posted Apr 19, 2017 22:51 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (7 responses)

The media player case isn't comparable - HSTS is about the site maintainer making a decision that gives them no benefit but is intended to improve the security of their user, while DRM is intended to benefit the rights holder while harming the user.

disabling HSTS

Posted Apr 20, 2017 2:59 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

Good point. I disagree that being motivated by paternalism rather than selfishness is an important distinction, but it is a distinction.

disabling HSTS

Posted Apr 21, 2017 19:15 UTC (Fri) by aggelos (subscriber, #41752) [Link] (5 responses)

> Whatever decisions upstream makes, having the source means that you can make your own choices.

Does it? Life is short. Even those of us who can code, probably want to
spend what (little) time remains outside work and (other?) social obligations
for personal fulfillment and gratification. Even when driven by larger concerns
(e.g. helping produce a healthy body of free software), one's time is arguably
better spent on what they enjoy doing, as that normally leads to more work, of
higher quality. Unless there's a critical mass of developers who would maintain
a minimal fork, carrying local modifications and eternally playing catch-up
with upstream is a losing game. That is without taking into account
considerations about ease of deployment and the implausibility of always having
time and motivation to spend on merging with upstream, rebuilding, etc
when some vital fix comes along (time which would normally be spent by your
friendly package maintainer).

For people who are more removed from programming as a daily practice, that is
even less of an option. Paying someone to maintain local changes forever and
learning what I'm sure seems like a very technical procedure for having your
own copy of a popular program is something few people would be prepared to do
(perhaps rightly so).

To a large degree this is unavoidable. Those who do the work get to decide on
the direction and even the minor implementation choices. Let's not pretend
there's an option though. This 'option' is only a theoretical possibility for
professional developers. Consider: every developer probably has 100-odd things
they'd like to be different in the programs they regularly use, yet they have
investigated, coded up and pushed for the inclusion of a patch for, like, five
of those? Closer to two?

Which brings me to the actual point.

> That's the contract the community has, nothing more.

Programs are large and complicated. The legal possibility of maintaining your
own fork is meaningless as a solution. What can and does work is listening to
people and taking their needs into consideration. Yes, the weighing of
conflicting needs is usually done by the developers or their employers, which
tends to bias the process in various ways[0]. This is inescapable. There
is a fundamental assymetry between the role of user and developer. It is
hardly news that the legal status of a piece of free software primarily
empowers developers and entities (or people) with large financial resources.
When it comes to users though, their agency is only preserved in their
interaction with the developers of the software they use. That is, in the
structure and decision-making processes we build around our projects. The
license is not enough.

This then is my point. The choice to not allow the user of the browser to
bypass the certificate check in the presence of HSTS is one that throws user
agency out the window. It is a choice some of us would have made too, and
could easily justify it in terms of second-order effects that are beneficial
for the users. This does not change the fact that the software is working
against the will of the user and is rubbing this in the user's face (that is in
contrast with most UIs which direct the user by omission).

It is in one word, disempowering. And this matters because putting
machinery under the control of its users is what free software is about. It is
about control. That control is rightly limited to make for a more useful system
(e.g. access checks, proper implementation of a network protocol etc). Yet
those serve to *enable* the user to communicate. Whereas examples such as
obeying CRDA and refusing to accept a certificate work in the opposite
direction. There is a good argument to be made that this is justified because
of the second order effects. All well and good.

But the argument (IIUIC) that "you have the source and the right to modify it
and distribute modifications, so user agency is preserved" does not, in
general, hold water. One can easily think of instances where
user-disempowering choices have been less than justified. If users do not
feel in control of their own system when using free software, then its value
compared to proprietary software is diminished. And that, i.e. less user
adoption and investment, has its own second-order effects too.

Geez this came out long.

[0] E.g. daunting and chaotic configurability or indifference to user issues,
to take two cliched cases.

disabling HSTS

Posted Apr 22, 2017 4:16 UTC (Sat) by pabs (subscriber, #43278) [Link] (3 responses)

I think this topic would make a great LWN article.

disabling HSTS

Posted Apr 22, 2017 8:21 UTC (Sat) by aggelos (subscriber, #41752) [Link] (2 responses)

Can I go a bit meta? I'm not sure articles diverging from the open source orthodoxy are a great idea for LWN (but see below).

One characteristic of LWN is that, AFAIU, people look forward to reading it as part of their Thursday morning routine (or daily routine now), knowing that there's a minimal chance it'll get their pulse rate up. Perhaps I'm mistaken, but the editors seem to have settled (in practice; not saying they actually discussed this) on a "no original controversy" (akin to Wikipedia's "no original research") rule. There's something to be said for this (apparent) rule. While I'm sure position articles which are controversial for the current audience of LWN would drive hits (and links) up, it's not obvious to me that people would want to fund such a publishing venue. Linking to an article that people are not comfortable with is one thing, having LWN endorse it by (possibly paying for its) publication is quite another.

So while some of us would appreciate reading articles which challenge our world view on LWN, would we keep paying for it if it did that regularly and deliberately? Probably not. I have zero data on this (and would very much like to learn more about actual case or aggregate studies), but I suspect a smaller, slowly-growing, ideologically-homogeneous (more or less) reader base is better suited to a subscriber-based site than a larger, polarized (across any number of axes) one.

That said, I do think there's room for experimentation within the current subscription model without succumbing to trollumnism. Say, by considering views which are in opposition to the kernel's groupthink regarding abuse or critical of the LF (or actually, any views which our editors might be mildly uncomfortable with but think are relevant to LWN's audience). The way things are, I doubt outside contributors would feel comfortable approaching LWN with such articles. But every move towards diversity acts as positive feedback.

So while I can't claim it's a Great Idea for LWN to do that, it is for the LWN I want to subscribe to. It might even be a Good Idea when it comes to low-hanging fruit such as the topic of this subthread here :-)

disabling HSTS

Posted Apr 22, 2017 13:10 UTC (Sat) by anarcat (subscriber, #66354) [Link]

Can I go a bit meta? I'm not sure articles diverging from the open source orthodoxy are a great idea for LWN (but see below).

Sure, but then we're deep into off-topic territory, and you're making me want an article about journalism itself, even though I just started here. ;)

As a new contributor here, I understand what you are talking about, but I identify it more with my own nature than LWN itself: I assume certain topics are off the table, and just self censor, so far. I have yet to come across direct editorial interference in my work, in general. The only exception is one case where I have made a broad social statement that was for me a basic axiom ("large corporations are bad", more or less) but that for the general public may not be a given fact. Keeping that argument in place would have required an elaborate rationalization of the argument, which defeated its purpose: it was supposed to be an argument, not an axiom. :) The trick is that controversial topics are, by nature, harder to argue than well-established positions, which is why you are going to have trouble finding journalists argue those correctly.

Nevertheless, I am, generally, confident that I will be able to bring controversial topics here - and I believe I did a few times already. As a journalist, however, your duty is not to take sides but to reflect on a discussion or situation that is already happening between different parties. Sure, there are opinion pieces to be made, but even those, I feel, are stronger when they are backed by strong arguments. In that context, your comment is even more interesting because it brings nice sound bites I can quote in an article while keeping critical distance. ;)

And as pabs said, there's a "Write for us" button on the left column, try it out and be the media.

disabling HSTS

Posted Apr 24, 2017 17:53 UTC (Mon) by Wol (subscriber, #4433) [Link]

> Can I go a bit meta? I'm not sure articles diverging from the open source orthodoxy are a great idea for LWN (but see below).

I miss Groklaw. But that had aggressive moderation. There were some wonderful off-topic conversations there. PJ just had this simple rule - you could argue anything you liked so long as you had the facts/argument to back yourself up, and you weren't offensive.

(This did cause a few problems, when English and American disagreed as to what was offensive ...)

Cheers,
Wol

disabling HSTS

Posted Apr 22, 2017 13:23 UTC (Sat) by anarcat (subscriber, #66354) [Link]

Freedom is being able to make decisions that affect mainly you. Power is being able to make decisions that affect others more than you. If we confuse power with freedom, we will fail to uphold real freedom. -- Richard Stallman

This is an off-topic but interesting debate. As a person that just enables HSTS yet sometimes has trouble visiting sites because of SSL compatibility problems, I certainly understand the frustration. While it is true that developers can fix that issue on their own, by basically forking a major web browser, that is no small feat of engineering. That software is a really complex piece of machinery, probably one of the most complex standalone pieces of software ever built. What is being proposed is to fork this to remove a limitation a site's author wanted to be configured. I believe this is being a little dishonest: there's nothing simple or easy about doing that kind of stuff. Some people *may* be able to do so, most people can't and basically nobody will.

The underlying problem here is that we have two different freedoms in conflict - one is the freedom of the website author to keep its content private to only the people that visit the site, ensuring better security for its users but also protecting itself from the liability of certain attacks. The other is the freedom for some of *those* users to disable those protections. Should users be able to disable such policies on their own? Maybe.

But why? In this case, it was to workaround a configuration problem on the server, which disabled the service. Should web browsers be modified to work around configuration problems on the server? My answer to this is an emphatic: oh please please please no. I would understand if there would be a more reasonable use case here, but there are legitimate technical reasons behind HSTS. If a websites shoots itself in the foot and (say) starts running on port 80 instead of port 443 because of a typo, should a browser start guessing and fallback to do SSL on port 80? No! We have standards for this, and HSTS was establish to say "I know what I'm doing, disable the site if i fuckup my ssl config". That's what torservers.net said, then they fucked up, and the site went down. Don't go blaming the browser for limiting your freedom then. The server admins did that. And now it's fixed.

So maybe now we can move on to free Bogatov already. The point of this news was not to satisfy your pet peeve about some weird technological corner of the internet. A fellow Debian Developer is in jail for enabling journalists and researchers to do anonymous work on the internet. Help him.

disabling HSTS

Posted Apr 19, 2017 1:28 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (3 responses)

Curl will actually do this properly because it understands both HTTPS and TLS, which is if anything _more_ likely to actually work than this trick using s_client. It aso requires (in modern versions of curl) you to explicitly enable a flag saying you don't want the security features, for each such resource fetched.

An about:config option would presumably be global, so the effect is "set this, and then you can ignore stuff by clicking through it" which is exactly what we already know doesn't work. But the facts have never impinged on projects like Pale Moon before and I don't see that changing.

[ Fun fact: Pale Moon decided Let's Encrypt is untrustworthy because the lead developer of Pale Moon thinks a CA should be responsible for preventing phishing and malvertising. Also, some hard to follow logic whereby there's an "inherent lack of validation" in Let's Encrypt's validation system (I have a long rant about this, but basically Ballot 169 rules significantly tighten up validation for the Web PKI, three of the nine methods specified in Ballot 169 are modelled on how Let's Encrypt already worked when the ballot was written, those three Ballot 169 methods are basically like the ELI5 sketch of how Let's Encrypt does validation, they don't really capture the nuances, but at least they're an improvement on the total ignorance that reigned prior). You won't have noticed because "untrustworthy" for Pale Moon turns out to mean nothing whatsoever, Let's Encrypt certificates still work fine, not that it matters because presumably you'd just click through the errors anyway and press on. ]

disabling HSTS

Posted Apr 19, 2017 3:10 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

> An about:config option would presumably be global, so the effect is "set this, and then you can ignore stuff by clicking through it"

The about:config option could be a list of domains to ignore HSTS for, or any number of other things.

> [Pale Moon doesn't trust Let's Encrypt.]

Indeed, it appears Pale Moon doesn't trust Let's Encrypt. The reasons appear to be different than you describe, however; Moonchild's main beef appears to be with the fact that there is no way to get Let's Encrypt to generate a revocation for a fraudulently issued certificate. That sound bad; I hope they fix that, if that's true.

> You won't have noticed because "untrustworthy" for Pale Moon turns out to mean nothing whatsoever, Let's Encrypt certificates still work fine

There's some false information here. Let's Encrypt certificates do, indeed, work fine in Pale Moon, but that is because the Let's Encrypt intermediate certificates are cross-signed by IdenTrust; indeed, viewing a site using Let's Encrypt as its CA results in "Verified by: IdenTrust" in the security information.

However, I can assure you that it is not the case that Pale Moon trusts certificates without a chain of trust ending in a root certificate it trusts. I can also assure you that Pale Moon behaves differently when it doesn't trust a certificate. As with anyone else, I run into self-signed certificate errors and "THE CERTIFICATE EXPIRED YESTERDAY PANIC PANIC OMGWTFBBQ!" inanity on a semi-regular basis. Every time I do, Pale Moon displays a dramatic, full-page, really scary error message with a blood red background. It doesn't do this for trusted certificates, so it's easy to tell when Pale Moon doesn't trust something.

> not that it matters because presumably you'd just click through the errors anyway and press on.

I doubt you really think, given our conversation, that I would blindly click through a certificate error for a site I use regularly and then give that site my login information. Are personal attacks really necessary?

disabling HSTS

Posted Apr 19, 2017 18:58 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

You can read everything I described about their position on Let's Encrypt in https://github.com/MoonchildProductions/Pale-Moon/issues/171

As with any other public CA, Let's Encrypt allows certificate problem reports, through which you could achieve revocation of a fraudulently issued certificate. However a certificate is not "fraudulently issued" just because you don't like who it was issued to or how they're using it, if Steve murders a woman in cold blood, then drives to the airport and boards a plane, neither his driving license nor his passport become "fraudulently issued" just because Steve is now a murderer. This is, by some irony, not so different from the muddled thinking that has the Russians persecuting a Tor node operator for the behaviour of Tor users.

But my main point wasn't this mundane lack of understanding, even though it ought to be enough for you not to want anything to do with somebody developing a web browser, we see the same failure to comprehend from all over. My point was that having decided this is untrustworthy Moonchild decided to do nothing whatsoever about it, so that the effect is exactly the same as if they hadn't made this silly declaration at all. You correctly diagnosed that the result is the certificates are trusted because they were cross-signed. But this isn't the end of the trail at all, stopping there tacitly accepts that these certificates and the CA are fine, but just you're going to make a song and dance.

As far as Pale Moon is concerned the Let's Encrypt CA is just a subCA for Identrust. Assuming that Pale Moon inherits most of the actual machinery of Mozilla's Firefox, this gives them three practical options to choose from. The most drastic is to demand IdenTrust fix this, or if they will not remove IdenTrust from their trust store for issuing subCA certificates to the untrustworthy Let's Encrypt. The next option is to add the cross-signed Let's Encrypt certs as explicitly distrusted in the Pale Moon package, this is how Firefox dealt with problems like DigiNotar early on. Finally the browser can be configured to restrict trust in some other way as a result of making a deal with Let's Encrypt, if they fix whatever troubles you, you'll trust certificates issued after some particular date.

In practice of course Let's Encrypt is ubiquitous at this point, so doing any of these things because of their misunderstanding about what it means for something to be "fraudulently issued" would be grossly disproportionate. But the situation today, in which they profess it is not "trustworthy" but in fact Pale Moon trusts it entirely is a joke.

disabling HSTS

Posted Apr 19, 2017 3:11 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

Btw, thanks for the info on CURL. Forgot to say that in my earlier reply.