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!
Related
I used Wireshark to monitor packages of some websites, but found that there are such many communicating patterns of TLS 1.2.
The first one is a generic one:
Client: Client Hello
Server: Server Hello, Certificate, Server Hello Done
Client: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
Server: Change Cipher Spec, Encrypted Handshake Message
Second one is as followed:
Wireshark1
I'm just confused with why Certificate and Server Hello Done was in another package. Who demand server to do that? For what reasons?
After multiply refreshing page, I got the third one:
Wireshark2
Only 3 packages in handshake? A lot of processes were missed, was it because the information was cached? And how about the pre-master key?
Thanks for the answering!
TLS is a protocol over TCP, i.e. over a streaming transport protocol. For transport the data stream gets split into packets and thus it can happen that the ServerHelloDone is contained in one packet or in another or even split over two packets. Since the sizes are visible in your second example but not in the first it is unknown why the difference is exactly but it might be caused by the size of the certificate(s) contained in the handshake.
As for the third example: this is simple a TLS session reuse, i.e. it continues an older session and thus no sending of server certificate or similar is needed.
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
I have a very basic question: how does client_hello or server_hello in SSL handshake determine what SSL/TLS version can it support? I mean, as far as I understand, first client and then server send out the highest possible SSL version they support. But, how is this determined?
Is it the version field in a certificate?
Best regards,
HL
This is all described in the TLS specification, appendix E. This is phrased slightly differently in the TLS 1.0, 1.1 and 1.2 specification, but the principle remains the same.
Essentially, the client asks for the highest version it can support and the server responds with the highest version it can support up to the client's version:
min(max. client supported version, max. server supported version)
This works as long as there the resulting version is indeed supported by both parties.
The client is responsible for initiating an SSL handshake by sending the ClientHello message. If this isn't the first message that is sent, the server responds with an error and shuts down the socket.
The client advertises to the server which cipher specs it supports, it's not required to support all of them.
The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
The client also sends a challenge token, which the server must encrypt using the newly negotiated key before sending back the encrypted value, in its hello message. The client verifies that the decrypted token is the same as what was sent. If it's not, the handshake is rejected.
View the complete demo here
I am using Amazon RDS MySQL and connecting with SSL certificate(the default certificate available at http://s3.amazonaws.com/rds-downloads/mysql-ssl-ca-cert.pem), I am doing the following steps:
Downloaded the mysql-ssl-ca-cert.pem
Modified the above file to JKS format
And connecting from a web application through Spring - Hibernate template (org.springframework.beans.factory.config.PropertyPlaceholderConfigurer) and also use c3p0, we are setting additional URL parameter as jdbc:URL/DB?autoReconnect=true&useUniCode=true&characterEncoding=UTF-8&useSSL=true&verifyServerCertificate=false&requireSSL=true
But I am facing the below issue...
javax.net.ssl.SSLException: Unsupported record version Unknown-0.0
How can I fix this?
Basically it means that the SSL parser is lost. The sockets layer has passed it some bytes that don't fit the SSL protocol.
When you transmit using an SSL Socket, it calls a formatting and encryption routine to create the encrypted packet. It then calls the plain sockets layer to transfer the encrypted packet to the server. The server's sockets layer receives the packet and then calls the SSL package to decrypt the packet. If the packet doesn't fit the SSL format, you get the unsupport version exception.
All bytes that arrive at the socket layer are sent to the SSL package. So the simplest way to get that error is to use the plain sockets layer to transmit a plain text message after establishing the SSL connection.
In my particular case, I ran into this error message because I was transmitting extra bytes. Let's see if I can explain my mistake clearly.
I had a buffer that was (for example) 100 bytes. I packed the buffer with my 50 byte message and called the SSL encryption routine. The resulting packet was 75 bytes long. I called send() to transmit the buffer. This was a plain sockets send; it did what I told it to do, which was transmit the entire 100 byte buffer.
At the server, the entire 100 bytes was received. The SSL package tried to decrypt the packet. It found a perfectly good SSL message packed into the first 75 bytes that were received. So far so good. Then it tried to figure out what the remaining 25 bytes meant. It assued that it was a SECOND SSL message and tried to decrypt it. That's when it choked and kicked out that nasty exception.
I hope that gives you some clues about what to look for in your code.
I found this error if I presented an unsupported client certificate. Blanking out "-Djavax.net.ssl.keyStore" and connecting with no client certificate worked.
See also http://feed.askmaclean.com/archives/secure-java-connections-by-default.html :
Support for various TLS versions differs based on the JRE version used. Make sure you know the capabilities of the JDK you are using before restricting specific TLS versions. When first running the test above, Eclipse was using JRE 1.6.0_45 instead of JRE 1.8.0_65 I expected, and was connecting using TLSv1.0 ciphers. When MySQL Server was configured to only allow TLSv1.1 and TLSv1.2, I received the following Exception:
Caused by: javax.net.ssl.SSLException: Unsupported record version Unknown-0.0
at com.sun.net.ssl.internal.ssl.InputRecord.readV3Record(InputRecord.java:504)
Usage of older JREs should be assessed before disabling TLSv1.0 – fortunately, PERFORMANCE_SCHEMA makes it easy to survey client JREs without having to inspect every application server.
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.