According to RFC client sends premaster secret encrypted with RSA public key of the server. But when they are using ECDHE as asymmetric algorithm, client key exchange message will contain the pulic key of the client. If this is the case ? when will the client send premaster secret and how ?
when will the client send premaster secret and how ?
It won't. See #8.1.2:
A conventional Diffie-Hellman computation is performed. The negotiated key(Z) is used as the pre_master_secret.
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.
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.
I understand that TLS handshake is done at the beginning of a session and is mainly about generating the symmetric key that is used to encrypt all later communications.
once the handshake is completed, then how often this handshake should happen (regenerate symmetric key) ?
where the symmetric key is stored on client side(browser) ?
how the server identifies the client on server side ?
When the Client sends the change cipher spec message before the handshake is finished, does he send it encrypted with the new key or with the public key of the server?
So, for example:
cipher suite= TLS_RSA_WITH_AES_128_CBC
Does the Client send the change cipher spec message encrypted with RSA and the PU of the Server or does he send it with AES and the master_key?
What I want is test tls handshake when psk is active.
I also want to see every http header exchanged during the connection between client (my laptop) and public server.
Now I am wondering if there is a public psk tls server where I can do my test.
Regards.
I doubt that there is a web server using PSK on the internet open for public testing. Also I doubt that browsers support PSK cipher suites. But you can setup your own web server using PSK with openssl:
openssl s_server -psk 1a2b3c4d -nocert -www
And the matching client:
openssl s_client -connect 127.0.0.1:4433 -psk 1a2b3c4d
As for the HTTP protocol: it is independent from the TLS layer, i.e. it does not change if PSK or the normal authentication with certificates is used.
Even if some public TLS Server were to support PSK, you won't be able to test your client with it. There is a fundamental difference between the way public key authentication (which is used by most of the TLS Servers) work and PSK.
Public Key Authentication:
Incase of Public Key Server Authentication (the ones that doesn't involve Client Authentication), the server sends a Certificate, which contains a Public Key and Client encrypts it's pre-master secret and sends it to server which only the server can decrypt. In this way both have the same pre-master secret and can use the same set of derivations to further derive the final key.
Pre-Shared key:
As the name indicates the pre-shared requires both parties to have the same key pre-shared among themselves. They just exchange the IDs between them to indicate which of the Pre-Shared they will be using to generate the final key.
So, even if there is a server which supports PSK, you should have the same set of (or atleast one) of the keys which it has, which is impossible as those servers won't share their keys with anyone apart from whom it is supposed to be shared with (the legit clients).
So, the best way for you is to use openssl's test client and server tools and test it.