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.
Related
Problem:
I'm pretty new to this TLS thing and networking in general. But i'm trying to passively listen and decode TLS packets. I find it kind of frustrating that i cant decode packets on my network on my computer. The conclusion i got to is that is impossible because how TLS works. But in mathematics if you have enough of information you can often get the value of the unknown. In this instance i guess it might be the servers key that is the missing link.
Even if it would be cool to totally decrypt packets its not my main goal. What i specifically trying to do is to know if a specific twitch stream is watched on my computer/network. So if i type in the streamers name in to the program it checks if that stream is sent to my computer and responds with a boolean.
So i want your input guys and girls. Is there any way of achieve this without doing Man in the middle?
Thoughts:
I have been thinking about this problem and i got a couple of ideas (don't laugh at the possible stupidity, I'm not always very smart but its just some things that came to my mind):
(Comparing) Using my cert to send request to the twitch api and somehow compare the response and see if they have the same encrypted payload. Then i know this specific stream is watched.
(Decoding) feed cert (public and private key), decrypted message and encrypted message to some algorithm to get server key. My theory here is that i have enough information to get the server key. But my knowledge about ssl is limited and i have not considered handshakes and such.
(Decoding) Generate training data to an ai to teach it to decode ssl packets. Generating a lot of ssl packets with different keys and feed the cert and encrypted data to the ai.
I hope you understand what I'm trying to do. English is not my native language (sorry).
(Comparing) Using my cert to send request to the twitch api and somehow compare the response and see if they have the same encrypted payload. Then i know this specific stream is watched.
Data are encrypted with a symmetric key specific for this SSL/TLS session. Also a random initialization vector is used. Thus, even transfer of exactly the same data results in different encrypted data which means no comparison of the encrypted data will help.
(Decoding) feed cert (public and private key), decrypted message and encrypted message to some algorithm to get server key. My theory here is that i have enough information to get the server key. But my knowledge about ssl is limited and i have not considered handshakes and such.
If (the obsolete) RSA key exchange is used you would need to have the servers private key to decrypt which you don't have. With Diffie-Hellman key exchange even this private key would not be sufficient, but you need to have the master secret or pre-master secret of this specific SSL/TLS session (see the TLS standards for details what this is). This secret can only be found in the TLS client and TLS server for the time the TLS session is active - which means that you will not be able to use this either for decryption unless you have access to the internals of the client, in which case you might just look directly which stream they are viewing.
(Decoding) Generate training data to an ai to teach it to decode ssl packets. Generating a lot of ssl packets with different keys and feed the cert and encrypted data to the ai.
Properly encrypted data are more or less random and have no inherent structure which can be mapped to the original data or even parts of the data. AI will not magically find such a structure too. The only possible difference it might use to distinguish streams are the size and timing of the data - but only if these are specific for a stream which I doubt. So, most likely it is impossible this way too.
I find it kind of frustrating that i cant decode packets on my network on my computer. The conclusion i got to is that is impossible because how TLS works.
Indeed this is primary purpose of TLS. If correctly implemented you should have no way of decrypting transfered data.
There are even buggy and obsolete implementation on some servers where one can exploit some vulnerabilities, but - not for Twitch and not with your knowledge level only for buggy implementation
Generally you could consider TLS secure enough to ensure traffic integrity and confidentiality.
What i specifically trying to do is to know if a specific twitch stream is watched on my computer/network.
I'd provide some options to achieve the goal, however that would introduce dangerous vulnerabilities into your computer or network. (you have been warned)
Still you can sniff out the unencrypted traffic. So you can see e. g. DNS requests (you could see what hostnames are resolved, but not specific URL).
For your computer you could install a keylogger or get the requested URL from browser before it is encrypted.
Integrity of TLS rely on certification authorities. In theory could can create your own CA certificate and make it trusted on your computer or network. That could allow you mounting a man-in-the-middle attack (posing yourself as the target server with your own keys).
I know generally how HTTPS works, and from what I read, it seems that the generation of the encryption key could be done by a computer that isn't the one establishing the connection.
My thought is to create a proxy that isn't actually able to see the traffic going over the SSL connection. To do this, you would have a handshake in the same way as usual between the proxy and the server. However you would pass the encrypted symmetrical key to the proxy from your computer who would then transmit it on to the server. Then, when the server returned an encrypted payload, the proxy would not be able to decrypt it, but would forward it on to the users computer.
Am I missing something fundamental about how HTTPS works?
I have a PCAP file that was given to me for a Forensics Challenge. The PCAP has encrypted traffic using TLS Version 1. I have looked into a BEAST attack but there are no tools to do this. Is there any way using just the packets I have in the PCAP file to decrypt this traffic in Wireshark without the private key? Can I get the private key from the certificate exchange in anyways or the master secret log or something? I could not find any tutorials online that do not involve having access to the private key. Any help is appreciated.
UPDATE:
My later research revealed that version 1 of TLS did have vulnerabilities and that it was possible to do but I would have needed access to the actual host as well not just the PCAP of its traffic.
If you have the master secret, you might be able to do something.
Have a look at the "Using the (Pre)-Master-Secret" section on the SSL page of the Wireshark wiki. You'll need a reasonably recent version of Wireshark, which adds the ability to set the master secret (instead of expecting the server's private key). This should also help for Ephemeral Diffie-Hellman cipher suites.
More details in this question on the Wireshark Q&A site.
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.
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.