[HN Gopher] Comcast Shot Themselves in the Foot with MTA-STS
___________________________________________________________________
Comcast Shot Themselves in the Foot with MTA-STS
Author : tomwas54
Score : 63 points
Date : 2022-01-19 17:53 UTC (5 hours ago)
(HTM) web link (www.agwa.name)
(TXT) w3m dump (www.agwa.name)
| _huayra_ wrote:
| Everyone can easily move to email at their own domain. A com
| domain is about $14/year and you can get free email hosting from
| your domain on zoho.
|
| Google can cut off your account on a whim with no recourse and
| God forbid you want to escape your isp but keep your email
| address with them!
| agwa wrote:
| Right, but now you're on the hook for setting up MTA-STS
| yourself, which as this post shows is no easy task.
| Byteflux wrote:
| For sure. It's not trivial but I also wouldn't say it's
| difficult either, maybe more of a moderate difficulty? The
| policy file format is straight forward, as are the necessary
| TXT and CNAME records.
|
| In my case, I use Cloudflare for my domain so I set up a
| Cloudflare Pages project to generate and host the policy file
| at the mta-sts subdomain which is nice because I don't have
| to worry about hosting or SSL/TLS.
|
| As long as your provider supports MTA-STS, you're only on the
| hook for setting up the records and hosting the policy file.
| agwa wrote:
| If you never make changes, that will work once it's set up.
|
| But if you ever decide to change your mail provider, you'll
| have to remember to correctly update your MTA-STS policy.
| If your change to Cloudflare Pages doesn't propagate
| through the Cloudflare CDN right away, you could end up in
| the situation described in the blog post, with the TXT
| record updated before the text file, and other mail servers
| unable to send you email.
| rovr138 wrote:
| If you're using a provider, you're not on the hook for it.
|
| Unless I'm mistaken in how this is implemented (not just
| server side)
| agwa wrote:
| Your provider is on the hook for properly configuring TLS
| on their mail server, but you still need to publish an MTA-
| STS policy saying who your provider is.
|
| Unless your provider provides MTA-STS endpoints that you
| can CNAME your _mta-sts and mta-sts subdomains to. I
| haven't seen anyone do this yet.
| nemomarx wrote:
| Does using your own domain stop Google from cutting off your
| account? My understanding was that the biggest risk is ending
| up on a spam filter, and Google could easily do that to you
| with a small or less heard of domain.
| ocdtrekkie wrote:
| Good Lord, someone took the dumpster fire that was HSTS and made
| it for mail servers? Heaven help us all and have mercy on our
| souls.
|
| I wanted to then follow up with an insightful or interesting
| comment but I am at a loss.
| Macha wrote:
| HSTS itself is fine? It just means "please only contact me over
| TLS for X amount of time". The only complaint I heard about was
| adtech companies using it for fingerprinting.
|
| Are you sure you're not thinking of HPKP?
| Karunamon wrote:
| Problem is "X amount of time" is usually "months-to-years"
| and there's no override.
| Macha wrote:
| But as for as stipulations go, "Must use TLS" seems pretty
| tame.
| RedShift1 wrote:
| I think the real problem is (emphasis mine):
|
| > the MX record is vulnerable to manipulation unless DNSSEC is
| used, _but people don 't like DNSSEC which is why MTA-STS was
| invented_
|
| This speaks volumes about the way these protocols are developed
| and subsequently implemented in software. People are not going to
| like complex solutions and that should be kept in mind when those
| protocols are being developed and implemented, otherwise its
| deployment is hampered just like we're seeing now with DNSSEC. In
| fact, now we've got MTA-STS because "people don't like DNSSEC",
| involving a whole HTTPS stack on both sides with so much more
| failure points just to send an email.
| tyingq wrote:
| Interesting. I'm curious if popular MTA software supports some
| kind of configuration to reload caches after some amount of MTA-
| STS failures.
| pas wrote:
| Isn't by design it must cache for the amount of time specified
| in the TXT file? So it has to be durable.
|
| Of course the MTA probably should provide ways for admins to
| override this. Maybe as simple as deleting a file, modifying a
| sql(ite) DB.
| agwa wrote:
| > Isn't by design it must cache for the amount of time
| specified in the TXT file? So it has to be durable.
|
| Kind of. The max_age in the text file is the max time a
| cached policy should be used _if a new policy can 't be
| retrieved_ (e.g. it's being blocked by an attacker). If a new
| policy _can_ be retrieved over HTTPS, it 's totally OK to use
| it even if the max_age of the cached policy isn't up yet.
|
| Thus, tyingq's suggestion is reasonable. In fact, the RFC
| already tells mail servers to look for a new policy if just
| one MTA-STS failure occurs
| (https://datatracker.ietf.org/doc/html/rfc8461#section-5.1
| step 3). The problem is that it checks for a new policy using
| the ID in the TXT record, which as explained in the blog post
| is unreliable.
| pas wrote:
| Thanks for the detailed explanation.
|
| It seems silly to introduce that extra level of indirection
| _when_ there 's already a well-known URL to try to fetch a
| new version.
|
| Is there any rationale for this? Also if DNS is explicitly
| a not trusted component this seems to strictly lead to a
| less secure system :o
|
| (But I guess the designers did not want to "completely"
| override MX records just with yet another out of band
| magic.)
| LinuxBender wrote:
| Wouldn't the simplest work around be to just remove
| mx2h1.comcast.net and mx1a1.comcast.net from the MX records for
| at least 2592000 seconds and instead add the IP addresses of
| those mail servers vips to other existing DNS records that were
| properly in the STS file?
|
| e.g. dig +short mx2h1.comcast.net
| 96.102.157.179 dig +short mx1a1.comcast.net
| 96.103.145.165
|
| So just add 96.102.157.179 to mx2c1.comcast.net and add
| 96.103.145.165 to mx1h1.comcast.net or something along that line?
| Their MX TTL is only 300 seconds.
| agwa wrote:
| Comcast just needs to rotate the ID in the _mta-sts.comcast.net
| TXT record. That will cause sending mail servers to download
| the new policy.
| LinuxBender wrote:
| Well that's way too easy. I supposed I improperly assumed
| that the results would be cached longer than the TTL of the
| TXT record based on the expiration in the well-known text
| file. In that case they should have only seen a tiny window
| of time that emails remained in queues. I will have to read
| up on the RFC for MTA-STS a bit more.
|
| In that case I would suggest they did not really shoot
| themselves in the feet. Rather they may have stubbed their
| toe.
| usbqk wrote:
| Oh boy. I sure hope you guys aren't using your ISP's email
| address.
| hffftz wrote:
| syntheticnature wrote:
| I'm not, but far too many folks do as a matter of course.
| ddtaylor wrote:
| That comcast.net email address is only good for storing all the
| DMCA complaints that pile up and get automatically deleted.
| zokier wrote:
| Does anyone know why SNI style approach is not used for email?
| The client could indicate in the TLS handshake (or in STARTTLS
| command) that it wants to send email to comcast.com and the
| server would use comcast.com certificate to prove that it is
| authentic destination for those emails. That way you'd avoid this
| whole mess of needing to fetch another file using another
| protocol based on another DNS record etc. SNI seems to work well
| for web, so why not for email too?
| meepmorp wrote:
| You're not always talking directly to the destination
| mailserver when sending a message via SMTP.
| zokier wrote:
| I don't see how that makes a difference? Sure, the cert
| issuance/distribution can be bit of hassle but it doesn't
| seem insurmountable
| [deleted]
| agwa wrote:
| This is a good question. It's a bit more complicated than just
| using SNI.
|
| First is certificate management. There is currently no
| automated way for mail providers to obtain TLS certificates for
| domains whose MX records point to them - i.e. there is no
| SMTP/MX equivalent to the Baseline Requirement's "Agreed-Upon
| Change to Website" domain validation method, or ACME's HTTP-01
| challenge type. And in general domain operators don't want
| their mail providers to have certificates which could be used
| to impersonate their websites.
|
| The certificate problem could be solved with SRVName
| certificates, which permit certificates to be scoped to a
| particular service on a host. Combined with an automated
| SMTP/MX-based validation method, this would permit mail
| providers to easily and securely get certificates for the
| domains whose mail they host. But there are thorny security-
| critical compatibility problems which are blocking the
| deployment of SRVName certificates. I wrote about the problem
| near the end of this blog post:
| https://www.agwa.name/blog/post/avoiding_dnssec
|
| Second is that you need a mechanism for servers to remember
| that they should use TLS with a particular recipient domain,
| similar to HSTS. This could probably be accomplished with a
| simple SMTP extension that's included in the EHLO response.
| zokier wrote:
| > And in general domain operators don't want their mail
| providers to have certificates which could be used to
| impersonate their websites.
|
| > The certificate problem could be solved with SRVName
| certificates, which permit certificates to be scoped to a
| particular service on a host.
|
| What about extended key usage extension, doesn't it function
| similarly without needing to fiddle with SANs? https://datatr
| acker.ietf.org/doc/html/rfc5280#section-4.2.1....
| agwa wrote:
| Yeah it seems like EKU could be used for this. But I might
| be overlooking something.
| tedunangst wrote:
| What do you do when the mail server you're talking to (or its
| impersonator) doesn't offer startssl?
| wolverine876 wrote:
| > MTA-STS is a relatively new standard that allows domain owners
| such as Comcast to opt in to authenticated encryption for their
| mail servers. (By default, SMTP traffic between mail servers uses
| opportunistic encryption, which can be defeated by active
| attackers to intercept email.) MTA-STS requires the domain owner
| to duplicate their MX record (the DNS record that lists a
| domain's mail servers) in a text file served over HTTPS. Sending
| mail servers, like Alex's, refuse to contact mail servers that
| aren't listed in the MTA-STS text file. Since HTTPS uses
| authenticated encryption, the text file can't be altered by
| active attackers. (In contrast, the MX record is vulnerable to
| manipulation unless DNSSEC is used, but people don't like DNSSEC
| which is why MTA-STS was invented.)
|
| Is this just a way of validating the MX record? That is, the
| public MX record in DNS can't be trusted, but because a cert
| verifies the identity of the sending mail server, the one they
| send can be trusted?
|
| If someone is successfully impersonating the sender, what stops
| them from sending a false MX record. If they aren't
| impersonators, why not just trust them regardless - why do they
| need the MX record?
|
| Obviously, I'm missing something.
| tedunangst wrote:
| This allows you to verify the mx record of the domain you're
| sending to, not the sender.
| aaronmdjones wrote:
| This is for the receiver, not the sender.
___________________________________________________________________
(page generated 2022-01-19 23:01 UTC)