Last week, I tried to measure the entropy of the session ID of an
SSL/TLS-wrapped web application. I prefer Burp Suite Pro for such tasks,
but in this case, it could only gather 5 to 10 session IDs per second. I fired
up Wireshark and found that it didn't reuse the SSL/TLS context, but opened a
new TCP socket and performed handshake for every new session, even though the
HTTP server set the Connection header to keep-alive.
Since collecting session IDs is not exactly rocket science, I decided that it's
faster to roll my own solution instead of waiting for the dead slow Burp
sequencer. First, I put a simple HTTP request into a text file, carefully
ending the lines Windows-style (\r\n) and putting an empty line at the end.
HEAD / HTTP/1.1
Host: domain.tld
User-Agent: Silent Signal
Connection: keep-alive
I used HEAD so that I could minimize the latency and server load by keeping
the server from sending me the actual contents (the session ID got sent in a
Set-Cookie header anyways). First, I sent as many requests as I could,
completely disregarding the answers.
$ while /bin/true; do cat req.txt; done | \
openssl s_client -connect domain.tld:443 2>&1 | fgrep Set-Cookie
As it turned out, the server stopped responding after around 100 requests, so
I simply reduced the number of requests per connection to 100, and put the
whole thing into a while loop, so that it would keep opening new SSL/TLS
connections after every 100 requests. I also added a simple sed invocation
so that the result can be directly used by Burp for analysis.
$ while /bin/true; do (for i in $(seq 100); do cat req.txt; done | \
openssl s_client -connect domain.tld:443 2>&1 | fgrep Set-Cookie | \
sed 's/^[^=]*=\([A-Z]*\);.*$/\1/' >>cookies.txt); done
In another terminal, I started watch -n1 'wc -l cookies.txt', so I also had
a sense of progress, as the above shell 1-liner produced the 20000 tokens
required by FIPS in a matter of minutes.