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.
Related
I am authenticating to my radius server using EAP-TLS v1.3 protocol. As TLSv1.3 mandates, all the certificates used are Elliptic curve (secp256-r1). However, the SSL tab of Wireshark supports only RSA Keys for now.
I want to decrypt the traffic on my supplicant (peer). Is there a way that can be done? (In a somewhat similar manner to Master Shared Secret method used for web browsers).
Any other program that can help me analyze the traffic?
Thanks in advance and apologies if I am missing something here. I am using wpa_supplicant v2.9 on peer.
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 have a C++ application that has a SSL/TLS communication with its own server and i don't have any access to that server. I'm trying to find out what is it sending from my PC to the server.
I tried burp and fiddler as man-in-middle but it didn't work. The application does not support Proxy so i tried routing the traffic using proxifier to burp and fiddler but it didn't work.
So I came up with these articles https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+All+Your+Secrets+/16415 and http://ask.wireshark.org/questions/4229/follow-ssl-stream-using-master-key-and-session-id
I just need to know , How I can find Master-key and Session-ID to decrypt SSL/TLS trafic.
It depends on the TLS cipher suite being used. If the ciphersuite uses forward secrecy (DHE) you cannot decrypt the stream. If it uses RSA encryption then you need at least the private key of the server. If it also uses client authentication then you would also need the private key of the client. if it uses symmetric encryption you need the symmetric (master) key from either one of them.
But if you do have a C++ application, I would simply add logging to that application (at the lowest level).
You can use following alrternates on a x86 windows
STRACE - http://blogs.msdn.com/b/emmanubo/archive/2007/06/04/introduction-to-strace-httpreplay-support-tools.aspx
SOCKTRC if this app is on windows checkout
http://blogs.msdn.com/b/emmanubo/archive/2007/08/03/socktrc-tool.aspx
HTTPREPLAY -
generally used for browsers but here can be used to view the responses in the UI
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.
So here is my 'problem', I set up an FTP server thanks to vsftpd so that both login & data transfers should be encrypted.
Here is the interesting part of my vsftpd.conf file.
ssl_enable=YES
allow_anon_ssl=NO
require_ssl_reuse=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
rsa_cert_file=/etc/vsftpd/vsftpd.pem
rsa_private_key_file=/etc/vsftpd/vsftpd.pem
ssl_ciphers=HIGH
I am using Filezilla as an FTP client, the connection is configured like this :
Protocol : FTP - File Transfer Protocol
Encryption : Require explicit FTP over TLS
Logon type: Normal
Some things to note :
Encryption : Plain FTP : does not work and I am happy with that.
(Response: 530 Non-anonymous sessions must use encryption.)
Encryption : Require implicit FTP over TLS : does not work either, the connection is refused by the server. I guess it is because I forced the SSL connection.
Now, once the (explicit) connection is established, Filezilla is showing a small lock icon at the bottom of the window saying The connection is encrypted. Click icon for details.
I wanted to make sure that the data transfers were indeed encrypted and not plain so I captured everything on my eth. card with Wireshark while downloading a file from my server to my computer.
Except that I can not find a single packet of SSL protocol, everything is TCP.
I am out of ideas on how to make sure the data transferred is encrypted, even if filezilla says so, and each time I google "vsftpd how to make sure data transfers are encrypted", the only answers I get is "ssl_enable=YES" or "Check the box Use SSL" ...
Thank you in advance for helping me !
After a little more research and especially after following the Complete walk through on http://wiki.wireshark.org/SSL, I have a better understanding of the whole thing.
I am answering to my own question hoping this will help someone someday, as long as what follows is correct...
Also writing this down is a good way for me, I think, to see if have clearly understood my problem. Any difficulties in writing this answer will prove me wrong.
First :
Typically, SSL uses TCP as its transport protocol.
SSL is wrapped in TCP, that is why I couldn't observe explicitly the SSL protocol while capturing packets.
When analyzing a TCP packet, I could only "Follow TCP stream" but not "Follow SSL stream" which mislead me into thinking the packet was not holding encrypted data. That is funny because the observable data was not human readable ... so encrypted.
To be able to decrypt it I had to provide wireshark the encryption key :
RSA keys list
This option specifies the bindings between an IP address, a port, a protocol and a decryption key.
Then, I could observe both encrypted / unencrypted data.
Also, after reading this on http://wiki.filezilla-project.org/ :
When you apply encryption to your FTP server the CPU will have to do many calculations to encrypt the data being sent and decrypt the data being received.
I simply decided to run the UNIX top command while downloading a file. I was able to observe a high CPU usage of the filezilla client process, contrary to a unencrypted data transfer. This was a second argument that confirmed the data transfered were indeed encrypted, and thus needed to be decrypted.