Question: I thought it'd be a neat idea to do a wireshark capture on my own login to a website and try to figure out where the packet containing the password is and decrypt it. 

So I logged into a website which uses SSL RSA with RC4 128 md5 to encrypt the password. I'm not asking for someone to tell me exactly what to do, that would be great, but I'd like some tips on how to find it and how to decrypt it.

(I already know the plaintext password since it's my own, but of course, it's not in plaintext in the wireshark trace)

I have got the standard MD5 hash of my password and I tried to find it in the trace, but it doesn't show up. I don't know how the SSL RSA encrypts the password, so I'm not sure what I'm looking for exactly.

Thanks in advance.

Answer: 
Ooops !!! You cannot do that .

**Why ?**

You cannot Decrypt the wireshark dump without having the Private key corresponding to the server's ssl certificate.

If you do have the SSL certificate's corresponding private key , then with the latest wireshark .

Goto Edit-> Preferences -> Protocol -> SSL --> RSA KeysList -> Edit , provide the server IP , Protocol as HTTP and the SSL PFX and its password and click APPLY and OK .
For a description of how SSL works, see [this answer](https://security.stackexchange.com/questions/20803/how-does-ssl-work/20847#20847). To make the story short, SSL begins with a special procedure called the *handshake* in which client and server exchange "handshake messages". A lot of cryptography is involved, to the effect that at the end of the handshake, client and server share a common session-specific secret value, from which they derive keys for encryption and integrity checks of data in both directions. The point of SSL is to establish a bidirectional tunnel for arbitrary data; that "arbitrary data" is called *application data* in SSL terminology.

[HTTPS](http://en.wikipedia.org/wiki/HTTP_Secure) is "HTTP within SSL": a SSL handshake is made first; and then, plain HTTP traffic (HTTP requests with their headers, and corresponding responses) are conveyed as "application data" through the SSL tunnel. When a Web site requires client authentication, this process occurs at the HTTP level, so, from the point of view of SSL, as "application data". The user password will be part of that application data.

However, all the application data is encrypted, since that's what SSL was designed for. As an outsider, you won't be able to read it, because that's the whole point of SSL. SSL protects the client-server traffic against eavesdroppers, including yourself. **You won't see anything** except "encrypted application data".

To "see" the inner traffic, the HTTP requests and responses (and, thus, the user name and password contained therein), you need to break through the SSL layer; Wireshark can do that, but only if you give it a copy of the server private key (the server private key might not be *sufficient* for that, when client and server agree on a "DHE" cipher suite, but that's not the situation you encounter). See [this page](http://wiki.wireshark.org/SSL) for some documentation. It would be quite alarming if breaking through SSL was possible without a privileged access to at least some client-side or server-side secret data...