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.
Related
It's slightly embarrassing to ask this, but here it goes: What's the difference between generating public/private keys via ssh-keygen and cfssl?
I've successfully used ssh-keygen to create pub/private key credentials that can be used to ssh into a server. I've also successfully used cfssl to create a private key & certificate for a web site. However, I can't seem to figure out how to use cfssl to do what ssh-keygen does.
Since they both can be used to generate public/private RSA 4096 keys, it seems as if they could be used interchangeably. Unfortunately, no matter how many different combinations I try, or how much I search the interwebs, I can't seem to find a working example.
I'm starting to think that there's something I fundamentally don't understand regarding each tool's approach to encryption.
People of stackoverflow land... have mercy on me, and please point out the error of my ways. Your help is truly appreciated.
No, these two types of keys aren't interchangeable. RSA is an algorithm for encryption and digital signatures. It is used in both TLS (for web sites) and SSH, but those two protocols, while they both support RSA keys, use the algorithm differently.
A protocol specifies a (hopefully secure) technique for using standard algorithms and protecting data with it, and there are many secure ways to use RSA to sign data, which differ based on the protocol. Similarly, both TLS and SSH can use AES-GCM to encrypt and authenticate data, but they will use it differently.
Moreover, even if you could generate keys for one with the other, you generally don't want to reuse keys for different purposes. That's because in some cases, an attacker can capture a valid message in one protocol and use it in the other protocol to impersonate the legitimate party.
Do note that the private key formats typically used by OpenSSH and TLS implementations are often the same, but the public key formats are not. An SSH public key is going to look totally different than an X.509 public key used with TLS.
If you need to create keys for use with SSH, you should use ssh-keygen, and if you need to create a key for use with your web server or another TLS server, use a tool for that, like openssl or cfssl.
I've used wireshark to watch several SSL3.0 traffic and decrypt the messages transferred between client & server.
And what I've just found is very strange :
AFAIK, the encryption-key, MAC and encryption algorithm used in calculating client-Finished and application-data sent by client are exactly the same.
But, when I use the same client-write-key used to encrypt client-finished (Derived from MasterSecret) to encrypt application data, I get the different result from what the client (firefox) calculated.
The odd behavior also happened with server: I can use server-write-key (derive from MasterSecret) to decrypt successfully the "server-finished" message, but failed to decrypt any other encrypted message from server.
So, can you please tell me what happened to the client-write-key & server-write-key ?
Did both client and server changed their write-key after "finished" message sent?
PS: I forced client (Firefox) to use SSL V3.0, cipherSuite = TLS_RSA_WITH_RC4_128_MD5
I found out the answer myself : the function RC4 I've used didn't save the cipher state, while SSL stream cipher required that. I've used a RC4 class and problem resolved!
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 have a client application that runs on my computer, which uses openssl to communicate with server using SSLv3. I need to see what they talk so I basically want to edit and recompile openssl library in order to acquire relevant encryption keys.
The application usually uses TLS-DHE-RSA-WITH-AES-256-CBC-SHA as cipher suite. Sometimes it uses aes128 instead of aes256 but that's not critical at this stage. I edited s3_enc.c file so far. At the end of ssl3_setup_key_block function I write the master key, key block(so the client-server write keys, mac keys and IV's), server and client randoms to a file. http://www.ietf.org/rfc/rfc2246.txt says if the stream cipher is exportable, client-server write keys are to be updated as final client-server write keys accordingly. I'm not sure if this cipher suite is considered exportable(whatever that means), but I create final write keys anyway.
The problem is whatever I tried, I couldn't successfully decrypt any packet which I acquired using wireshark. The output is meaningless no matter what and I'm stuck. I am considering checking the mac fields of packets after decryption in order to see whether decryption was correct. But that also seems to be a dead end.
Does anyone have any idea what I am missing, what I might be doing wrong?
If you can modify OpenSSL and make your client application use it, then all you need to do is make your modified OpenSSL dump the decrypted data to the file. Even easier alternative would be to make OpenSSL use one of NULL ciphersuites even when the application requests certain encryption.
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.