2

This question is a bit of a follow on to this Q&A:

TLS 1.2 Handshake: Does the server have to take all extensions sent by the Client?

If the client sends an Extension that the server does not recognize, the server can simply ignore it and continue with a Server Hello -- the client is then free to terminate the session if that particular extension was required by the client, or continue the handshake without that extension.

My question: Are there any TLS Extensions which some servers might choose to require, thereby responding to a Client Hello which doesn't include those extensions by terminating the session?

Granted, this could be different on a deployment by deployment basis, but if there are some extensions that might be lend themselves to being required by the server, they would suffice as the answer to this question.

Eddie
  • 751
  • 1
  • 6
  • 21
  • This feels a bit like an [XY Problem](https://xyproblem.info/). Is purely a question for academic curiosity, or do you have some concrete problem you're trying to solve? (and if so, what are you trying to do?) – Mike Ounsworth Feb 23 '21 at 04:40
  • @MikeOunsworth I'm trying to fully understand the behavior of Extensions in TLS. I understand the Client initiates extensions in the Client Hello, and that the Server can respond omitting extensions it doesn't support -- leaving it to the Client to decide whether to continue the handshake or not. I'm trying to understand if the Server has the option to require any Extensions as well. Obviously, I know a Server *can* be programmed as such, but I'm trying to see if that actually occurs in real life. – Eddie Feb 23 '21 at 04:57
  • 1
    @Eddie: I'm not sure if this fits your question, but it is pretty common that a server will croak if the client does not send the `server_name` extension (SNI) or if this extension contains a name which is not configured at the server. This is not actually about requiring the extension itself, but since the server otherwise cannot send the appropriate certificate matching the requested name. – Steffen Ullrich Feb 23 '21 at 05:31
  • @SteffenUllrich Yes, that is absolutely a possible answer. What does the Server do at that point? Just send a generic Handshake Failure alert? Or would Unsupported Extension apply? Or Unrecognized Name? – Eddie Feb 23 '21 at 05:52
  • 1
    @Eddie: It is not uncommon to just get a generic handshake failure or even simply a close of the underlying TCP connection on any kind of TLS related errors, even if there would be in theory a more specific TLS alert. But I've also seen unrecognized name. Unsupported extension instead would not be a good fit for such a problem, since it is about the (missing) value and not about an unknown extension. – Steffen Ullrich Feb 23 '21 at 05:55
  • @SteffenUllrich Good call about Unsupported Extension not applying. As for resetting the TCP connection, wouldn't that simply prompt the Client to try again (as if it were simply a network error)? Otherwise, if no one else chimes in with other occasions where the Server will require a specific extension in the next few days, please feel free to turn your comment into an Answer to get the Green Check mark =) – Eddie Feb 23 '21 at 17:10
  • @Eddie: *"... wouldn't that simply prompt the Client to try again (as if it were simply a network error)?"* - a TCP connection close is different from a network error. It is an explicit act, not just some packet loss. – Steffen Ullrich Feb 23 '21 at 17:56
  • 1
    @SteffenUllrich+ I've answered at least a dozen Qs on several Stacks over the last few years "why does my program/system fail to connect with TLS (or HTTPS)" and the answer is "missing SNI". IIRC most of them were alert 40 but some were RST or even FIN. – dave_thompson_085 Feb 24 '21 at 03:20
  • During the Apache-splice furor a decade ago I saw some servers reject connections without rfc5746 (which can be offered _either_ as an extension or a SCSV), but now everybody implements it. I can imagine a server rejecting a 1.2-or-lower connection for lacking extended_master_secret and/or encrypt_then_mac, which logically should be alert 71, but I haven't seen it. – dave_thompson_085 Feb 24 '21 at 03:23

0 Answers0