| 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 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 theavailable server certificate(s). That is different to the clientcertificate which is independent of the ciphersuite.Matt
Suman
On Mar 1, 2017, at 1:51 AM, Matt Caswell <matt@xxxxxxxxxxx
<mailto:matt@xxxxxxxxxxx>> 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@xxxxxxxxxxx
<mailto:matt@xxxxxxxxxxx>
<mailto:matt@xxxxxxxxxxx>> 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 listTo unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
|
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
