How do you decrypt SSH .pcap file that uses Diffie Hellman encryption. With public and private keys.
We are trying through Wireshark with no luck.
One of the benefits of ephemeral Diffie-Hellman (the DHE ciphersuites of TLS) is that it provides perfect forward secrecy. This means that even if the private DSA key used to authenticate the server (and possibly client) are obtained by an attacker someday, she won't be able to go back and decrypt any sessions captured in the past.
In other words, you can't decrypt these captures unless you recorded the secret session key; there's no way to recover it afterward.
This is different than the RSA cipher suites, where knowledge of the server private key allows one to decrypt the session.
Because the session is encrypted by a transient "session key", having the public/private keys of the server and/or client at the end is of no use to you. Those keys are only used to verify that there has been no man-in-the-middle attack.
In order to decrypt a SSH session, you must either somehow obtain the session key (perhaps by attaching a debugger to a client on either side) or perform a man-in-the-middle attack - this requires the private key of the server (and the client, if key authentication is being used). Some more info on the latter option can be found here: http://taosecurity.blogspot.com/2007/08/loving-ssh.html
So if I understand well, the process to decrypt a SSH session is very similar to decoding wifi WPA2-PSK, you need to capture the 4-way handshake to be able to derive the transient key aka PTK. In wifi WPA2-PSK if we don't have the 4-way handshake, there is also no way to recover the transient key and decrypt the traffic even if you know the actual passphrase.
Related
Do you know if it is possible to disable Diffie-Hellman or set a fixed session key for openssh? Actually i want to analyze the traffic with WireShark and I need to decrypt it.
Your Options with SSH and Wireshark are really limited. Wireshark cannot decrypt SSH traffic because it uses session keys derived from DH. OpenSSH doesn't have a "fixed session key mode" because that would be really insecure and make it basically impossible to resolve the key oven an open channel.
you will need to put a MITM between your client and server, the record a pcap file of the decrypted traffic for wireshark to analyze. Ettercap is a good tool for this.
I am using wireshark to intercept SSL traffic that is being sent from my machine. Because it is encrypted on my machine, the private key for the connection has to be stored there... correct?
Is there an application that will just show my the private keys. I guess it would kind of be a security vulnribility if it were easy though.
correct me if I am wrong, but because I encrypt out going connections with the servers public key, and decrypt incoming with my private key, I can only decrypt incoming connections... correct?
You're confusing several things here.
You don't necessarily have a private key at all in a client;
an SSL server practically always has a private key; but
SSL is not encrypted with public/private keys, it is encrypted with a symmetric session key which is generated for the session using the algorithm defined in RFC 2246.
As pointed out by EJP, this is only relevant if you're running a server, not a client.
If running a server, the location and format of the key used is detailed in the specific server's configuration. Some servers also include a procedure for exporting this key, which is inside a container or keystore.
Note also that even if you do obtain the private key, certain SSL cipher suites- notably those using the Diffie-Hellman key exchange mechanism - will prevent Wireshark from decrypting the traffic.
I understand that through SSL, the browser gets the public key of the secured website and through public key encryption rsa algorithm, these 2 establish session key and then continue communication thru some symmetric algorithm, because symmetric key encryption/decryption is faster. Which symmetric key algorithm does SSL use? DES? AES? or something else?
When the client connects to the server, it negotiates a so-called ciphersuite (combination of encryption, key exchange, authentication algorithms) to use. Each SSL client or server has a list of allowed ciphersuites and during handshake the client and the server negotiate on what ciphersuite to use. It can happen sometimes, that there's no common denominator (ciphersuites sets don't intersect) and connection can't be established.
Symmetric algorithms supported in SSL are DES, 3DES, ARCFOUR, AES, Camellia, RC2, IDEA, SEED, NULL (no encryption).
During the connection establishment (the "handshake"), the client and server decide upon a "cipher suite" to use. The cipher suite states the algorithms which are used (asymmetric key agreement, symmetric encryption, and integrity check). In details, the client sends a list of the cipher suites it supports, and the server selects one of them, that it also supports. Normally, the server selects the first suite that it supports among those sent by the client (in other words, the ordering of the suites in the client message is its "order of preference" and the server usually honors the client preferences).
For instance, the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA means that the session key will be transmitted with RSA (asymmetric encryption, using the RSA public key from the server certificate), the data will be symmetrically encrypted with 3DES, and the integrity check will use the SHA-1 hash function. See the TLS specification for the list of standard cipher suites (other suites were added later on, in particular some with AES).
Several possibilities including RC4 and DES or even no encryption. Not an area I know well, but I assume client and server negotiate to find one they can both use
http://httpd.apache.org/docs/2.0/ssl/ssl_intro.html#ssl
If you are using HTTPS under Firefox, if you click the little "lock" icon in the URL bar, it will give you a pop up with the details of your connection. For example, with my server, I connect with 128 bit AES with firefox.
Different web browsers can give different results of course, since the TLS connection negotiates the connection.
I am using Botan utility to perform encryption. When I initialize my connection to a remote machine using SSH, I am able to trade keys over the secure SSH connection. However, sometimes I use inetd to establish the connection, and in this case, there is no security on the inetd connection, but I need to use it to trade keys with the remote machine.
I imagine there is some standard for this whereby I send a public key over an insecure channel and the remote end uses this to encrypt a key to send back to me over the insecure channel, which I can then decrypt to get the key.
What would be an example of this kind of protocol that Botan supports?
Without previous trust, or communication through a side channel, there's no way to do that. Diffie-Hellman kex allows you to establish a channel secure against others who don't participate in the connection, but you cannot verify that you're communicating with the intended recipient.
Classic MITM example: you connect to some remote endpoint, it receives your public key and sends you something signed with that key. However, you have no way to verify whether you've sent your key to the real destination, or whether the response comes from an attacker - therefore, you have a secure tunnel, but you have no information with whom you're securely communicating (the attacker may even connect to your intended destination and proxy the traffic, which passes over him unencrypted).
To be sure that you are indeed communicating with the intended endpoint, you need to exchange some sort of identification of the host beforehand or through a secure channel. SSH does this using the "fingerprints" - it asks you on first connection if you trust that host, and you're supposed to verify the fingerprint through an independent channel.
What I did in a similar situation was to first arrange to get a private/public key pair exchanged, so, I had the public key of each client, so when they connected to me, a message was passed, that had a timestamp on it, that I could then decrypt.
If that passed, and the timestamp was valid (I used 5 seconds as the life of the timestamp) then I would exchange the key, since we had a way to securely communicate.
But, this required doing something upfront.
If you expect an anonymous user to connect and have some security that is impossible.
One article I found very helpful on issues like this was *Programming Satan's Computer", http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf, where you are trying to have a secure communication with an untrustworthy sysadmin.
I always use ssh in putty to connect a remote server. As I know, ssh is based on public/private key mechanism, is it?
Does that mean the client will receive a public key first time when it connects to the server and then use the public key to continue with following communication?
Thanks.
Do you mean for authentication, or for encryption?
For authentication, Section 5.5.1 here covers it:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch05_05.htm#ch05-46136.html
In general, you create the key pair and get them there through other means.
If you mean for the encryption, try section 3.9.1.3 here:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_09.htm#ch03-65213.html
There are two parts where public/private key come into play -- session initialization and (optionally) user authentication.
In session initialization, the host public and private keys are used to set up the encrypted connection, but are not used to encrypt the connection itself. Instead, the initial set up is used to securely generate a unique session key that is used to encrypt the connection. The host public/private keys are generated and installed on the server.
While connecting, your ssh client (PuTTY in this case) will verify that the host key is what it remembers from the last time you connected. (If they are different, then somebody might be snooping on your connection!) This is why PuTTY asks you to confirm the hash of the host key the first time you connect -- it doesn't have a record of what the key is supposed to be, so it asks you to verify. If you tell PuTTY to confirm and save, then PuTTY will save the hash of the host key in the registry for future connections.
In user authentication, the user public and private keys are used to allow access to the server. The public key is installed for the user on the server. The server can then use that key to issue a challenge to the client that can only be answered correctly by using the user's private key. The user generates the public/private keys him/herself (e.g. with ssh-keygen).
For PuTTY, you can generate your own public and private key using the PuTTYgen utility (this is the PuTTY equivalent to ssh-keygen). It's up to you how you want to get the public key installed on the server. Then, run Pageant (a little app that sits in your notification area) and add your private key. If you set a passphrase on your private key, then Pageant will prompt you to enter it. Pageant, while running, will then work with PuTTY (or pscp, psftp, etc.) to make use of your private key.
This is a gross simplification of the processes involved; see James' answer for links to details.