Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: crypto/tls: make server name extension optional #28754
The current tls stack will always send the server name extension to the server. And the
It is well know that the server name extension is transfer in plaintext. So we should only transfer them if we do need them. As we can put multiple domain name into one certificate, the SNI Extension should not be needed widely, and make sending them as a default behavior seems not a good choice.
I propose to introduce an option like
RFC 8446 upgraded server_name to Mandatory To Implement (Section 9.2) and depending on how you read made it a SHOULD or a MUST to send it as an HTTP client.
As an ecosystem position, we struggled for years with low SNI adoption, and now that it's ubiquitous it finally enables packing multiple websites on depleting IPv4s without tradeoffs. IPv6 is not even close in adoption. Now is not the time to roll SNI back.
Even if the server you are contacting doesn't require SNI now, not sending it puts it in a difficult position should it decide to start depending on it later. I don't think we should make it easy.
If you really want to defeat it, there is a way: unset
hi @FiloSottile , thank you for reviewing this propose.
As far as i see, the RFC doe not require the client always send the SNI extension, does it?
What the RFC require is both the server and client must implement the SNI extension, but not the client must always send the SNI information.
And the RFC also reads
The when applicable here should not be always or must.
And, this propose just make the tls ecosystem has the ability to not always send the SNI extension, but not recommend to use it. However, why the SkipSNI is needed? Because, the server name is transferred in the plain text and could be used by some government for auditing.
Introduce the SkipSNI option does not break the RFC, does not break widely-SNI-adopt ecosystem, but protect user's privacy. So i beg you to reconsider this proposal.
People in certain country need your help.
I understand the purpose of this option, and I respect it, however if an option is made visible in
SNI stops being useful as soon as even a small percentage of clients don't send it, because if the server can't afford to break those clients it can't start hosting multiple sites on the same IP.
As I mentioned, applications that are sure they need to remove SNI (like anti-censorship applications) can use
I do not think the see-it-and-enable-it style make sense. For example, user also see the MinVersion and set it to a higher verson like TLS1.3, and the server with only TLSv1.2 support will be break. Besides, the SkipSNI is closed by default. Setting it to be true without thinking just like write loop without a break condition.
And the RFC also reads
If the server depends the SNI extension, it should alert the "missing_extension".
Setting InsecureSkipVerify and VerifyPeerCertificate is the recommended way to customize and override certificate validation. However, there is boilerplate involved and it usually requires first reimplementing the default validation strategy to then customize it. Provide an example that does the same thing as the default as a starting point. Examples of where we directed users to do something similar are in issues #35467, #31791, #28754, #21971, and #24151. Fixes #31792 Change-Id: Id033e9fa3cac9dff1f7be05c72dfb34b4f973fd4 Reviewed-on: https://go-review.googlesource.com/c/go/+/193620 Reviewed-by: Adam Langley <firstname.lastname@example.org>