Show exactly what is being blocked when clicking the extension.

[Nige_39]

I think it's because I allow ads from trusted sources which means that instead of blocking an ad it will replace it with an address to AdTrustMedia which HTTPS Everywhere does not agree with so HTTPS Everywhere redirects the element to some emediate or something url.

Edit: Yup, just tested with setting PrivDog to block all ads, then I get no conflicts. Heh though I still get conflicts for facebook button for an extension I hate seeing that button in chrome go yellow/orange.

I see where you are coming from now, But it is still a mystery on what is happening on your system

Regards

Nigel 

[Sanya IV Litvyak]

I see where you are coming from now, But it is still a mystery on what is happening on your system

Regards

Nigel 

I don't think it's that much of a mystery. I assume that PrivDog acts first on the element and redirects the element to point to adtrustmedia and HTTPS Everywhere acts later and tris to redirect the element to the https version of that ad and since it acts later it overrides what PrivDog did, OR it simply just has a higher priority somehow, does PrivDog use the "!important" thingy apparently Chrome has some thing I think it's "!important" and only other applications using "!important" can override an application that uses "!important" so it could be that HTTPS Everywhere uses "!important" and PrivDog does not? I really don't know but I don't think it's a mystery.

[JoWa]

Indeed however if the domain isn't in the list it will take you to the http instead of https site, right? In that case you might want to have something that redirects you to the https site

Perhaps, but it might not be of such great worth and use as one would expect. See these FAQs:
https://www.eff.org/https-everywhere/faq
https://code.google.com/p/kbsslenforcer/wiki/FAQ#Is_it_secure_against_MITM/Firesheep_attacks?

[Sanya IV Litvyak]

Perhaps, but it might not be of such great worth and use as one would expect. See these FAQs:
https://www.eff.org/https-everywhere/faq
https://code.google.com/p/kbsslenforcer/wiki/FAQ#Is_it_secure_against_MITM/Firesheep_attacks?

I see, but still if HTTPS Everywhere and HSTS does not have the site registered then it will use the http protocol rather than the https protocol so MITM attacks are still able to happen with HTTPS Everywhere, the only unique problem with KB SSL Enforcer is that it might take you to sites that don't work, for example if it seems like a site supports SSL and it actually doesn't have all the stuff on it. (and the weakness of having to make the first request unencrypted) So then it would be great if you could layer them to first use HTTPS Everywhere system and if it is not registered then try the system KB SSL Enforcer uses since I would argue that using KB SSL Enforcer would be safer than not using anything like that at all, and now couple that with PrivDog and we have a nice extension.

[JoWa]

I see, but still if HTTPS Everywhere and HSTS does not have the site registered then it will use the http protocol rather than the https protocol so MITM attacks are still able to happen with HTTPS Everywhere

Not using https automatically does not mean you cannot use https, and I advise anyone to make sure https is used (if available) before exchanging information with a site. And though I think encryption should always be used, the real need for encryption varies depending on how a site is used. It does not matter much if you go to https://www.comodo.com or http://www.comodo.com if all you do is to browse the site. But using https://forums.comodo.com is important, not only when logging in, but also when sending and recieving PMs, for example.

the only unique problem with KB SSL Enforcer is that it might take you to sites that don't work, for example if it seems like a site supports SSL and it actually doesn't have all the stuff on it. (and the weakness of having to make the first request unencrypted)

Indeed make the first request unencrypted. You will probably not even notice that happens, and you will think that encryption was used all the time.

[Sanya IV Litvyak]

Not using https automatically does not mean you cannot use https

I wasn't implying otherwise.

Indeed make the first request unencrypted. You will probably not even notice that happens, and you will think that encryption was used all the time.

Okay think about it this way:
Scenario 1: You do not have HTTPS Everywhere or KB SSL Enforcer but you do manually set websites to HTTPS when you visit them, the issue of first making unencrypted requests is there.

Scenario 2: You do have HTTPS Everywhere but not KB SSL Enforcer and you do manually set websites to HTTPS when you visit them, the websites known by HTTPS Everywhere will not make any unencrypted requests but websites not known by HTTPS (or HSTS) will still have the issue of first requesting unencrypted.

Scenario 2.5: You do have HTTPS Everywhere but not KB SSL Enforcer and you don't manually set websites to HTTPS when you visit them, websites known to HTTPS Everywhere will always be encrypted with no "leakage" however sites not known to HTTPS Everywhere will most likely always be HTTP instead of HTTPS which is more damaging than if just a single first requests were unencrypted.

Scenario 3: You do have KB SSL Enforcer but not HTTPS Everywhere, you have the issue of initial unencrypted request.

Scenario 4: You do have an extension like HTTPS Everywhere and KB SSL Enforcer combined, The sites known to support HTTPS would directly connect to that while sites not known would automatically test if HTTPS is supported, the issue of initial unencrypted requests is still there but you won't forget to change the site to HTTPS in either way and anything subsequent will always be via HTTPS if the site allows it.

