[log] dns/ssl misbehaviors to google today

Shawn K. Quinn skquinn at rushpost.com
Fri Mar 4 22:45:50 PST 2022


On 3/4/22 15:39, Undiscussed Horrific Abuse, One Victim of Many wrote:
> Was stuck with this error doing a casual activity:
> 
> Downloading android ndk...                                    curl 
> --fail --retry 3 -o ndk.zip 
> https://dl.google.com/android/repository/android-ndk-r23b-linux.zip 
> <https://dl.google.com/android/repository/android-ndk-r23b-linux.zip>    
>                                            % Total    % Received % 
> Xferd  Average Speed   Time    Time     Time  Current                    
>              Dload  Upload   Total   Spent    Left  Speed
>   88  691M   88  609M    0     0  67.2M      0  0:00:10  0:00:09  
> 0:00:01 63.9M          curl: (56) OpenSSL SSL_read: error:1408F119:SSL 
> routines:ssl3_get_record:decryption fail
> ed or bad record mac, errno 0
> 
> The error means the ssl stream has been mutated, possibly by a third 
> party. Note: it's hard for me to believe that, I kind of just feel it as 
> paranoid fear. I got it every time I tried the download, at about the 
> same amount into the stream.

It could be third party interference. It could also be your network 
interface (wired or wireless) failing by flipping bits at that point 
every time. I have had network interfaces fail this way; this is why I 
am currently using a USB 2.0 Ethernet adapter on my laptop and not using 
the built-in Ethernet.

> I think there are better solutions for routing, like cjdns or something, 
> where connects are solid and prevent such things. Not set up with them.
> 
> $ host dl.google.com <http://dl.google.com>
> dl.google.com <http://dl.google.com> has address 142.250.80.110 
> dl.google.com <http://dl.google.com> has IPv6 address 
> 2607:f8b0:4006:80d::200e
> 
> I went on the web to get other information on the ip address of 
> dl.google.com <http://dl.google.com> and ended up at 
> whatismyipaddress.com <http://whatismyipaddress.com>, which also has 
> host lookup.  It said the ip address was 142.250.72.238 . Since it 
> starts with the same two numbers, I figured it was just some load 
> balancing system.
> 
> $ cat /etc/resolv.conf
> nameserver 8.8.8.8
> nameserver 208.67.222.222
> nameserver 1.1.1.1                                                  
> nameserver 84.200.69.80
> 
> I tried each nameserver in sequence like:
> $ host dl.google.com <http://dl.google.com> 8.8.8.8
> for each one.
> 
> The first three gave the same ip address that fails for me, each 
> request, which seems strange to me for a load balancing system. The 
> fourth gave a different ip address. I have 172.217.19.238 in my 
> scrollback history but presently am getting 142.251.36.14 .
> 
> I moved this nameserver to the top of my list and the download finally 
> completed successfully. This could be a coincidence, but didn't seem one 
> at the time.

As of a few minutes ago this is what I get for reference:

skquinn@********:~$ host dl.google.com 9.9.9.9
Using domain server:
Name: 9.9.9.9
Address: 9.9.9.9#53
Aliases:

dl.google.com has address 172.253.124.91
dl.google.com has address 172.253.124.136
dl.google.com has address 172.253.124.190
dl.google.com has address 172.253.124.93
dl.google.com has IPv6 address 2607:f8b0:4002:c08::5b
dl.google.com has IPv6 address 2607:f8b0:4002:c08::88
dl.google.com has IPv6 address 2607:f8b0:4002:c08::be
dl.google.com has IPv6 address 2607:f8b0:4002:c08::5d
skquinn@********:~$ host dl.google.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

dl.google.com has address 142.251.45.46
dl.google.com has IPv6 address 2607:f8b0:4000:800::200e
skquinn@********:~$ host dl.google.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:

dl.google.com has address 142.251.33.14
dl.google.com has IPv6 address 2607:f8b0:4000:806::200e
skquinn@********:~$ date -u
Sat 05 Mar 2022 06:25:53 AM UTC

As of this writing I prefer to use Quad 9 (9.9.9.9) over the others for 
various reasons.

I would say deliberate third-party interference can't be ruled out 
conclusively yet, but neither can simple hardware glitches triggered by 
certain sequences of bits/bytes, which include the IP address.

-- 
Shawn K. Quinn <skquinn at rushpost.com>
http://www.rantroulette.com
http://www.skqrecordquest.com


More information about the cypherpunks mailing list