1976254 - Support getting the MS AutoDiscover domain from SRV records

Status: RESOLVED FIXED

(MailNews Core :: Account Manager, task)

Description

[Brendan Abolivier [:babolivier]]

https://learn.microsoft.com/en-us/exchange/architecture/client-access/autodiscover describes 4 ways to get an account configuration from the AutoDiscover service:

• Connect to https://example.com/AutoDiscover/AutoDiscover.xml
• Connect to https://autodiscover.example.com/AutoDiscover/AutoDiscover.xml
• Connect (without authentication) to http://autodiscover.example.com/autodiscover/autodiscover.xml with the expectation of a redirection to an HTTPS URL to request (with authentication)
• Search for the DNS SRV record at _autodiscover._tcp.example.com

While we correctly support the first 3 methods, we don't support the 4th one at all. This isn't too much of an issue because the other methods are decent at locating the AutoDiscover service, but in case of a configuration issue the SRV record method can provide extra resilience. For instance, earlier today I was running some tests on a third-party platforms that would normally work with the 3rd option, but does not redirect to an HTTPS URL, making the AutoDiscover process fail where an additional SRV record lookup could have provided an additional domain to query (which would have worked).

Comment 1

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1976254 - Look up SRV records when performing Microsoft Autodiscover. r=#thunderbird-reviewers

Since DNS records are inherently unsafe (because they lack proper encryption and
authentication), we're treating them the same way we do with redirects from
plain HTTP requests, i.e. by not sending any authentication to the derived URL
without the user's consent.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/271867a643b3
Look up SRV records when performing Microsoft Autodiscover. r=mkmelin

Comment 3

[Ben Bucksch (:BenB)]

http://autodiscover.example.com/autodiscover/autodiscover.xml with the expectation of a redirection to an HTTPS URL

third-party platforms that would normally work with the 3rd option, but does not redirect to an HTTPS URL, making the AutoDiscover process fail > where an additional SRV record lookup could have provided an additional domain to query (which would have worked).

For the record, if we're refusing to redirect to http: for security reasons, then DNS SRV is far worse, because DNS is far easier to spoof than HTTP, given that DNS is based on UDP, e.g. UDP flooding, UDP sender IP fake etc.pp. Any HTTPS it directs to could be attacker.com. That was the reason why we deliberately didn't implement DNS SRV anywhere in the process.

We got so much heat for even trying HTTP in the process, but nobody seems to have a problem with DNS SRV, which is far worse security-wise.