I have not used shields up in years but today I did and with adguard active I get following. The ShieldsUP! system incorporates technology designed to circumvent many common web browser proxies so that most of our visitors never encounter this special interception page. This built-in circumvention technology is one of several reasons why ShieldsUP!'s tests are often more accurate than other web-based online security tests. However, in this case, it appears that our automatic proxy circumvention system has failed to determine your machine's true IP address, so the results of further tests would not be trustworthy. The worrisome header contained in your request is: https://www.grc.com/image/transpixel.gif X-Forwarded-For: 166.213.1.155 The presence of this header is indicative of an intermediate proxy, as discussed above. We are unable to bypass this proxy, since even your browser's secure SSL connections are being intercepted. If you are able to disable your browser's use of this proxy we'll be able to check your system, but until then we are unable to proceed.
That IP address associated with AT&T wireless network. Note that if you are using a router, what the GRC test is connecting to and testing is the router.
Tests like this don't really tell you how secure your system is. As long as its properly secured, you should be able to safely surf the Internet.
yes I understand , guess what I am saying is when all web traffic is going through adguards proxy, grc won't work but as soon and you shut adguard grc gets your ip right away and does not give the error.yup I am using a router and have been for years.
UUhm, good to know. One reason not to use adguard that like some AVs mess-up with your SSL connection.
Some AVs like Kaspersky and Avast replace site certificate with their own and then you get access denied websites in FF and Chrome. As I've found out, there is no way to restore the original certificates and your browser gets hosed for good. Use them at your own risk.
Actually, what the AV's and AdGuard do is insert their own self-signed root certificate in the OS's root CA store. They then use this certificate as the root certificate in the SSL certificate pinning validation. The web site certificate is never replaced; it is just "pinned" to the AV vendor's root CA store certificate instead of the normal issuing intermediate root CA certificate which in turn is pinned to the OS stored root CA issuing certificate. There is also no "restoration" required if the vendor's SSL protocol scanning is turned off. Most AV vendors will automatically remove their root certificate from the OS root CA store. If for some reason that is not done, you can manually delete the certificate using certmgr.msc.
