From: Hansang Bae
| At 04:29 AM 8/3/2004, Jordi Masramon wrote:
| >How do you exactly decode ssl in order to see the application data
sent?
| >I am capturing the traffic between my browser and my web server but
I cannot see the data sent using ssl.
| >I have tried to use "tools/Decode as.." but it doesn't seem to work
at all. I still see application data as an unredable junk.
|
|
| This is a major pain. couple of approaches are:
|
| 1) Use a proxy so you can sniff from there. Since you control the
proxy, you can decrypt the packets.
That won't work as most HTTP proxies behave as dumb data pipes for
encrypted HTTP (HTTPS). Typically the client issues a CONNECT request,
which requests a TCP connection from the proxy to the host:port
specified in the URI of the CONNECT request. When the TCP connection
has successfully been established, the proxy issues a 200 OK response
to the client, and then the client can start *any* protocol over this
TCP stream. One (and the most relevant) use is setting up a TLS, SSL
or PCT tunnel between client and server (over the proxy). The proxy
does *not* play a role in this setup but for passing data as a "dumb"
bit pipe. It is up to the client/server to use the correct encryption.
Typically the client can only encrypt the traffic as the server is the
only one to know the decryption key.
| 2) Try using a debug (checked) version of I.E's DLL (if you're
using IE. while this isn't perfect, you can see what requests are
being sent.
That works. You can also write a tiny Java application which behaves
as a HTTPS client. This takes less than 20 lines.
| 3) Try using something like WebDetective on the PC itself.
I don't know that one, but here are other options:
4) Allow a NULL cipher (cleartext).
5) Some HTTP servers defer the HTTPS decryption/encryption to
dedicated servers. As such, the deciphered traffic runs between those
nodes and the actual web server. Some web switches even support this
operation mode.
Best regards,
Olivier