Fails SSL/TLS connection against load balancer requiring SNI

[rbeede]

If the remote target is a load balancer that is requiring TLSv1.2 and SNI with hostname identification then slowhttptest fails to successfully connect. An option to set the SNI hostname would appears to be needed.

slowhttptest -H -u https://loadbal.sni.example.com

slow HTTP test status on 0th second: initializing: 0 pending: 1 connected: 0 error: 0 closed: 0 service available: YES Wed Dec 2 20:54:55 2020: Test ended on 1th second Exit status: Connection refused

[shekyan]

Hi. Able to connect to a server supporting SNI. Can you give an example that doesn't work?

[shevkoplyas]

Hi Sergey,

Thank you for the great tool! I can confirm - your latest commit to master "ac19b0f" (10 months ago) does not support SNI, which is getting into "must have" these days when everything is moving into the cloud and simple standalone web server dedicated to serve just 1 website on 1 IP is no longer the case.

See this short article "What is SNI". Also note: the SNI support works with TLS 1.2 and "is a must" for TLS 1.3, so the whole world is moving into this direction.

As the linked above article suggests: SNI adds the domain name to the TLS handshake process, specifically, SNI includes the hostname in the Client Hello message, or the very first step of a TLS handshake.

So basically it is up to the connecting client to say whether it wants to use SNI or not. Thus in order to check slowhttptest we don't even need to have any "specially configured" web-servers. Any https target will do or even better - you can listen on localhost :443 by say "netcat" and it will work good enough for our need to fake out "web server presence". All we need to check if SNI is in play or not - to collect few initial packets and analyze them in the wireshark.

Let's run simple curl query and then slowhttptest and compare collected pcap files. Btw, not all curls are created (compiled) equal. There are some requirements on the curl versions and dependency libraries well described in this StackOverflow: Use cURL with SNI (Server Name Indication)

Running netcat to listen locally on port 443, let's wrap it into while/true loop so it continue "serving" more than one connections attempts (use Ctrl-c few times to interrupt):

while true; do sudo nc -l 443; sleep 1; done

Start collecting packets:

sudo tcpdump -ni lo port 443 -s0 -w /tmp/curl_reqeust_sni_check.pcap

Run simple curl command.

curl -v https://localhost/

Interrupt packet capture by Ctrl-c, it collected 10 packets, run wireshark:

wireshark /tmp/curl_reqeust_sni_check.pcap

In the collected pcap capture we see: right after TCP 3-way handshake (syn - synack - ack) complete client sends "Client Hello" and we see extension "server_name" is used in the client's TLS handshake request:

This indicates that curl https request does support SNI.

Now let's take a look at the latest master branch slowhttptest.

Collecting the traffic (netcat is still listening port 443): sudo tcpdump -ni lo port 443 -s0 -w /tmp/slowhttptest_sni_check.pcap

git clone git@github.com:shekyan/slowhttptest.git
cd slowhttptest/
./configure 
make
src/slowhttptest  \
  -l 65539 \
  -v 4 \
  -c 65539 \
  -X \
  -t GET \
  -r 3 \
  -u 'https://localhost/'

This time we see that the "server_name" extension was not listed in the client's handshake request:

Thus SNI is not supported by slowhttptest.

May be few somewhat relevant links on a side note: StackOverflow: Setting up TLS1.2 connection which supports SNI

Apache project has tiny "apache bench" (ab) testing utility (basically a client for stess-test wev-servers), and they added support for SNI:

search for "sni" in "ab.c" file.

I think they added SNI support into ab somwehre here:

7b62ffbe80 - (5 years ago) ab: add SNI support when available. - Yann Ylavic

To see the delta use:

git diff 7b62ffbe80~ 7b62ffbe80

Cheers, Dmitry Shevkoplyas