Hacker News Reader

Comment by dijit | Hacker News Reader

Are we pretending browsers aren’t a universal app delivery platform, fueling internal corporate tools and hobby projects alike?

Or that TLS and HTTPS are unrelated, when HTTPS is just HTTP over TLS; and TLS secures far more, from APIs and email to VPNs, IoT, and non-browser endpoints? Both are bunk; take your pick.

Or opt for door three: Ignore how CA/B Forum’s relentless ratcheting burdens ops into forking browsers, hacking root stores, or splintering ecosystems with exploitable kludges (they won’t: they’ll go back to “this cert is invalid, proceed anyway?” for all internal users).

Nothing screams “sound security” like 45-day cert churn for systems outside the public browser fray.

And hey, remember back in the day when all the SMTP submission servers just blindly accepted any certificate they were handed because doing domain validation broke email… yeah

Inspired.

View on HN

> Or opt for door three: Ignore how CA/B Forum’s relentless ratcheting burdens ops into forking browsers, hacking root stores, or splintering ecosystems with exploitable kludges (they won’t: they’ll go back to “this cert is invalid, proceed anyway?” for all internal users).

It does none of these. Putting more elbow grease into your ACME setup with existing, open source tools solves this for basically any use case where you control the server. If you're operating something from a vendor you may be screwed, but if I had a vote I'd vote that we shouldn't ossify public PKI forever to support the business models of vendors that don't like to update things (and refuse to provide an API to set the server certificate programmatically, which also solves this problem).

> Nothing screams “sound security” like 45-day cert churn for systems outside the public browser fray.

Yes, but unironically. If rotating certs is a once a year process and the guy who knew how to do it has since quit, how quickly is your org going to rotate those certs in the event of a compromise? Most likely some random service everyone forgot about will still be using the compromised certificate until it expires.

> And hey, remember back in the day when all the SMTP submission servers just blindly accepted any certificate they were handed because doing domain validation broke email… yeah

Everyone likes to meme on this, but TLS without verification is actually substantially stronger than nothing for server-to-server SMTP (though verification is even better). It's much easier to snoop on a TCP connection than it is to MITM it when you're communicating between two different datacenters (unlike a coffeeshop). And most mail is between major providers in practice, so they were able to negotiate how to establish trust amongst themselves and protect the vast majority of email from MITM too.

> Everyone likes to meme on this, but TLS without verification is actually substantially stronger than nothing for server-to-server SMTP (though verification is even better). It's much easier to snoop on a TCP connection than it is to MITM it when you're communicating between two different datacenters (unlike a coffeeshop). And most mail is between major providers in practice, so they were able to negotiate how to establish trust amongst themselves and protect the vast majority of email from MITM too.

No, it's literally nothing, since you can just create whatever TLS cert you want and just MITM anyway.

What do you think you're protecting from? Passive snooping via port-mirroring?

Taps are generally more sophisticated than that.

How do I establish trust with Google? How do they establish trust with me: I mean, we're not using the system designed for it, so clearly it's not possible- otherwise they would have enabled this option at the minimum.

> No, it's literally nothing, since you can just create whatever TLS cert you want and just MITM anyway.

> What do you think you're protecting from? Passive snooping via port-mirroring?

Yes, exactly. For datacenter to datacenter traffic, passing snooping is much easier for small-time criminals to achieve than a MITM. You can do it just by having a device on the same L2 switch domain and spoofing the MAC table (MAC spoofing/port security being un- or mis-configured is typical in those environments). No need to compromise routing at all.

> How do I establish trust with Google? How do they establish trust with me: I mean, we're not using the system designed for it, so clearly it's not possible- otherwise they would have enabled this option at the minimum.

Establishing trust with Google specifically is super-simple: their SMTP servers all have valid public PKI certificates and have for a long time. Even if they didn’t, they could give you an internal CA root to verify them. This doesn’t scale to lots of orgs, but almost all legitimate email traffic is between Google, Microsoft, Yahoo, and the top 10 marketing/transactional email services.

That’s why nobody was in a rush to solve the SMTP MITM problem. Plus, since SMTP for delivery is not authenticated at the application level, you only have to really worry about snooping/preventing delivery. If you want to send fake emails, the certificates provided by the server are irrelevant - there’s no password that you need to steal.

Reply on news.ycombinator.com