ssldump - dump SSL traffic on a network
[ -vTshVq -aAdeHnNqTxXvy
] [ -i
[ -k keyfile
] [ -p password
] [ -r
] ] [
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:
you must have read access to /dev/nit
. 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
You must be root or it must be installed setuid to root. Under
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
You must have read access to /dev/bpf*
- Print bare TCP ACKs (useful for observing Nagle behavior)
- Print all record fields (by default ssldump chooses the most interesting
- 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
can't 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.
- Print absolute timestamps instead of relative timestamps
- Print the full SSL packet header.
- Don't try to resolve host names from IP addresses
- Attempt to parse ASN.1 when it appears, such as in certificates and
- Use password as the SSL keyfile password.
- Don't put the interface into promiscuous mode.
- Don't decode any record fields beyond a single summary line. (quiet
- Print the TCP headers.
- Display version and copyright information.
- Print each record in hex, as well as decoding it.
- 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.
- Decorate the output for processing with nroff/troff. Not very useful for
the average user.
- -i interface
- Use interface as the network interface on which to sniff SSL/TLS
- -k keyfile
- 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.
- -p password
- 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
- -S [ crypto | d | ht |
- Specify SSL flags to ssldump. These flags include:
- Print cryptographic information.
- Print fields as decoded.
- Print the handshake type.
- Print handshake type and highlights.
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 don't result in incomplete TCP streams are listed here.
consists of one or more primitives
usually consist of an id
(name or number) preceded by one or more
qualifiers. There are three different kinds of qualifier:
- qualifiers say what kind of thing the id name or number refers to.
Possible types are host, net and port. E.g., `host
foo', `net 128.3', `port 20'. If there is no type qualifier, host
- qualifiers specify a particular transfer direction to and/or from
id. Possible directions are src, dst, src or
dst and src and dst. E.g., `src foo', `dst net 128.3',
`src or dst port ftp-data'. If there is no dir qualifier, src or
dst is assumed. For `null' link layers (i.e. point to point protocols
such as slip) the inbound and outbound qualifiers can be
used to specify a desired direction.
More complex filter expressions are built up by using the words and
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:
- dst host host
- True if the IPv4/v6 destination field of the packet is host, which
may be either an address or a name.
- src host host
- True if the IPv4/v6 source field of the packet is host.
- host host
- True if either the IPv4/v6 source or destination of the packet is
host. Any of the above host expressions can be prepended with the
keywords, ip, arp, rarp, or ip6 as in:
ip host host
which is equivalent to:
ether proto \ip and host host
If host is a name with multiple IP addresses, each address will be
checked for a match.
- ether dst ehost
- True if the ethernet destination address is ehost. Ehost may
be either a name from /etc/ethers or a number (see ethers(3N) for
- ether src ehost
- True if the ethernet source address is ehost.
- ether host ehost
- True if either the ethernet source or destination address is
- gateway host
- True if the packet used host as a gateway. I.e., the ethernet
source or destination address was host but neither the IP source
nor the IP destination was host. Host must be a name and
must be found in both /etc/hosts and /etc/ethers. (An equivalent
ether host ehost and not host host
which can be used with either names or numbers for host / ehost.)
This syntax does not work in IPv6-enabled configuration at this
- dst net net
- True if the IPv4/v6 destination address of the packet has a network number
of net. Net may be either a name from /etc/networks or a
network number (see networks(4) for details).
- src net net
- True if the IPv4/v6 source address of the packet has a network number of
- net net
- True if either the IPv4/v6 source or destination address of the packet has
a network number of net.
- net net mask mask
- True if the IP address matches net with the specific netmask. May
be qualified with src or dst. Note that this syntax is not
valid for IPv6 net.
- net net/len
- True if the IPv4/v6 address matches net a netmask len bits
wide. May be qualified with src or dst.
- dst port port
- True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
destination port value of port. The port can be a number or
a name used in /etc/services (see tcp(4P) and udp(4P)). If a
name is used, both the port number and protocol are checked. If a number
or ambiguous name is used, only the port number is checked (e.g., dst
port 513 will print both tcp/login traffic and udp/who traffic, and
port domain will print both tcp/domain and udp/domain
- src port port
- True if the packet has a source port value of port.
- port port
- True if either the source or destination port of the packet is
port. Any of the above port expressions can be prepended with the
keywords, tcp or udp, as in:
tcp src port port
which matches only tcp packets whose source port is port.
Primitives may be combined using:
- A parenthesized group of primitives and operators (parentheses are special
to the Shell and must be escaped).
- Negation (`!' or `not').
- Concatenation (`&&' or `and').
- Alternation (`||' or `or').
Negation has highest precedence. Alternation and concatenation have equal
precedence and associate left to right. Note that explicit and
not juxtaposition, are now required for concatenation.
If an identifier is given without a keyword, the most recent keyword is assumed.
not host vs and ace
is short for
not host vs and host ace
which 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
To listen to traffic on interface le0
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
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
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
). To allow the user to disentangle
traffic from different connections, each connection is numbered. This is
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
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.
indicates records transmitted from client to server and
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
, 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
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
ServerHello - version, session_id, chosen cipher suite,
Alert - type and level (if obtainable)
Fuller decoding of the various records can be obtained by using the -A
ssldump can decrypt traffic between two hosts if the following two conditions
1. ssldump has the keys.
2. Static RSA was used.
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 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
messages do not have types. These are the Finished
messages, but because they are encrypted ssldump only knows that they are of
. 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 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 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
ssldump was written by Eric Rescorla <firstname.lastname@example.org>.