ssldump is an SSL/TLS network protocol analyzer. It identifies TCP connections on the chosen network interface and attempts to interpret them as SSL/TLS traffic. When it identifies SSL/TLS traffic, it decodes the records and displays them in a textual form to stdout. If provided with the appropriate keying material, it will also decrypt the connections and display the application data traffic.
ssldump has been tested on FreeBSD, Linux, Solaris, and HP/UX. Since it's based on PCAP, it should work on most platforms. However, unlike tcpdump, ssldump needs to be able to see both sides of the data transmission so you may have trouble using it with network taps such as SunOS nit that don't permit you to see transmitted data. Under SunOS with nit or bpf: To run tcpdump you must have read access to /dev/nit or /dev/bpf*. Under Solaris with dlpi: You must have read access to the network pseudo device, e.g. /dev/le. Under HP-UX with dlpi: You must be root or it must be installed setuid to root. Under IRIX with snoop: You must be root or it must be installed setuid to root. Under Linux: You must be root or it must be installed setuid to root. Under Ultrix and Digital UNIX: Once the super-user has enabled promiscuous-mode operation using pfconfig(8), any user may run ssldump Under BSD: You must have read access to /dev/bpf*.
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:
More complex filter expressions are built up by using the words and, or and not to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'. To save typing, identical qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-data or domain' is exactly the same as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
Allowable primitives are:
ip host hostwhich is equivalent to:
ether proto \ip and host hostIf host is a name with multiple IP addresses, each address will be checked for a match.
ether host ehost and not host hostwhich can be used with either names or numbers for host / ehost.) This syntax does not work in IPv6-enabled configuration at this moment.
tcp src port portwhich matches only tcp packets whose source port is port.
Primitives may be combined using:
Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation.
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 443
ssldump -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 foobar
ssldump -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 following
New TCP connection #2: iromeo.rtfm.com(2302) <-> sr1.rtfm.com(4433)The 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.
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:
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, it's 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 ssldump@rtfm.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 that's 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 doesn't implement session caching and therefore can't decrypt resumed sessions.
tcpdump(1)
ssldump was written by Eric Rescorla <ekr@rtfm.com>.