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.
Related
I've read somewere how https encryption and decryption works.
But that made me curious if you could get someones https decryption key by running some kind of command
By running a command from your client: no. Really, where would the security be then. Believe it or not, all this has been well thought out and vetted by serious cryptographers.
But you can get the decryption key, iff the server is vulnerable or you coerce a server admin, then you can get the certificate private key. Short of that no.
While enabling ssl in greenplum, it needs ONLY server.key(which is a private key) & certificates to be present in the master data directory.
What about public key and the session key? Why don't we need to provide these keys as well.
If we don't provide these keys then how the ssl communication will happen?
In General, ssl communication happens with the help of the public key and the private key( which is Asymmetric Encryption) for handshake and
the session key will be used for actual data transfer between client and server(which is symmetric encryption).
Is it possible to have ssl communcation with only private key?.Does SSL communication with Greenplum database server is different from normal SSL communication with a typical web server?
The public key is in the certificate. The session key is negotiated during the handshake. There is nothing different about this SSL server from any other SSL server in this respect.
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.
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.