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>
(cherry picked from commit
f7aa318552c4ef62d902c480b59bd7c4513c0009)
Conflicts:
ssl/ssl_locl.h
# define SSL_CLIENT_USE_TLS1_2_CIPHERS(s) \
((SSL_IS_DTLS(s) && s->client_version <= DTLS1_2_VERSION) || \
(!SSL_IS_DTLS(s) && s->client_version >= TLS1_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)
/* Mostly for SSLv3 */
# define SSL_PKEY_RSA_ENC 0
}
skip_ext:
- if (SSL_USE_SIGALGS(s)) {
+ if (SSL_CLIENT_USE_SIGALGS(s)) {
size_t salglen;
const unsigned char *salg;
salglen = tls12_get_psigalgs(s, &salg);