Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-19560

Client may not compare IP address to Subject Alternative Name fields for server certificate verification

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • 10.2.24, 10.1.40, 10.3.15, 10.4.5
    • N/A
    • SSL
    • None

    Description

      This is similar to CONC-413.

      Support for server certificate verification against subjectAltName (SAN) fields was added in the following Jira issues:

      However, I noticed that clients don't necessarily check the server's IP address against the subjectAltName (SAN) fields in the certificate. They only check mysql->host, which can be a host name or an IP address. If the user specifies the server's host as a host name, then I don't believe that the client will verify the certificate using the server's IP address.

      https://github.com/MariaDB/server/blob/mariadb-10.1.40/sql-common/client.c#L2647

      https://github.com/MariaDB/server/blob/mariadb-10.1.40/sql-common/client.c#L1840

      Could the IP address of the remote server be fetched in ssl_verify_server_cert() with the socket_remoteN functions by passing vio_fd(vio)?

      https://linux.die.net/man/3/socket_remote4

      https://linux.die.net/man/3/socket_remote6

      Attachments

        Issue Links

          Activity

            wlad Vladislav Vaintroub added a comment - - edited

            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

            wlad Vladislav Vaintroub added a comment - - edited 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!

            GeoffMontee Geoff Montee (Inactive) added a comment - 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!
            georg Georg Richter added a comment - - edited

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

            georg Georg Richter added a comment - - edited @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.:

            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!

            GeoffMontee Geoff Montee (Inactive) added a comment - 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!

            People

              wlad Vladislav Vaintroub
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.