What are these re-writes doing example-> https://www.eff.org/https-everywhere/atlas/domains/abmr.net.html
Chrome content rules: https://github.com/2d1/HTTPS-Everywhere/blob/master/src/chrome/content/rules/Aart_de_Vos.xml
HTTPS Everywhere is not particularly advised for platforms where avast is not scanning https.
With partial https enabled and the present security header situation, some here in the forums advise against it.
polonus
The statement was made a long time ago that “using https everywhere is a bad idea”
since it prevents Avast from checking the sites for malicious content.
Avast or any other AV can’t check what it can’t see. Using https everywhere makes you AV blind.
Moreover you have to be aware of sites with so-called mixed content.
Remember for a lot of sites that are forced to use https the security header situation is not optimal to say the least.
An example here: https://www.uploady.com/#!/download/FouiM5aocH2/wiKm56SjCf5er_Ik
One could check at http://cyh.herokuapp.com/cyh and http://www.webconfs.com/http-header-check.php and
https://securityheaders.com/test-http-headers.php
Or use an extension like https://www.recx.co.uk/products/chromeplugin.php#httpheaderandcookie
to check whether best policy measures were taken.
Look for issues here: http://toolbar.netcraft.com/site_report/
Some domains have problems like POODLE: http://www.webconfs.com/http-header-check.php
Others have exctensive server header proliferation problems, http only cookie warnings, and clickjacking warnings
For asp sites check at/scan with https://asafaweb.com/
The DNS configuration can be with issues (nameserver version proliferation, so script kiddies may attack):
http://www.dnsinspect.com/ or http://dnscheck.iis.se/
Now test some of what you find here: https://www.eff.org/https-everywhere/atlas/
and then reach your own conclusions why the majortity of websites both http and https are still grossly insecure and attackable.
Loads of sites are on outdated servers that are being badly managed and configured and webmasters keep websites up with
outdated and vulnerable CMS and even more vulnerable (free) plug-ins and themes.
Never assume your surfing is without risks and act accordingly and do not click randomly and become a victim of
adware tracking, monitoring, malcreants, ad retargeting, fingerprinting, viruses, worms, phishing, scams and fraud.
I hope you always will find the reliable, secure websites in between. Oh and feel protected through Avast ;D
polonus
I guess many of the re-written websites have problems like this:
Poodle Scan results
O2.CO.UK:443 (82.132.141.84) - VULNERABLE
This server supports the SSL v3 protocol.
This server does NOT support the SSL v2 protocol.
Scan results are cached globally for 15 minutes. This scan was performed just now. (2015-24-1: 15:21 CET)
Doesn’t this make you wonder? 
Bingo: http://toolbar.netcraft.com/site_report/?url=https%2F%2Fo2.co.uk.html
Confirmed Poodle Issue: http://toolbar.netcraft.com/site_report/?url=https%3A%2F%2Fwww.o2.co.uk%2F
and https://www.uploady.com/#!/download/~pe5A_~GScS/fK0J_B3JuLL2ZXdC
What we see there? cache-control - does not follow best policy ; X-XSS protection, X-frame-options, content-security-policy,
these headers are not being returned. Insecure settings for meta security headers like content-security-policy and cache-control,
broadway-a cookie security options - warnings and does not exist because of overriding conditions.
polonus
Also check here: https://www.whynopadlock.com/
for instance:
Yes, and what about insecure content: https://shopplugin.net/kb/insecure-content/
Threats: http://www.stealmylogin.com/
So common problems with insecure content on pages using SSL, which pertain in coding going on under the hood: https://wordpress.org/plugins/ssl-insecure-content-fixer/
An eye-opener here: https://www.owasp.org/index.php/How_to_write_insecure_code
polonus
Here we have a re-write with problems: https://www.eff.org/https-everywhere/atlas/domains/kaizencrossfit.com.html
Re: htxps://www.kaizencrossfit.com/ Your connection is not private - NET:ERR_CERT_COMMON_NAME_INVALID
FAIL: Found differences between information provided by your authoritative name servers and glue provided by the parent name servers:
ns1.cpanelservices.com. @parent=[104.206.178.2] @ns=[104.206.178.3]
The glue provided by the parent name servers has to match the data provided by the authoritative name servers.
So flagged here: https://app.webinspector.com/public/reports/29108267 Invalid SSL Certificate. CNAME IS MISMATCH
See: https://www.uploady.com/#!/download/E0CCl2jJE40/xu48327CYVmm6Oka
See: http://www.dnsinspect.com/kaizencrossfit.com/1422117236
→ http://toolbar.netcraft.com/site_report/?url=https%3A%2F%2Fwww.kaizencrossfit.com%2F
polonus
Here we have another problem for a so-called rfewritten SSL site:
Signature Algorithm sha1WithRSAEncryption (SHA-1 is being phased out) → http://foundeo.com/products/iis-weak-ssl-ciphers/test.cfm?test_domain=kenshoo.com
POODLE vulnerability: http://toolbar.netcraft.com/site_report/?url=https%3A%2F%2Fkenshoo.com
Number of insecure items: 110 → https://www.uploady.com/#!/download/MPuL5Z5pUvC/Io43IDxXZekxi7hg
Secure identifier sent: Unique IDs about your web browsing habits have been securely sent to third parties.
67=o0mj6upayitsnw////////////-ubaiygsp5hbr1ixyx7n4i-lxpttsugf7m_-oq_7kbhswn8hjgzgdvqmyt75q-ufxflesy62j9gpaey6zg_lbz9vb7ik/////////////ogrrcq0kqelef1gyok www.google.com
See: https://www.eff.org/https-everywhere/atlas/domains/kenshoo.com.html
Security Header Situation therefore unsatisfactory to say the least: https://www.uploady.com/#!/download/cUvo0RrsPG1/OjmnFA~Y15o2m~tT
polonus
@my good avast forum friends,
Here Google admits it has failed to make a clear-cut and understandable SSL warning: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43265.pdf
So the ultimate alert for an insecure https page or SSL warning is a fail.
Users do not understand why there is no padlock, why security headers weren’t installed or configured not according to best policies,
why there are certification mismatches, insecure items on the SSL-encrypted site, POODLE vulnerability through insecure protocol sequences
etc. etc.
I understand the implications of that google warning on a https website and won’t click on it - no-way. This because it is insecure and going there is dangerous, also towards my privacy. But there are still users that seek to circumvent access, because they are completely unaware of the dangers of insecure SSL websites.
polonus
Allthough tested good here: https://www.bluessl.com/en/ssltest → https://www.uploady.com/#!/download/_fHZW_u5Wu9/YTfgKE~FVE5OPJe6
It seems vulnerable to Poodle: Scan results
WXW.WEBINK.COM:443 (54.212.218.37) - VULNERABLE
This server supports the SSL v3 protocol.
This server does NOT support the SSL v2 protocol.
See: https://www.uploady.com/#!/download/BDY1g1MIzJn/Od2~7lLzsKgGuXsK
Security Header Status: https://www.uploady.com/#!/download/eRMc4vz~K_V/kz18AvPyyPmrn_3a
At least 1 third parties know you are on this webpage.
-d2whgtudg2hrtn.cloudfront.net → https://www.virustotal.com/nl/domain/d2whgtudg2hrtn.cloudfront.net/information/
Scan for: htxp://d2whgtudg2hrtn.cloudfront.net
Hostname: -d2whgtudg2hrtn.cloudfront.net
IP address: 54.230.50.128 *
System Details:
Running on: Apache-Coyote/1.1
Via proxy: 1.1
Unable to properly scan your site. Site returning error (40x): HTTP/1.1 400 Bad Request
Unable to properly scan your site. Site empty (no content): Content-Length: 0
polonus