3

Following my troubleshooting of making a TLS connection (See: Testing TLS with openssl), it looks like there might be an active firewall in place.

  1. The connection on that port works with nc on both sides (nc -l -p 8883 on the server, nc server.com 8883 on the client)

  2. It even works if I manually send the binary preamble for making a TLS connection, but leave off the last byte (again, captured with nc -l -p 8883 | xxd). I think I see a delay...

  3. Just incase I also checked if the connection is just being forced closed at 289 bytes, so I sent a lot of random text and it went through fine.

  4. Sending the full TLS preamble results in nothing received at the server, and the connection closed. I tried adding some delay before the last byte, it goes through and the connection stays open!

What the heck is this and how do I phrase my request to the company IT to allow it? (we have a special APN set up with AT&T and I think that's where it is)

Trouble shooting details:

I used nc -l -p 8883 to capture the TLS preamble from a successful connection attempt to the server from elsewhere (289 bytes)

0000000: 1603 0101 1c01 0001 1803 03f4 f363 0180  
0000010: 3ce4 957f ee17 8b7f d8ef 9ce0 e608 1cac  
0000020: d328 798d 8b10 cc7b b521 0....
...
0000120: 01

Then here's the client command to reproduce it:

(head TLS1.hex -n18 | xxd -r; sleep 0.3; echo 0: 01 | xxd -r ) 
                                  | nc server.com 8883 -q 1
  • < 0.3s, fails
  • = 0.3s fails intermittently
  • > 0.3s, succeeds
Michael
  • 331
  • 1
  • 4
  • 11
  • 1
    Looks like a DPI (deep packet inspection) technology, commonly used in some enterprise firewalls to detect what's going on in the network and to apply policies (i.e. block or pass) based on the detected application. But DPI is also used with some network providers especially in mobile networks for "bandwidth management" which might include throttling or blocking VPN or VoIP traffic if these are excluded by the contract. – Steffen Ullrich Apr 26 '17 at 04:54
  • Yup, that's it. We told IT the wrong protocol and DPI was catching it. – Michael Apr 26 '17 at 23:35

1 Answers1

2

Shot in the dark, but maybe this is a firewall or other middlebox that can't handle ClientHello with length field >= 256 (and thus using both bytes of the encoding).

When OpenSSL 1.0.1 first implemented TLS1.2 (and 1.1) in 2012, resulting in ClientHello containing more ciphersuites and additional extensions and thus by default exceeding 256 for the first time, there was a slew of reports of breakage on servers that had not been coded correctly to handle this; I don't recall any similar problems with firewalls but it isn't impossible.

To test, try s_client with -no_tls1_2 (or more simply with -tls1 or -tls1_1 as you choose) to see what happens. You can add -debug to s_client to see exactly what is sent and received, and in particular the two bytes starting at offset 3 in each record are the (big-endian) length of the content of that record: in your example this is 011c and the 5 bytes record header plus 0x011c bytes of content matches your total 0x0121 bytes.

dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28