GeoffMontee, it is very well possible for the client to provide IP address. The reason why mutual authentication exists in SSL, is that client verifies that the certficate contains the name that client specified. Otherwise, one can exaggerate with the double-guesses, friendliness and ambiguity.

let's say client uses host name, and the DNS can resolve this as IPv4 or IPv6, or can generally have multiple entries for both IPv4 or IPv6. The address to which you connect is not deterministic.

If you use IP address to connect, it is deterministic, and if it is exactly what is in the subjectAltNames, then the client should use the IP addresses, and not the host names, simple and works every time

Hi wlad,

it is very well possible for the client to provide IP address. The reason why mutual authentication exists in SSL, is that client verifies that the certficate contains the name that client specified. Otherwise, one can exaggerate with the double-guesses, friendliness and ambiguity.

...

If you use IP address to connect, it is deterministic, and if it is exactly what is in the subjectAltNames, then the client should use the IP addresses, and not the host names, simple and works every time

Right, I understand that. I was not referring to the scenario where the client provides the server's IP address to connect. I was actually unsure of what should happen in the opposite scenario: what details from the server certificate must be verified if the client provides the server's host name?:

Of course, the client will verify that the server certificate belongs to the provided host name. This is obviously the correct behavior.

However, the client will not verify that the server certificate belongs to the IP address resolved from the provided host name. I was not sure if this is the correct behavior, because it could potentially allow for a man-in-the-middle attack in cases where:

• The client's DNS has been compromised.
• And the server's private key has also been compromised.

However, I think there are some problems with this criticism:

• If the client's DNS and the server's private key are both compromised, then that is a catastrophic scenario, and a lot of bad stuff can happen.
• If users are worried about their DNS being compromised, they should solve that by using something like DNSSEC.
• RFC5280 section 4.2.1.6. Subject Alternative Name does not say that the certificate would need to be verified with both the dNSName and iPAddress fields if they are both present in the Subject Alternative Name extension.

And regarding this comment:

let's say client uses host name, and the DNS can resolve this as IPv4 or IPv6, or can generally have multiple entries for both IPv4 or IPv6. The address to which you connect is not deterministic.

RFC5280 section 4.2.1.6. Subject Alternative Name is actually designed to account for this. Note the bolded sentence in this paragraph:

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4. Note that where such names are represented in the subject field implementations are not required to convert them into DNS names.

So if a DNS name could resolve to multiple IP addresses, then the certificate's Subject Alternative Name extension could contain a dNSName field for the DNS name and multiple iPAddress fields--one for each resolvable IP address. Therefore, the non-deterministic nature of DNS and the 1-many relationship of DNS names to IP addresses is not an issue.

Regardless, you can probably close this, unless you or ralf.gebhardt@mariadb.com think it may be worth providing an option to verify a server certificate using both the DNS name and the IP address. If you close this, then georg may also want to close CONC-413, since that issue is pointing out the same behavior in Connector/C.

Thanks!

@Geoff Do we really need this?

From RFC-6125:
Identifiers other than fully qualified DNS domain names.

_Some certification authorities issue server certificates based on
IP addresses, but preliminary evidence indicates that such
certificates are a very small percentage (less than 1%) of issued
certificates. Furthermore, IP addresses are not necessarily
reliable identifiers for application services because of the
existence of private internets, host mobility, multiple
interfaces on a given host, Network Address Translators (NATs)
resulting in different addresses for a host from different
locations on the network, the practice of grouping many hosts
together behind a single IP address, etc. Most fundamentally,
most users find DNS domain names much easier to work with than IP
addresses, which is why the domain name system was designed in the
first place. We prefer to define best practices for the much more
common use case and not to complicate the rules in this
specification._

Hi georg,

Thanks for the reference to RFC 6125. The section you referenced provides a good argument for why most users don't need the server certificate to be verified against the IP address. However, it does not necessarily say that no users want the server certificate to be verified against the IP address.

It looks like RFC 6125 was originally released in 2011. Do you think the section you referenced still applies a decade later? It seems like the TLS landscape has changed a bit since then. Additionally, I would suspect that IPv6 has become more common.

More recently in 2019, I see that the CA/Browser forum voted in Ballot SC7 on a related topic. Ballot SC7 modified the baseline requirements for CAs, so that CAs must use stricter validation methods when a customer wants a certificate tied to a public IP address. As far as I can tell, that change would help prevent some of the issues mentioned in RFC 6125. If you want to see the specific ballot, see here: https://cabforum.org/2019/02/09/ballot-sc7-update-ip-address-validation-methods/

Additionally, I do see that some certificate providers are currently offering certificates that include public IP addresses in the Subject Alternative Name extension. e.g.:

• https://support.globalsign.com/ssl/general-ssl/securing-public-ip-address-ssl-certificates
• https://www.ssl.com/faqs/order-ssl-tls-certificate-for-ip-address/
• https://blog.entrust.com/2019/03/what-is-a-san-and-how-is-it-used/
• https://sectigostore.com/page/ssl-certificate-for-ip-address/

However, I also checked the TLS documentation for other databases. It looks like MySQL, PostgreSQL, and Microsoft SQL Server perform server certificate validation in a way that is similar to MariaDB. That's probably a good indication that we don't need to change anything at the moment.

Regardless, you and wlad are the experts in MariaDB's TLS implementation, so if you think this is not needed, then I trust your judgement.

Thanks!