wget hangs in docker on some hosts with debian:buster image

  debian-buster, docker, linux-mint, wireshark

I have the following Dockerfile that hangs on the wget and eventually errors out 300s later.
I have run these steps manually inside just the debian:buster container with the exact same behavior.

from debian:buster
RUN apt update && apt install -y wget
RUN wget https://raw.githubusercontent.com/dwyl/english-words/master/words.txt

Here is the output:

 > [3/3] RUN wget https://raw.githubusercontent.com/dwyl/english-words/master/words.txt:                                                                 
#6 0.296 --2021-02-05 23:38:59--  https://raw.githubusercontent.com/dwyl/english-words/master/words.txt                                                  
#6 0.304 Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.192.133, 151.101.128.133, ...
#6 0.310 Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... connected.
#6 301.7 GnuTLS: Error in the pull function.
#6 301.7 Unable to establish SSL connection.

This successfully builds on other hosts, but myself and another person running on Linux Mint 19.3 on a work network both experience it hanging. Other people on different Ubuntu based OSes do not appear to see this behavior on this same network.

Things that do work:

  1. Using different hosts.
  2. Using debian:stretch or debian:bullseye or ubuntu:bionic
  3. Using Linux Mint 19.3 on VM on my home computer as my host.

Things that don’t work:

  1. Using debian:buster-backports or debian:buster-slim

I double checked that the versions of things that should be the same are exactly the same (i.e. VM is running exact same docker and uses the exact same debian:buster image, etc.).

I ran Wireshark to see what might be different and I noticed that for some reason the "Client Hello" is sent as TLSv1 — whereas on my VM it’s sent as TLSv3 (even though it’s the exact same OS, docker version, image etc):

"No.","Time","Source","Destination","Protocol","Length","Info"
"1","0.000000000","172.17.0.2","10.100.211.10","DNS","85","Standard query 0x8f40 A raw.githubusercontent.com"
"2","0.000028023","172.17.0.2","10.100.211.10","DNS","85","Standard query 0x785c AAAA raw.githubusercontent.com"
"3","0.002271772","10.100.211.10","172.17.0.2","DNS","178","Standard query response 0x785c AAAA raw.githubusercontent.com CNAME github.map.fastly.net SOA ns1.fastly.net"
"4","0.002274784","10.100.211.10","172.17.0.2","DNS","136","Standard query response 0x8f40 A raw.githubusercontent.com CNAME github.map.fastly.net A 151.101.52.133"
"5","0.002386107","172.17.0.2","151.101.52.133","TCP","74","40752  >  443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=82201871 TSecr=0 WS=128"
"6","0.006092750","151.101.52.133","172.17.0.2","TCP","74","443  >  40752 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1380 SACK_PERM=1 TSval=1983610677 TSecr=82201871 WS=512"
"7","0.006104753","172.17.0.2","151.101.52.133","TCP","66","40752  >  443 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=82201875 TSecr=1983610677"
"8","0.006372922","172.17.0.2","151.101.52.133","TLSv1","583","Client Hello"
"9","0.007137626","151.101.52.133","172.17.0.2","TCP","66","443  >  40752 [ACK] Seq=1 Ack=518 Win=65536 Len=0 TSval=1983610677 TSecr=82201875"
"10","0.185610511","151.101.52.133","172.17.0.2","TCP","66","[TCP Dup ACK 9#1] 443  >  40752 [ACK] Seq=1 Ack=518 Win=65536 Len=0 TSval=1983610677 TSecr=82201875"

This is where it hangs. No "Server Hello" is sent back. On the debian:stretch image TLSv2 is used (and works), if I force TLSv2 for wget in the Dockerfile, it still does not work in debian:buster. Also debian:bullseye uses TLSv3.

Could it be something about the work network that would cause this behavior? Some library thing? I’m at my wit’s end.

Source: Docker Questions

LEAVE A COMMENT