Suggestion: Send TLS "unrecognized name alert" instead of serving default certificate if no correct certificate is found
Summary
Currently, if GitLab Pages does not find a correct certificate/key bundle for the domain sent by the client in the TLS SNI, it uses the default certificate/key bundle. This leads to a security warning in current browsers (see table below).
In my opinion, it would make more sense to send an unrecognized name alert
at the TLS level and not even complete the handshake. This is what should be communicated to the client: the Pages instance has no certificate for this domain and can thus not serve it properly.
Steps to reproduce
- Add an entry
<ip of gitlab.io> some.test.domain.com
to/etc/hosts
- Visit https://some.test.domain.com
What is the current behavior?
Firefox | Chrome | Edge |
---|---|---|
To the user, this looks as if the administrator of GitLab pages isn't able to do proper TLS/HTTPS.
What is the expected correct behavior?
The server should not respond at all to requests for domains it is not configured with. In current browsers, the client would see the following error pages:
Firefox | Chrome | Edge |
---|---|---|
Unfortunately, this is not very helpful in the cases of Chrome and Edge, but Firefox provides a helpful explanation:
SSL peer has no certificate for the requested DNS name.
Possible fixes
The Go tls package automatically sends the a proper TLS alert (alertUnrecognizedName
) to the client when provided the correct error (errNoCertificates
).
Further information
The "unrecognized name" was discussed in this issue in the Go TLS package.