2020-04-19
Verifying the server hostname for a TLS certificate has two purposes
One of the two parts of verifying a TLS server certificate is what I described as 'making sure that this valid certificate is actually for the server you're talking to'. This is done by verifying that the hostname you're connecting to appears in the TLS certificate's Common Name or Subject Alternative Names fields (CN and SAN respective), which is how TLS certificates specify what hosts they're for. I have come to feel that there are two reasons for doing this verification, and doing it by insisting that the hostname you're connecting to is in the certificate.
The first reason is to verify that you are connecting to the real server for hostname X, instead of a server that an attacker or a third party (such as a captive portal on a public network) has interposed in the way. This is the obvious reason, the one everyone thinks of (me included until very recently), and it is where most of the threats to TLS connections are; you don't want people gaining access to cookies or credentials or whatever by faking out a HTTP web server, a TLS protected IMAP or POP server, or whatever.
The second and more subtle reason is to insure that whatever you're connecting to is actually intended to handle traffic for the particular hostname you're connecting to. If you are talking to the real host but to something that's not intended to handle such traffic, sending traffic to it anyway is potentially dangerous. Perhaps you're going to be sending live traffic to a debugging server that's configured with copious logging that is going to wind up writing live credentials to log files. That's bad. Perhaps it's a HTTPS web server that is going to see what it thinks is a non-official name for itself and will serve you a permanent redirect to its official hostname, which your web browser will cache for a long time; that's at least inconvenient, and bad for non-technical users.
There are many possible things that can go wrong if you're not actually talking to a service that is supposed to handle hostname X, even if hostname X is really handled by the server. Requiring that the hostname be in the TLS server certificate doesn't completely guarantee that the service properly handles that hostname, but it's at least a reasonableness check; if the hostname is not in the TLS server certificate, something is certainly wrong and the safe thing is to not continue.
By extension, this means that programs probably shouldn't continue if the hostname isn't in the TLS certificate even if they're absolutely sure (for some good reason) that they're talking to the right server.
GMail, POP, and TLS server certificate verification
TIL that GMail has apparently spent years not verifying that the hostname of the remote POP server it was connecting to was included in the server's TLS certificate.
Like the more common and more recent IMAP, POP is a protocol used to retrieve email from email servers. GMail has for many years supported pulling email from your account elsewhere into GMail by logging in to it with POP and directly grabbing the mail (presumably using POP instead of IMAP because the POP protocol is a lot simpler).
(As a side note, this necessarily involves giving GMail the credentials for your POP account.)
Our local IMAP server also supports POP (over TLS) and has for a long time, and various people here who use GMail use this GMail feature to retrieve email from their account here (rather than directly forwarding it to GMail). This has worked for years, but recently we got a report from a user that GMail was now reporting SSL errors. Specifically, the error reported to us was saying:
Server returned error "SSL error: ok Hostname "pop.cs.toronto.edu" doesn't match any SANs: "imap.cs...."
For historical reasons, our IMAP server has multiple names in DNS. However, some time many years ago when we were rolling over TLS certificates for it, we neglected to get the TLS certificate for anything other than its primary name. So for years and years, anything connecting to it by any of those alternate names was being presented with a TLS certificate that failed the second part of verifying a TLS certificate; it was signed, but not for the host that you were connecting to.
However, GMail only started failing its connection attempts a few days ago for our user; before then pulling email from us via POP over TLS has worked fine. Since the TLS certificate has been improper for that host name for years, I can only conclude that for some reason GMail was accepting it before now. I'm glad they stopped, whatever the reason was (including perhaps silently turning off a flag in the user's settings that previously allowed this).
(GMail may not have been alone in this; apparently Thunderbird spent a long time not verifying this either.)