internet google not working/giving "unsecure" error messages

[watercooled]

Firefox uses its own built-in CA database, separate to the Windows one use by IE/Chrome/etc, so if it were client-side certificate problems I'd expect it to affect IE or Firefox, not both.

Edit: What antivirus/security package are you using?

[kalniel]

Change to open DNS/google DNS?

[ik9000]

wikipedia traceroute gives me

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Windows\System32>tracert wikipedia.org

Tracing route to wikipedia.org [208.80.154.224]
over a maximum of 30 hops:

1 8 ms 2 ms 8 ms [192.168.1.1]
2 * * * Request timed out.
3 41 ms 22 ms 29 ms 10.247.226.219
4 31 ms 28 ms 17 ms 172.27.181.222
5 52 ms 33 ms 27 ms 172.27.181.19
6 42 ms 73 ms 36 ms 172.27.181.173
7 41 ms 29 ms 28 ms 109.249.190.3
8 45 ms 17 ms 24 ms 87.237.20.202
9 41 ms 42 ms 22 ms 87.237.20.75
10 32 ms 22 ms 29 ms 87.237.20.32
11 55 ms 19 ms 22 ms 80.150.170.17
12 34 ms 26 ms 29 ms xe-0-1-0-8.r02.londen03.uk.bb.gin.ntt.net [129.250.8.49]
13 33 ms 26 ms 27 ms ae-4.r22.londen03.uk.bb.gin.ntt.net [129.250.5.24]
14 117 ms 108 ms 101 ms ae-4.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.126]
15 * 108 ms 104 ms ae-0.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.73]
16 * 143 ms 107 ms ae-9.r20.asbnva02.us.bb.gin.ntt.net [129.250.2.149]
17 111 ms 102 ms 113 ms ae-1.r04.asbnva02.us.bb.gin.ntt.net [129.250.3.17]
18 104 ms 108 ms 110 ms xe-0-7-0-8.r04.asbnva02.us.ce.gin.ntt.net [129.250.204.190]
19 128 ms 107 ms 107 ms text-lb.eqiad.wikimedia.org [208.80.154.224]

Trace complete.

and google traceroute

C:\Windows\System32>tracert google.com

Tracing route to google.com [173.194.40.104]
over a maximum of 30 hops:

1 3 ms 9 ms 3 ms [192.168.1.1]
2 * * * Request timed out.
3 42 ms 28 ms 30 ms 10.247.226.207
4 44 ms 28 ms 32 ms 172.27.181.218
5 28 ms 20 ms 33 ms 172.27.181.3
6 30 ms 66 ms 33 ms 172.27.181.173
7 31 ms 23 ms 23 ms 109.249.190.3
8 65 ms 17 ms 18 ms 87.237.20.202
9 34 ms 42 ms 44 ms 87.237.20.75
10 38 ms 28 ms 24 ms 72.14.213.58
11 39 ms 24 ms 30 ms 209.85.255.78
12 32 ms 27 ms 20 ms 209.85.253.94
13 44 ms 65 ms 41 ms 72.14.232.210
14 47 ms 33 ms 29 ms 209.85.245.73
15 42 ms 30 ms 35 ms 209.85.243.45
16 59 ms 28 ms 30 ms par10s09-in-f8.1e100.net [173.194.40.104]

Trace complete.

[ik9000]

ok so digging into this in ie:

https://google is accessible in ie now, but google search still screwed up unless from search toolbar.

can't view the certificate kasp AV seems to be doing something in the middle as you suggested....

but for https google.co.uk i get SHA1 thumbprint ‎c5 47 bd 33 d7 2f 35 73 48 a4 9e 92 fc 42 28 f8 00 5b 6f 9a
and for https wikipedia.org i get SHA1 thumbprint‎ f5 8f f4 57 f8 ca 30 7e 90 12 12 17 f9 41 07 fe ac bd e6 8f

interesting, these are different from those we got earlier....

[ik9000]

I've now tried playing around with kasp settings:

disabling Kasp parental control and all becomes well... I get the same SHA1 on firefox as I did at work earlier.

and the same in ie too: ‎da aa a4 9b ad 0c 1f a3 29 71 d8 cc 62 ba 72 d1 a4 db 94 9f

so it is clearly something kasp is doing.

wtf? why on earth would it block https browsing? it's set to block "anonymous proxies" could it be this setting?

[ik9000]

so yup it's the av screwing it up. reactivating it and overriding the permissions in firefox I get the same SHA as i got in IE above - ie the ones that don't match what we've all got earlier in the day. So it will let you do https, just it is doing some scanning in the middle, that means firefox (rightly) spots something is up. And in so doing it is garbling the pages on the way through. but it only garbles them in firefox, not IE. And it only started doing that a few days ago. So if we can sort that out it will be problem solved.

[watercooled]

Yeah some AV packages offer HTTPS scanning, but in order to do so they must effectively be a man-in-the-middle, which of course browsers are designed to spot.

I'm assuming it would try to install its own root certificates to the system to avoid this sort of problem so I'm not sure why that isn't the case.

However it's up to you whether you think it's worth AV intercepting, decrypting, scanning, then re-encrypting traffic. To work around the problem it's just a case of disabling 'scan encrypted connections' under network. Alternatively you could try manually installing the certificates again if you want HTTPS scanning. The certificate fingerprints won't match with it enabled though, just FYI.