So by merging them into one, in my opinion you don't really get anything negative, however you do the get positive thing of never forgetting to set the websites that support it to HTTPS.

[JoWa]

By “manually set websites to HTTPS when you visit them” you seem to assume that I would first visit e.g. http://www.polisen.se and then add the heroic s: https://www.polisen.se
Well, I can go straight to https://www.polisen.se, in which case manually using https is more secure than doing it automatically (KB SSL Enforcer-method).
If I’m really cautious, I can make sure a domain (e.g. my bank) is in the HSTS-list before visiting it. Actually it is good to make sure to use strict security for such sites.

So by merging them into one, in my opinion you don't really get anything negative, however you do the get positive thing of never forgetting to set the websites that support it to HTTPS.

I think it might have the opposite effect, that I forget about https because I count on that someone else does it for me.

Another thing to remember is that HTTP Secure is not always secure. Old cryptographic protocols are insecure and it’s time to move (servers and browsers) to TLS 1.2.

Anyway, Adam Langley (Google) has written some articles you might find interesting: https://www.imperialviolet.org/posts-index.html

[Sanya IV Litvyak]

By “manually set websites to HTTPS when you visit them” you seem to assume that I would first visit e.g. http://www.polisen.se and then add the heroic s: https://www.polisen.se
Well, I can go straight to https://www.polisen.se, in which case manually using https is more secure than doing it automatically (KB SSL Enforcer-method).
If I’m really cautious, I can make sure a domain (e.g. my bank) is in the HSTS-list before visiting it. Actually it is good to make sure to use strict security for such sites.I think it might have the opposite effect, that I forget about https because I count on that someone else does it for me.

Another thing to remember is that HTTP Secure is not always secure. Old cryptographic protocols are insecure and it’s time to move (servers and browsers) to TLS 1.2.

Anyway, Adam Langley (Google) has written some articles you might find interesting: https://www.imperialviolet.org/posts-index.html

Hmm I see, would it not be possible to "hijack" the browser so that when someone tries to go to http://www.polisen.se it never requests that site before trying https://www.polisen.se but if it does not support SSL then fall back on http and display a message that the site does not support SSL and is hence not secure?

[JoWa]

Not in any way I am aware of. http is the default transport protocol for every browser and I guess that behaviour must be changed in the browser-code.

Replacing TCP with the UDP-based and encrypted QUIC will improve the situation.

It is also being discussed whether to make TLS mandatory in the SPDY-based HTTP 2.0 (draft).

[Sanya IV Litvyak]

Not in any way I am aware of. http is the default transport protocol for every browser and I guess that behaviour must be changed in the browser-code.

Shame however also in a way good from a security point of view on hijacking the browser.

Replacing TCP with the UDP-based and encrypted QUIC will improve the situation.

It is also being discussed whether to make TLS mandatory in the SPDY-based HTTP 2.0 (draft).

I don't know if I would vote yes for a mandatory TLS, however I would vote for it being the default. In my opinion security is more important than speed.

[JoWa]

Indeed, it’s a shame I don’t know everything. But I’m working on it.

QUIC and SPDY are meant to increase both security and speed. Speed (low latency) is also very important, especially for mobile networks.

[Sanya IV Litvyak]

Indeed, it’s a shame I don’t know everything. But I’m working on it.

Oh, sorry I didn't mean to imply that.

QUIC and SPDY are meant to increase both security and speed. Speed (low latency) is also very important, especially for mobile networks.

Standards and protocols take too long. When can we expect QUIC and SPDY to be ready? If any such date is available I mean.

[JoWa]

Oh, I’m sure you did.

Well, don’t hold your breath while waiting for HTTP 2.0 (you might turn pale while doing so).

SPDY is actually not a formal standard, but a de facto-standard (Wikipedia), and is already in use. Google, Facebook and Twitter use it on their servers, as do many others. Chromium, Firefox and Opera support it, and so does IE11 (source).

QUIC is at a more experimental state:

Our next step is to test the pros and cons of the QUIC design in the real world by experimenting with using QUIC for a small percentage of Chrome dev and canary channel traffic to some Google servers, just as we did with SPDY.

http://blog.chromium.org/2013/06/experimenting-with-quic.html

QUIC used in Chrome Canary (Google+)

[Sanya IV Litvyak]

Oh, I’m sure you did.

I didn't! 

Well, don’t hold your breath while waiting for HTTP 2.0 (you might turn pale while doing so).

SPDY is actually not a formal standard, but a de facto-standard (Wikipedia), and is already in use. Google, Facebook and Twitter use it on their servers, as do many others. Chromium, Firefox and Opera support it, and so does IE11 (source).

QUIC is at a more experimental state:http://blog.chromium.org/2013/06/experimenting-with-quic.html

QUIC used in Chrome Canary (Google+)

Oh alright, still I think the interwebs should be changed so HTTPS can be the default protocol instead of HTTP... however one would do that...