https rr cert error not displayed if the record has no A/AAAA addresses
Categories
(Core :: Networking: DNS, defect)
Tracking
()
People
(Reporter: jschauma, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0
Steps to reproduce:
The name 'https.dns.netmeister.org' has an HTTPS RR, but neither an A nor AAAA record:
$ dig +short https https.dns.netmeister.org
1 www.netmeister.org. alpn="h2,http/1.1" ipv4hint=166.84.7.99 ipv6hint=2001:470:30:84:e276:63ff:fe72:3900
$ host https.dns.netmeister.org
$
The cert on 'www.netmeister.org' does not include 'https.dns.netmeister.org' as a SAN.
When trying to visit that site, Firefox displays an error indicating it can't resolve the name instead of showing the certificate error.
Actual results:
Visiting 'https.dns.netmeister.org' in Firefox yields the error message:
Firefox can’t protect your request for this site’s address through our trusted DNS resolver. Here’s why:
This website wasn’t found by mozilla.cloudflare-dns.com.
Firefox did perform the DoH lookup for the HTTPS record for 'https.dns.netmeister.org'. After that, I see it performing AAAA and A record lookups via DoH for 'www.netmeister.org' (although it could have used the ipv4hint/ipv6hint from the HTTPS result). It then connects to the server in question sending the correct SNI ('https.dns.netmeister.org').
The server's certificate does not include 'https.dns.netmeister.org', however, so the TLS connection yields a TLS 'bad certificate' alert.
After that failure, Firefox then proceeds to attempt to look up the A and AAAA records for 'https.dns.netmeister.org', which do not exist. Firefox then displays the above error to the user.
Expected results:
I would have expected Firefox to bubble up the cert mismatch to the user (SSL_ERROR_BAD_CERT_DOMAIN) and stop. The current behavior is misleading for the user, as the problem is not that the name can't be resolved, but that the cert in question isn't valid for that name.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 3•2 years ago
|
||
https://www.rfc-editor.org/rfc/rfc9460.html#name-ipv4hint-and-ipv6hint
If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints.
You could say that once the records have been resolved, the hints provided by the HTTPS record no longer apply.
These parameters are intended to minimize additional connection latency when a recursive resolver is not compliant with the requirements in Section 4 and SHOULD NOT be included if most clients are using compliant recursive resolvers.
So if they wouldn't be included for compliant recursive resolvers, I read it as the A/AAAA records are still required.
I'm seeing the same behaviour in Chrome.
@Jan, please let me know if you disagree with my reading of the RFC.
|
|
Reporter | |
Comment 4•2 years ago
|
||
I think that part of the RFC is not directly relevant
to this bug. :-)
The problem here is that Firefox doesn't show the
correct error. One way or another, Firefox finds the
right IP address for the service, and tries to make a
TLS connection. It then fails, because the
certificate in question isn't valid.
However, instead of displaying a cert mismatch error,
Firefox displays an error saying it couldn't resolve
the hostname - which is simply not true, as Firefox
did resolve the hostname and attempted the
connection.
(FWIW, I wouldn't model Firefox's behavior after
Chrome here; I found that Chrome (at least as of a few
weeks ago) does not support any of the options beyond
ECH, so would indeed not be able to resolve the name
and then should display an error saying so. See
also:
https://bugs.chromium.org/p/chromium/issues/detail?id=1494759)
|
|
||
Comment 5•2 years ago
|
||
But the domain still needs to have A and AAAA records.
Their absence is a signal that something went wrong.
A more interesting question is what happens if there isn't a cert error? Does Firefox still load the website? How about subsequent refreshes? Should that actually work?
|
|
Reporter | |
Comment 6•2 years ago
|
||
Yes, that does work as (I believe) it should:
$ dig +short https https.test.netmeister.org
1 www.netmeister.org. alpn="h2,http/1.1" ipv4hint=166.84.7.99 ipv6hint=2001:470:30:84:e276:63ff:fe72:3900
$ host https.test.netmeister.org
$
Firefox has no problem with that.
I think that Firefox should display the correct cert error for "https.dns.netmeister.org" because that error happens on a different layer than any IP errors. If there are problems resolving the name, firefox should display a relevant error, but once it has managed to identify the right IP address and then made a connection, we're up a layer and are now talking TLS. A TLS error should yield a TLS error message, not a DNS error message.
Description
•