3 ms·
Never mind, apparently encrypted extensions is only sent by the server to the client, not the other way around.
by rocqua 8y ago
Never mind, apparently encrypted extensions is only sent by the server to the client, not the other way around.
- nashvillecactus 8y agoI think you got it right the first time, server_name is referring to SNI in this context: https://tools.ietf.org/html/rfc8446#page-37 https://tools.ietf.org/html/rfc8446#page-37 Specifying which extensions are encrypted is part of the ClientHello. Encrypted Extensions are supposed to be sent directly after the client receives ServerHello. With that said, I don't think we'll see implementations of encrypted SNI in the wild any time soon. From the ietf draft on encrypted SNI: DISCLAIMER: This is very early a work-in-progress design and has not yet seen significant (or really any) security analysis. It should not be used as a basis for building production systems.
- rocqua 8y agoThat table is what I based my first post on. However, as far as I can find out, Encrypted Extensions are only ever send by the server to the client. [1] The SNI that most people care about encrypting are those sent from the user to the server. [1] https://tools.ietf.org/html/rfc8446#page-120 https://tools.ietf.org/html/rfc8446#page-120
- nashvillecactus 8y agoOkay, I see what you mean. Apparently I need to read more, because that completely flies in the face of how I thought this whole thing worked.