search

claustromaniac / httpz

Fat-free hardenable opportunistic encryption for Firefox
https://addons.mozilla.org/firefox/addon/httpz/
GNU General Public License v3.0
61 stars 5 forks source link

Unsuccessful redirect to http & no toolbar icon #1

Closed ghost closed 5 years ago

ghost commented 5 years ago

HTTPZ 0.5.0 / Firefox 64.0 (x64) / Windows 7 (x64)

Hi,

As mentioned in the title, besides an unavailable httpz toolbar icon the extension here fails to redirect to http on http-only sites, but https-available site called via http was correctly redirected to https.

Examples:

http://www.cartesfrance.fr/ : no https, was not redirected to http http://www.acidtests.org/ : https available, was redirected successfully to https

Once these issues fixed (provided they are not explained by a compatibility reason with other extensions, settings of mine) I'd wish to know if HTTPZ handles 3rd-party sites : for instance cartesfrance.fr mentioned above calls http servers (but https available) which are handled correctly by the 'HTTPS Everywhere' extension. Does HTTPZ handle those 3rd-party servers as well?

I already use your three other Firefox extensions (Etag Stoppa, Poop, True Sight). I'd love to add HTTPZ to the lot and abandon 'HTTPS Everywhere' whatever its qualities.

claustromaniac commented 5 years ago

There is no toolbar icon for now, that is intended.

The error in https://www.cartesfrance.fr/ is not currently being handled by the extension. I will add it.

I'd wish to know if HTTPZ handles 3rd-party sites : for instance cartesfrance.fr mentioned above calls http servers (but https available) which are handled correctly by the 'HTTPS Everywhere' extension. Does HTTPZ handle those 3rd-party servers as well?

I'm not sure it would be necessary to handle those. Most HTTPS sites I've seen manage that on their own. I would have to take a good look first.

ghost commented 5 years ago

The error in https://www.cartesfrance.fr/ is not currently being handled by the extension. I will add it

I don't understand very well. The concept of HTTPZ is not based on a whitelist approach so what does 'including' a site mean?

I didn't mention that my first surprise with HTTPZ was to notice that my localhost pages (http://localhost/*) weren't handled (same as cartefrance.fr, error page).

I'm not sure it would be necessary to handle those. Most HTTPS sites I've seen manage that on their own. I would have to take a good look first.

The scenario I mentioned is that of an http only site calling via http servers which are https available. Seems to me that these calls be handled is pertinent even if they are a minority.

claustromaniac commented 5 years ago

The concept of HTTPZ is not based on a whitelist approach so what does 'including' a site mean?

I won't add a site. I will make the extension handle that error (SEC_ERROR_UNKNOWN_ISSUER), as it should.

ghost commented 5 years ago

OK. So HTTPZ reverts to http on the basis of the connection error. I get it, thanks.

claustromaniac commented 5 years ago

The scenario I mentioned is that of an http only site calling via http servers which are https available. Seems to me that these calls be handled is pertinent even if they are a minority.

So you mean upgrading requests triggered from HTTP sites to third-party sites that support HTTPS, did I get that right? Sure, I can do that.

ghost commented 5 years ago

Exactly. This problematic was that of the extension 'SmartHTTPS' which is why I had reverted to 'HTTPSEverywhere'.

I use an extension called SixIndicator which shows not only accessed 3rd-party sites but the security status of those connections as well:

With 'HTTPSEverywhere' on cartesfrance.fr 1

Without 'HTTPSEverywhere' 2

It seems to me security-wise to handle those connections, but I may be over-zealous

crssi commented 5 years ago

Another site that does not open... it may be related to the same problems as ^^above... IDK. If its different, then I can open a new issue?

http://www.yuntrack.com/

Cheers

sergeevabc commented 5 years ago

@crssi, meanwhile take a peek at HTTP-to-HTTPS (which is another alternative to Smart HTTPS).

claustromaniac commented 5 years ago

it may be related to the same problems as ^^above... IDK. If its different, then I can open a new issue?

It was due to an unrelated error (a timeout), but it is just as easy to fix. I will open a new issue for such reports, to keep them in one spot.

EDIT: both errors should be fixed in 0.5.1.

As for StanGets' second question/request, I may have jumped to a conclusion too early. I've been thinking it some more and I still haven't made a decision, but there are a number of problems:

  1. implementing that would most likely make the code a lot more complex and would have a significant impact on performance. For me, security & privacy > performance, but I think this point is worth mentioning anyway.
  2. if I use content scripts to implement that, it is very likely for that feature to leave us open to complex attacks that target extensions specifically. I don't think such attacks are common in the web, but it is still an important point to consider.
  3. I may be able to implement this without sacrificing security, but there will be other trade-offs. For starters, the extension will definitely not be as unobtrusive anymore, and it will break some sites in diverse new ways.

In case you are wondering, HTTPS Everywhere doesn't suffer from those problems because its approach uses a master list of domains, so it doesn't have to try and retry when something breaks - it's a safe route, so to speak. Of course, that extension has its own drawbacks for the users (it's heavy and it misses many sites that support HTTPS), and for the maintainers (they have to update the list constantly).

Anyway. I still didn't reach a decision, but don't expect me to implement that anytime soon (if ever).

ghost commented 5 years ago

In case you are wondering, HTTPS Everywhere doesn't suffer from those problems because its approach uses a master list of domains, so it doesn't have to try and retry when something breaks

Indeed. This is so obvious and corresponds to what the developer of a similar extension, HTTPtoHTTPS , had answered me when I submitted the same problematic about his extension

@claustromaniac maybe indeed my concern about 3rd-party servers isn't worth the complications of implementing it in a no-list approach, especially that this scenario is less and less encountered. I was in a theoretical state of mind when reality is efficiency+simplicity and that fine tuning is valuable in proportion of the probability what it tunes be encountered.

sergeevabc commented 5 years ago

@claustromaniac, what about a loop like for request in http_requests do try_https else try_http?

claustromaniac commented 5 years ago

especially that this scenario is less and less encountered.

Indeed. More and more sites adopt HTTPS as time passes. Anyway, my problem is only with the implementation. I would love to add this, it just is complicated.

@sergeevabc I wish it were that simple. The extension needs to block/abort/redirect HTTP requests before they take place, but it still needs the DOM to load to know which requests are going to be made. Retrying is the complicated part. I could instead try to fetch the HTML document in the background and work from there, but that would have its own set of different problems... Anyway, I have to think this more.

sergeevabc commented 5 years ago

@claustromaniac, why parsing DOM instead of hooking into web requests like some extensions do?

claustromaniac commented 5 years ago

@sergeevabc, this extension is already hooking into web requests. Redirecting top-level frame requests and retrying when they fail is trivial, but doing the same with requests triggered by the DOM has many complications (some of them I already mentioned).

claustromaniac commented 5 years ago

I've been leaving this open as a reminder but I don't really need it. I'm closing this. Thanks for the feedback.