Slashdot Mirror
ISPs Removing Their Customers' Email Encryption
Presto Vivace points out this troubling new report from the Electronic Frontier Foundation:
Recently, Verizon was caught tampering with its customer's web requests to inject a tracking super-cookie. Another network-tampering threat to user safety has come to light from other providers: email encryption downgrade attacks. In recent months, researchers have reported ISPs in the U.S. and Thailand intercepting their customers' data to strip a security flag — called STARTTLS — from email traffic. The STARTTLS flag is an essential security and privacy protection used by an email server to request encryption when talking to another server or client.
By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted. Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.
By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted. Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.
This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.
Is it just my observation, or are there way too many stupid people in the world?
I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.
Okay.. I assume that's the reason. The people who believe in encryption will just have to encrypt their mail before it leaves the machine. That's just the way it is. How many times does it need to be said? If you want something done right...
How is it that anybody trusts their providers with the kind of history they have? I mean, can we tawk?
“He’s not deformed, he’s just drunk!”
The encryption is a method I use to keep others from reading said copyrited work, correct?
This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.
XDInd
This.
Law firm emails are protected by attorney–client privilege and medical emails are protected by HIPAA, for instance.
For another entity to expose those communications should fall under FCC jurisdiction.
It little behooves the best of us to comment on the rest of us.
I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate. The IMAP server also requires encryption and won't accept unencrypted connections. If my ISP starts pulling anything that disables encryption, my e-mail will start failing with errors. I'd recommend all mail servers be configured this way.
It's disappointing that we're increasingly having to treat our ISPs as obstructions to be worked around or opponents that need to be defeated for things to work right. We're paying them that monthly subscription to carry our traffic, we oughtn't have to jump through hoops to get our traffic carried without interference.
If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.
The world's burning. Moped Jesus spotted on I50. Details at 11.
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
Maybe he's suggesting to just use plain SSL without the initial plaintext exchange and initiation.
Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.
Editor, A1-AAA AmeriCaptions
Look, most severs these days are configured in such a way that STARTTLS runs on a different port than the plain-text connection.
Wrong. STARTLS specifically allows for both plain text and TLS on the same port.
The server will reject login requests until the STARTTLS handshake is completed.
Partially correct. A well configured server will behave this way on the *submission* port (587) but if the MX port (25) were configured this way then you would be blocking a lot of legitimate email from old servers on the internet that do not support STARTTLS and as such is is not recommended to require STARTTLS for port 25 MX to MX communication. Also even when STARTTLS is used the connection is still plain text until STARTTLS is negotiated.
But take it from a guy who worked on an email client
Thanks for giving me a link to yet another piece of software written by someone who doesn't understand the technology behind it.
(Also: STOP USING STARTTLS!!!)
Wrong again. The only way to have an encrypted SMTP submission channel without STARTTLS (other than tunnelling through ssh or something like that) is via SMTPS (port 465). SMTPS is long ago deprecated and should not be used. Port 465 was *never* officially registered for this use and was essentially "hijacked" and there are only a very small number of old email clients that support SMTPS but do not support STARTTLS. You *should* be using STARTTLS over port 587 which is the submission port. Also STARTTLS is the only legitimate means of encryption between a submission server and an MX.
Of note (which I've also said elsewhere), the real reason the author of the original article had problems is because he is trying to use port 25 for submission. He should be using the submission port (587) and it is highly unlikely that his ISP would be blocking the STARTTLS flag on that port.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.
That's the point of using DMCA, it didn't require "doing it right". Even if ROT13 was used, DMCA still applies.
Oliver.
Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?
Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.
That's still circumvention in my books. http://www.law.cornell.edu/uscode/text/17/1201
to “circumvent a technological measure” means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner;
This is one of the most irritating thing in IT. People think they can figure out law, accounting, fiscality, politics, marketing or diplomacy by using what they perceive as "common sense".
Here is the thing. All those disciplines are a gray area by nature, and the right answer is largely a matter of professional interpretation. Can you put that number in that column? Can you consider that such or such situation has caused actual damage to someone? There's no compiler to tell you if this is right or not, there's just people navigating a fuzzy field armed with their experience and knowledge. They live in a world where two people can have opposite opinions and be both right at the same time.
Anyone with a background in applied disciplines like IT or engineering is trained to look at things with a problem-solving angle. That's a great attitude, but unfortunately it sometimes make people overestimate their grasp of concepts that are outside of their area of expertise. It's a lot like those artists who have it all figured out (war, terrorism, pollution, crime, poverty). Case in point: this "enlightened" feedback from Ben Affleck during Bill Maher show: http://www.youtube.com/watch?v...
Don't be that guy.
lucm, indeed.
It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.
The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.
Obnoxious as their behavior is, I don't think the copyright violation holds. Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.
And this doublespeak legalese bullshit right here boys and girls, is exactly fucking why you use your own encryption.
Seriously, my ears are bleeding because common sense is trying to murder them. If this isn't circumvention, I don't know what is.
Here's another litmus test. If it were illegal, ANY ONE OF US would be behind bars. No questions asked.
Here's yet another litmus test. Why is it NOT illegal to tamper with email encryption. This would be akin to the postal service purposely using steam generators on snail mail processing lines and then us overhearing "whoops, I don't know how all this mail got opened accidentally..."
If we wouldn't stand for them doing such a thing in the physical world, I don't see why the hell we stand for it in the virtual one.
The headline is wrong. The ISP is removing the mail server's announcement that it supports STARTTLS, and your mail client/server sends your email unencrypted.
The solution to that is using SMTPS on 465, where encryption is presumed, not negotiated. But that was deprecated soon after the RFC came out in favor of TLS. It's almost like someone was thinking ahead and wanted the internet to be less secure:
http://cr.yp.to/talks/2014.10....
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
He's casting a wide net to cover all possibilities...
Its a Mountweazel in case someone plagiarizes his wonderful post.