TLS failure

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS failure

Colin Law
I have a very strange problem, which may well not actually be a Ubuntu
problem, but I would be grateful for any help in diagnosing it.
When I go to https://vehicletax.service.gov.uk/ in Firefox it shows
'Performing a TLS Handshake to vehicletax.service.gov.uk' for a little
while then fails saying 'Secure Connection Failed, The connection to
the server was reset while the page was loading'.  A similar thing
happens in Google Chrome.  Also it happens on two machines, one
running Ubuntu 18.04 and the other 18.10.

However, if I connect via a VPN that I run (in the UK) then it
connects ok, which suggests it is something to do with the router or
connection to the internet.  This is supported by the fact that if I
connect my phone to the wifi it does the same thing, but if I connect
via mobile data it works ok.

I have not got any problems accessing other websites that I have
noticed.  Nothing has changed with my router (which is running LEDE)
for many months.  I do run pihole adblocker on my system but disabling
that makes no difference.

I am lost as to what to do next and would be very grateful for any suggestions.

Colin

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Phil Dobbin
On 21/10/2018 20:16, Colin Law wrote:

> I have a very strange problem, which may well not actually be a Ubuntu
> problem, but I would be grateful for any help in diagnosing it.
> When I go to https://vehicletax.service.gov.uk/ in Firefox it shows
> 'Performing a TLS Handshake to vehicletax.service.gov.uk' for a little
> while then fails saying 'Secure Connection Failed, The connection to
> the server was reset while the page was loading'.  A similar thing
> happens in Google Chrome.  Also it happens on two machines, one
> running Ubuntu 18.04 and the other 18.10.
>
> However, if I connect via a VPN that I run (in the UK) then it
> connects ok, which suggests it is something to do with the router or
> connection to the internet.  This is supported by the fact that if I
> connect my phone to the wifi it does the same thing, but if I connect
> via mobile data it works ok.
>
> I have not got any problems accessing other websites that I have
> noticed.  Nothing has changed with my router (which is running LEDE)
> for many months.  I do run pihole adblocker on my system but disabling
> that makes no difference.
>
> I am lost as to what to do next and would be very grateful for any suggestions.
FWIW it loads fine in 16.04 & Firefox Developer Edition.

Cheers,

  Phil.

