security/nss/cmd/ssltap/ssltap-manual.html@925c144e1f1f (annotated)
security/nss/cmd/ssltap/ssltap-manual.html
Fri, 16 Jan 2015 18:13:44 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Fri, 16 Jan 2015 18:13:44 +0100
- branch
- TOR_BUG_9701
- changeset 14
- 925c144e1f1f
- permissions
- -rw-r--r--
Integrate suggestion from review to improve consistency with existing code.
| michael@0 | 1 | <HTML> |
| michael@0 | 2 | <!-- This Source Code Form is subject to the terms of the Mozilla Public |
| michael@0 | 3 | - License, v. 2.0. If a copy of the MPL was not distributed with this |
| michael@0 | 4 | - file, You can obtain one at http://mozilla.org/MPL/2.0/. --> |
| michael@0 | 5 | <HEAD> |
| michael@0 | 6 | <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> |
| michael@0 | 7 | <META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (WinNT; U) [Netscape]"> |
| michael@0 | 8 | <META NAME="Author" CONTENT="Steve Parkinson"> |
| michael@0 | 9 | <TITLE>SSLTap - manual</TITLE> |
| michael@0 | 10 | </HEAD> |
| michael@0 | 11 | <BODY> |
| michael@0 | 12 | |
| michael@0 | 13 | <H1> |
| michael@0 | 14 | SSLTap Manual page</H1> |
| michael@0 | 15 | |
| michael@0 | 16 | <H3> |
| michael@0 | 17 | Summary</H3> |
| michael@0 | 18 | A command-line proxy which is SSL-aware. It snoops on TCP connections, |
| michael@0 | 19 | and displays the data going by, including SSL records and handshaking |
| michael@0 | 20 | if the connection is SSL. |
| michael@0 | 21 | <H3> |
| michael@0 | 22 | Synopsis</H3> |
| michael@0 | 23 | <TT>ssltap [-vhfsxl] [-p port] hostname:port</TT> |
| michael@0 | 24 | |
| michael@0 | 25 | <P><TT> -v [prints version string]</TT> |
| michael@0 | 26 | <BR><TT> -h [outputs hex instead |
| michael@0 | 27 | of ASCII]</TT> |
| michael@0 | 28 | <BR><TT> -f [turn on Fancy HTML |
| michael@0 | 29 | coloring]</TT> |
| michael@0 | 30 | <BR><TT> -s [turn on SSL decoding]</TT> |
| michael@0 | 31 | <BR><TT> -x [turn on extra SSL |
| michael@0 | 32 | hex dumps]</TT> |
| michael@0 | 33 | <BR><TT> -p port [specify rendezvous port (default 1924)]</TT> |
| michael@0 | 34 | <BR><TT> -l [loop - continue |
| michael@0 | 35 | to wait for more connections]</TT> |
| michael@0 | 36 | <H3> |
| michael@0 | 37 | Description</H3> |
| michael@0 | 38 | SSLTap opens a socket on a rendezvous port, and waits for an incoming connection |
| michael@0 | 39 | (client side). Once this connection arrives, SSLTap makes another connection |
| michael@0 | 40 | to hostname:port (server side). It passes any data sent by the client to |
| michael@0 | 41 | the server, and vice versa. However, SSLTap will also display the data |
| michael@0 | 42 | to the console. It can do this for plain HTTP connections, or any TCP protocol. |
| michael@0 | 43 | However, SSLTap can also work with SSL streams, as detailed below. |
| michael@0 | 44 | |
| michael@0 | 45 | <P>Let's assume your development machine is called 'intercept'. The simplest |
| michael@0 | 46 | usage of SSLTap is to run the command <TT>'ssltap www.netscape.com:80'</TT> |
| michael@0 | 47 | on intercept. The program will wait for an incoming connection on port |
| michael@0 | 48 | 1924. Next you would want to go to your browser, and enter the URL http://intercept:1924. |
| michael@0 | 49 | The page retrieved by the browser will actually be gotten from the server |
| michael@0 | 50 | at www.netscape.com, but will go via SSLTap. |
| michael@0 | 51 | |
| michael@0 | 52 | <P>Data sent from the client to the server is surrounded by a '--> [ ]' |
| michael@0 | 53 | symbol, and data sent from the server to the client, a '<---[ |
| michael@0 | 54 | ]' symbol. |
| michael@0 | 55 | |
| michael@0 | 56 | <P>You'll notice that the page retrieved with this example looks incomplete. |
| michael@0 | 57 | This is because SSLTap by default closes down after the first connection |
| michael@0 | 58 | is complete, so the browser is not able to load images. To make the SSLTap |
| michael@0 | 59 | continue to accept connections, switch on looping mode with the -l option. |
| michael@0 | 60 | |
| michael@0 | 61 | <P>You can change the default rendezvous port to something else with the |
| michael@0 | 62 | -p option. |
| michael@0 | 63 | |
| michael@0 | 64 | <P>The remaining options change the way the output is produced. |
| michael@0 | 65 | |
| michael@0 | 66 | <P>The -f option prints 'fancy' output - in colored HTML. Data sent from |
| michael@0 | 67 | the client to the server is in blue. The server's reply is in red. This |
| michael@0 | 68 | is designed so you can load the output up into a browser. When used with |
| michael@0 | 69 | looping mode, the different connections are separated with horizontal lines. |
| michael@0 | 70 | |
| michael@0 | 71 | <P>-x will turn on HEX printing. Instead of being output as ascii, the |
| michael@0 | 72 | data is shown as Hex, like this: |
| michael@0 | 73 | <UL><TT><-- [</TT> |
| michael@0 | 74 | <BR><TT> 0: 56 d5 16 3e a1 6b b1 4a 8f 67 c4 d7 |
| michael@0 | 75 | 21 2f 6f dd | V..>.k.J.g..!/o.</TT> |
| michael@0 | 76 | <BR><TT> 10: bb 22 c4 75 8c f4 ce 28 16 a6 20 aa |
| michael@0 | 77 | fb 9a 59 a1 | .".u...(.. ...Y.</TT> |
| michael@0 | 78 | <BR><TT> 20: 51 91 14 d2 fc 9f a7 ea 4d 9c f7 3a |
| michael@0 | 79 | 9d 83 62 4a | Q.......M..:..bJ</TT> |
| michael@0 | 80 | <BR><TT>]</TT> |
| michael@0 | 81 | <BR> </UL> |
| michael@0 | 82 | |
| michael@0 | 83 | <H4> |
| michael@0 | 84 | SSL Parse mode</H4> |
| michael@0 | 85 | The following options deal with SSL connections. |
| michael@0 | 86 | <UL>-s will turn on SSL parsing. (SSLTap doesn't automatically detect SSL |
| michael@0 | 87 | sessions.) |
| michael@0 | 88 | <BR>-x will turn on extra SSL hexdumps. Mostly, if SSL can decode the data, |
| michael@0 | 89 | it doesn't display the hex.</UL> |
| michael@0 | 90 | The following SSL3 Data structures are parsed: Handshake, ClientHello, |
| michael@0 | 91 | ServerHello, CertificateChain, Certificate. In addition, SSL2 ClientHello, |
| michael@0 | 92 | ServerHello, ClientMasterKey are also partly parsed. NO DECRYPTION IS PERFORMED |
| michael@0 | 93 | ON THE DATA. SSLTAP CANNOT DECRYPT the data. |
| michael@0 | 94 | |
| michael@0 | 95 | <P>If a certificate chain is detected, DER-encoded certificates will be |
| michael@0 | 96 | saved into files in the current directory called 'cert.0x' where x is the |
| michael@0 | 97 | sequence number of the certificate. |
| michael@0 | 98 | <BR> |
| michael@0 | 99 | <H3> |
| michael@0 | 100 | Operation Hints</H3> |
| michael@0 | 101 | Often, you'll find that the server certificate does not get transferred, |
| michael@0 | 102 | or other parts of the handshake do not happen. This is because the browser |
| michael@0 | 103 | is taking advantage of session-id-reuse (using the handshake results from |
| michael@0 | 104 | a previous session). If you restart the browser, it'll clear the session |
| michael@0 | 105 | id cache. |
| michael@0 | 106 | |
| michael@0 | 107 | <P>If you run the ssltap on a different machine that the ssl server you're |
| michael@0 | 108 | trying to connect to, the browser will complain that the host name you're |
| michael@0 | 109 | trying to connect to is different to the certificate, but it will still |
| michael@0 | 110 | let you connect, after showing you a dialog. |
| michael@0 | 111 | <H3> |
| michael@0 | 112 | Bugs</H3> |
| michael@0 | 113 | Please contact <A HREF="mailto:ssltap-support@netscape.com">ssltap-support@netscape.com</A> |
| michael@0 | 114 | for bug reports. |
| michael@0 | 115 | <H3> |
| michael@0 | 116 | History</H3> |
| michael@0 | 117 | 2.1 - First public release (March 1998) |
| michael@0 | 118 | <BR> |
| michael@0 | 119 | <H3> |
| michael@0 | 120 | Other</H3> |
| michael@0 | 121 | For reference, here is a table of some well-known port numbers: |
| michael@0 | 122 | <BR> |
| michael@0 | 123 | <TABLE BORDER=2 > |
| michael@0 | 124 | <TR> |
| michael@0 | 125 | <TD>HTTP</TD> |
| michael@0 | 126 | |
| michael@0 | 127 | <TD>80</TD> |
| michael@0 | 128 | </TR> |
| michael@0 | 129 | |
| michael@0 | 130 | <TR> |
| michael@0 | 131 | <TD>SMTP</TD> |
| michael@0 | 132 | |
| michael@0 | 133 | <TD>25</TD> |
| michael@0 | 134 | </TR> |
| michael@0 | 135 | |
| michael@0 | 136 | <TR> |
| michael@0 | 137 | <TD>HTTPS</TD> |
| michael@0 | 138 | |
| michael@0 | 139 | <TD>443</TD> |
| michael@0 | 140 | </TR> |
| michael@0 | 141 | |
| michael@0 | 142 | <TR> |
| michael@0 | 143 | <TD>FTP</TD> |
| michael@0 | 144 | |
| michael@0 | 145 | <TD>21</TD> |
| michael@0 | 146 | </TR> |
| michael@0 | 147 | |
| michael@0 | 148 | <TR> |
| michael@0 | 149 | <TD>IMAPS</TD> |
| michael@0 | 150 | |
| michael@0 | 151 | <TD>993</TD> |
| michael@0 | 152 | </TR> |
| michael@0 | 153 | |
| michael@0 | 154 | <TR> |
| michael@0 | 155 | <TD>NNTP</TD> |
| michael@0 | 156 | |
| michael@0 | 157 | <TD>119</TD> |
| michael@0 | 158 | </TR> |
| michael@0 | 159 | |
| michael@0 | 160 | <TR> |
| michael@0 | 161 | <TD>NNTPS</TD> |
| michael@0 | 162 | |
| michael@0 | 163 | <TD>563</TD> |
| michael@0 | 164 | </TR> |
| michael@0 | 165 | </TABLE> |
| michael@0 | 166 | |
| michael@0 | 167 | |
| michael@0 | 168 | <P> |
| michael@0 | 169 | </BODY> |
| michael@0 | 170 | </HTML> |
