3

What is the expected behavior when a server hello contains an unexpected reply for a TLS extension (e.g. ALPN)?

Should I (as a client) terminate the connection or just ignore the extension? Is it defined in the RFC? Should the behavior be different for different extensions?

5

In the TLS 1.2 RFC Section 7.4.1.4 it says the following:

An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert.

For TLSv1 and TLSv1.1 look to RFC 3546 which applies to both versions.

Section 2.3:

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.

Section 4: Error Alerts

"unsupported_extension" - this alert is sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello (see Section 2.3). This message is always fatal.

  • Is this new to TLS 1.2 or is it also valid for TLS 1.0 for example? – EarthDragon Oct 2 '17 at 13:17
  • @EarthDragon: for 1.0 and 1.1 it was in 3546 rep 4346 section 2.3 (i.e. not in the base protocol document) and didn't specify the alert at that point (but did in sec 4) – dave_thompson_085 Oct 3 '17 at 4:52
  • @EarthDragon+ sorry I mistyped; 4366 is the rfc that 'obsoletes' 3546 and (officially) applies substantively the same extensions (plus added discussion of client-certurl handling) to 1.1=4346 as well as 1.0=2246 according to the text although the heading and rfc-index entry shows only 4346. – dave_thompson_085 Oct 4 '17 at 3:41
1

What is the expected behavior when a server hello contains an unexpected reply for a TLS extension (e.g. ALPN)?

I assume you're when you say "unexpected reply" you're suggesting the server responds with an ALPN "selected protocol" value that isn't among those proposed by the client.

Should I (as a client) terminate the connection or just ignore the extension? Is it defined in the RFC?

While RFC 7301 isn't explicit, I believe that the implicit expectation is that the client should terminate the TLS handshake - just as the server would if it didn't support any protocols that the client advertised:

In the event that the server supports no protocols that
the client advertises, then the server SHALL respond
with a fatal "no_application_protocol" alert.

Should the behavior be different for different extensions?

Different extensions may handle this case differently - the two most common handlers being "abort the handshake" and "ignore the extension attempt." By their very nature, extensions are often tolerant of differing levels of support and implementation maturity.

  • You are specifically answering for the ALPN extension, my question was about a reply to any type of extension that wasn't in the original client hello – EarthDragon Oct 15 '17 at 4:23

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.