Cover V13, i12

Article

dec2004.tar

Debugging SSL

Ryan Matteson

The SSL and TLS protocols have become the standard for securing network communications. These protocols provide confidentiality, authentication, and message integrity, but add additional complexity to client/server communications. This situation is most evident when application maintainers and systems administrators need to debug application-layer protocols protected by SSL. In this article, I will discuss two utilities -- ssldump and openssl -- that can help debug applications utilizing SSL.

How SSL Works

The SSL and TLS protocols define the rules SSL clients and servers use to communicate with each other. These rules define the order in which messages are sent, the format of each message, and the way cryptographic algorithms are applied to network communications. The SSL and TLS protocols use a layered communications stack, and define several message types. The bottom layer of this communication stack is called the SSL record layer. This layer accepts protocol messages and application data from higher-level protocols, adds SSL-specific headers, and hands these messages (often referred to as SSL record layer messages) to TCP to be transmitted.

The SSL and TLS connection setup process consists of four stages. The first stage allows the client and server to negotiate security capabilities, such as the public-key algorithm, the symmetric key algorithm, and compression algorithms. The second stage allows the server to transmit digital certificates and key information to the client, allowing the client to validate the identity of the server. The third stage allows the client to exchange key information with the server, and optionally authenticate itself with a digital certificate. The final stage allows the client and server to use the negotiated parameters.

The openssl utility can be used to connect to an SSL-enabled service, and print each stage described above:

$ openssl s_client -connect mail.daemons.net:443 -state \
  -nbio 2>&1 | grep "^SSL"

SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:SSLv3 read server hello A
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:error in SSLv3 read finished A
SSL_connect:error in SSLv3 read finished A
SSL_connect:SSLv3 read finished A
SSL handshake has read 1584 bytes and written 346 bytes
SSL-Session:
For a detailed analysis of each state, see the references.

Testing SSL Servers

When debugging SSL client server communications, it is often beneficial to watch the SSL connection setup process, and if this completes successfully, pass application data to the server. The openssl utility provides the s_client option, which can be used to set up an SSL connection and pass arbitrary data (e.g., POP3 commands, IMAP commands, HTTP methods) to a server process. The following example lists the available messages on a POP3 server utilizing SSL:

$ openssl s_client -connect mail.daemons.net:995
CONNECTED(00000003)

[ ..... ]

user ME
+OK Name is a valid mailbox

pass SOMETHING_OR_ANOTHER
+OK Mailbox locked and ready

list
+OK scan listing follows
1 1225
2 1863
3 1668
4 963
5 1969
6 1437
7 2357
8 3316
9 3517
10 8952
11 9616

quit
+OK
The following example issues an HTTP GET request to a Webserver utilizing SSL:

$ openssl s_client -connect mail.daemons.net:443
CONNECTED(00000003)

[ .... ]

GET / HTTP/1.0

HTTP/1.1 403 Forbidden
Date: Sat, 04 Sep 2004 16:54:01 GMT
Server: Apache/2.0.50
Content-Length: 202
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /
on this server.</p>
</body></html>
closed
Printing Encrypted Application-Layer Data

When the SSL and TLS protocols are used to protect network communications, the application-layer data is obfuscated, and unavailable to network analysis tools (e.g., snoop, tcpdump). This limits an administrator's ability to debug application problems, and view application-layer headers and data. The ssldump utility can be used in these situations and allows SSL messages and application data to be displayed in real time. The following example shows how ssldump can be used to print the SSL handshake messages:

$ ssldump -a -A -H -i en0

New TCP connection #1: winnie(32866) <-> 192.168.1.8(8389)
1 1  0.0043 (0.0043)  C>S SSLv2 compatible client hello
1 2  0.0057 (0.0014)  S>C  Handshake  
      ServerHello
1 3  0.0057 (0.0000)  S>C  Handshake
      Certificate
1 4  0.0057 (0.0000)  S>C  Handshake
      ServerHelloDone
