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.
Related
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.
I am trying to decrypt a pcap file. This pcap file contains a capture of an HLS encrypted video stream. The pcap contains TLSv1.2 packets.
Below are some information from the pcap file
Server Hello message Cipher Suite:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
EC Diffie-Hellman server Params: pubkey (1)
The Certificate Status message:
Signature Hash Algorithm Hash: SHA256
Signature Hash Algorithm Signature: ECDSA
Client Key Exchange Message
EC Diffie-Hellman server Params: pubkey (2)
I tried to follow [this Wireshark SSL decryption tutorial][1]. But it seems that it works only for RSA encryptions.
I have been researching for a while and found [this discussion][2]. I am quoting an extract from this discussion:
There is an important parameter to mind: decryption of a passively
recorded session (with a copy of the server private key) works only if
the key exchange was of type RSA or static DH; with "DHE" and "ECDHE"
cipher suites, you won't be able to decrypt such a session, even with
knowledge of the server private key. In that case, you will need
either the negotiated "master secret", or to use the server private
key to actively intercept the connection
It's note worthy that I have the client private key. In my case, the client is FFmpeg video streamer (FFplay). I had a look also on the [TLS v1.2 RFC][3].
My question:
Is it possible to do a decryption in this scenario ? If yes, what do I need to have to do so?
Is the decryption done using the client's private key or using the pre_shared_master (i.e. Diffie-Hellman) ?
[1]: https://wiki.wireshark.org/SSL
[2]: https://security.stackexchange.com/questions/117778/how-to-decrypt-ssl-traffic-with-a-packet-sniffer-when-i-have-the-private-key
[3]: https://www.rfc-editor.org/rfc/rfc5246
First, the clients private or public key are not involved in the key exchange in any way but only used to authenticate the client (if requested by the server). What is used in the key exchange are the servers private and public key, but only if RSA key exchange is used. For DHE/ECDHE they are not used so private/public key are not sufficient. See it is possible to decrypt HTTPS with the (private, public) pair if it uses DHE? for the details why this is the case.
What you would need instead of the private key is actually the exchanged key which is unique for each TLS session even if the private key is the same. Some clients can store this key for later use and if your client can do it see Decrypting TLS Browser Traffic With Wireshark – The Easy Way! how to proceed then to decrypt the traffic.
No, it is not possible to decrypt in this scenario. That would involve breaking EC Diffie-Hellman.
Decryption is not directly performed using the pre_master_secret but it is performed by keys directly derived from the pre-master secret. That is: the client and server decryption keys that are derived from it by first deriving the master_secret and then performing the PRF and dividing the output to the session keys and IV's.
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.
My application capture every packet coming from the server. I can read those packet for HTTP. I want to read the subject field from ssl certificate. But I cant. Is it encoded? If it is, how can I decode & read it?
Assuming that SSL negotiates a protocol that needs certificates, the certificates are generally in ASN.1 based X.509v3 format when they're sent from the server to the client.
From the TLS 1.0 RFC (which is a start if you want to listen to/analyze the protocol);
7.4.2. Server certificate
When this message will be sent:
The server must send a certificate whenever the agreed-upon key
exchange method is not an anonymous one. This message will always
immediately follow the server hello message.
Meaning of this message:
The certificate type must be appropriate for the selected cipher
suite's key exchange algorithm, and is generally an X.509v3
certificate.
I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).
One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.
If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.
If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).
I guess you may encounter a problem whereby:
not presenting a certificate is accepted by the server (it's effectively optional),
presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.