Per RFC 5246,
Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand.
Although second sentence would suggest that there would be no interop
problems in always offering the extension, WebRTC has reported issues
with Bouncy Castle on < TLS 1.2 ClientHellos that still include
signature_algorithms. See also
https://bugs.chromium.org/p/webrtc/issues/detail?id=4223
RT#4390
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
# define SSL_CLIENT_USE_TLS1_2_CIPHERS(s) \
((!SSL_IS_DTLS(s) && s->client_version >= TLS1_2_VERSION) || \
(SSL_IS_DTLS(s) && DTLS_VERSION_GE(s->client_version, DTLS1_2_VERSION)))
+/*
+ * Determine if a client should send signature algorithms extension:
+ * as with TLS1.2 cipher we can't rely on method flags.
+ */
+# define SSL_CLIENT_USE_SIGALGS(s) \
+ SSL_CLIENT_USE_TLS1_2_CIPHERS(s)
# ifdef TLSEXT_TYPE_encrypt_then_mac
# define SSL_USE_ETM(s) (s->s3->flags & TLS1_FLAGS_ENCRYPT_THEN_MAC)
}
skip_ext:
- if (SSL_USE_SIGALGS(s)) {
+ if (SSL_CLIENT_USE_SIGALGS(s)) {
size_t salglen;
const unsigned char *salg;
unsigned char *etmp;