Timeline for Are there any TLS Extensions that a server can *require* the client send?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 24, 2021 at 3:23 | comment | added | dave_thompson_085 | 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. | |
| Feb 24, 2021 at 3:20 | comment | added | dave_thompson_085 | @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. | |
| Feb 23, 2021 at 17:56 | comment | added | Steffen Ullrich | @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. | |
| Feb 23, 2021 at 17:10 | comment | added | Eddie | @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 =) | |
| Feb 23, 2021 at 5:55 | comment | added | Steffen Ullrich | @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. | |
| Feb 23, 2021 at 5:52 | comment | added | Eddie | @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? | |
| Feb 23, 2021 at 5:31 | comment | added | Steffen Ullrich |
@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.
|
|
| Feb 23, 2021 at 4:57 | comment | added | Eddie | @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. | |
| Feb 23, 2021 at 4:40 | comment | added | Mike Ounsworth | This feels a bit like an XY Problem. 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?) | |
| Feb 23, 2021 at 1:49 | history | asked | Eddie | CC BY-SA 4.0 |