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
Kind of, smtpd_* is for when postfix is the server and smtp_* is for when postfix is the client (ie when it connects to another server to relay mail). At any rate this setting should only be used for submission and not for server to server communication otherwise you will end up blocking mail to and from other servers that do not support TLS (there are many). The default setting for this is "may" which is for "opportunistic" TLS which can fall back to plain text if need be.
If you RTFA you will see that the author is trying to submit mail to port 25 on his email server which is supposed to be for MX to MX communication only. If he were to submit to the proper submission port (587) he would likely find that the STARTTLS flg is not blocked by his ISP, in other words this whole article is a farce written by someone who doesn't know what they're talking about.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
It's just as secure as everything else.
As this incident proves using a policy of "tls if available" has a serious security hole. An attacker can make encryption appear to be unavailable and then sniff the plaintext when the system sends without authentication or encryption.
Emails multihop nature makes it very difficult to ensure that all the hops are enforcing appropriate transport encryption and authentication. If you want your emails to be secure then you need to use end to end encryption.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
It is very relevant. Roe versus Wade was decided base upon the constitutional right to privacy.
OK, so you've never had the need to communicate securely with someone who didn't live in your town. Lots of people do have that need, though, on a regular basis.
You are welcome on my lawn.
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;
Do you have citation for this? A single court that has found there's no privilege simply because a communication was sent between attorney and client by email?
After all, you say it's well known, yet all the lawyers I know use email pervasively to discuss client information.
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.
Just being deprecated doesn't mean it's necessarily a bad idea. I still prefer IMAPS/POP3S/SMTPS over this silly STARTTLS nonsense. For one it can't be hijacked as easily as these ISPs are doing.
For one it can't be hijacked as easily as these ISPs are doing.
...which they're *not* doing. This article is a farce written by someone who can't even configure his email client to use the correct port for submission. He's trying to use port 25 which is only for MX to MX communication and not for submission, he should be using 587 and if he did there would very likely be no problems.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
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.
It's easy enough to configure your mail server to not send if the STARTTLS command is ignored. It should treat it the same as a server that doesn't support TLS. If someone is concerned about email getting sniffed they will configure their server in this manner and will effectively be unable to send any mail over these networks. This should certainly fall under the Computer Fraud and Abuse Act, it's basically a denial of service attack.
Enigma
For one it can't be hijacked as easily as these ISPs are doing.
...which they're *not* doing. This article is a farce written by someone who can't even configure his email client to use the correct port for submission. He's trying to use port 25 which is only for MX to MX communication and not for submission, he should be using 587 and if he did there would very likely be no problems.
Bell Sympatico in Canada uses port 25 for encrypted client to server connections Port 587 times out. Completely non-standard fuckery, I realize, but it's certainly possible that this guy's ISP does something similarly stupid.
"City hall" in German is "Rathaus" Kinda explains a few things......
When someone other than a large corporation does it.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I'm pretty sure ISPs can't hijack people's copyrights just because they transmit the data.
Yeah, that would be like a photo sharing site saying they have permission to use your copyrighted photos for their own promotional purposes since you agreed to the TOS for their site.
Oh, wait...
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.
This....! Anyone who trusts a network to pass traffic untouched, maintaining privacy, etc. that is not owned by them is just fooling themselves.
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.
That's what we do here on the big-gov't email servers. Filtering for non-auth'd relays curbs spam quite cheaply. We already have an answer for ISPs who'd complain about rejection: "Tough."
Maybe we deserve this world ?