2

I am trying to get a grasp on different stages of SSL. I have referred to some fantastic answers about how SSL/TLS works and specifically about authentication mechanisms, and numerous other sources.

But I am still confused about this: what does Au=ECDH mean for a cipher such as ECDH-ECDSA-AES256-SHA. From the cmd line:

ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1

What I understand is that the server's certificate will have the DH public key (since this is fixed DH). The certificate will be signed by the CA. So what role do DSS (aka DSA) keys play here? Does the certificate have a DSS signature?

Secondly, since authentication is DSS, why say Au=ECDH?

EDIT: If you have suggestions for a good resource to read specifically about Authentication mechanisms in SSL, I would appreciate it.

sandyp
  • 1,126
  • 1
  • 9
  • 17
  • possible duplicate of [Client-server encryption technique explanation (TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, 128 bit keys)](http://security.stackexchange.com/questions/65622/client-server-encryption-technique-explanation-tls-ecdhe-rsa-with-aes-128-gcm-s) – RoraΖ Jun 24 '15 at 16:09
  • The above is a different question. My question is specific to Au=ECDH. – sandyp Jun 24 '15 at 16:15
  • (bump this thread) – sandyp Jun 25 '15 at 22:43

2 Answers2

1

Taken from RFC4492 Section 2.1

2.1. ECDH_ECDSA

In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA.

A ServerKeyExchange MUST NOT be sent (the server's certificate contains all the necessary keying information required by the client to arrive at the premaster secret).

The client generates an ECDH key pair on the same curve as the server's long-term public key and sends its public key in the ClientKeyExchange message (except when using client authentication algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the modifications from Section 3.2 or Section 3.3 apply).

So in this case the server's provides a DSA certificate containing an ECDH capable public key that's signed with ECDSA. So to answer your first question, the server must be signed with ECDSA. The authentication (Au) for the key exchange is still verified with ECDSA. I could be wrong, but I think this might just be an error in OpenSSL's parsing.

RoraΖ
  • 12,347
  • 4
  • 51
  • 83
1

For static/fixed ECDH or static DH, like plain-RSA (akRSA), server proof-of-possession is implicit by having keyexchange correctly produce Finished. OpenSSL apparently indicates this by using the KX algorithm for the Au= algorithm, since there isn't really a specific algorithm used for authentication. Note OpenSSL implements static (non-EC) DH only very recently, since 1.0.2 in 2015/01, so you may not have seen Au=DH cases.

Also note that for TLSv1.2 the former restrictions on the CA-cert keytype matching the ciphersuite or the CertReq message (if used) are removed, instead the new SignatureAlgorithms extension controls this. See the text after the table in rfc5246 7.4.2 compared to earlier versions, and 7.4.6 and for ECC changes to rfc4492.

dave_thompson_085
  • 10,064
  • 1
  • 26
  • 29