I have traffic between clients (which send XML over HTTPS) to my IIS.
I tried to decrypt the traffic using Wireshark and the following settings:
Adding the private key:
But even after setting this, I can't see the decrypted data:
Should I change any other settings to see the original data?
There is strong possibility that a Diffie-Hellman (DH) key exchange is being used here. In that case Wireshark cannot decipher SSL/TLs with a private key. You can check for this in the handshake packet.
From the Docs:
The RSA private key file can only be used in the following
circumstances:
The cipher suite selected by the server is not using (EC)DHE.
The protocol version is SSLv3, (D)TLS 1.0-1.2. It does not work with TLS 1.3.
The private key matches the server certificate. It does not work with the client certificate, nor the Certificate Authority (CA)
certificate.
The session has not been resumed. The handshake must include the ClientKeyExchange handshake message.
Related
I'm looking at this example, and I can see that as part of client authentication the user should pass the --key holding the private key used for certificate signing request to the curl command, I'm not sure why this is needed if it's for encryption shouldn't the public key of the server to be used?
Having the certificate itself doesn't prove anything. Certificate is never secret, can be shared freely and as such multiple parties could be in a possession of a valid client certificate.
As part of the TLS handshake with mutual authentication, client sends CertificateVerify message to prove it also has the private key matching the certificate it sent in Certificate message before. With TLS server already having client's certificate (and thus its public key), it can verify the signature.
In most of the online sources, I was told that in the two way TLS,
the client needs to provide the cert for the server to validate. My
case is that the device gets the cert from the CA, but when the
device attempt establish a tls connection, the pfx is required which
will contain the private key from the device.
I have used openssl to convert the pfx to .cert and .key. By only using the .cert part on
POSTMAN, I failed to connect to the server with 403. Only when I
include both .key and .cert the TLS 1.2 connection was established.
For the regular TLS (one-way), the private key will never be sent
from the server, but why is the client need to send pfx.
I am setting up a IoT 2-way TLS authentication.
The common way is that both client- and the root (CA) certificate Private Key is RSA.
Now we have devices with limited memory, why we chose to switch to Eliptic Curve Private Keys on the client certificates in the IoT devices. The server certificate remained untouched (RSA).
From my understanding the handshake should succeed. Or do I understand anything wrong? Or do we have to switch the CA certificate to ECC as well?
After a quick test session: It IS possible to use a client certificate with a different private key algorithm than the Root Certificate on the server.
Client: OpenSSL
Server: BoringSSL
I have an existing server that is using the following setting.
The connection to this site uses TLS 1.2 (a strong protocol), RSA (an
obsolete key exchange), and AES_128_CBC with HMAC-SHA1 (an obsolete cipher).
If I want to change the key exchange and cipher, do I need to get a new certificate?
The cipher is (mostly) unrelated to the certificate. Given that you are using a RSA certificate (since otherwise RSA key exchange would not be possible) you can switch to ECDHE key exchange. And instead of AES-128-CBC you might use AES-128-GCM or AES-256. For useful configurations you might use the Mozilla SSL Configuration Generator.
My server may be attached to a RSA or ECDSA certificate.
In my code I set the prtocol method as
sslmethod = SSLv23_server_method();
and setting the cipher using the SSL_CTX_set_cipher_list() API.
The problem is when the server is attached to ECDSA certificate and if I pass "RSA" cipher SSL_CTX_set_cipher_list() does not return any error though "RSA" cipher is not compatible with ECDSA certificates.
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
If you author the app and own the server, then YES, you do know what to expect. But the general case is NO, you don't know in advance and you can't query for it. You try to setup a channel and if it fails, then you try something else.
Generally speaking, there's no way to know in advance what cipher suites a server supports; or what type of public key is bound in the server's certificate. In fact, there's no way to know what protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, etc) a server supports. Its the reason for RFC 7405, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks.
In 2016/2017, about the best you can do is assume:
No SSLv2, SSLv3; only TLS 1.0 and above
Cipher suites from the collection "HIGH:!aNULL:!kRSA:!RC4:!MD5"
"!kRSA" is "no RSA key transport", and it means you can only use ephemeral key exchanges. If a server has a RSA key, then it will only be used for authentication. That is, the key will be used to sign the server's ephemeral values during key exchange so the client knows they are authentic.