clarification regarding mitm attack

[atomGit]

this was brought up on the privacytools.io repo and i'm wondering if you could provide some insight claustro - thanks! ...

This is the issue with HTTPZ, and why I think HTTPS Everywhere's whitelist solution is the more secure option, even if it isn't as comprehensive. I haven't seen any evidence that HTTPZ has any kind of downgrade attack prevention.

For example, if I was an attacker in between a client and a webserver, say privacytools.io, I could block HTTPS access to https://privacytools.io, by blocking port 443 or whatever...

• From what I can tell, HTTPZ would just say "this resource isn't available over HTTPS" and happily load http://privacytools.io, because it has no way of knowing if the site should be loaded over HTTPS.

• On the other hand (assuming privacytools.io is in the whitelist), as far as I understand it, HTTPS Everywhere will see that access to https://privacytools.io is blocked (by the MITM) and not allow any connections over HTTP, because it knows that privacytools.io needs to be loaded over HTTPS. That's the entire point of the whitelist which I think is what is being missed in this thread.

Yes, HTTPZ may upgrade more connections to HTTPS, which is cool and all, but it doesn't prevent downgrade attacks which is a security flaw. This is the same issue I brought up when recommending to close #810 (comment).

[claustromaniac]

Well. Sure, that makes sense. That can be considered a vulnerability, in theory, but it is one that cannot be exploited reliably, because this extension only handles HTTP requests. This guy/gal spared me some explaining on that.

For example, say you visit http://github.com/ (note the http). HTTPZ redirects that request to https://github.com/ and shows the page action (the urlbar icon). Now, click some link there. No page action anymore? Why is that? Because the link already had https to begin with, so HTTPZ didn't have to do anything there. So, an attacker attempting to exploit that vulnerability would have only one shot in that scenario: that one time when HTTPZ redirected http://github.com/ to https://github.com/. Now, say you bookmark https://github.com/ or simply access it from the browser's history every time. No more chances for the evil guy there either. Ever.

As you see, it is not much of a risk, but it is a risk inherent to the way the extension works, and one I can at least help minimize even more. I'll hopefully do a beta release soon.

PS: I purposely ignored the fact that when you're being MitM'd by someone with the means to exploit that vulnerability, you have much more dangerous shit to be worrying about.

[claustromaniac]

Actually, my example above is kinda wrong in that the page action will still be displayed as long as you click the link after no more than two minutes have passed since https://github.com/ loaded. If that second request failed it wouldn't be redirected to http, though (no risk). I hope I'm making sense.

[claustromaniac]

0.7.0b introduces a new feature that should minimize the issue even more. I don't think much more can be done beyond that.

[atomGit]

thanks for your explanation and work claus - i would've commented sooner but i totally forgot i was the one that created the issue :)

your explanation indicates something i should already know, but apparently don't - that apparently there is no way to authenticate that the browser is talking only to who it's supposed to be talking to? the answer seems to be a resounding 'NO', else MITM attacks wouldn't be a thing

[if] you're being MitM'd by someone with the means to exploit that vulnerability, you have much more dangerous shit to be worrying about.

not only does that sound logical, but i would posit that anyone silly enough to do business over an unsecured connection has more shit to worry about

[claustromaniac]

apparently there is no way to authenticate that the browser is talking only to who it's supposed to be talking to? the answer seems to be a resounding 'NO', else MITM attacks wouldn't be a thing

There are some ways, but nothing is bullet proof. HTTPS is in part there for that... as long as certificates can't be spoofed you're safe to assume your browser is talking to whoever it's meant to be talking. Then there are CDNs that site owners give their private keys to, basically trading their users' privacy and security for their own convenience (basically shitting on the whole concept of authentication and allowing those intermediaries to read the communication in plain text), and shit like that. Firefox has a bunch of built-in protections against various MitM and phishing attacks, too, but it can't deal with the vast myriad of different attacks on its own in the end.

not only does that sound logical, but i would posit that anyone silly enough to do business over an unsecured connection has more shit to worry about

Absolutely. As it happens with almost everything related to privacy and security, the biggest risk factor is sitting right behind the keyboard.

Anyway, thanks for letting me know of this and also for recommending this extension :)

[stoically]

Nice work on HTTPZ - and thanks for recommending Temporary Containers. :)

Just a quick thought that came to mind while reading this: the web is moving to https-only anyway (let's encrypt, googles downranking of http sites, chrome planning to introduce https-first); how about letting HTTPZ show a warning-page (possible MITM ahead!) when downgrading to HTTP and let the user confirm before proceeding? (Like the certificate warning, just the other way around, heh)

[claustromaniac]

Nice work on HTTPZ

Hey, that means a lot coming from you! :smile_cat:

how about letting HTTPZ show a warning-page (possible MITM ahead!) when downgrading to HTTP and let the user confirm before proceeding?

Ah yes. I had the same idea the other day, but ended adding this option to remember secure sites, because it is simpler to implement and less obtrusive for the end user. I may eventually add that as an option, though.

Anyway, good to have you around!

[claustromaniac]

Just FYI, 0.7.0b6 allows users to toggle off the automatic redirection.