ehloonion / onionmx Goto Github PK

suddenly you speak of postdns.ini ???? where is this file wher does it come from ?

do you assume posfix tor and Maiserver are all on one machine?

I have these three services in 3 separate VM's

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)

A couple things I thought of about the output of map2postfix-transport.rb:

• it does not output a generic onion entry .onion smtptor:. We had used this in the past to cover any MX records that pointed to onion addresses directly. I don't know if this is common at all, or if it should be encouraged/discouraged
• for records in the map that are your own organization, you might not want them in there to avoid the extra transport via tor for what is probably already going over loopback (or maybe a private network to another host). When generating this map I always pruned these by hand just to be safe. Ideally in your transports you'd have some sort of local transport map listed first before the SRV lookup and this static map so these records shouldn't matter. But it does still seem like a potential pitfall for people setting this up. Options: 1) document the pitfall(not great) 2) make the script filter local domains(janky) 3) stop doing a static map and only do SRV(solves static map but not the same pitfall in SRV).

Opinions?

you assume I cloneed the project
you assume I have Ruby installed
you assume I mad a pull request with the changed map.yaml

this Doku needs rewriting

Thought you might be interested. The following Exim macro+router allows me to route to systems with _onion-mx srv records without having to use an external script:

ONIONMX = ${map{\
  ${filter\
    {${lookup dnsdb{srv=_onion-mx._tcp.$domain}}}\
    {match{$item}{ 25 \\S+}}\
  }\
}{\
  ${sg{$item}{.+ }{}}\
}}

onionmx:
  driver     = manualroute
  transport  = remote_smtp
  route_data = ONIONMX

Of course, it relies on the system that it is running on to be set up with transparent Tor routing.

I can't get this to work for postfix. All I see in the log is:

postfix/master[197567]: warning: process /usr/lib/postfix/sbin/smtp_tor pid 197606 exit status 134
postfix/master[197567]: warning: /usr/lib/postfix/sbin/smtp_tor: bad command startup -- throttling

I've found one person who seems to have had a similar problem: https://endchan.net/os/res/2.html#240

Is this still working for anyone else?

I ran strace and got:

1656582307 WARNING torsocks[1946690]: [syscall] Unsupported syscall number 39. Denying the call (in tsocks_syscall() at syscall.c:604)
1656582307 WARNING torsocks[1946690]: [syscall] Unsupported syscall number 39. Denying the call (in tsocks_syscall() at syscall.c:604)
1656582307 WARNING torsocks[1946690]: [syscall] Unsupported syscall number 39. Denying the call (in tsocks_syscall() at syscall.c:604)
...
Assertion 'fclose_nointr(f) != -EBADF' failed at src/basic/fd-util.c:126, function safe_fclose(). Aborting.
Aborted (core dumped)

Currently it uses #!/bin/env ruby which doesn't exist in newer distro releases. I think it should just call the interpreter directly #!/usr/bin/ruby but if there is a good reason I suppose #!/usr/bin/env ruby might be acceptable.

I realized the static postfix map we were using locally hadn't been updated in a while, so I generated a new one from git and compared them and discovered that we had made some updates that weren't in the upstream map. I will list them below, but first I think we should consider if there are reasons to still maintain this file over using the SRV method.

• calyx.com moved to v3: kz4bswvhrqufq7e3ntwtco7jwgrpwwmh5j5kvlbonogt7xoipzwfedyd.onion (SRV record still points to the v2)
• calyxinstitute.org moved to v3: kz4bswvhrqufq7e3ntwtco7jwgrpwwmh5j5kvlbonogt7xoipzwfedyd.onion (SRV points to the v3)
• potager.org moved to v3: smsriptlensuwrolqrqp3sqhqpuovc4fg7n2q3l3b6dq3owgrv6c26yd.onion (but no SRV record)
• espora.org v2 record dropped (no SRV, no answer on v2)
• espiv.net moved to v3: jcifdulylocooyez2fh32i53kdo66d7tq7fotdc7lw6r2bgcb3rhjzqd.onion (SRV is CNAME for espiv.net? maybe a wildcard record? doesn't answer?)
• lists.espiv.net moved to v3: zo37k42zdy6n4lw22iamcy46rihir6t7d5imnrxcsyb7vmazvbjej2id.onion (no SRV, doesn't answer?)
• boum.org v2 record dropped (no SRV, no answer on v2)

If these domains want to keep doing onion-mx, make sure you are on v3 and publishing SRV records. Then we can either update the records in the map, or just drop them in the move to SRV only.

I had to manually add these to the tor_transport file:

tt3j2x4k5ycaa5zt.onion smtptor:[tt3j2x4k5ycaa5zt.onion]
danwin1210.me          smtptor:[tt3j2x4k5ycaa5zt.onion]
wc2eyfmw7wrwomf4.onion smtptor:[wc2eyfmw7wrwomf4.onion]
onionmail.info         smtptor:[wc2eyfmw7wrwomf4.onion]
bitmailendavkbec.onion smtptor:[bitmailendavkbec.onion]
bitmessage.ch          smtptor:[bitmailendavkbec.onion]
eludemaillhqfkh5.onion smtptor:[eludemaillhqfkh5.onion]
elude.in               smtptor:[eludemaillhqfkh5.onion]

Note as well that I added "<onion host> smtptor:[<onion host>]" for each of them as well as for all the existing ones. Not sure why those were not generated, but they are needed when the recipient is addressed using the .onion form.

With the support of onion v3 landing in stable Tor, it is time to take advantage of the better crypto and security properties of next generation of onion. I'm not sure what's the best way to coordinate the effort with all the maintainers of the servers included on the static map, but it would be great to nudge them to upgrade to onion v3 if they haven't already. And also to include the ones who already have. I know Riseup has, for example.

What is the reason for using SRV records instead of simply having .onion MX records?

Also, none of the docs seem to mention dnssec as a way to verify the .onion addresses as being genuine?

I did not find a policy on how to get a domain added or removed from the project's map.yml file. It seems like a nice possibility for MitM attacks.

I propose to require prove of ownership by the non-onion domain owner. This can be done simply by requiring the presents of a SRV record pointing to the provided onion domain.

In #25 I created a simple script to check for the SRV records. This or something similar could be used for regular checking of currently present records and those to be added.

Why don't you verify the smtp server's onion service with the tls certificate they offer on direct connect? This would make trolling etc harder

get with the program