Re: [openssl-users] DTLS handshake in WebRTC
The last bit of information makes my life a little hard. In DTLS-SRTP usage, the DTLS server must present it's server fingerprint in SDP before the client support ciphersuites are known, how can a DTLS server support clients that may support only RSA or ECDSA? Suman > On Mar 1, 2017, at 4:01 PM, Matt Caswell wrote: > > > > On 01/03/17 23:52, Suman Paul wrote: >> 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? > > Yes, this is expected. The ciphersuite selection is limited by the > available server certificate(s). That is different to the client > certificate which is independent of the ciphersuite. > > Matt > > >> >> Suman >> >>> On Mar 1, 2017, at 1:51 AM, Matt Caswell >> <mailto:m...@openssl.org> >>> <mailto:m...@openssl.org <mailto:m...@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 >>>> <mailto:m...@openssl.org> >>>>> <mailto:m...@openssl.org <mailto:m...@openssl.org>> >>>>> <mailto:m...@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 >> >> >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > <https://mta.openssl.org/mailman/listinfo/openssl-users> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS handshake in WebRTC
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 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 >> <mailto:m...@openssl.org> >>> <mailto:m...@openssl.org <mailto:m...@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> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS handshake in WebRTC
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 Mar 1, 2017, at 1:33 AM, Matt Caswell 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 > <https://mta.openssl.org/mailman/listinfo/openssl-users> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] DTLS handshake in WebRTC
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). Can someone educate me as to why same kind of key is not required at both ends? Thanks Suman -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] DTLS Server with support for both EC and RSA keys
Hi, I have a server that implements DTLS using OpenSSL 1.0.1 but supports only RSA keys as of today. I want to add support to this server to accept EC keys to be able to implement the newer ECDHE-ECDSA cipher suites while retaining support for RSA. Any pointers as to how to go about this? What I believe is that each kind of key would need a different SSL_CTX object. So I want to switch to the correct context for the SSL session as per the cipher supported by the client (maybe from the cipher list advertised in the ClientHello). Is that the best way of implementing this? Thanks Suman -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
