Originally published at: http://boingboing.net/2017/03/03/muppets.html
…
…Think of it as an open records policy…
This is a big fat nothing. End users don’t communicate with The Met’s mail server directly. They send an email through their ISP or mail provider (e.g. GMail) and that connection will be encrypted. Yes, the connection from that server to the Met’s might be sniffable, but the chances of that are slim because that connection is from a “well connected” server to the Met’s server; you’re talking about probably a 1/2 dozen hops at most, all of them through a large internet exchange. The only attackers who could pull off such an attack are state sponsored and would therefor likely have the ability to MITM the TLS connection anyway!
It isn’t as bad a mistake as plenty of others you could make; but given the value of access to the Met police, an ‘eh, only nation states, or motivated adversaries with access to one of a number of telcos could possibly get in!’ approach to security seems like the wrong attitude.
It’s not nearly as juicy as having an MiTM between individual users of the system and the server; but assuming anything but the worst is generally not a good plan.
Really? Not SMTPS?
However, government organisations in the UK are only allowed to send protectively marked (classified) information by email by using the GSI - the Government Secure Intranet. This is a non-Internet connected secure network used by all UK government departments, and it is very secure indeed.
Not that it would do any harm to enable STARTTLS on their public facing servers though.
SMTPS used to exist but is no longer a thing (you would connect to TCP port 465 on a mail server, negotiate a TLS connection, and then speak SMTP over that connection). It was officially abolished nearly 20 years ago.
What most people use these days is SMTP (on TCP port 25), using the STARTTLS command within SMTP to negotiate an encrypted (and possibly authenticated) connection. For mail clients – as opposed to other mail servers – it is widespread to use TCP port 587 for message submission accoring to RFC 6409, which requires authentication and in many practical cases also STARTTLS-style encryption.
Getting a mail server to support STARTTLS is fairly straightforward and shouldn’t take more than a few hours, tops, especially since mail servers don’t require a fancy X.509 certificate signed by a certification authority. You can issue a self-signed certificate for your own mail server and that should be quite adequate since MTAs generally don’t check other MTA’s certificates the way web browsers do with web servers.
OK. So why does the URL I use to send mail via Gmail from my desktop client begin smtps://
? Is that just a legacy convention?
I don’t use Google Mail a lot but it seems that they still support SMTPS. This is probably on account of people out there who are running ancient versions of some Microsoft client applications (like Outlook for Mac or its predecessor, Entourage) that support direct SMTPS connections but not STARTTLS, and can’t or won’t upgrade.
The IANA has reassigned the official SMTPS TCP port (465) but of course that doesn’t prevent anyone from putting a SMTPS server on that port if they so choose, even though it has been formally deprecated. The official use for port 465 is now “source-specific multicast”, or SSM, which isn’t very useful on a mail server, so it’s not as if you were missing out on anything important.
If you’re going to be pedantic about it, STARTTLS isn’t SMTP, it’s only in ESMTP, because RFC3207 specifically references EHLO.
If you’re going to be empirically rather than academically correct, SMTPS is still quite broadly supported, at least in MTAs, albeit infrequently used.
Personally I approve of the pedantry approach!
I assumed he meant that users’ connections to webmail are HTTPS, not that MTAs are using it.
Ah. That makes more sense.
They should have talked to Mike Pence. He could have given them info on getting setup on AOL.
You’re 100% right about ESMTP, but the operative difference is really between TCP port 24 (or 587) plus STARTTLS, and TCP port 465 without STARTTLS. This is basically like HTTP vs. HTTPS, except that the STARTTLS equivalent for HTTP (as per RFC 2817, and more recently RFC 7230/7231) is not widely used to switch from unencrypted/unauthenticated HTTP to HTTPS.
MTA developers don’t mind supporting SMTPS because once you can handle SMTP and STARTTLS, also supporting SMTPS is very little extra trouble. It makes reasonable sense to deploy a SMTPS server if you’re Google because there may be legacy clients out there that can’t use anything else, but in a corporate context I would avoid doing so unless somebody with a lot of clout comes along and wants it.
Is anyone still using port 24 for private email? I thought that died with PUPnet and the all zeroes broadcast controversy, back at the dawn of the Internet. I think you mean 25.
Man, I didn’t even know there was a STARTTLS for HTTP, though!
Did I say 24? Oops. 25 is correct, of course. Thank you for pointing that out.
Phew. Thank god Juno’s/Cisco iOS/pans/sonicwalls never are misconfigured or have obvious glaring remote code execution vulns.
We need to have a talk. A very, very serious talk.
Certificate authorities are an extortionist swindle, a corrupt confidence game.
Unfortunately the con is complete as far as web commerce is concerned and there’s no way of avoiding the need to pay the extortionists.
But for email? Self-signed certs will work fine as long as you have DNSSEC, SPF and DKIM set up properly. Keys are better than certs…
If all you’re interested in is opportunistic encryption between MTAs, there’s no point in bothering with a certificate that is signed by a commercial CA, because very few if any MTAs will appreciate it – all they want is a key to encrypt their mail, and they can get that perfectly well from a self-signed certificate. In fact, MTAs can’t afford to insist on a certificate chain to a trusted root certificate because if they did, they would never be able to deliver their outgoing mail to many destinations. It would sure be nice if things were otherwise – it’s a bit of a chicken/egg problem – but as of 2017 they aren’t and that is unlikely to change anytime soon.
Personally I run my mail server with a certificate from Let’s Encrypt, which is both free and official and would make an MTA happy if it actually deigned to check the certificate chain. You have to jump through a few burning hoops to ensure that your certificate is reissued automatically every so often but it’s not that hard to do.
When I went to work for REDACTED the first thing I did was set up a normal double proxy using Nginx that would decrypt and re encrypt any TLS connection that didn’t have a valid bundle or chain.
The prices for certs? Insane. I ain’t paying a grand for a cert (well, I did for an EV code signing authenticode cert, different story) But self signed is the worst of all. I will mitm you, it is easy, and the only thing that stops me is that third leg of the stool, the chain.