| Sorry, I meant to say when the client sends its certificate, firefox in this case, it has a key of type ECDSA. How does a key of this type work when the cipher selected is of type RSA?
Suman
On 01/03/17 05:55, Suman Paul wrote:I have been looking at WebRTC DTLS handshake and don’t understand the
logic of how it works.
My Firefox client has support for both RSA and ECDSA ciphers while my
DTLS server only supports DHE-RSA-AES128-SHA and has a RSA key. I see
that Firefox sends a ECDSA key during client hello. What ends up
happening is that DHE-RSA-AES128-SHA is selected. I would have
expected the negotiation to fail due to there being no common
ciphers.
I also verified this behavior using the OpenSSL s_server and s_client
utilities. Seems to me that as long as s_server has a cert and key of
the type of cipher I enforce with ‘-cipher’ option the negotiation
succeeds irrespective of the type of key the s_client (provided that
cipher is also supported by the client).
Your terminology is slightly confusing. No keys are sent in theClientHello at all. You should see a list of all the ciphersuites thatthe client supports being sent in the ClientHello and then the servershould respond with a ServerHello which picks a ciphersuite from that list.Matt-- openssl-users mailing listTo unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
|
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
