disabling HSTS [LWN.net]

disabling HSTS

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

In order to make an even halfway informed decision you need to be pretty expert. So this approach essentially pushes Pale Moon into a tiny niche - only intended for people who are experts on the dozens of technologies used in order that their decisions about "whether to care" will be informed rather than undirected.

In practice what we know from observing users and from general human psychology is that even the experts will mostly just switch off safety devices that are annoying if that's easy, because humans don't value safety anywhere near as much as convenience, even though they're astonished by the consequences of that trade. Alas.

to post comments

disabling HSTS

Posted Apr 18, 2017 8:54 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (25 responses)

Yeah, no. I don't need to be an expert on cryptography to know that overriding the SSL error to some blog is not a security risk. The error is the certificate expired a few days ago and it's blindingly obvious what's going on, but that's not even the point. The point is I would have connected to this site over HTTP; connecting through a days-expired SSL certificate is certainly no worse than that.

I wouldn't necessarily trust the general population to know when and when not to override SSL errors, but I would certainly trust just about everyone on this site. I'd trust most of SoylentNews and Slashdot, even. Not that it matters, because, even if I didn't, people at our level will find a way. Ffs, the comment we're replying to is someone talking about how to type raw HTTP GET commands into openssl so you can save the HTML to a file and then point the browser at that file ... to override the SSL error. And thanks, btw, I learned something new from that, but it's also absurd that some browsers reduce us to having to do that.

You want to stop the clueless from overriding SSL errors for HSTS sites, make it a hidden option in about:config and be done with it. Don't get in the way of the significant population of people who know what they're doing.

disabling HSTS

Posted Apr 18, 2017 13:42 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (20 responses)

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.

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.

disabling HSTS

