The root problem I am trying to solve is to view the (encrypted) requests I am making from HtmlUnit(http://htmlunit.sourceforge.net/) inside of wireshark. I can see the packets and Under Secure Sockets Layer, I can see that TLSv1.2 is being utilized in wireshark, but I need to see the contents of the packet. I have read information on: exporting firefox keys and on: using those keys in wireshark from a browser into wireshark for decryption is feasible, but HtmlUnit is not a 'traditional' browser. I know it is possible, I just do not know what info I need and where to get it. Any tips are appreciated.
Thanks!
Maybe it is simpler to enable HttpClient wire log.
java.util.logging.Logger.getLogger("org.apache.http.wire").setLevel(java.util.logging.Level.FINEST);
This will dump all outgoing and incoming content to the log.
Related
I am trying to see data (using tcpdump) which my browser sends to server which is using https protocol
tcpdump -i any -w /tmp/http.log
but application data is encrypted(as it was expected).
I am wondering is there a way to see data before it will be encrypted when the server is https?
EDIT: Encryption traffic is created by common web browsers like Firefox, Chrome, IE...
If you control the server, you can set it to permit the null cipher then force your client to use the same. The null cipher is just a fancy way of saying "unencrypted". This should NEVER be deployed, as even having it as an option in the ciphers list is HIGHLY insecure.
You could also add a trusted key to the client, and have the client use a proxy. The communication with the proxy uses the trusted key you created, and can look at the data before sending it on, encrypted with the key of the destination server. This is, effectively, a "Man in the Middle attack," and can be defeated by things like certificate pinning. Some companies use this to track employee computer usage (when used in that way, it's somewhat controversial).
Strictly speaking, both of those are attacks to get around the encryption, not looking at the data before it's encrypted. To see it before it's encrypted, you would, generally, have to modify either the client or server to record what it's sending (or maybe use a debugger), as generally the encryption is done by a library directly linked to the programme.
EDIT: the developer tools in Chrome and Firefox might be what you're looking for: if you click the page on the "network" tab (in chrome, I don't have FF up, but it has almost exactly the same thing) you can see almost all the aspects of the info being sent and received.
Just use Charles Proxy (free trial) on your computer. If the certificate is pinned this will not work bit that is probably not the case for a browser..
so i started to work in this summer and the first task they have given to me is to use wireshark to understand why an application that uses webRTC doesn't use the turn server.
Can you guys help me out, to understand which steps should i do to understand better where is the problem.
I already run the wireshark and only get protocols STUN, that bind to a UDP connection.
TURN is a STUN extension so you will only see STUN packets in Wireshark.
You can easily test WebRTC+TURN in isolation using this sample from the WebRTC project. Remove the default stun server and add the url and credentials for your own TURN server.
Fire up wireshark, start capturing.
Click the "gather candidates" button on that page. You should see candidates with host type at least. You should, if the browser can reach the TURN server usually also see candidates with a srflx type.
If the TURN server is working and your credentials are valid, then you will get candidates with type relay. But you probably wouldn't be asking then.
Now go back to wireshark. Set the display filter to 'stun'. You should see some packets sent to the ip address of the TURN server. Right-click on one of them, 'follow' and 'udp stream'. That should show you all the packets between the browser and the TURN server.
You should be seeing binding requests (message_type=0x01) as well as binding success responses (message_type=0x101) from the server. If you don't see those, your turn server is not responding or something is blocking the client. You will also not get srflx candidates on the candidate gathering demo page.
You should also see packets wireshark interprets as 'allocate request udp' (the message type is 0x101). These are the important ones for TURN.
You should see an error from the TURN server with a message type 0x113 and an error code 401 (unauthorized) because in the first packets, there is no username attribute. In response to those the browser will start sending allocate requests that contain both a username and a message-integrity.
If things go well, those should be answered with an allocate success response (message type=0x103) indicating a xor-relayed-address.
If not and you see more 401 errors that usually means your username and password is wrong.
You might also find the articles on using wireshark to reverse-engineer Amazon Mayday and Whatsapp on WebRTChacks useful -- both use Wireshark.
The WebRTC project has some notes on Wireshark, too.
I have a couple questions about SSL.
What happens if someone tampers or changes the encrypted data? There are many ways in which the data being transferred can be tampered, so though the encrypted data will not make any sense to the tamperer, what would happen if he just tampers it? How would I handle such scenarios?
What will happen if a webpage is requested by a browser which does not support SSL? Or the client accessing the website is actually some kind of malware?
I am pretty new to SSL so maybe my questions are very trivial but I don't have answers to them.
The packets including the URL itself is encrypted. Modify the bytes will make the packet invalid. As far as I know it is not accepted by the server then.
If a client browser don't support your SSL protocol it can't access the website. The client get a "Insecured Request Denied Error".
SSL is to establish a secured connection. Any software, including malware, that support the protocol can start a connection. The SSL protocol "just" encrypt the communication so the packets can't be inspected outside. So your software itself need to be protected against any attacks anyway.
The tampering will be detected on arrival and the connection automatically dropped, probably resulting in a dialog box to the browser user.
I'm not aware of any browser that doesn't support SSL. Such a thing would be singularly useless.
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.
i am trying to block ssl handshakes before the secure connection is established. So can anyone advice me how to do this. I allready have access to all data transfered to network using Winsock SPI(LSP). But how can i identify that now there is a request for SSL connecion? the data needed for establisment cant be crypted but are encoded in some way. I cant find the format anywhere.
If you have any idea about this, please let me know. I am doing this in c++.
While I think what you are doing is totally dubious, well, the best place to start is this document: The SSL Protocol - it describes the actual packet format used by SSL to envelope the encrypted data.