1) What
is the SSL Sniffer?
2) Does
the Sniffer have any software or hardware requirements?
3) Do I have
to reconfigure the MakeFile?
4) Who wrote
the SSL Sniffer?
5) Is there documentation?
6) What should I do if I find a bug?
7) How do I use the sniffer?
8) What do I do if I like the sniffer?
9) What do I do if I don't like the
sniffer?
10) What is SSLv3 or TLS?
11) Where do I get it?
12) Is there sample output?
13) Why is all the code in the sniffer
contained in just one file?
A SSLV3/TLS proxy server that sniffs SSL/TLS packets and prints out the contents of packets in stdout. It can also serve as a proxy server.
2) Does the Sniffer have any software or hardware requirements?
The sniffer was developed in C on a pentium I 166 MHz running RedHat Linux 6.1. It works only on little endian machines that run variants of unix. I used glibc 2.1.3-8 and openSSL 9.4 but older versions of glibc and openSSL should be able to work. It has also been tested on a i386 machine running Solaris.
If you don't care about certificate information, then it's possible to run the proxy without having the openSSL libraries. Just go to the source and comment out the #include openssl/ files and also comment out the declarations and definitions of the functions processCertificateChain, processCertificate and printCertificateInfo. Next, remove the lines in the code where these functions are being used. You also need to comment out the UTL_CERT_INFO struct. Once that is done, the sniffer will work as usual, but it will not display any information about the certificate handshake messages.
It does not work on big endian machines because there are some length conversion fields that I converted directly from network byte order to little endian. The main problem is the 3-byte length field in the handshake message header which I could not use the ntohl function to convert. Furthermore, the printouts of the data are a little odd on big endian machines because of the endian-ness as well. I have a working version for big endian machines but the printouts are a little odd because of some trailing 0's. I intend to fix this and post the Solaris version soon.
3) Do I have to reconfigure the MakeFile?
You might have to change the CCFLAGS field from '-I/usr/local/ssl/include/openssl' to point to wherever your openssl .h's are. Also, you might need to add to LIBS the location of your openSSL libraries if they are not in the default location.
The SSL Sniffer was written by Eu-Jin Goh, under the supervision of Professor Dan Boneh in Stanford University Applied Crypto Group. The Sniffer was written from scratch, referring to the specs in the RFC 2246. The certificate chain parsing functions in the sniffer were taken partly from the OpenSSL libraries 0.94 written by Eric Young and partly from Professor Boneh's code which also used the OpenSSL libraries.
Certainly. Documentation is found here.
6) What should I do if I find a bug?
I would be grateful if you save a copy of the output and email it to me (eujin at cs.stanford.edu). Note that if the server that you're trying to connect to uses SSLV2, there will be numerous unrecognised packet errors after the intial clientHello and subsequent packets will typically have a first byte that has value either -128 or some other -12x value. This is NOT a BUG. The sniffer does not support SSLv2 servers but still can read SSLv2 client Hello packets. This is to provide support for browsers that support SSLv3/TLS but have to remain backward compatible with SSLv2 servers because they initiate the SSL connection by sending a SSLv2 client Hello.
Just set your client so that it sends SSL packets to the sniffer instead of directly to the server. The default port of the sniffer is 8888. The sniffer will parse the packets to obtain the interesting bits of information and then forward the packets to the destination server. Even if it is unable to parse the packets, it will still forward the packets to the destination server.
I think that the easiest way to get started viewing SSL packets would be to configure your browser so that it is using a secure proxy. In Netscape 4.x, go to preferences under the edit menu and open up the advanced settings. There will be a option called proxy and you can manually set it there. In IE, the proxy settings are under the internet options menu.
The sniffer outputs a lot of information very quickly when the connection is going through. I typically redirect the output from stdout to an out file by calling 'sslproxy >! out' at the command line.
8) What do I do if I like the sniffer?
You should definitely tell me (eujin at cs.stanford.edu) about it. :-)
9) What do I do if I don't like the sniffer?
You should definitely tell me (eujin at cs.stanford.edu) about why you don't like it. :-(
See the documentation.
Yes there is. I've received some requests from commercial websites to state here that using the sniffer on any secure websites does not constitute a crack of the site. All the sniffer does is to parse the unencrypted traffic that occurs before the exchange is complete and they switch to encrypted traffic. It naturally cannot parse the encrypted packets because it does not even attempt to do any decryption.
From https://www.etrade.com:
-- etrade.txt
From https://enigma.barclaycard.co.uk:
-- barclaycard.txt
On a side note, you might want to check out Netscape's sample traces which does the same thing as the sniffer except that it's a lot more cryptic and doesn't look as nice. The information is the same but displayed in integer form; there is no translation into a human readable form.
It's found at http://home.netscape.com/eng/ssl3/traces/index.html.
Take a look and decide which you prefer. :-)
13) Why is all the code in the sniffer contained in just one file?
The only computer that I own is a laptop that has a very small display, 12.1", and so working with more than one file is rather painful even with a pager. So to minimize the inconvenience to myself by having to repeatedly page back and forth to view several files on a small display, I put them all in one file, which is probably very bad style.