SecureSocket does not validate the name against the CN/SAN of the certificate

[cmidgley]

Build environment: Windows
Moddable SDK version: 5.0.1
Target device: ESP32, Simulator (Win)

Description
A SecureSocket connection can be made to a server even when the connection name does not match the certificate names (CN/SAN).
The connection succeeds and communicates without errors over the secure connection.

Steps to Reproduce

1. Start with examples/network/socket/socketsecure
2. Change the connection line to use the IP address of example.com (93.184.215.14 as of this write-up), which does not match the certificate. Alternatively, you can set up a DNS entry that resolves to that address and then use the DNS name instead of the IP address.

Line before changing:

(new SecureSocket({host, port,

Line after changing:

(new SecureSocket({host: "93.184.215.14", port,

This approach keeps the host variable referencing www.example.com so the HTTP GET will use the expected hostname (example.com requires this to return the normal page content, though it can be overridden and the connection will succeed but the HTTP payload will be an error message).

3. Run on simulator or ESP32 and see that the connection succeeds and the page content is returned.

Other information
If the certificate is expired (or time is not set on ESP32; can't easily simulate on win as Time.set(...) isn't supported), or the certificate root is invalid, it correctly rejects the session.

[phoddie]

You're going to make me go back and relearn how this is supposed to work. ;) Will take a look but understand that TLS matters are seldom quick to resolve.

[cmidgley]

As I'm sure you recognize, it's an attack vector since there is no validation that the domain name matches the certificate, but it doesn't affect the actual communications. While likely best to be implemented in SecureSocket, another approach might be to have an API where the callered can get the (decoded?) certificate info and leave it up to the caller to do the check.

I did some research on the requirements, in case it might help. There are two fields that contain the domain info:

Certificate:
    Data:
        Subject: CN = some.domain.com
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:some.domain.com, DNS:another.domain.com, DNS:*.wild.domain.com

The Subject: CN = ... field will represent the "primary" domain (and is considered legacy), whereas the Subject Alternate Name (SAN) will contain multiple names for each domain that is registered. Both support wildcards, where the wildcard *.domain.com will match example.domain.com but not match domain.com. If the SAN is provided, the CN field can be ignored.

Also worth noting, an alternate format instead of commas on the DNS entry is to list each entry on a separate line. It is not valid for it to be both comma and separate lines:

Certificate:
    Data:
        Subject: CN = some.domain.com
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:some.domain.com
                DNS:another.domain.com
                DNS:*.wild.domain.com

Let me know if I can help further. This is not a high priority for me (lots of time before my code reaches the public) - but it is an attack vector that seems worth addressing eventually.

[phoddie]

@cmidgley – yes, I understood that this is a potential vulnerability. As such, it should be solved in the TLS stack to benefit all clients.

[phoddie]

Thanks for reporting this. It took a while to free up a big enough block of time to dig into the details.

Summary: I've got this working and it should arrive in this repository shortly.

When the verification fails to find a match, an error message is output to the console and validation fails:

subjectAltName match failed for 93.184.215.14

Background and Details

There's a recent RFC, 9525, from November 2023 that is all about how to validate the service identify (mostly, the name). It is great -- it is very clear and simplifies wildcard resolution. I've tried to follow its guidance in the implementation. For example, it is very explicit that the CN (Common Name) should be ignored and only the SAN (subjectAltName) should be used for the check.

As I worked through an implementation, I rediscovered that an earlier revision of our TLS stack did support this check. It looks like was disabled when the socket was rearchitected and no longer provided a host property. That implementation isn't up-to-date with RCC 9525 or the current TLS architecture, so I didn't try to revive it.

There are two ways to verify the server identify that are relevant here: the DNS name and the IP address. The IP address is less common, but it is used. A typical example is for DNS services with easy to remember IP addresses like 8.8.8.8 and 1.1.1.1. Both of those are now supported. Wildcards in DNS names from certificates are also supported. They are common enough that there would be failures otherwise. For example, GitHub uses wildcards in the certificate for user hosted content (https://ecmatc53.github.io/spec/).

The changes are to the core TLS implementation that is shared across the original SecureSocket and the newer 419 TLS socket, so both versions have the additional security checks.

I need to build some unit tests for this check. Testing the various cases manually takes awhile and it is important to make sure this check doesn't get broken down the line.

Just FYI – your notes above show the certificate in text format. That's why there are details about linefeeds and commas. Certificates in the TLS transaction are binary (DER). Their content is equivalent, but parsing is completely different.