Decrypting SSL/TLS traffic from a app with Wireshark - ssl

I have a pcap file with has the TLSv2.0 traffic from an Windows exe application.
I also have the backend server's private key used to establish the connection.
I have tried both the enabling ssllogfile environment variable and also tried selecting the private key under Wireshark -> Preferences -> TLS. But I still could not decrypt the traffic.
Is there any other way?
The cipher suite used is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The "ECDHE" means the key exchange is done using Elliptic Curve Diffie-Hellman, which provides forward secrecy. This means that the private key from the server X.509 cert is not enough to decrypt the traffic. You will need to get the client application to generate an SSLKEYLOGFILE, which can be done with Chrome, Firefox and curl. If the "Windows exe application" is something different, then you'll have to intercept the TLS traffic in order to see what goes inside the TLS tunnel.
If you wanna analyze the decrypted traffic in Wireshark, then I'd recommend to proxy the traffic with PolarProxy, because it generates a PCAP file with the decrypted traffic from the TLS session. You will not need any SSLKEYLOGFILE if you choose to intercept and decrypt the TLS traffic with PolarProxy.

Related

How sim800 get ssl certificate?

Sim800 supports SSL protocol. AT command "AT+CIPSSL" sets TCP to use SSL function.
In the "sim800_series_ssl_application_note_v1.01.pdf" is noted that: "Module will automatic begin SSL certificate after TCP connected."
My Problem: What is the exact meaning of the begin SSL certificate? what does sim800 do exactly? Does sim800 get SSL certificate from website? where does sim800 save SSL certificate?
As far as I know, SIM800 has some certificates in it and when you use a TCP+SSL or HTTP+SSL connection it will automatically use those certificates.
If those certificates are not ok for you, you will need to use an SD card, save there the certificates you want and use the command AT+SSLSETCERT to set the certificate you saved on your SD card. Here you can find how to use the File System.
Usually the certificates that come with the module are enough and you won't need this. But for example they didn't work for me when I tried to communicate with Azure via MQTT. I had to encrypt the data myself using wolfSSL library and send it using TCP without SSL.
Note: Not all SIM800 modules have SD card support.
There are a very few information about sim800 and ssl certificate on the web, and like you i got a lot of questions about it.
About your questions on how does sim800 get certificate and where does it save it, it seems, according to sim800_series_ssl_application_note_v1.01.pdf, that you can create (defining your own path), write and import a ssl certificate on your own with the AT+FSCREATE, AT+FSWRITE and AT+SSLSETCERT commands. An example is provided at the paragraph 3.10.
I'm sorry, i can't answer your other questions.
Anyway, if you get further informations about sim800 and ssl, i would be grateful if you share it with me.
When you use AT+CIPSSL you tell the SIM-module to use the SSL connection with TCP. When you use +CIPSTART command->
SIM module requests the TCP connection with the server through SSL.
Server sends the Server SSL certificate.
The authenticity of that certificate is checked with internal certificate authority certificate (The one that resides inside SIM-module) which is cryptographically connected with server certificate.
If the authenticity of certificate can not be confirmed SIM-module will close the connection unless you use the command AT+SSLOPT=0,0 (which forces the SIM-module to ignore invalid certificate authentication) prior to AT+CIPSSL command.
//Key exchange
SIM-module then encrypts it's master key (already inside SIM-module cannot be changed or read) with the public key (Which is part of the already sent server certificate) and sends it back to server.
Server then encrypts it's master key with SIM-module's master-key and sends it back to SIM-module. Key exchange is now complete as both (server and SIM-module) recieved master keys.
SIM-module currently doesn't support Client authentication which means that server cannot authenticate the client. That means there must be some other option of authentication (For example in MQTT that can be username and password that only client knows)
If you want your module to be able to authenticate server you will need to create the self-signed certificate for server and certificate authority certificate (for SIM-module) which is cryptographically connected to self-signed certificate and upload them to server and SIM-module (through AT+SSLSETCERT command from SD card).
If you only want to encrypt the data traffic you can ignore invalid certificate (AT+SSLOPT=0,0) as you will recieve publickey nevertheless. But if you want to be sure about server authenticity you will need to upload right certificate to module.

Is there any SSL handshakes when trying to load https://localhost from browser on local machine?

I have Local Webserver that configured to use SSL connection.
The question is - would there be any handshakes if i try to open https://localhost from any browser?
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys. But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
So, does handshake really happens, but on the upper OSI level? Or it doesnt happen at all, and there are no derive key creation?
Would there be any handshakes if i try to open https://localhost from any browser?
Yes,
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys.
No. It requires a certificate, and a premaster secret, and mutual negotiation of a master key from which session keys are derived. All this is irrelevant.
But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
Wireshark can't see loopback packets.
So, does handshake really happens
Yes.
but on the upper OSI level?
SSL happens in the application layer of the TCP model. The OSI model does not apply to TCP/IP. TCP/IP has its own model.
Or it doesn't happen at all
It does.
and there are no derive key creation?
There is creation of a pre-master secret, a master secret, and a session key. You seem to have some misconception of this process, but again it isn't relevant.

