Get cracking on STARTTLS says Facebook Facebook has debunked the idea that SMTP STARTTLS encryption still isn't taking hold, after an analysis of the billions of messages it sends to millions of servers each day. In this blog post, The Social NetworkTM says the numbers are clear: “STARTTLS has achieved critical mass and there is immediate value in deploying it”, …
Facebook is concerned with privacy in communications!
Only until they have it on their servers. I suspect it's for the same reason Google started using SSL: to prevent others on the wire from grabbing the same data. Let's not forget that once the data has *cough* "safely" *cough* arrived at Facebook (or Google) it will immediately be scanned for whatever juicy bits or keywords the NSA is after that day.
The fact that is has arrived over SSL, sorry,, TLS (still have to get used to that) won't make a difference...
What's the conclusion of this research? Are they going to start blocking anything without STARTTLS?
Certificate mismatch isn't really a problem, just an example of the problems in the certificate infrastructure. I've been using TLS for all my e-mail for over ten years with my domains but not my mail servers.
> Encryption without authentication doesn't protect your content.
Right, but it is still worth doing because it is cheap and because it protects against passive monitoring which is often used in datagobbling dragnets.
Security is not a binary yes/no question! Just because somebody can smash your windows you don't remove the locks on your front door.
Instead of http we should also use unauthenticated SSL in https IMHO. It is not perfect, but it is certainly better than clear-text http!
Best regards
Steen
"Encryption without authentication doesn't protect your content."
If you follow that route you could just as well say that SSL authentication isn't worth anything as it relies on central trust-centres operated by rather shady organisations. SSL authentication is broken, period.
However SSL is still useful for encryption. It raises the bar from a passive attacker to an active one. That's a lot more effort and makes it a lot more likely to be detected.
As with browsers, I wish they would display a graphical version of the fingerprint of the key. That way a user could easily check it by taking a glance at it.
"Without a valid certificate ..... all you are doing is stopping people from being able to decode the content just by sniffing the packets."
Yes. Which is exactly why I configured my mail server to use STARTTLS in the first place. I simply want to prevent people on the wire seeing my emails, not prove to myself that I know how to buy a globally recognized SSL certificate.
I always thingkthat this is solving the wrong problem.
Emails need to be encrypted end to end, encrypt them in the users client and decrypt them in the recipients client. Encrypting the links isn't a good solution.
The theat of someone grabbing my emails off the wire is less than that of someone reading them at facebook or google or (random email provider).
They should be encrypted until they are in my email agent.
So there is little point in this.
I somewhat disagree, but figured a downvote would be a bit strong. I use STARTTLS on my mail server and its excellent for convenience. I don't expect emails going out to be encrypted, although they might be. It does mean that emails I send that stay on the server are encrypted though (in transit), i.e. to other family members. I asked on my local LUG list how many people had non-tech family or friends using PGP etal. None, Not scientific, but an okay representation, I think.
Yes... and no...
Clearly encrypting client to client is preferable for those who actually use desktop clients, or a webmail service that supports PGP/public-private key encryption. But sadly the general public are not up to maintaining their own PGP keys and doing that. They just want to fire off a barbeque invite quickly and easily.
However, for those using exclusively the likes of Hotmail, gMail, etc, encrypting in transit makes life that bit harder for spooks - they can't just dragnet them on the wire (as easily), they physically have to hack the mail server or get a warrant to access the messages at the provider (and unless you run your own mail server, no provider is immune to warrants and court orders, short of burning all the data like Lavabit chose to).
You're not wrong, in that end-to-end is far superior, but as most people don't actually store their email locally, it's a moot point. The data is no more secure than the SSL connection to the webmail interface they use to read and write their emails, thus an SSL-alike level of encryption in transit is appropriate.
However, for those using exclusively the likes of Hotmail, gMail, etc, encrypting in transit makes life that bit harder for spooks - they can't just dragnet them on the wire
If the email was encrypted in the users client, they still can't read it off the wire, so I'm not sure what your point is.
If they use a web-based client, their "client" is the web server servicing their requests, and all communication with that is SSL already (or should be). The "client" receives data over SSL, immediately encrypts it with the target users public keys, and stores a version encrypted with the senders public key (for sent mail).
Handling the decryption on the client side would require a piffly JS cryptography standard.
STARTTLS is popular with service providers because it gives point-to-point security whilst still allowing the service provider to do whatever they like with your cleartext - the poacher is telling the gamekeeper how to fix his fences.
We spend billions on making sure Joe Sixer can watch DRM'd HQ cat videos in his browser without the chance of Joe being so evil as recording it, but we cant spend 1% of that to properly fix email security...
That depends on the problem you are trying to solve
STARTTLS for MX records may not deliver perfect secrecy (or security), but it does provide a layer of protection. e.g. it stops someone from using Carnivore (or whatever it is called this week) to get the sender and recipient information, since the session is encrypted. PGP or S/MIME (the encryption option, not the signature option) cannot mask the envelope and headers, they have to be plain text, hence channel encryption becomes interesting.
Also, if you are doing Authenticated SMTP, STARTTLS should be required, not optional.
Re. @theodore
Ars Technica (don't know whether that reference will get past the moderator :-) covered setting up an email server in a very good multi-part article series recently. You could Google for that. Or look up the ISPMail tutorials. Both of those would be good places to start/refer to.
Minor tweak on the question from @theodore - I'm wondering if there's an *easy*/convenient way to double-check whether STARTTLS is correctly set up on a domain.
For example, an email address I can send mail to from my domain, or a service that can be pointed at an email address on my domain, and which will return results on whether STARTTLS is correctly set up.
Thoughts/suggestions?
MTIA
I'm wondering if there's an *easy*/convenient way to double-check whether STARTTLS is correctly set up on a domain.
- Telnet to port 25 on the server in question.
- Type "EHLO my.example.com"
- Look for the line "250-STARTTLS" in the result
- Type "quit" to get out of the session.
Vic.
Thanks for all the suggestions and feedback.
mxtoolbox.com was an easy way of checking whether STARTTLS is stated as being supported - just do an MX lookup on the chosen domain to identify the MX server(s) and then click on the "SMTP Test" button for each MX server. The "Session Transcript" box then shows the response to EHLO - as per comments, you're looking for "250-STARTTLS".
However, http://checktls.com is vastly better (since it's designed just to check TLS) - does a very detailed check of all MX servers, and gives a commented, easy to understand, session transcript/analysis. Amongst other things, it checks the full certificate chain and gives a nice colour-coded summary results panel.
So with the email address/domain I was interested in, MX servers include service19.mimecast.com and service20.mimecast.com. The results tell me that both have incorrect certificate chains because Mimecast are using certificates issued for *.mimecast.com instead of the specific service19 and service20, and include RFC references. The summary results include the helpful message that:
"Note: Cert failures do not affect TLS encryption, but may mean the site isn't who they say they are."
Another email address I tried has Google providing all MX servers, and passed all checks.
Yahoo fails for the same reason as Mimecast.
Interestingly, there's a lot of variation in the crypto algorithms used, which is interesting since I would expect there to be some kind of an industry consensus on what to use. Thoughts/comments anybody?
:)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
