-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto/tls: Allow sending unrecognized_name alert from GetCertificate #18377
Comments
Seems reasonable. @agl? |
I suppose the bigger question is why this matters to you. How did this come up? Do clients & servers implement this in the wild? |
They will: caddyserver/caddy#1303 (comment) With this change, the browser will have a specific kind of error message to display for the user rather than making it look like TLS is broken on the server. Mostly a "nice to have" feature. :) (To answer your question, it just came up in a discussion about changing how Caddy handles handshakes with server names it does not have a certificate for; right now, like nginx, it will serve a 'default' certificate, but we were thinking of changing it so that it returns a TLS alert rather than what looks like an attack.) |
We could just make a callback error always trigger |
True, but I can also think of countless other types of problems that could occur in more advanced situations of getting a certificate, even if the name is recognized. For example, Caddy is subject to rate limits and, even if its configuration recognizes the name in the handshake, it may not be able to get a certificate for that hostname. In my opinion, that's different than the server not being configured at all to connect with that name. The special error value fundamentally says, "I don't know this identity/name, what are you even doing??" (client's mistake) as opposed to "I know this name, but [something went wrong] and I can't prove it..." (server's mistake) |
But why expose that difference to a client? The fatal alert values are very rough already and few of them are terribly meaningful. If Thus I can see that perhaps |
@estark37 from the Chrome team suggests in this comment that the correct alert value could be used instead of the existing heuristic that triggers for some mismatched certificates. |
(I think Emily was just saying that a fatal alert might be better for users than returning a certificate that's not going to match. But I've asked her to be sure.) |
My main feeling is that an alert is better than a certificate error, and I don't feel too strongly about when |
I knew about the In my opinion, if GetCertificates is configured to fetch files and fails at that, |
This sends an “unrecognized name” alert (112) instead of an “internal error” (80) when no certificate is found. This addresses golang/go#18377.
This sends an “unrecognized name” alert (112) instead of an “internal error” (80) when no certificate is found. This addresses golang/go#18377.
While I am strongly in favour of this proposal, I don't think a sentinel error is the right way to go about this. The
The current behaviour is to emit an This means the current behaviour of "no certificates configured" + Not only do I think this is much cleaner than using a sentinel error, it avoids exporting any of the crypto/tls alert code or internal TLS implementation details - and I think that's actually a really strong positive. It also doesn't require any sort of compatibility guarantee. Obviously a I'm happy to take this on and submit a change for review, if others agree about doing it this way. It's a relatively minor change. |
@tmthrgd I like that proposal. At least, from the perspective of my use case (Caddy), it should fit nicely since we don't use the Certificates field at all. (We make heavy use of GetCertificate). |
Context: toying with a dumb proxy server that uses GetConfigForClient instead of plain GetCertificate due to additional side-effects based on the SNI. |
We can just make unrecognized_name the alert we send whenever there are no certificates available. That can be reached easily both from I would accept a CL that implements that. (Once the tree opens.) |
I'll implement this while reworking certificate selection in #32426. |
Change https://golang.org/cl/205059 mentions this issue: |
RFC 6066 says:
Currently returning an error from the
GetCertificate
hook results in a genericinternal_error
fatal alert. To implement the first action in the RFC, there should be a way to return anunrecognized_name
fatal alert to the client when aGetCertificate
hook is unable to find a certificate for the server name specified in the ClientHello. I propose the addition of a special error variable to thecrypto/tls
package that triggers this alert:The text was updated successfully, but these errors were encountered: