crypto/tls: Allow sending unrecognized_name alert from GetCertificate

[titanous]

RFC 6066 says:

If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake.

Currently returning an error from the GetCertificate hook results in a generic internal_error fatal alert. To implement the first action in the RFC, there should be a way to return an unrecognized_name fatal alert to the client when a GetCertificate 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 the crypto/tls package that triggers this alert:

// ErrUnrecognizedName sends an unrecognized_name fatal alert to the client
// when returned from a GetCertificate hook function call.
var ErrUnrecognizedName = errors.New("crypto/tls: unrecognized server name")

[bradfitz]

Seems reasonable. @agl?

[bradfitz]

I suppose the bigger question is why this matters to you. How did this come up? Do clients & servers implement this in the wild?

[mholt]

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.)

[agl]

We could just make a callback error always trigger unrecognized_name.

[mholt]

We could just make a callback error always trigger unrecognized_name.

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)

[agl]

But why expose that difference to a client? The fatal alert values are very rough already and few of them are terribly meaningful. If unrecognized_name could mean to a client "you might have better luck with a different SNI value" then maybe that's of value, although I'm skeptical. You seem to assume that Chrome would display a different error message for this but I consider that unlikely.

Thus I can see that perhaps unrecognized_name is a better alert when this callback fails, but I'm unsure that we should add complexity to let the callback try and control the alert.

[titanous]

You seem to assume that Chrome would display a different error message for this but I consider that unlikely.

@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.

[agl]

(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.)

[estark37]

My main feeling is that an alert is better than a certificate error, and I don't feel too strongly about when unrecognized_name is sent vs internal_error. Hypothetically, I could imagine a future in which Chrome treats unrecognized_name specially for certain names. But I wouldn't make any plans based on that, as I haven't really thought it through and it would be pretty low-priority (the existing heuristic only fires for a very small percentage of certificate errors).

[Luit]

I knew about the unrecognized_name alert from a server (which appears to be Apache) configured to deny connections for unrecognized names. The Chrome error I got was the generic SSL protocol error page though, only showing the internal name for the protocol error. I'd prefer to see that alert over an internal_error one though.

In my opinion, if GetCertificates is configured to fetch files and fails at that, internal_error is still the "right" alert, so I'd vote for having just a specific marker error to trigger an unrecognized_name as described in this issue.