No Starttls(nostarttls.secvuln.info)
nostarttls.secvuln.info
No Starttls
https://nostarttls.secvuln.info/
22 comments
I was under the impression 8314 was a "done deal". IANA have listed 465 as submission over TLS since december 2017.
(The previous iteration was submission over SSL in the late 90s on the same port.)
(The previous iteration was submission over SSL in the late 90s on the same port.)
Similarly, I have my personal SSH server configured to only accept "modern" crypto. A fair number of attacking clients fail to negotiate a cipher!
I recently switched my SSH servers to only listen to IPv6. They're still on port 22, and still pointed to by DNS, yet, while they received bot connection attempts every few seconds when listening for IPv4, they haven't received a single bot connection attempt in the last week since I made the switch.
Bots apparently simply don't bother with IPv6.
Bots apparently simply don't bother with IPv6.
Enumeration of all IPv4 is easy. Enumeration of all DNS entries is hard to impossible. Enumeration of all IPv6 is impossible.
> Enumeration of all IPv6 is impossible.
Though do take note of RFC 7707, "Network Reconnaissance in IPv6 Networks":
Though do take note of RFC 7707, "Network Reconnaissance in IPv6 Networks":
IPv6 offers a much larger address space than that of its IPv4
counterpart. An IPv6 subnet of size /64 can (in theory) accommodate
approximately 1.844 * 10^19 hosts, thus resulting in a much lower
host density (#hosts/#addresses) than is typical in IPv4 networks,
where a site typically has 65,000 or fewer unique addresses. As a
result, it is widely assumed that it would take a tremendous effort
to perform address-scanning attacks against IPv6 networks; therefore,
IPv6 address-scanning attacks have been considered unfeasible. This
document formally obsoletes RFC 5157, which first discussed this
assumption, by providing further analysis on how traditional address-
scanning techniques apply to IPv6 networks and exploring some
additional techniques that can be employed for IPv6 network
reconnaissance.
If we move to ipv6 majorly I suspect reflex scanning will become more of a thing (see a connection from X, scan X).
IPv4 is trivial to enumerate. IPv6 is not.
Guess how most SSH-scanning bots find targets?
Guess how most SSH-scanning bots find targets?
Probably saves them time. You are not a soft target. What incentive do they have to add support when it only gains them access to more hardened systems that most likely are not vulnerable to their next phase.
STARTTLS and its ilk are what happens when technology companies (& their minions) are pussies. It has been clear for decades that secure e-mail transport would be a good idea, but not if we had to actually upgrade software / systems to get it. This bullshit is so endemic that Google Mail has actually released two new standards in 2019, that depend on two other protocol stacks, just to advertise to SMTP servers that they support secure mail.
Thankfully, in 2018 someone had the balls to release RFC8314, which explicitly obsoletes cleartext for MUA <-> MSS <-> MAS mail. So why did Google release standards in 2019 that presume that some servers still won't talk TLS? My guess is they're terrified someone won't send them mail, and they'd lose some of that sweet sweet analytics money.
We clearly have an endemic problem in our technology culture related to breaking changes in order to fix shit. This is going to keep happening, unless we come up with new industry principles and practices to enforce breaking upgrades of legacy systems. If your system doesn't have a sunset date of less than 8 years, it should be considered broken out of the box. If it doesn't expect major feature overhaul after 4 years, it should be abandoned in favor of a system that does. Not having zero-downtime upgrades and rollbacks should be a non-starter too. Basically we need a "12 factor app" for protocols and systems.
Thankfully, in 2018 someone had the balls to release RFC8314, which explicitly obsoletes cleartext for MUA <-> MSS <-> MAS mail. So why did Google release standards in 2019 that presume that some servers still won't talk TLS? My guess is they're terrified someone won't send them mail, and they'd lose some of that sweet sweet analytics money.
We clearly have an endemic problem in our technology culture related to breaking changes in order to fix shit. This is going to keep happening, unless we come up with new industry principles and practices to enforce breaking upgrades of legacy systems. If your system doesn't have a sunset date of less than 8 years, it should be considered broken out of the box. If it doesn't expect major feature overhaul after 4 years, it should be abandoned in favor of a system that does. Not having zero-downtime upgrades and rollbacks should be a non-starter too. Basically we need a "12 factor app" for protocols and systems.
I'm OK with StartTLS. What I think is missing is a DNS record that mail servers cache for a long time, similar to HSTS that says you MUST use encryption for this domain. Probably also a variation to the record to say to validate the cert chain. This would align with an existing capability in postfix that allows you to specify which domains must be encrypted, or mandatory cert chain validation and to what level. At least I think this would be the easiest path to a better security stance and probably the simplest to implement given the myriad of email servers, clients and client libraries. Perfect is the enemy of good, or so they say. Below is from postfix. There are many more options.
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
example.net secure match=example.net:.example.net
anotherexample.net may match=anotherexample.com:.anotherexample.comIt sounds like you're asking for [MTA-STS](https://dmarcian.com/mta-sts/)
"MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers."(..)
"The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages."
"MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers."(..)
"The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages."
Maybe. Any time we ask a library or client to do HTTP fetches when it historically only did SMTP I become less optimistic about adoption. There are obvious easy wins like Thunderbird and Outlook and those could potentially use a plugin or add-on. Maybe that could be a good start and good enough.
IIRC AWS SES has always worked this way. I remember complaining years ago it wasn't compatible with Go's SMTP library for that reason(it expected STARTTLS).
Somewhat OT: What is Meddler-in-the-Middle? I can’t find anything about it, is it just another term for MitM, or is it more nuanced?
It's probably just a gender-neutral term that still begins with M, so "MitM" still makes sense to use as an acronym (yes, grammar nerds, I pronounce it as "mittem", don't say it's an initialism).
I have no idea what the actual answer is, and instead it seems several posts about it got downvoted. Sincerely, what the fuck? Is this some secret code that can’t be discussed?
> How important is this
This should be at the top of the post honestly
This should be at the top of the post honestly
someone should tell the openbsd guys https://github.com/OpenSMTPD/OpenSMTPD/issues/451 who explicitly tell certain users to use starttls
I totally support RFC 8314's attempt to standardize existing practice, and get port 465 officialy recognized. https://datatracker.ietf.org/doc/html/rfc8314 Once done, what is "standard" will no longer be an excuse. Though, updating out-of-support middleboxen will probably still take a while.