[openssl-users] DTLS handshake in WebRTC

[Suman Paul]

What I have seen in my trials with s_server and s_client is that if run s_server with an ECDSA cert/key and I specify one RSA and one ECDSA cipher with the -cipher option, then s_client can only connect to it using the ECDSA cipher. I have been unsuccessful in connecting to this server using a RSA cipher. RSA cipher fail shows up at the s_server as 

140480482967256:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1417:

Your thoughts on this?

Suman

> On Mar 1, 2017, at 1:51 AM, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
> 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>
>>> <mailto: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
>> 
>> 
>> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users <https://mta.openssl.org/mailman/listinfo/openssl-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170301/cc9c0990/attachment-0001.html>