3
$\begingroup$

I have an application using TLSv1.2 for communication. I use the option -Djavax.net.debug=all

Cipher Suites: [TLS_DHE_DSS_WITH_AES_128_CBC_SHA]
Compression Methods:  { 0 }
Extension signature_algorithms, signature_algorithms: SHA512withECDSA,SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
Extension renegotiation_info, renegotiated_connection: <empty>
***
[read] MD5 and SHA1 hashes:  len = 74

I do not quite understand this output.

  1. The client sends the cipher suites it wants to use, and the signature algorithms extensions correspond to that cipher suite?

  2. I also do not understand the [read] MD5 and SHA1 hashes: len = 74 why is the length of the message equal to 74 ?

$\endgroup$
  • $\begingroup$ The cipher suite specifies the signature algorithm the public key in the certificate uses. The signature_algorithms extension specifies the signatures in the certificate chain. $\endgroup$ – SEJPM Oct 11 '16 at 18:47
3
$\begingroup$

Although you don't say so, this appears to be a server-side log; your 'application' is accepting a connection from something else which is the client.

Yes, the client sends the list of ciphersuites it supports and is willing to use in ClientHello; this is usually more than one (often 10 to 20 and sometimes over 50) but it can be one as in your example. However offering only suite(s) using DHE-DSS requires the server to have a DSS (aka DSA) certificate, which is rare on the public Internet, although it may be more common in intranets (especially in the US government). See rfc 5246 section 7.4.1.2 which is not materially changed in this area from earlier versions. Each ciphersuite that uses certificate authentication (not anonymous or pure PSK,SRP,Kerberos) defines the type of publickey in the server (EE) certificate, and thus the 'raw' signature algorithm (except for plain-RSA which doesn't sign at all) but not the associated hash.

In TLS1.2 only, the client MAY include the signature_algorithms extension indicating what types of signatures it supports verifying. If used, this constrains both the signature done by the server on ServerKeyExchange if ephemeral (and DHE-DSS is), and the signatures on the certificates in the server's chain (except the root/anchor if present, since verify it is meaningless). If not used in TLS1.2, the server assumes the signature type implied by the ciphersuite, and SHA1; see section 7.1.4.1. Also if used, the rare static (EC)DH ciphersuites which formerly constrained the second (CA) certificate key type no longer do so; see section 7.4.2.

Earlier versions of TLS did not have signature_algorithms; the server's signature on ServerKX always used a nonstandard combination of SHA1+MD5 for RSA and SHA1 for DSA and ECDSA, and the certificate signatures were not specifically constrained but prior to 2015 in practice almost always used SHA1 or MD5. MD5 is now considered broken for certificate signatures and prohibited by nearly all reliers (browsers and clients). The standard for DSA, FIPS 186, did not even allow it to use any hash other than SHA1 until 2009, and it took some time after that for most implementations to follow suit.

For completeness, if client authentication is used in TLS 1.2, the client signature in CertVerify if ephemeral, and certificate signatures, are constrained by a similar field supported_signature_algorithms (required, not extension) in CertificateRequest, and also by the certificate (and key) chosen which is constrained by the certificate_types field; see section 7.4.4. In earlier versions only certificate_types was present, and the CertVerify signature used the default hashes like ServerKX while the certificate signatures in practice used SHA1 or MD5.

All versions of TLS (back to 1.0) also allow the client to send a supported_curves extension identifying which elliptic curves it supports. If present and an ECDH[E] ciphersuite is negotiated (which can only occur if the client offers it/them) the server must use an ECDH key (point) on a curve on that list; if present and ECDHE-ECDSA keyexchange is negotiated it must use a certificate for (and thus sign ServerKX with) a key on a curve in that list; if present and any ECDSA-signed certificate(s) are used they must use curve(s) on that list. In practice the supported_curves list is often the two formerly-NSA-SuiteB curves, P256 and P384, sometimes extended to add P521.

Aren't you glad you asked :-?

$\endgroup$

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.