On Sat, Jul 14, 2018 at 6:49 PM, Gareth Williams <gareth at garethwilliams.me.uk> wrote: > Hi Dan, > > On 13/07/2018 22:12, Daniel Lenski wrote: >> >> On Fri, Jul 13, 2018 at 2:03 PM, Daniel Lenski <dlenski at gmail.com> wrote: >>> >>> Something in between the client and server is injecting an RST,ACK in >>> both directions. >> >> If you tweak the signature of the ClientHello, for example by changing >> the cipher list with `gnutls-cli --priority=SECURE128` (default is >> `--priority=NORMAL`). Does it still get intercepted and reset? > > > I've made some progress. > > I captured the client side with Wireshark while connecting first with > openssl, then with gnutls-cli. I then compare the two. > > My initial observation was that openssl sends a much smaller cipher list to > the server. I therefore played around with the priority strings on > gnutls-cli to decrease the cipher list until a) it worked over xDSL and b) > it was smaller than openssl's, before testing it on the mobile network. I > ended up with a list of one; but while it worked over xDSL, it still failed > over the mobile network. Obviously, this issue isn't down to cipher list > size. > > I then noticed that the TLS extensions are different. In a desparate > attempt, I added the --disable-extensions option to gnutls-cli and found it > worked over the mobile network. What was the total size of the client hello? There was a particular firewall which would terminate the TLS connection if the client hello was between 256 and 512 bytes, and it was the reason of rfc7685 extension. You can append %DUMBFW to see if that's the case, and it will ensure that gnutls' hello is outside that range. > Oddly enough, gnutls-cli still sends the following extensions when > --disable-extensions is set: I think it is time to deprecate that option. It is not possible to negotiate TLS1.2 or TLS1.3 without extensions. > So while I may have narrowed down the cause of this issue, I'm still no > closer to a resolution. It really depends on the firewall in between and how it was configured. Let's hope it is the one rfc7685 was written for. regards, Nikos
