Dealing with a hostile network

Last summer I was working at an event with some internet provided by a UK educational establishment, hanging off JANET. It’s great, getting about a gigabit of connectivity with the usual test.

Basic web browsing was working, and I went to set up a nodejs application which talks to a server in AWS.

connect error....reason":"Error: websocket error"

Sigh. So I ran curl from the box

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 3.x.x.x:443

OK, that’s an unusual error. I could however ssh into the AWS machine on port 22. tcpdump on both ends and compare in wireshark (which is not the nicest thing to do on a 13″ laptop)

The client is saying that the AWS server is sending RSTs after the Client Hello

The RST from 3.11.2xxxx to the client’s private 172.24xxx address

But the server is saying it’s the client sending the RST!

Not only that, the actual SSL traffic seems to be being changed too.

It’s extremely frustrating when you get this type of middlebox. You shouldn’t be breaking communications, and it’s unlikely a user’s setup would be broken enough to allow it to happen with TLS. Middleboxs cause real problems for default traffic, but are generally easy enough to work around if you want to do something nefarious (tunnel traffic via ssh, or wireguard, or DNS)

Of course this same middlebox was breaking out SSTP vpn, so that was something else to fix. Adding a second SSTP port on a high number was enough to get the vpn up, then routing the 3.11.x.x target down that vpn and natting at the far end bypassed the middlebox completely.

Once you realise the problem these can be worked around, but these application level firewalls just mean more time and more workarounds. If you don’t want traffic flowing on a network, send an ICMP reject, don’t spoof traffic.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.