Earlier I talked about issuing test requests to a SSL/TLS-enabled web server.
That works well as long as you can recreate the request contents by hand. But sometimes you really need to diagnose a connection which is being issued by some real client (such as a browser or client app). There are a number of ways to observe such request and response data.
One such tool is ssltap, also part of NSS. ssltap takes the proxy approach – it serves as a simple proxy between the client and the real server and displays information about the connections it forwards (note that you can just as well use ssltap for observing plain HTTP requests or even requests based on other protocols).
Let’s look at an example. I have a JES Web Server with an SSL-enabled listener on port 8088 of my machine, so I issue the following (you’ll always want the -l option so ssltap doesn’t exit after a single request):
% ssltap -l -s localhost:8088 Looking up "localhost"... Proxy socket ready and listening
By default ssltap listens on port 1924 (run ssltap without any options to see usage info) which will do fine. I then connect from firefox to ‘https://localhost:1924’ which produces ssltap output such as this:
Connection #1 [Mon Apr 10 15:49:49 2006]
Connected to localhost:8088
--> [
alloclen = 87 bytes
(87 bytes of 87)
[Mon Apr 10 15:49:49 2006] [ssl2] ClientHelloV2 {
version = {0x03, 0x01}
cipher-specs-length = 60 (0x3c)
sid-length = 0 (0x00)
challenge-length = 16 (0x10)
cipher-suites = {
(0x000039) TLS/DHE-RSA/AES256-CBC/SHA
(0x000038) TLS/DHE-DSS/AES256-CBC/SHA
(0x000035) TLS/RSA/AES256-CBC/SHA
(0x000033) TLS/DHE-RSA/AES128-CBC/SHA
(0x000032) TLS/DHE-DSS/AES128-CBC/SHA
(0x000004) SSL3/RSA/RC4-128/MD5
(0x000005) SSL3/RSA/RC4-128/SHA
(0x00002f) TLS/RSA/AES128-CBC/SHA
(0x000016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x000013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0x00feff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x000015) SSL3/DHE-RSA/DES56-CBC/SHA
(0x000012) SSL3/DHE-DSS/DES56-CBC/SHA
(0x00fefe) SSL3/RSA-FIPS/DES-CBC/SHA
(0x000009) SSL3/RSA/DES56-CBC/SHA
(0x000064) TLS/RSA-EXPORT1024/RC4-56/SHA
(0x000062) TLS/RSA-EXPORT1024/DES56-CBC/SHA
(0x000003) SSL3/RSA/RC4-40/MD5
(0x000006) SSL3/RSA/RC2CBC40/MD5
}
session-id = { }
challenge = { 0xdfb5 0x1d22 0x6562 0x34f6 0x95b9 0x668a 0x234e 0x38ea
}
}
]
This is the SSL client hello being sent from the browser to the server. Of interest, note the list of cipher suites the browser sent. This is the set of cipher suites the browser is configured to handle (note also they are sorted in order of preference). The server will pick one of those for the handshake (if the server is not set up to handle any of these, the connection will then immediately fail). Notice also the session-id is empty, which tells us the browser does not have any cached SSL session (not to be confused with HTTP sessions!) with this particular server.
The server responds with:
<-- [
(1015 bytes of 1010)
SSLRecord { [Mon Apr 10 15:49:49 2006]
type = 22 (handshake)
version = { 3,1 }
length = 1010 (0x3f2)
handshake {
type = 2 (server_hello)
length = 70 (0x000046)
ServerHello {
server_version = {3, 1}
random = {...}
session ID = {
length = 32
contents = {..}
}
cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA
}
type = 11 (certificate)
length = 928 (0x0003a0)
CertificateChain {
chainlength = 925 (0x039d)
Certificate {
size = 485 (0x01e5)
data = { saved in file 'cert.001' }
}
Certificate {
size = 434 (0x01b2)
data = { saved in file 'cert.002' }
}
}
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
The server picked TLS/RSA/AES256-CBC/SHA as the cipher suite to use (JES Web Server 7.0 supports AES in addition to ECC).
A ‘session ID’ was sent, which this client will include in subsequent requests. The server also sent its certificate chain for the browser to verify. ssltap saved these certificates in the files noted (‘cert.001’, ‘cert.002’). You can examine these certificates later with any tool which can parse X.509 certificates. For example, using openssl you could do:
% openssl x509 -in cert.001 -text -inform DER
I will skip the rest of the ssltap output as there is a lot of it, but try it and see. You can observe a fair amount of useful information from it such as the number of requests and responses and the size of each.
The major drawback is that the actual session data is of course encrypted between the client and the server so ssltap has no way to decipher it (with the -h flag ssltap will give a hex dump of the raw data). Thus, while this is useful for observing the handshake and request progress, it won’t help if you needed to look at the request or response details.
One option here is to enable a NULL cipher suite on both the client and the server. The NULL suites are SSL/TLS suites which perform all the regular protocol steps with the only difference that the bulk encryption algorithm used to encrypt the request/response data is ‘NULL’ – that is, it goes in plain text.
As noted earlier, the handshake protocol attempts to negotiate the strongest cipher suite that is common to the client and the server, so the NULL suites will never be selected unless it is the only choice. That means that in order to make it work you will have the explicitly disable every cipher suite except a NULL one in either the client or the server.
To show this scenario, I disabled all suites in the JES Web Server 7.0 except SSL_RSA_WITH_NULL_SHA and also enabled the corresponding suite in firefox (unfortunately firefox has no UI to configure these but you can do it by entering ‘about:config’ as the URL; search for the ‘security.ssl3’ options).
With that, the initial client hello containing the list of ciphers shows up through ssltap as:
cipher_suites[22] = {
(0x0039) TLS/DHE-RSA/AES256-CBC/SHA
(0x0038) TLS/DHE-DSS/AES256-CBC/SHA
(0x0035) TLS/RSA/AES256-CBC/SHA
(0x0033) TLS/DHE-RSA/AES128-CBC/SHA
(0x0032) TLS/DHE-DSS/AES128-CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x002f) TLS/RSA/AES128-CBC/SHA
(0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x0015) SSL3/DHE-RSA/DES56-CBC/SHA
(0x0012) SSL3/DHE-DSS/DES56-CBC/SHA
(0xfefe) SSL3/RSA-FIPS/DES-CBC/SHA
(0x0009) SSL3/RSA/DES56-CBC/SHA
(0x0064) TLS/RSA-EXPORT1024/RC4-56/SHA
(0x0062) TLS/RSA-EXPORT1024/DES56-CBC/SHA
(0x0003) SSL3/RSA/RC4-40/MD5
(0x0006) SSL3/RSA/RC2CBC40/MD5
(0x0002) SSL3/RSA/NULL/SHA
(0x0001) SSL3/RSA/NULL/MD5
The NULL ciphers are of course at the very bottom of the list. The server, having nothing else enabled, responds with:
...
cipher_suite = (0x0002) SSL3/RSA/NULL/SHA
...
And so, the application data of this session is now unencrypted. Without the -h option ssltap will still show the data records as ‘< encrypted >’ because it doesn’t know any better (remember that all the regular SSL protocol encapsulation is in place even though the bulk encryption algorithm happens to be a no-op). If you give the -h option you’ll see the hex dump of what is now the readable request/response data. Of course, being plan text, now you can use your favorite network observation tool instead.
If you do this, be absolutely sure to remember restore the original configuration afterwards! Disable all NULL cipher suites and reenable the ones you need. You never want to have the NULL suites enabled outside of special testing circumstances (JES Web Server 7.0 will log warnings if weak suites are enabled, as a reminder).
A final note about ssltap – it is a single threaded proxy so if you issue multiple requests through it they will get serialized. Usually not a problem, but if you need to analyze some problem with your application which only occurs on concurrent requests through SSL, it will not help (try running multiple ssltap instances).