1 5  0.0182 (0.0125)  C>S  Handshake
      ClientKeyExchange
1 6  0.0182 (0.0000)  C>S  ChangeCipherSpec
1 7  0.0182 (0.0000)  C>S  Handshake
1 8  0.0367 (0.0184)  S>C  ChangeCipherSpec
1 9  0.0367 (0.0000)  S>C  Handshake
1 10 3.2154 (3.1786)  C>S  application_data
1 11 3.2154 (0.0000)  C>S  application_data
1 12 3.4370 (0.2216)  C>S  application_data
1 13 3.4370 (0.0000)  C>S  application_data
1 14 3.4681 (0.0311)  S>C  application_data
1 15 3.4681 (0.0000)  S>C  application_data
2    3.4307 (3.4307)  S>C  TCP FIN
1 16 3.5172 (0.0491)  S>C  Alert
1 17 3.5178 (0.0006)  C>S  Alert
1    3.5180 (0.0001)  C>S  TCP FIN
2    3.4815 (0.0508)  C>S  TCP FIN
1    3.5194 (0.0013)  S>C  TCP FIN
The "-A" and "-H" options tell ssldump to print all of the SSL record-layer headers. The "-a" option will provide TCP connection state (e.g., SYN, SYN/ACK, ACK, FIN, etc.) information. Communications originating from the client are marked with "C>S," and messages originating from the server are marked with "S>C." In the previous example, ssldump was not configured to decrypt communications, so the words "application_data" were printed instead of the actual application data.

To decrypt communications and dump application data, ssldump will need a copy of the private key associated with the server you want to debug. ssldump will use this key to derive the session key that is negotiated between the client and the server, and used to encrypt all network communications. The following example uses the private key stored in the file rsa.key to decrypt communications, and display the application-layer data:

$ ssldump -a -A -H -k rsa.key -i en0

< connection setup removed >

3.6155 (3.6155)  C>S
---------------------------------------------------------------
GET / HTTP/1.0
---------------------------------------------------------------

2 12 3.8862 (0.2310)  C>SV3.1(32)  application_data
2 13 3.8862 (0.0000)  C>SV3.1(32)  application_data
3.8466 (0.2311)  C>S
---------------------------------------------------------------

---------------------------------------------------------------

3.8777 (0.0310)  S>C
---------------------------------------------------------------
HTTP/1.1 403 Forbidden
Date: Sun, 25 Jul 2004 04:27:16 GMT
Server: Apache/2.0.50
Content-Length: 1
Connection: close
Content-Type: text/html; charset=iso-8859-1
As you can see from this example, ssldump displays the HTTP requests sent to the daemons.net Web server. ssldump supports Berkeley Packet Filter style filters, allowing you to grab and decode specific communications. The following example shows how to capture SSL communications destined for host fred on TCP port 443:

$ ssldump -a -A -H -k rsa.key -i en0 host fred and port 443
Conclusion

This article provided a brief introduction to the SSL and TLS protocols, and showed how ssldump and openssl can be used to debug network communications. Both commands provide several facilities to help troubleshoot SSL and TLS communication problems. For additional information on the internal workings of the SSL state engine and handshake process, see the references.

References

TLS 1.0 RFC -- http://www.ietf.org/html.charters/tls-charter.html

SSL Reference -- SSL & TLS Essentials by Stephen Thomas

OpenSSL Web site -- http://www.openssl.org

OpenSSL References -- Network Security with OpenSSL, by John Viega, Matt Messier, and Pravir Chandra

SSL Dump Web site -- http://www.rtfm.com/ssldump/

Acknowledgements

Ryan thanks the ssldump and openssl developers, and all the folks who have put time and energy into the design and implementation of the TLS and SSL protocols.

Ryan Matteson works as a systems engineer for Earthlink and speciailizes in Web technologies, Storage Area Networks, high-availability systems, and the Linux and Solaris operating systems. Questions and comments about this article can be addressed to: matty@daemons.net.