TCP protocol instead of SSL/TLS in Wireshark

I am trying to use .NET implementation of SslStream by this tutorial.
I did everything like in this article, but I have some question. I downloaded RawCap and captured packets from the localhost, after that I opened dump file(.pcap) using Wireshark, but instead of SSL or TLS type of protocol, I saw just TCP: Here is the part of the TCP stream:
....l...h..T...........Y.2..1...t.4....8.J...../.5...
.......
.2.8.......'..............SslServer.
......................M..T...M.<.......e.E...M.%c...Kg.. .....iKku.^q(C.$..;..Mx......g&./..................0...0.............L.^..F.)...{.0...+......0.1
0...U....MyCA0..
150228143257Z.
391231235959Z0.1.0...U....SslServer0.."0
..*.H..
..........0..
......p9.cq...F.^....Bm...S... .....Bg.B.<]..f[...<...q'..Tc......R...Z.C.D.D...N...1..0.v..l.<...d[=C.7.8.+^..j(...X.........D'.!*5.^.^Ef..=.6y#.=..)|...Sp..Sv.|h.-..UT..&bG.......J{.7k.X...........:.[o....o.,r.......0..Wi.s..8.Jn9........4...WU....fkmw..........D0B0#..U...907..m.....#..
...f...0.1
0...U....MyCA..(J..j+..K......0...+...........h..X.+.M..{...n.....#.'.F........~....#9J.......A4,>.9.DE.R.V4t._bGY.,v.>G......J ....3....#..c,%[S._..u...$....!V.r....~...'.~..T*[.#[.?.B{..Z..m.p.9.7.U.u.}.e..c..H^n.:...-AJxs.. ...:...
..u.....YB....2n...y.g=...(.Fv...B.Is..GK.....;.F..Ln.....L...ao
......#...q0o1.0...U....SE1.0...U.
..AddTrust AB1&0$..U....AddTrust External TTP Network1"0 ..U....AddTrust External CA Root..0..1.0...U....US1.0...U.
.
GeoTrust Inc.1907..U...0(c) 2008 GeoTrust Inc. - For authorized use only1604..U...-GeoTrust Primary Certification Authority - G3.g0e1.0...U....US1.0...U.
Is this correct SSL/TLS stream? And why Wireshark marked it like TCP?
UPD:
By default Wireshark uses TCP port numbers to know if this is standard TCP or TLS/SSL.
If you want to make Wireshark permanently recognize any port as SSL/TLS, then go to Edit > Preferences > Protocols > HTTP > Under SSL/TLS Ports change it from 443 to 443,5555, ... <other TLS/SSL ports go here>.
Also note that SSL traffic is encrypted, and that is why you won't be able to see the actual data being transmitted. If you want Wireshark to decrypt SSL traffic, then you will have to give it your server's private key (reference SSL dissection in Wireshark)

Sniffing https/SSL traffic with Burp Suite Proxy in combination with Wireshark

What I'm trying: to sniff all packets, including encrypted, from an iDevice.
What I use: Burp Suite Proxy which generates a CA-signed per-host certificate and Wireshark for all other traffic.
What isn't working: The Burp Suite Proxy does not capture all traffic, Wireshark does. But I can't get Wireshark to decrypt https-sessions.
What I've tried: I tried to create a self-signed certificate and use it with Burp Suite Proxy and Wireshark. I managed to decrypt some traffic both with Burp Suite Proxy as well as Wireshark. The problem is that in case I use a self-signed certificate some handshakes fail, this does not happen if I use the CA-signed per-host certificates that Burp Suite Proxy automatically creates. The problem is that I can't extract private keys from those certificates for Wireshark.
Can anyone push me in the right direction?
Sometimes device apps check for the signature of the certificate, so maybe that's the reason it's not working.

Is data sent from the server also encrypted in HTTPS/SSL?

I'm using wireshark and then opening gmail and hotmail to see if I can see the HTML text sent from server to client, but I couldn't find it! Is it encrypted? I knew HTTPS encrypts client packets -- not both!
Please tell me what is wrong with my information.
HTTPS is HTTP over SSL/TLS, where SSL/TLS encrypts the connection in both directions.
During the SSL/TLS handshake, shared keys are negotiated (via the negotiation of a master secret): you get a client write key and a server write key, as described in the TLS specification (Key Calculation).
Yes. In SSL you and the server both have a public and a private key which is used to encrypt/decrypt sent and received data.