HTTPS Server with TLS1.2 using signature algorithm
Reported by
michael....@nexans.com,
May 31 2016
|
||||||||||
Issue description
Chrome Version : 50.0.2661.94
URLs (if applicable) :
Other browsers tested:
Firefox: OK
IE: OK
What steps will reproduce the problem?
1. Sending request to a side which only handle TLS1.2 with signature algorithm extension
2. Chrome send alert.
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unsupported Extension)
Content Type: Alert (21)
Description: Unsupported Extension (110)
What is the expected result?
Show content of the side
What happens instead?
Error page
I believe that this is the problem:
file: t1_lib.c
function: ext_sigalgs_parse_serverhello (Line 1061)
Code:
if (contents != NULL) {
/* Servers MUST NOT send this extension. */
*out_alert = SSL_AD_UNSUPPORTED_EXTENSION;
OPENSSL_PUT_ERROR(SSL, SSL_R_SIGNATURE_ALGORITHMS_EXTENSION_SENT_BY_SERVER);
return 0;
}
I read the RFC 5246 in a different way.
Chapter 7.4.1.4.1 Signature Algorithms Page 46:
"If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by the server, i.e., server
certificates and server key exchange), it MUST send the
signature_algorithms extension, listing the algorithms it is willing
to accept."
Chrome send a list of algorithms. Here it is:
Signature Hash Algorithms (8 algorithms)
Signature Hash Algorithm: 0x0601
Signature Hash Algorithm: 0x0603
Signature Hash Algorithm: 0x0501
Signature Hash Algorithm: 0x0503
Signature Hash Algorithm: 0x0401
Signature Hash Algorithm: 0x0403
Signature Hash Algorithm: 0x0201
Signature Hash Algorithm: 0x0203
In the next paragraph the RFC describe the handle if the client does not send this extensions:
"If the client does not send the signature_algorithms extension, the
server MUST do the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha1,rsa}.
- If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value {sha1,dsa}.
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
Note: this is a change from TLS 1.1 where there are no explicit
rules, but as a practical matter one can assume that the peer
supports MD5 and SHA-1.
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."
I believe that the next paragraph is a part of the handle when a client
does not send the signature_algorithms extension
"Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension."
In Chromium you send a alert.
The RFC 3546 Transport Layer Security (TLS) Extensions describe the
handling of extensions
Chapter 2.3 Hello Extensions Page 5:
"Note that for all extension types (including those defined in
future), the extension type MUST NOT appear in the extended server
hello unless the same extension type appeared in the corresponding
client hello. Thus clients MUST abort the handshake if they receive
an extension type in the extended server hello that they did not
request in the associated (extended) client hello."
,
Jun 20 2016
Hi! Can I have a status update? For us it is critical because your embedded hardware product use this feature and customer using Chrome. Thanks in advance CU Michael
,
Jul 1 2016
,
Jul 1 2016
Could you please include a net-internals log per the following instructions? That will confirm if it is indeed that logic firing or elsewhere. https://dev.chromium.org/for-testers/providing-network-details If it is indeed the signature algorithms extension, you've got client and server backwards. The spec spends a lot of time talking about when and how clients are supposed to send the extension, which we indeed do. It then says quite clearly, as you quote: "Servers MUST NOT send this extension. TLS servers MUST support receiving this extension." That code you quoted is our client rejecting connections when the server incorrectly sends this extension. If your server is indeed doing that, it is not implementing the specification correctly and must be fixed. But first get us the net-internals log to confirm that's what's going on.
,
Jul 4 2016
Hi David!
I send you two files. One is the net-internals.log and the other is a
wireshark capture file.
I already tried to send no answer on the requested extensions but it does
not work.
The problem:
If the client does not send signature_algorithms extension the server have
to the default way
and is not allowed to send the extension to client. But when the client
support other the the
default one, it have to send the algorithms it is willing to accept. And in
that way the server have
to answer, which one it want to use.
You are right in one way. If the client does not send the extension the
server is not allowed to
send this extensions. In the other way it is allowed because the client
have to know which
algorithm it have to use.
I need a longer time to understand the following text.
The other browsers work on this way.
The blue text corespond.
If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by the server, i.e., server
certificates and server key exchange), it MUST send the
signature_algorithms extension, listing the algorithms it is willing
to accept.
If the client does not send the signature_algorithms extension, the
server MUST do the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha1,rsa}.
- If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value {sha1,dsa}.
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
Note: this is a change from TLS 1.1 where there are no explicit
rules, but as a practical matter one can assume that the peer
supports MD5 and SHA-1.
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 <https://tools.ietf.org/html/rfc5246#ref-TLSEXT>]
require servers to ignore extensions they do not understand.
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension.
When performing session resumption, this extension is not included in
Server Hello, and the server ignores the extension in Client Hello
(if present).
,
Jul 4 2016
Thank you for providing more feedback. Adding requester "davidben@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 4 2016
Thanks for the packet trace. That does indeed confirm the problem. Your server does not implement the specification and must be fixed. What software is your server running? We've had this logic in for some time now and this is the first violation I'd ever heard of. > If the client does not send signature_algorithms extension the server have > to the default way > and is not allowed to send the extension to client. Yes, but this is not relevant because we send the extension. > But when the client > support other the the > default one, it have to send the algorithms it is willing to accept. Yes, and we do so. The server, however, still does not send the extension. The spec very clearly says "Servers MUST NOT send this extension." which, again you have quoted. Nowhere in the spec does it say the server should send the extension. In TLS, servers do not have flexibility in the extensions they send, only clients. Clients should fail on anything unexpected from the server because the server is obligated to only send things the ClientHello said would be understood. We enforce such things to keep the ecosystem honest, so new software does not ship with bugs everyone must workaround. > And in > that way the server have > to answer, which one it want to use. The server tells the client which one it wishes to use right before the signature itself, which is in ServerKeyExchange, not ServerHello. See RFC 5246, section 4.7.
,
Jul 4 2016
,
Jul 4 2016
> I already tried to send no answer on the requested extensions but it does > not work. To clarify, did you try sending an empty extension or omitting the extension? You must omit the extension entirely, as the specification prescribes.
,
Aug 5 2016
No feedback was received in the last 30 days from reporter "michael.ott@nexans.com", so archiving this. Please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ranjitkan@chromium.org
, Jun 1 2016