TLS failure

[Ralf Mardorf]

On Sun, 21 Oct 2018 23:20:51 +0100, Colin Watson wrote:
>On Mon, Oct 22, 2018 at 12:11:48AM +0200, Ralf Mardorf wrote:
>> $ traceroute vehicletax.service.gov.uk --mtu  
>
>That's probably a reasonable thing to try, yes.  The other cruder thing
>I sometimes do when I've forgotten about that sort of tool is to just
>try decreasing a particular system's MTU temporarily and see if it
>helps; if it does, you can then bisect to find the maximum value that
>works.

IIUC this usually should work automatically.
--------------------------------------------

"Path MTU Discovery

The Internet Protocol defines the "Path MTU" of an Internet
transmission path as the smallest MTU of any of the IP hops of the
"path" between a source and destination. Put another way, the path MTU
is the largest packet size that can traverse this path without
suffering fragmentation.

RFC 1191 (IPv4) and RFC 1981 (IPv6) describe "Path MTU Discovery", a
technique for determining the path MTU between two IP hosts. It works
by setting the DF (Don't Fragment) option in the IP headers of outgoing
packets. Any device along the path whose MTU is smaller than the packet
will drop such packets and send back an ICMP "Destination Unreachable
(Datagram Too Big)" message containing its MTU. This information allows
the source host to reduce its assumed path MTU appropriately. The
process repeats until the MTU becomes small enough to traverse the
entire path without fragmentation.

Unfortunately, increasing numbers of networks drop ICMP traffic (for
example, to prevent denial-of-service attacks), which prevents path MTU
discovery from working. One often detects such blocking in the cases
where a connection works for low-volume data but hangs as soon as a
host sends a large block of data. For example, with IRC a connecting
client might see the initial messages up to and including the initial
ping (sent by the server as an anti-spoofing measure), but get no
response after that. This is because the large set of welcome messages
are sent out in packets bigger than the real MTU. Also, in an IP
network, the path from the source address to the destination address
often gets modified dynamically, in response to various events
(load-balancing, congestion, outages, etc.) - this could result in the
path MTU changing (sometimes repeatedly) during a transmission, which
may introduce further packet drops before the host finds a new reliable
MTU. " -
https://en.wikipedia.org/wiki/Maximum_transmission_unit#Path_MTU_Discovery





Trial and error with 'ping' results in <= 1464.
-----------------------------------------------

[rocketmouse at archlinux ~]$ ping -M dont -s 1464 vehicletax.service.gov.uk
PING vehicletax.service.gov.uk (107.162.132.57) 1464(1492) bytes of data.
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=1 ttl=242 time=15.1 ms
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=2 ttl=242 time=14.3 ms
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=3 ttl=242 time=14.7 ms
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=4 ttl=242 time=14.3 ms
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=5 ttl=242 time=14.4 ms
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=6 ttl=242 time=14.4 ms
1472 bytes from vehicletax.service.gov.uk (107.162.132.57): icmp_seq=7 ttl=242 time=14.4 ms
^C
--- vehicletax.service.gov.uk ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 15ms
rtt min/avg/max/mdev = 14.325/14.506/15.075/0.270 ms
[rocketmouse at archlinux ~]$ ping -M dont -s 1465 vehicletax.service.gov.uk
PING vehicletax.service.gov.uk (107.162.132.57) 1465(1493) bytes of data.
^C
--- vehicletax.service.gov.uk ping statistics ---
182 packets transmitted, 0 received, 100% packet loss, time 594ms





On my machine there's no issue with this webpage when using Firefox or
----------------------------------------------------------------------
Chrome. What exactly went wrong if Colin does use his router?
-------------------------------------------------------------

[rocketmouse at archlinux ~]$ traceroute vehicletax.service.gov.uk --mtu | grep F=
 1  _gateway (192.168.1.1)  0.645 ms F=1500  0.692 ms  0.640 ms
 2  loopback1.0002.acln.02.dus.de.net.telefonica.de (62.52.200.185)  10.322 ms F=1492  10.199 ms  10.213 ms
[rocketmouse at archlinux ~]$ tracepath vehicletax.service.gov.uk | grep -i mtu
 1?: [LOCALHOST]                      pmtu 1492
^C
[rocketmouse at archlinux ~]$ grep mtu /etc/dhcpcd.conf -B1
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
[rocketmouse at archlinux ~]$ ip ad | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
[rocketmouse at archlinux ~]$ cat /sys/class/net/*/mtu 
1500
65536