Originally published at: https://boingboing.net/2018/06/26/hop-to-hop.html
…
5 Likes
Even more interesting than the project page itself is the list of STARTTLS-enabled servers that could be used to prevent downgrade attacks.
I look forward to the milter that can be used to query that list!
5 Likes
Speaking of which! Looks like there’s some tweaks we could use to improve our reliability, according to the EFF scorecard.
3 Likes
Between this and its legal campaign to make sure the Feds have a more difficult time poking their noses into the servers themselves the EFF continues to be an organisation worthy of all our support.
3 Likes
This is great news.
I run my own email server for private use. But I was also a messaging administrator for about 15 years, and can tell you that nobody really cared about getting the right certificates for mail servers.
A bank I worked for got around to it after I’d worked there for five years - and even then, most other banks we exchanged emails with didn’t bother. We could have turned on an option that would reject mail to and from any connection with an invalid certificate - but our analysis showed that if we did, we’d lose 90% of emails.
However, with that being said, the cobbler’s children have no shoes. My own private mail server uses self-signed certificates precisely because there’s no downside. I moved the websites on the same machine to HTTPS via LetsEncrypt, and added a To-Do for adding that same certificate to my mail server configuration - but I’ve just not managed to find the time. And the benefits are very low.
I’ll block some out so that I can use this project to get it done. Thanks EFF!
2 Likes
I wish em luck on this but don’t think this is going to be as easy as the campaign to encourage HTTPS.
Besides spam, the biggest volume of email is corporate. Since I work in security this issue has come up almost everywhere I’ve worked. End to end is honestly only for the most dedicated and the tin foil hat crowd and damn near impossible to manage at the corporate level so inevitably theres always “hey lets mandate STARTTLS with our third parties, child companies, partners, etc”. As the EFF page points out the chicken and egg problem gets in the way. As does the problem of getting all the possible MXs setup including the ones that are too old to support this and theres no budget to upgrade them.
Certificate non validation is also a major concern as it really brakes what enterprises are trying to achieve in the first place. Not only knowing that the channel is at least moderately secured but also that impersonation is unlikely to happen.
Unlike with HTTPS where users have a very visual indication of if it is there or not (despite all the fraud going on around domain registration (hello letsencrypt) things appear right. Theres currently no such visual indication for email. CFO Alice in Finance has been told that she can send secure mail to barbara@consultant.com about last year’s audit. Unfortunately Alice doesnt know that in fact it isn’t or that because of how SMTP works in the first place, the first hop was but the second wasn’t.
Its a hard problem but I guess you gotta start somewhere.
EDIT: @doctorow technically STARTTLS sint a protocol of its own, its just part of the SMTP protocol
2 Likes
My employers have been using opportunistic TLS (aka StartTLS protocol extensions) for mail (SMTP & IMAP) for at least 15 years now, and for LDAP for a couple of years less, and for IM (jabber/XMPP) since it existed.
This is sort of bare minimum competency level that any Internet connected organization should demand from system administrators. It’s very very simple, after all, and there aren’t enough ports under 1024 for duplication of the existing protocols as encrypted protocols.
Email admins at this point should be implementing DKIM, which means actually talking to a DNS admin, quelle horreur!
If you can’t do it, face it, you can’t do the job, find another one. Don’t you know, you could make more money as a butcher?
1 Like
I’ve love to spend a couple hours getting SPF, DKIM, and DMARC set up on our mail gateways here at [redactedCo]. Problem is, I don’t exactly have a test environment in the event something goes wrong, and our end users get… cranky if the email system goes down for for than… five minutes. 
Once our project load gets a bit easier, I’ll get it snuck in at some point. (or I’ll force the issue)
Start with just publishing SPF, in the mode where it is essentially ignored - a TXT record with “v=spf1 +a +mx +all” is easy enough and does nothing except let you run tests. Set the dns ttl low (like a minute or two) while you are testing it.
Then set up the real SPF record with a softfail and test again - “v=spf1 +a +mx ~all” perhaps. Send some invalid mail from your own PC workstation or a server that’s not supposed to send domain-level mail and see what happens.
Publishing SPF takes maybe 15 minutes of work if you have root access to your DNS servers. 20 if you have true split internal/external DNS. If you haven’t ever written an SPF record it’ll take another 20 minutes of research beforehand.
When you get it all working, and have hardfail in place, you will discover the weird and stupid things your users are doing without your knowledge, many of which may well be illegal under federal regulation. You won’t be happy while you are dealing with that, but you will be very happy after you’ve solved their problems with sane email methods.
And once you are publishing SPF you will necessarily understand it well enough to use it on the mail you’re accepting (although in modern mail servers that’s usually just clicking on a button or enabling an option, no real effort required).
::nods:: did the research already, have the spf records all ready to put in. DKIM and DMARC will need some minor additional work (iirc, I may have to buy a second certificate for our other mail gateway instead of having the two share one). at this point I just need to get time to set it up and convince the higher ups that this is a Good Thing and Something We Need To Do.
1 Like
I don’t see why this would be necessary unless you were not using proper CN’s in your certs to begin with or something.
letsencrypt makes a lot of that stuff trivial now as well, especially if you can manage their DNS-based authentication for wildcard certs.
1 Like
Ooh, thanks, didn’t know about that! Schwifty!
Maintaining a standards-based CA that does not use proprietary software is annoyingly difficult. Mad props to letsencrypt!
1 Like
This topic was automatically closed after 5 days. New replies are no longer allowed.
