search

ehloonion / onionmx

Onion delivery, so delicious
200 stars 27 forks source link

Bad interaction with MTA-STS #29

Open Valodim opened 4 years ago

Valodim commented 4 years ago

Hey folks

Host authentication via onionmx, from what I understand, hinges on the SRV record that points to the hidden service, with no TLS/PKI or DNSSEC. That's not a huge issue compared to typical regular SMTP, given that most hosts don't validate TLS certificates either, and connections can be trivially downgraded.

However, this does become an issue for hosts that use MTA-STS, which offers reliable PKI host authentication via strict verification policies, and some measure of downgrade resistance.

So on a host that respects onionmx and MTA-STS for outgoing e-mails, the onionmx SRV record suddenly becomes the weakest link for authentication of recipient hosts. For example, if some host already knows via MTA-STS that gmail.com can be strictly authenticated by PKI certificate, an attacker could spoof an onionmx SRV record, and circumvent the host authentication that would have happened otherwise.

Any thoughts on this? Perhaps there is a simple fix, or my analysis is wrong?

(context: I considered adding onionmx support to keys.openpgp.org)

dkg commented 4 years ago

fwiw, some domains that offer onionmx are secured by DNSSEC:

0 dkg@alice:~$ dig +dnssec -t srv _onion-mx._tcp.riseup.net
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 31589
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 230 B

;; QUESTION SECTION:
;; _onion-mx._tcp.riseup.net.       IN  SRV

;; ANSWER SECTION:
_onion-mx._tcp.riseup.net.  600 IN  SRV 0 5 25 wy6zk3pmcwiyhiao.onion.
_onion-mx._tcp.riseup.net.  600 IN  RRSIG   SRV 14 4 600 20191107172946 20191024155946 33676 riseup.net. MIJDq4ljczqbpfqo9jcra1bMYS0HT5ZZi1ARAVVSVh+1WrnRsTt6YFspm7JuuprSnIBHBF23/QwoAlZEIfn3izzuKxCGfjROEl7jb+x3tO4vyIIuscpiLvE/LA11m7p6

;; Received 468 B
;; Time 2019-10-24 14:09:13 EDT
;; From 199.58.81.218@853(TCP) in 177.6 ms
0 dkg@alice:~$

If you've got a validating DNSSEC resolver, you can avoid the gap that you describe.

Valodim commented 4 years ago

If you've got a validating DNSSEC resolver, you can avoid the gap that you describe.

Are you just assuming that a validating dnssec resolver that hard fails for missing dnssec records would be a viable option now or anytime soon? Or am I missing something, and your idea would work without that?

dkg commented 4 years ago

There is a distinction between the following three cases:

If your goal is secure mail delivery, then yes, a validating dnssec resolver that hard-fails in the "bad" case is probably acceptable for _onion-mx delivery.

Note that delivery to "unsigned" zones via unsigned _onion-mx SRV records remains vulnerable.

link2xt commented 7 months ago

Alternative solution would be to stop using SRV records and instead use https://mail.example.net/.well-known/onion-mx.txt URLs to lookup onion MX domains. onion-mx.txt would contain the same contents as SRV records, i.e. .onion domains sorted by priority.

This is the same mechanism as MTA-STS uses, so there is no need to cross-check against MTA-STS and make transport map daemon interact with policy daemon.