Posted Apr 24, 2017 15:46 UTC (Mon) by gerv (guest, #3376) [Link] (3 responses)

Well... did you know that the cert could be revoked, but even if you check the CA won't tell you because expired certificates are not required to be on any revocation lists? So this cert could have been misissued a couple of years ago, then revoked, but now it's expired the attacker is trying to use it again.

Also, did you know that when you override a cert error, you allow that cert for any SAN in it, not just the one you are connecting to? So if that cert is for www.securityblog.example.com and also www.paypal.com, you just allowed them to MITM you for paypal.com. This is more of a risk for self-signed than for expired, but I bet you didn't know it, nevertheless.

Overriding SSL cert errors, particularly with the permanent flag checked, is a _bad_ idea.

disabling HSTS

Posted Apr 24, 2017 21:43 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

Except if it's your own self-signed cert, or a cert generated by some embedded box or software you own and necessarily trust. I definitely trust my ADSL router -- I have to even though it is a horrible closed lump, since *everything* flows through it and it can change everything. It has a self-signed cert for its admin pages. There is no point not accepting that... it can already MITM me if it wants to in a much simpler fashion.

disabling HSTS

Posted Apr 24, 2017 22:38 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> I definitely trust my ADSL router -- I have to even though it is a horrible closed lump, since *everything* flows through it and it can change everything. It has a self-signed cert for its admin pages. There is no point not accepting that... it can already MITM me if it wants to in a much simpler fashion.

The router may be able to change any of the traffic passing through it, but that does not imply that it can present itself as an arbitrary properly authenticated HTTPS site... unless you accept its self-signed certificate without first checking that the certificate is limited to the router's admin domain. TLS is specifically designed to thwart MiTM attackers with exactly that ability to intercept and modify any of the participants' traffic.

disabling HSTS

Posted Apr 29, 2017 19:32 UTC (Sat) by flussence (guest, #85566) [Link]

My router's UI optimizes for "not terrorizing the user": it uses HTTP Authenticate, which just pops up a modal username/password box and bypasses all this warning fatigue. Completely insecure, and yet it's the least awful option browsers give us.

disabling HSTS

Posted Apr 18, 2017 13:22 UTC (Tue) by bandrami (guest, #94229) [Link] (2 responses)

Funny, I don't know of a single browser that complains about a plaintext connection, despite the fact that it's strictly worse than an HTTPS connection with a problematic certificate. Kind of makes the whole certificate verification paranoia seem like so much theater.

Seriously, this seems so obvious: there are two questions that TLS is trying to answer at once. I want to know

A) is the transport between me and the other party secure? and sometimes
B) is the other party who he or she claims to be?

For most traffic (where even a verified A isn't particularly trusted), A is the much more important question, and hand-wringing about B has prevented widespread adoption of simple techniques to solve A. Establish a secure channel, and we can then use that to negotiate authenticity.

disabling HSTS

Posted Apr 18, 2017 14:02 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

In this case, torservers.net is HSTS pre-loaded. So if you try typing the HTTP version of the URL into a halfway modern browser it'll just turn into the HTTPS version. It won't complain, it just won't let you access the HTTP URLs at all.

In a current (late 2016, 2017) browser HTTP sites are affirmatively marked insecure if they seem to have content that you'd expect to be secured, such as a password dialog (really, you want asterisks on the screen, then you're going to send it plaintext over the Internet..?). In a modern (2015 onwards) browser new features don't work for HTTP at all, location services, integrated video conferencing, all that stuff is gated on HTTPS

Eventually (maybe 10 years from here) HTTP sites will all be marked affirmatively insecure, so yes, the browser will "complain". In hindsight this is how things should have worked from the outset, but I've met Tim and he's not exactly the sort of person to fully chase things through before putting them live, so by the time his Web was visible to the world it was too late.

Your A / B observation is very old, and we accepted the same rationale for SMTP (see below) but notice that A without B gives you nothing whatsoever in the fact of an active adversary. Now, many years ago people might have argued that active adversaries are extremely rare, maybe they don't even exist. But then Google & co inadvertently discovered that they not only exist, they're so common they think this is their network and they will fight very hard to sabotage it if given the opportunity. Such adversaries do not wish their existence to be widely known, if you've ever wondered why Google is so enthusiastic about transparency, that's why. Creatures that fear the light are not dangerous - so long as you stay out of the shade.

Now, for SMTP we were stuck with a problem. Like HTTP, SMTP is plaintext by default and there was a huge installed base of systems that only grok plaintext SMTP. To deploy anything at all it needed to seamlessly interoperate, otherwise you've got a flag day for email and that's not happening. So for SMTP we have "opportunistic encryption" where most clients will ignore the poor quality of certificates and encryption settings out there, because anything is better than nothing. But the result is pretty poor, an active adversary can snoop all the email pretty effectively, we know that in some countries this is happening today - and even a passive adversary can snoop a lot of email, a lot of the time. We have no idea how common that is. But it's a start, the ambition is to some day tighten things up, as happened previously for the Web PKI itself.

disabling HSTS

Posted Apr 18, 2017 14:21 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Seriously, this seems so obvious: there are two questions that TLS is trying to answer at once. I want to know
>
> A) is the transport between me and the other party secure? and sometimes
> B) is the other party who he or she claims to be?
>
> For most traffic (where even a verified A isn't particularly trusted), A is the much more important question, and hand-wringing about B has prevented widespread adoption of simple techniques to solve A. Establish a secure channel, and we can then use that to negotiate authenticity.

You can't solve A without solving B. If you don't know whether the other party is who they claim to be, you don't know whether you are talking to the other party or to an eavesdropper. That is, if Alice can't authenticate Bob, she can't know whether the connection is going A -> B or A -> E -> B, where Eve is talking to Alice as if she were Bob, and talking to Bob as if she were Alice, repeating (and possibly modifying) the messages between them.

> Funny, I don't know of a single browser that complains about a plaintext connection, despite the fact that it's strictly worse than an HTTPS connection with a problematic certificate. Kind of makes the whole certificate verification paranoia seem like so much theater.

I know of one: recent versions of Firefox complain about plaintext connections with password form fields. The reason for not complaining is historical (plaintext connections came first and are still very widespread), but that's slowly beginning to change. Also, once users start trusting the "https://" as the sign of a "safe" connection, it becomes important to warn or block the connection in case it's compromised.