--
Men are much better than their ordinary life allows them to be
     JB Priestley


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Peter Flynn
On 21/10/18 20:49, Phil Dobbin wrote:
> On 21/10/2018 20:16, Colin Law wrote:
[...
>> When I go to https://vehicletax.service.gov.uk/ in Firefox it shows
>> 'Performing a TLS Handshake to vehicletax.service.gov.uk' for a little
>> while then fails saying 'Secure Connection Failed, The connection to
>> the server was reset while the page was loading'.
[...]
>
> FWIW it loads fine in 16.04 & Firefox Developer Edition.

Loads from here (Ireland) using Chromium Version 69.0.3497.81 (Official
Build) Built on Ubuntu, running on LinuxMint 18.3 (64-bit)

P

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Colin Law
On Sun, 21 Oct 2018 at 21:49, Peter Flynn <[hidden email]> wrote:

>
> On 21/10/18 20:49, Phil Dobbin wrote:
> > On 21/10/2018 20:16, Colin Law wrote:
> [...
> >> When I go to https://vehicletax.service.gov.uk/ in Firefox it shows
> >> 'Performing a TLS Handshake to vehicletax.service.gov.uk' for a little
> >> while then fails saying 'Secure Connection Failed, The connection to
> >> the server was reset while the page was loading'.
> [...]
> >
> > FWIW it loads fine in 16.04 & Firefox Developer Edition.
>
> Loads from here (Ireland) using Chromium Version 69.0.3497.81 (Official
> Build) Built on Ubuntu, running on LinuxMint 18.3 (64-bit)

The question is why is it not working for me when I connect through my
router, but is working if I go in via a VPN, or at least how do I
debug it to get some clues?

I have tried disabling IPV6 in the vain hope it might be that, but no joy.

Colin

>
> P
>
> --
> ubuntu-users mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

ubuntu-users mailing list
In reply to this post by Colin Law
Hi,

on Arch Linux there are no issues using Firefox 62.0.3 or Chrome
70.0.3538.67. The router I'm using does use GPL'ed and other FLOSS
software.

"This Product includes MIPS Linux Kernel, ATM on Linux, bridge-utils,
busybox, cms_boardctl, cms_util, cms_msg, dproxy-nexgen, ebtables,
isdn4k-utils, inadyn, iproute2, iptables, ndisc6, ntfs-3g, samba,
sysstat, udhcp, urlfilterd, vsftpd, wput, ppp, zebra, and proftpd
software under GPL 2.0 license."

- End-User License Agreement for O2 HomeBox 6641
  [http://www.zyxel.de/uploads/images/sphairon/1708_EULA_o2HomeBox6641.pdf]

On Sun, 21 Oct 2018 20:16:24 +0100, Colin Law wrote:
>https://vehicletax.service.gov.uk/

Perhaps you should get in contact with

"BETA This is a new service – your feedback
[[hidden email]] will help us to improve it."

and asked at the OpenWrt forum [https://forum.openwrt.org/] ("LEDE Forum
renamed to OpenWrt Forum").

Regards,
Ralf


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Colin Watson
In reply to this post by Colin Law
On Sun, Oct 21, 2018 at 08:16:24PM +0100, Colin Law wrote:
> I have a very strange problem, which may well not actually be a Ubuntu
> problem, but I would be grateful for any help in diagnosing it.
> When I go to https://vehicletax.service.gov.uk/ in Firefox it shows
> 'Performing a TLS Handshake to vehicletax.service.gov.uk' for a little
> while then fails saying 'Secure Connection Failed, The connection to
> the server was reset while the page was loading'.  A similar thing
> happens in Google Chrome.  Also it happens on two machines, one
> running Ubuntu 18.04 and the other 18.10.

Have you checked for MTU problems?  This is the sort of weird problem
that an incorrect MTU can cause.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

ubuntu-users mailing list
In reply to this post by Colin Law
On Sun, 21 Oct 2018 22:18:11 +0100, Colin Law wrote:
>how do I debug it to get some clues?

I don't know, but perhaps

$ traceroute vehicletax.service.gov.uk

and/or

$ tracepath vehicletax.service.gov.uk

show something helpful.


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

ubuntu-users mailing list
In reply to this post by Colin Watson
On Sun, 21 Oct 2018 23:00:16 +0100, Colin Watson wrote:
>Have you checked for MTU problems?  This is the sort of weird problem
>that an incorrect MTU can cause.

It's double Dutch to me, but IIUC traceroute could be used to follow
related issues.

$ traceroute vehicletax.service.gov.uk --mtu


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Colin Watson
On Mon, Oct 22, 2018 at 12:11:48AM +0200, Ralf Mardorf via ubuntu-users wrote:
> On Sun, 21 Oct 2018 23:00:16 +0100, Colin Watson wrote:
> >Have you checked for MTU problems?  This is the sort of weird problem
> >that an incorrect MTU can cause.
>
> It's double Dutch to me, but IIUC traceroute could be used to follow
> related issues.
>
> $ 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.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

ubuntu-users mailing list
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@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@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@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@archlinux ~]$ tracepath vehicletax.service.gov.uk | grep -i mtu
 1?: [LOCALHOST]                      pmtu 1492
^C
[rocketmouse@archlinux ~]$ grep mtu /etc/dhcpcd.conf -B1
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
[rocketmouse@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@archlinux ~]$ cat /sys/class/net/*/mtu
1500
65536


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Colin Watson
On Mon, Oct 22, 2018 at 09:52:01AM +0200, Ralf Mardorf via ubuntu-users wrote:
> IIUC this usually should work automatically.

It's a nice theory.  It doesn't always, in practice.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: TLS failure

Colin Law
In reply to this post by Colin Watson
On Sun, 21 Oct 2018 at 23:01, Colin Watson <[hidden email]> wrote:
> ...
> Have you checked for MTU problems?  This is the sort of weird problem
> that an incorrect MTU can cause.

Thanks to all for the various suggestions.  I don't think it is an MTU
problem.  I have now tried it setting the MTU to 1000 and it makes no
difference.

I have had a go with tcpdump and using sudo tcpdump host
vehicletax.service.gov.uk I see this. (I have inserted line feeds
between each transaction to make it a bit easier to read.
11:44:04.711668 IP tigger.33584 > 107.162.132.57.https: Flags [S], seq
1219288911, win 29200, options [mss 1460,sackOK,TS val 270762524 ecr
0,nop,wscale 7], length 0

11:44:04.725582 IP 107.162.132.57.https > tigger.33584: Flags [S.],
seq 2537281460, ack 1219288912, win 4356, options [mss
1460,sackOK,eol], length 0

11:44:04.725596 IP tigger.33584 > 107.162.132.57.https: Flags [.], ack
1, win 29200, length 0

11:44:04.725764 IP tigger.33584 > 107.162.132.57.https: Flags [P.],
seq 1:235, ack 1, win 29200, length 234

11:44:04.739037 IP 107.162.132.57.https > tigger.33584: Flags [.], ack
235, win 4590, length 0

At this point there is several seconds wait

11:44:08.738918 IP 107.162.132.57.https > tigger.33584: Flags [R.],
seq 1, ack 235, win 4590, length 0

11:44:08.739859 IP tigger.33590 > 107.162.132.57.https: Flags [S], seq
3421144022, win 29200, options [mss 1460,sackOK,TS val 270766552 ecr
0,nop,wscale 7], length 0

11:44:08.751098 IP 107.162.132.57.https > tigger.33590: Flags [S.],
seq 2514563206, ack 3421144023, win 4356, options [mss
1460,sackOK,eol], length 0

11:44:08.751163 IP tigger.33590 > 107.162.132.57.https: Flags [.], ack
1, win 29200, length 0

11:44:08.751774 IP tigger.33590 > 107.162.132.57.https: Flags [P.],
seq 1:235, ack 1, win 29200, length 234

11:44:08.762568 IP 107.162.132.57.https > tigger.33590: Flags [.], ack
235, win 4590, length 0

Then there is another wait and the last five lines are repeated.  It
repeats this a few more times then fails.

When I connect through the VPN and repeat the exercise I see
11:35:24.829072 IP tigger.55710 > 107.162.132.57.https: Flags [S], seq
822655265, win 29200, options [mss 1460,sackOK,TS val 801822720 ecr
0,nop,wscale 7], length 0

11:35:24.862589 IP 107.162.132.57.https > tigger.55710: Flags [S.],
seq 2005228617, ack 822655266, win 4104, options [mss
1368,sackOK,eol], length 0

11:35:24.862608 IP tigger.55710 > 107.162.132.57.https: Flags [.], ack
1, win 29200, length 0

11:35:24.862784 IP tigger.55710 > 107.162.132.57.https: Flags [P.],
seq 1:235, ack 1, win 29200, length 234

11:35:24.888874 IP 107.162.132.57.https > tigger.55710: Flags [.], ack
235, win 4338, length 0
This time there is no delay at this point
11:35:24.890242 IP 107.162.132.57.https > tigger.55710: Flags [P.],
seq 1:103, ack 235, win 4338, length 102

11:35:24.890250 IP tigger.55710 > 107.162.132.57.https: Flags [.], ack
103, win 29200, length 0

and the communication continues.
I have run tcpdump in the router watching the internet port and it
shows the same packets.
With my limited knowledge it looks as if there is a packet missing
from the server back to me, but hopefully someone with more knowledge
will be able to throw some more light on this.

Colin

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users