5

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?

Community
  • 1
Secu Noob
  • 53
  • 1
  • 4

3 Answers3

5

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 1
    One possible source of confusion is that https://www.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
  • @dave_thompson_085 When I do this today, I get the same certificate with either request. How is that possible? – subtleseeker Aug 03 '21 at 03:29
  • 1
    @subtleseeker: please don't ask a new question inside a comment, especially not on a 5 year old question. In short: the protocol now used is TLS 1.3 where ciphers no longer speciify the pubkey algorithm of the certificate. If you want to know more please ask a completely new question with sufficient detail. – Steffen Ullrich Aug 03 '21 at 05:09
3

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 Diffie-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.

Bruno Rohée
  • 5,221
  • 28
  • 39
Xander
  • 35,525
  • 27
  • 113
  • 141
  • 1
    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.

sandyp
  • 1,146
  • 1
  • 9
  • 17