s|b wrote:
> Today, I suddenly got an error while trying to do a search with
> Both IE 11.x and Fx 38.x were acting up.
>
> IE 11.x:
>
>
>
> This page can't be displayed
>
> - Make sure the web address https://startpage.com is correct.
> - Look for the page with your search engine.
> - Refresh the page in a few minutes.
>
> [Fix connection problems]
>
>
>
> Fx 38.x:
>
>
>
> Secure Connection Failed
>
> The connection to the server was reset while the page was loading.
>
> The page you are trying to view cannot be shown because the
> authenticity of the received data could not be verified.
> Please contact the website owners to inform them of this problem.
>
> [Try again] Report this error
>
>
>
> So, I started searching what could be wrong and by coincidence I found
> out it turned out to be Avast, more specific, the HTTPS scanning
> feature. Turning it off seemed to resolve the problem. There are several
> topics about it on the avast! webforum. For example:
>
>
> (I'm using Avast Free Antivirus 2015.10.2.2218.)
>
> The solution is to either turn off the HTTPS scanning completely:
>
> Settings > Active Protection > Web Shield > Customize > [v] Enable HTTPS
> scanning
>
> OR you can add exclusions like
>
> https://startpage.com/*
>
> Settings > Active Protection > Web Shield > Customize > Exclusions
> (menu on the left)
>
> You need to reboot in order for these to have effect.
>
> I also added my bank and PayPal, because I didn't feel quite comfortable
> about Avast being "the man in the middle" during my transactions. A bit
> late, I know, but better late than never...
HTTPS scanning is way too slow in Avast. They perform the MITM attack
by installing a root certificate in your local certificate store (in
Windows, run certmgr.msc to see the Avast cert got installed). They
then have to intercept client's HTTPS connect to their local transparent
proxy. You'll notice the web browser will report Avast's cert, not the
site's cert, for the SSL/TLS connection. The traffic from the server
gets decrypted before passing it on to your client (web browser). This
lets Avast do the same content interrogation that it can for HTTP
(non-secure) connects. Then it has to encrypt the traffic before
sending it on to your client. All that takes time and Avast is too slow
for all of this. If you didn't notice it, web surfing gets a l-o-t
slower when Avast's HTTPS scanning is enabled. That's because more and
more sites have gone to HTTPS for connecting to them. Even if you
specify HTTP, often a site will redirect to their HTTPS page.
As more site adopt secure connects, and with Avast's HTTPS scanning
enabled, your web experience will slow down. I eventually had to
disable the HTTPS scanning so I did not have to keep waiting for the
pages to load. Avast needs to change how they intercept the traffic.
For one, any off-domain content (ads, scripts, libs) should be checked
in parallel, not when your client decides it has to do those retrieves.
That means inspecting the web page (once decrypted) for off-domain
resources to then go get them. However, that also means parallel
retrieve of ads so the type of content should be configurable. Until
Avast severely speeds up their HTTPS content interrogation process, it
is way too slow. You might start to think your ISP halved your
bandwidth or something you installed or configured screwed up your
network traffic to slow it down. Nope, it's just the HTTPS scanning
"feature" in Avast which is too slow and incurs delays in delivery. The
more resources a page has, the slower Avast will be to deliver the HTTPS
page.
In fact, Avast's HTTP (non-secure) interrogation also slows delivery of
the page but they've had years to improve that inspection. When it
first showed, I had to disable it so page loads were speedy again. It
took over a year before I enabled it, test, and any delay was tolerable
for the added security. Security and speed are the antithesis of each
other: you can't have more security without a penalty in speed. Avast
just needs to work on their MITM method of interrogating HTTPS traffic
to speed it up, and that'll be awhile.
I don't know if it is Avast trying to change the proxy settings in IE or
if some nasty site using Javascript is doing it. I've done some
searching on Javascript to see if it can change the proxy settings in
IE. While Javascript can change to a different proxy for an existing
session with a site, I haven't found information that Javascript can
permanently change the proxy settings in IE. So I suspect it is IE.
The proxy will get changed to 127.0.0.1 (no port assigned). Without the
port, the web browser doesn't know where to connect locally. A process
listens on a port for a connect request. The result is that I get
errors in IE about not being to access a page or find a site. This
happened often enough that I defined a shortcut (put in a toolbar in the
Windows taskbar) that runs:
C:\Windows\regedit.exe /s C:\Batch\InternetSettings\NoProxy.reg
The .reg file has the settings saved for when IE did *not* have a proxy
defined. The IE settings are in the registry. Basically I step atop
whatever settings are in the registry for IE's proxy setting to force
them to define "no proxy" for IE. The .reg file contains:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings]
"ProxyEnable"=dword:00000000
I got into the habit of clicking on my "No Proxy" shortcut after a long
web surfing session, or anytime I got the error in IE about it could not
find the page or site (whereupon IE worked just fine after that).
Interestingly is that after disabling HTTPS scanning in Avast that I
haven't had to click my "No Proxy" shortcut for quite awhile. Could be
coincidence, could be consequential, to the HTTPS scanning option.
By the way, if you get into the local certificate manager (certmgr.msc)
and do not find Avast's root certificate then that is the cause of the
"authenticity" error. For HTTPS scanning to work requires a MITM (Man
In The Middle) attack where your client actually connects to Avast's
local proxy and establishes an SSL/TLS session to that proxy using
Avast's cert. Avast then pretends to be the client to connect to the
server. MITM attacks are always possible when a cert gets saved in your
local cert store. In fact, some companies do the same MITM attack by
setting up their sysprep image for their workstations to have the
company's root cert in the certificate store. They can get tricky by
using login scripts to push their cert into your local cert store. They
want the ability to interrogate all traffic moving across THEIR network
which is, after all, THEIR property and they probably had you sign some
form that granted them the right to monitor all traffic across THEIR
network. Since you're supposed to be working for them when you are at
work and are using their resources, they want to ensure everything you
transmit or receive is related to your job for which they are paying
you. So run certmgr.msc to see if Avast's cert was added.
- Run certmgr.msc.
- Go to the "Certificates - Current User -> Trusted Root Certificates ->
Certificates" tree node in the left pane.
- Look for the cert titled "avast! Web/Mail Shield Root".
The cert gets added when you install Avast, not when you later decide to
use or not use their HTTPS feature. I have seen Avast installs that
were missing the Avast cert. Did not see enough such scenarios to know
if the user had some other security software that blocked adding new
certs unless permitted by the user via prompt or policy. Maybe the user
deleted the cert. I don't remember if there was an easy fix for a
missing Avast cert (if you still want to use HTTPS scanning). Only
remember having to uninstall Avast, probably do some remnant registry
and file/folder cleanup, and reinstall Avast to get it to add its cert
during its installation. Having the cert does not mandate that you must
use Avast's HTTP scanning feature. As I recall, uninstalling Avast will
NOT have it remove its cert, so you have to do the remnant cleanup.
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)
|