1589761 - Look up webserver port in DNS SRV RR

Status: UNCONFIRMED

(Core :: Networking, enhancement, P3)

Description

[Bjartur Thorlacius]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Navigate to an https URI — with no port set in the authority part — whose domain name has a SRV resource record.

Actual results:

Firefox connects to an IP address found in an A or AAAA record on TCP port 443 and then sends a Server Name Indication in cleartext. This leaks potentially sensitive information (enabling selective censorship) and makes it unnecessarily hard to share IPv4 addresses between multiple websites.

The new, but as it turns out inferior, method for IPv4 address sharing Server Name Indications, leaks hostnames in cleartext. Daniel Stenberg is trying to work around the issue by publishing public keys in DNS for encrypting the Server Name Indicator. Unlike SRV resource records, such Encrypted Server Name Indicators are non-standard and present their own host of problems, including public key configuration in DNS being more complicated than port configuration in DNS. Server Name Indication also violates protocol layering by forcing network address translators to participate in TCP and TLS handshakes (possibly with a yet another key pair for Encrypted Server Name Indication) before forwarding a connection to a webserver.

Expected results:

Firefox should have connected to the TCP port specified by the SRV resource record as per RFC 2782.

https://tools.ietf.org/html/rfc2782

The SRV proposed standard has been stable for two decades and been proven in multiple widespread protocols, including SIP, Exchange Autodiscover, XMPP (Jabber), LDAP and Minecraft. Name servers already support SRV, and many organizations already use SRV for some protocol.

Comment 1

[Kershaw Chang [:kershaw]]

Set this to P3, since I think we don't have a plan to support this in the near future.

Comment 2

[Rick van Rein]

This is not a software issue; it is related to the HTTP and TLS specifications. Your expected behaviour (use of SRV record) is not standardised yet.

Also, this replicates bug 14328 which you may not have found because as it was closed.

Comment 3

[Bjartur Thorlacius]

I didn't want to hijack that feature request which seems to be about partially ordering hosts for fallback instead of an even round robin. Mentioning SRV in this privacy leak report was perhaps a bit forward of me, considering that the leak can be stopped by not sending a server name indication. In special I hope, but haven't tested, that no server name indication is sent to IPv6 hosts. Then each webserver moved to IPv6 would prevent this leak, but obviously `leaks' the IPv6 address and the IPv6 migration has not even begun in Africa, Iceland and other places. Encrypting the server name indicator can work, but that's a clever but unstandardized and narrownsolution.

Are Bugzilla ticket boundaries defined by technology, so we'd have one ticket for eSNI and one for SRV RR? Or by functionality,? If the latter, we can have this ticket for domain name privacy, whether it's achieved by address+port addressing (using the port number to disambiguate hostnames sharing IP address, providing weak privacy since the mapping is not secret) or by encrypting the server name indicator.