1SSLsniffer. 2---------------------------------------------- 3Written by: Eu-Jin Goh (eujin@cs.stanford.edu) 4 Stanford University April 2001 5 6----------------- GNU Public License ----------- 7Copyright (C) 2001 Eu-Jin Goh 8 9This program is free software; you can redistribute it and/or modify 10it under the terms of the GNU General Public License as published by 11the Free Software Foundation; either version 2 of the License, or (at 12your option) any later version. 13 14This program is distributed in the hope that it will be useful, but 15WITHOUT ANY WARRANTY; without even the implied warranty of 16MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 17General Public License for more details. 18 19You should have received a copy of the GNU General Public License 20along with this program; if not, write to the Free Software 21Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, 22USA. 23 24INSTALLATION: 25------------- 26 27First type 'tar zxvf sslsniffer-1_2.tar.gz' to extract the files. 28Just use the Makefile. You might have to change the paths of the 29headers and libraries for openSSL. 30 31USAGE: 32----- 33 34sslsniffer [-p <local port>] [-np <remote port> <remote hostname/ip>] 35 36-p <local port> 37 38specifies which port the sslsniffer will listen to on the local 39machine. 40 41-np <remote port> <remote hostname/ip> 42 43no means no proxy which means that the CONNECT message is not 44sent. Instead the remote host name (it also accepts numerical ip 45addresses) and the remote port number is specified. 46 47If not options are given, the sslsniffer listens on the default port 488888 and assumes that a CONNECT message will be sent as the first 49packet. 50 51---------------------------------------------------------------- 52 53PROGRAM NOTES: 54 55Version 1.21 56------------ 57 58Bug fixes. 59 60The version number of a connection would not be updated if the first 61packet is not a V2 packet. This doesn't break anything except that 62certificates will not be parsed in that connection. 63 64Forgot to place a break statement in a switch while parsing certain 65handshake packet types. Symptoms were that the sniffer would try to 66parse more than it should and print out garbage values. Fortunately, 67the packet that triggers this was not a common one. 68 69Version 1.2 70----------- 71 72Main changes in this version is that support for parsing SSLV2 packets 73has been implemented. It took a lot less time than I thought it would 74because the rewritten code base makes it easy to add this in and also 75because sslv2 is a much simpler protocol to parse than TLS. 76 77It seems that SSLV2 doesn't offer support for certificate chains. 78 79I removed a couple of structs from the sslsniffer.h because I forgot 80that C doesn't guarantee how structs are laid out in memory and hence 81I shouldn't be relying on structs to typecast network data for pointer 82access. 83 84 85Version 1.1 86----------- 87 88I totally rewrote the entire sslsniffer so that it handles fragmented 89packets in a cleaner fashion. The entire structure is changed and I'm 90much happier with the current incarnation now. It's also a lot more 91flexible and I plan to add support for SSLV2 very soon. I've already 92written that part but it's under the old style and I want to rewrite 93it as well. 94 95It now handles those multiple handshake packets in one record case 96perfectly (I think!) and also those fragmented packets. The style of 97the code has been changed to make it a lot more readable. 98 99Also, the no connect case where you want to connect directly to the 100server without sending a CONNECT request has been made as a flag 101rather than spinning it off to another program. 102 103 104Version 1.02. 105------------ 106 107I was printing out the reverse of session ID for a V3 hello and also 108for the RSA encrypted premaster secret. the function extractParams 109suffered from this problem too. there was a one by off error in these 110same functions 111 112 113Version 1.01 / 1.00 114------------------- 115 116This program uses the OpenSSL libraries and Dan Boneh's code for the 117processing of the certificates. Other than that, everything else was 118coded from scratch. 119 120The proxy handles SSLV3/TLS servers only. It deals with the first 121clientHello packet being in SSLV2 format but other than that, no other 122SSLV2 packets are handled. You can typically recognise when the site 123is using SSLV2 when the first byte of the error messages that the 124proxy prints out are -128 or -126. try it on wellsfargo to see. This 125was developed in RedHat linux 6.1 using glibc 2.1.3-8 and openssl 1260.94. Works best in linux using x86 architecture. On some machines, 127the print outs in hex will appear to have either leading or trailing 128zeros. 129 130Please send all bug reports to me. It would be great if you could 131attach the output when the bug ocurred too. I typically use 'sslproxy 132>! out' and read the out file later because there is usually too much 133output to read at one go. 134 135NOTE: 136 137I have not ported this to big endian architectures yet, i think it's 138not too hard since all that is needed is to change the function 139threeBytesToInt so that it converts the handshake length field to from 140a three byte number in network byte order to the host byte order. 141 142If the server returns a cipher suite that is unknown, currently my 143proxy doesn't handle it too well. it still works but doesn't parse the 144messages properly. 145 146Occasionally (very rarely), the multiple application data fragments 147aren't handled properly and invalid type errors keeping appearing but 148the proxy should still work properly after that connection. 149 150Netscape enterprise servers were rather flakey on the proxy and i 151added some code so that it works properly. I tested on stronghold 152servers and this proxy works best with those. This is due to the fact 153that enterprise servers place multiple handshake messages within a 154single TLS record while stronghold sends out handshake messages with 155their own TLS record. 156 157The application data and certificate messages might be split up over 158several packets and the code that i have currently handles this fine 159but is rather ugly. Given more time, i would rewrite it so that it's 160cleaner. 161