[HN Gopher] Vulnerabilities show why STARTTLS should be avoided ...
___________________________________________________________________
Vulnerabilities show why STARTTLS should be avoided if possible
(2021)
Author : fanf2
Score : 53 points
Date : 2024-08-27 17:42 UTC (5 hours ago)
(HTM) web link (blog.apnic.net)
(TXT) w3m dump (blog.apnic.net)
| tuwtuwtuwtuw wrote:
| Server to server communication still relies on STARTTLS all the
| time, and very often simply ignore cert errors or, my favorite,
| attempts STARTTLS and fall back to non-encrypted if handshake
| fails due to host name mismatch.
| dogma1138 wrote:
| The blog post is a bit poor; this seems like a packet racing
| vulnerability where by the attacker attempts to hijack the
| session.
|
| This means that the attacker needs to be on the same network
| network as the victim as spoofing the IP on a TCP connection is
| rather challenging.
|
| Not great but also not particularly useful in the real world
| either.
| tremon wrote:
| That's not the only way, DNS cache poisoning or hijacking can
| also redirect a victim to an attacker-controlled proxy. Or am I
| missing something?
| dogma1138 wrote:
| If you can redirect the victim to a proxy via DNS poisoning
| you don't need this attack you can simply pretend to be the
| mail server; not only that but it doesn't actually allows you
| to execute this specific attack.
|
| How this works is that you inject the commands into the plain
| text of the victim which requires packet racing or some other
| local network attack that allows you to take over the TCP
| stream.
|
| How this works is that the victim sends from:, creds, to:,
| email content but you somehow inject starttls, from:, creds:,
| to: a head of it which forces the entire message from the
| victim to be treated as data fully so the SMTP commands are
| disregarded which means you will be receiving an email with
| their credentials.
|
| I highly suspect that SMTP without starttls will work in the
| same manner, but perhaps the opportunistic encryption gives
| more time for this attack to be more effective.
|
| Every other scenario requires you to be able to MITM the
| traffic which is pretty much already gameover.
|
| I honestly can't really think of a scenario where you could
| launch a network attack that would allow you to inject
| yourself in the middle in this manner that won't allow you
| also to eavesdrop on credentials sent in plaintext or MITM
| the entire thing.
| jsiepkes wrote:
| > If you can redirect the victim to a proxy via DNS
| poisoning you don't need this attack you can simply pretend
| to be the mail server.
|
| Not if the client uses SMTPS (i.e. SMTP with TLS) on port
| 587. Which is actually quite common for mail clients.
| dogma1138 wrote:
| Yes but then this attack doesn't work either, you need a
| client that is happy with either unencrypted SMTP or one
| that will attempt opportunistic encryption.
| maxdamantus wrote:
| > Every other scenario requires you to be able to MITM the
| traffic which is pretty much already gameover.
|
| MITM attacks is one of the major reasons for using TLS/PKI.
| You might have total control over the TLS connections I
| make to a website, but you won't be able to inject
| information in either direction. All you can do is observe
| the amount of data being transferred and
| terminate/hang/throttle the connection. If you send
| something effectively different to what was intended by the
| sender, the recipient will detect it as a TLS error and
| terminate the connection.
|
| This attack involves injecting information before STARTTLS
| which puts the connection into a state that the client is
| not aware of, this is not normally possible in plain TLS
| connections.
| hannob wrote:
| Author here.
|
| If you want more technical details, we've put up a webpage back
| then, and published a background paper on those vulns:
| https://nostarttls.secvuln.info/
| newman314 wrote:
| I wonder what the uptake of MTA-STS is. Does anyone collect stats
| on this?
| 8organicbits wrote:
| I was poking around recently. Adoption appears very low on a
| per-domain basis [1], but high-volume mail providers like Gmail
| support it.
|
| Relatedly, DNSSEC adoption (and presumably DANE) is finally
| decreasing. So MTA-STS looks like the path forward. Lots of
| folks have been predicting this. [2]
|
| [1] https://www.uriports.com/blog/mta-sts-survey-2024/
|
| [2] https://www.verisign.com/en_US/company-
| information/verisign-...
| exabrial wrote:
| For awhile (2018ish - now), many large companies (Google, for
| example) were pushing everyone from STARTTLS and trying to move
| away from implied TLS. It was dumb then and of course it's still
| a bad idea.
|
| Binary (or text) protocols needs to be de-bundled from transport
| layer for _a lot_ of reasons (looking at you QUIC).
|
| Once we conquer this, we can de-bundle port number from service
| location.
| woodruffw wrote:
| Do you have a link for Google pushing people away from
| latent/implied TLS and towards STARTTLS? My recollection was
| the exact opposite (companies have increasingly pushing to kill
| off STARTTLS), but it's possible I've misremembered.
| unethical_ban wrote:
| What is port number, if not an identifier of service location?
| oasisaimlessly wrote:
| Using port number as a service identifier sucks because it
| means you can only run e.g. one normally-accessible SSH
| server per IP address. One potential solution is to look up
| port numbers via DNS SRV records[1], but very few protocol
| standards demand clients do this.
|
| HTTP and SMTP have their own ad-hoc, partial solutions to
| this (vhosting, MX records), but most every other service
| requires a unique IP address per instance.
|
| * [1]: https://en.wikipedia.org/wiki/SRV_record
| exabrial wrote:
| In the early internet years, your ip address was your
| identifier. It would have been absurd for your ip address to
| ever change. That changed quickly.
|
| In the early internet years, fixed ports were the service
| locator. Yet this has not evolved.
|
| As another commentor said, you can now only run one instance
| of a service per IP, which is aburdly wasteful of the
| possible ~65k inbound ports. TLS and SNI have come up with
| workarounds, but the root problem is still, port numbers
| should be available for anything, and we should have a system
| for service location. DNS is certainly an option, but there
| are other practical ways to do it.
| moduspol wrote:
| Sadly it probably won't ever happen because of the numerous
| packet forwarding layers that have baked-in security
| expectations that "HTTP = 80" and "HTTPS = 443", etc. It'd
| still be nice to reach that promised land, but I think the
| damage has already been done.
| agwa wrote:
| Called this 10 years ago:
| https://www.agwa.name/blog/post/starttls_considered_harmful
|
| I'm very glad that Hanno et al gave this the thorough look that
| it needed and that the IETF no longer favors STARTTLS.
| metadat wrote:
| I don't mean to be difficult, but in the spirit of being
| forthcoming:
|
| _" Called it!"_ posts really turn me off. You were right
| before, that's cool. What else can you add to a potentially
| interesting conversation? Bring your audience along for the
| ride..
|
| I'm much more interested in any new insights you have on the
| matter!
|
| Best wishes and take care <3, and again, I'm sorry, I wish I
| had the perfect words to connect with you.
___________________________________________________________________
(page generated 2024-08-27 23:00 UTC)