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!
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