[openssl-users] DTLS handshake in WebRTC

[Matt Caswell]

On 01/03/17 09:39, Suman Paul wrote:
> 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?

Ah, right - you are using client auth. The choice of client certificate
has nothing to do with the underlying ciphersuite - it is chosen
independently. When client auth is in use you should see the server
sending a CertificateRequest message to the client. That
CertificateRequest contains within it the list of acceptable certificate
types.

Matt

> 
> Suman
>> On Mar 1, 2017, at 1:33 AM, Matt Caswell <matt at openssl.org
>> <mailto:matt at openssl.org>> wrote:
>>
>>
>>
>> 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 the
>> ClientHello at all. You should see a list of all the ciphersuites that
>> the client supports being sent in the ClientHello and then the server
>> should respond with a ServerHello which picks a ciphersuite from that
>> list.
>>
>> Matt
>> -- 
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
>