3

I'm trying to understand the SSL/TLS protocol and I'm lost on a specific point.

What is the link between the public server key (eg. : "EC 256 bits" or " RSA 2048 bits") and the cipher suites ?

This post give an answer : SSL certificates and cipher suites correspondence but when I try to analyse cipher suites for https://www.wikipedia.org, there is something illogical to me. wikipedia.org has an EC 256 bits key and TLS_RSA_WITH_AES_128_CBC_SHA is an accepted cipher suite. According to this post SSL certificates and cipher suites correspondence (if I understand it correctly) it should not be possible because

" For TLS_RSA_* cipher suites, key exchange uses encryption of a client-chosen random value with the server's RSA public key, so the server's public key must be of type RSA, and must be appropriate for encryption (the server's certificate must not include a Key Usage extension that says "signature only"). "

So, why can we use TLS_RSA_WITH_AES_128_CBC_SHA on wikipedia?

1

wikipedia.org has an EC 256 bits key and TLS_RSA_WITH_AES_128_CBC_SHA is an accepted cipher suite. According to this post SSL certificates and cipher suites correspondence (if I understand it correctly) it should not be possible

Actually wikipedia.org has both ECDSA and RSA certificates and uses these depending on which ciphers the client offers. When the client supports ECDSA ciphers you get the EC256 certificate:

 $ openssl s_client -connect www.wikipedia.org:443 -cipher 'ECDSA' |\
     openssl x509 -text -noout
 ...
    Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
            Public-Key: (256 bit)

If instead your are enforcing ciphers with RSA authentication you get a different certificate which uses a RSA 2048 key:

 $ openssl s_client -connect www.wikipedia.org:443 -cipher 'RSA' |\
     openssl x509 -text -noout
 ...
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)

Such setup is not uncommon since ECDSA offers better performance with the same security but not all clients support ECDSA yet. A setup with dual certificates is not supported by all web servers but you have support in widely used servers like nginx and apache.

  • One possible source of confusion is that ssllabs.com/ssltest tests each ciphersuite separately but displays information about only one server certificate (with multiple trust paths for that one cert if applicable), so its report can list both RSA-cert and ECDSA-cert suites while showing a cert consistent with only some suites. Other 'scan' tools may be similar. – dave_thompson_085 Aug 10 '16 at 13:32
2

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite uses RSA for both authentication and key exchange. Key length is not specified, but the current standard is 2048 bit RSA keys, so that is likely what is used in this case.

For other ciphersuites, you may see components that differentiate between the key exchange algorithm and the authentication algorithm. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 would be an example of this, where ECDHE (Elliptic Curve Diffe Hellman Ephemeral) is the key exchange algorithm, but the key in the certificate is for the Elliptic Curve Digital Signature Algorithm.

So, if the ciphersuite being used for your TLS session was TLS_RSA_WITH_AES_128_CBC_SHA, it was for an RSA certificate, not an ECDSA certificate. You would have needed to use a different ciphersuite in that case.

  • I understand that the key exchange algorithm has no dependancy with the format of the key (eg. : "EC 256 bits" or " RSA 2048 bits or ...), but there is a dependancy between the authentication algorithm and the format of the key (with an EC key you can't use a cipher suite with RSA authentication). Am-I right? – Secu Noob Aug 10 '16 at 10:08
  • @SecuNoob Yes, your understanding is correct. – Xander Aug 10 '16 at 13:13
1

Too long for a comment so posting here.

I just did this so not sure what you are referring to:

$ openssl s_client -connect www.wikipedia.org:443

---                                                                                                                        │ SSL handshake has read 3278 bytes and written 441 bytes             

│In [12]: (1072759 + 626961)*8

--- │ New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
│Out[12]: 13597760 Server public key is 256 bit
│ Secure Renegotiation IS supported
│In [13]: from marathon_test Compression: NONE
│marathon_test Expansion: NONE
│ No ALPN negotiated
│In [13]: SSL-Session:

Remember that the server might advertise compatibility to different protocols (such as RSA that you highlight). The agreed upon protocol is one of the several that both client and servers support.

  • Thanks! Whats looks strange to me was that TLS_RSA_WITH_AES_128_CBC_SHA is possible but the certificate key is not a RSA key : it is an EC key. – Secu Noob Aug 10 '16 at 7:08
  • Not sure about the downvote here? It echoes pretty much what got accepted. – sandyp Aug 10 '16 at 19:24
  • I don't know why there is a downvote here. Not coming from me! – Secu Noob Aug 10 '16 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.