|-a||Print bare TCP ACKs (useful for observing Nagle behavior)|
|-A||Print all record fields (by default ssldump chooses the most interesting fields)|
|-d||Display the application data traffic. This usually means decrypting it, but when -d is used ssldump will also decode application data traffic before the SSL session initiates. This allows you to see HTTPS CONNECT behavior as well as SMTP STARTTLS. As a side effect, since ssldump cant tell whether plaintext is traffic before the initiation of an SSL connection or just a regular TCP connection, this allows you to use ssldump to sniff any TCP connection. ssldump will automatically detect ASCII data and display it directly to the screen. non-ASCII data is displayed as hex dumps. See also -X.|
|-e||Print absolute timestamps instead of relative timestamps|
|-H||Print the full SSL packet header.|
|-n||Dont try to resolve host names from IP addresses|
|-N||Attempt to parse ASN.1 when it appears, such as in certificates and DNs.|
|-p||Use password as the SSL keyfile password.|
|-P||Dont put the interface into promiscuous mode.|
|-q||Dont decode any record fields beyond a single summary line. (quiet mode).|
|-T||Print the TCP headers.|
|-v||Display version and copyright information.|
|-x||Print each record in hex, as well as decoding it.|
|-X||When the -d option is used, binary data is automatically printed in two columns with a hex dump on the left and the printable characters on the right. -X suppresses the display of the printable characters, thus making it easier to cut and paste the hex data into some other program.|
|-y||Decorate the output for processing with nroff/troff. Not very useful for the average user.|
|Use interface as the network interface on which to sniff SSL/TLS traffic.|
|Use keyfile as the location of the SSL keyfile (OpenSSL format) Previous versions of ssldump automatically looked in ./server.pem. Now you must specify your keyfile every time.|
|Use password as the SSL keyfile password.|
|-r file||Read data from file instead of from the network. The old -f option still works but is deprecated and will probably be removed with the next version.|
|-S [ crypto | d | ht | H ]|
Specify SSL flags to ssldump. These flags include:
Selects what packets ssldump will examine. Technically speaking,
ssldump supports the full expression syntax from PCAP and tcpdump.
In fact, the description here is cribbed from the tcpdump man
page. However, since ssldump needs to examine full TCP streams,
most of the tcpdump expressions will select traffic mixes
that ssldump will simply ignore. Only the expressions which
dont result in incomplete TCP streams are listed here.
The expression consists of one or more primitives. Primitives usually consist of an id (name or number) preceded by one or more qualifiers. There are three different kinds of qualifier:
If an identifier is given without a keyword, the most recent keyword is assumed. For example,
not host vs and aceis short for
not host vs and host acewhich should not be confused with
not ( host vs or ace )
Expression arguments can be passed to ssldump as either a single argument or as multiple arguments, whichever is more convenient. Generally, if the expression contains Shell metacharacters, it is easier to pass it as a single, quoted argument. Multiple arguments are concatenated with spaces before being parsed.
To listen to traffic on interface le0 port 443ssldump -i le0 port 443
To listen to traffic to the server romeo on port 443.ssldump -i le0 port 443 and host romeo
To decrypt traffic to to host romeo server.pem and the password foobarssldump -Ad -k ~/server.pem -p foobar -i le0 host romeo
All output is printed to standard out.
ssldump prints an indication of every new TCP connection using a line like the followingThe host which send the first SYN is printed on the left and the host which responded is printed on the right. Ordinarily, this means that the SSL client will be printed on the left with the SSL server on the right. In this case we have a connection from iromeo.rtfm.com (port 2303) to sr1.rtfm.com (port 4433). To allow the user to disentangle traffic from different connections, each connection is numbered. This is connection 2.
New TCP connection #2: iromeo.rtfm.com(2302) <-> sr1.rtfm.com(4433)
The printout of each SSL record begins with a record line. This line contains the connection and record number, a timestamp, and the record type, as in the following:
2 3 0.2001 (0.0749) S>C Handshake Certificate
This is record 3 on connection 2. The first timestamp is the time since the beginning of the connection. The second is the time since the previous record. Both are in seconds.
The next field in the record line is the direction that the record was going. C>S indicates records transmitted from client to server and S>C indicates records transmitted from server to client. ssldump assumes that the host to transmit the first SYN is the SSL client (this is nearly always correct).
The next field is the record type, one of Handshake, IAlert, ChangeCipherSpec, or application_data. Finally, ssldump may print record-specific data on the rest of the line. For Handshake records, it prints the handshake message. Thus, this record is a Certificate message.
ssldump chooses certain record types for further decoding. These are the ones that have proven to be most useful for debugging:
ClientHello - version, offered cipher suites, session id if provided) ServerHello - version, session_id, chosen cipher suite, compression method Alert - type and level (if obtainable)
Fuller decoding of the various records can be obtained by using the -A , -d , -k and -p flags.
ssldump can decrypt traffic between two hosts if the following two conditions are met:In any other case, once encryption starts, ssldump will only be able to determine the record type. Consider the following section of a trace.1. ssldump has the keys. 2. Static RSA was used.
1 5 0.4129 (0.1983) C>S Handshake ClientKeyExchange 1 6 0.4129 (0.0000) C>S ChangeCipherSpec 1 7 0.4129 (0.0000) C>S Handshake 1 8 0.5585 (0.1456) S>C ChangeCipherSpec 1 9 0.6135 (0.0550) S>C Handshake 1 10 2.3121 (1.6986) C>S application_data 1 11 2.5336 (0.2214) C>S application_data 1 12 2.5545 (0.0209) S>C application_data 1 13 2.5592 (0.0046) S>C application_data 1 14 2.5592 (0.0000) S>C Alert
Note that the ClientKeyExchange message type is printed but the rest of the Handshake messages do not have types. These are the Finished messages, but because they are encrypted ssldump only knows that they are of type Handshake. Similarly, had the Alert in record 14 happened during the handshake, its type and level would have been printed. However, since it is encrypted we can only tell that it is an alert.
Please send bug reports to email@example.com.
The TCP reassembler is not perfect. No attempt is made to reassemble IP fragments and the 3-way handshake and close handshake are imperfectly implemented. In practice, this turns out not to be much of a problem.
Support is provided for only for Ethernet and loopback interfaces because thats all that I have. If you have another kind of network you will need to modify pcap_cb in base/pcap-snoop.c. If you have direct experience with ssldump on other networks, please send me patches.
ssldump doesnt implement session caching and therefore cant decrypt resumed sessions.
ssldump was written by Eric Rescorla <firstname.lastname@example.org>.
|-->||SSLDUMP (1)||28 September 2001|