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?
When does this shit start to count as criminal? Say a company encrypts all communications with their mailserver and this is part of their legal requirements to protect privacy. Can we sue the pants off them yet?
Please, someone (insert large company here), lose all your data because of this!
No DMCA but I can make a pretty good defamation case. ISP is claiming email provider doesn't support TLS to the ISP's customer.
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.
DO NOT TRUST your email or internet connection, and DO NOT TRUST your cellphone
there is no privacy anymore, none, nowhere to be found anywhere, thanks to a government that has used terrorism as an excuse to snoop on EVERYBODY and EVERYTHING, George Orwell was a prophet, 1984 is here and now
Politics is Treachery, Religion is Brainwashing
Not setting *require TLS* in your mail client. Anyone else could do the same, not just your ISP
... encryption should begin on YOUR computer and end on the recipient's. This is why your data should not be stored in the cloud. This is why people need to pull their heads out of their asses and learn how to protect themselves and not rely on others (companies) to do it for them.
It sounds a lot less like the summary in terms of transmitting unencrypted mail data; from TFA (which, naturally, I didn't read before commenting), it sounds like they just got a failed connection over TLS, which is a lot different than "faking" that your data is encrypted and transmitting it as plaintext.
Is it just my observation, or are there way too many stupid people in the world?
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
Look, most severs these days are configured in such a way that STARTTLS runs on a different port than the plain-text connection. The server will reject login requests until the STARTTLS handshake is completed.
So sure, a few old, badly configured servers will continue over an unencrypted connection. But take it from a guy who worked on an email client, this is not a typical setup these days.
(Also: STOP USING STARTTLS!!!)
There's no -1 for "I don't get it."
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 this is happening to businesses, not just people, wouldn't this fall under espionage?
I believe the setting for postfix smtpd to smtpd is this:
smtpd_tls_security_level=encrypt
And for clients:
smtp_tls_security_level=encrypt
Any wizards with corrections or comments welcome!
Then complain to the isp that they have broken the email server.
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."
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
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
He's casting a wide net to cover all possibilities...
What the hell are you talking about? I don't see how limiting the government's power to ban people from controlling their own bodies is the same as Uncle Sam entering the wombs of fertile women. Care to explain?
It should be.
"If any question why we died, Tell them because our fathers lied."
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. If the sending side agrees to send unencrypted, then it is effectively consenting to send in the clear. No matter what happens between your client and the server there is always a chance a server in the forwarding chain will not preserve the TLS connection, nor is there any guarantee in most cases that the message recipient will access the message over an encrypted channel. God help us all, because corporations sure can't help themselves.
He could explain, but then he'd have to kill you.
This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.
Isn't this just hacking, in the criminal media-defined sense of the word.
With recent additions from patriot to fraud act, this smells a lot like "conspire to commit" at the very least. It certainly seems like unauthorized access, as you forced access to information you were not authorized to access.
Just because the internet protocols have lots of holes does not mean they can be legally exploited.
Is this a crazy thought?
1) Because SSL/TLS was so poorly supported for years, many email clients default to using security only if the server supports it. Email software should simply drop support for unencrypted SMTP, or report a big warning if the server doesn't support it. We would not tolerate such a proxy for the web, so we should not tolerate it for email either.
2) A recent Slashdot discussion revealed that the STARTTLS stripping was due to misconfigured proxy servers. I think this is a rehash of the same incident.
Some firewalls do this (or at least they did in 2006-7) on inbound email. The remote server would issue the EHLO command, and the firewall would convert it to HELO so no extensions (like STARTTLS) would be supported. This made it difficult to provide a secure channel for customers to send data via email. As this was happening in the firewall of a hosting center, we were able to persuade the authorities to turn off this misfeature in the firewall, at least for our traffic.
It is very relevant. Roe versus Wade was decided base upon the constitutional right to privacy.
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;
One problem to the argument is that it's not actually decrypting your messages, which the topic makes the mistake on.. it's just telling the client that the server doesn't support Encryption, in which the client will then sent in the clear.
Encrypt it on your system before you send it. Expect the recipient to decrypt it on theirs after receipt. Everything traveling on teh Internets is subject to interception.
Have gnu, will travel.
But you don't have to actually decrypt something to violate the DMCA. Can't you just be in violation for making a system to bypass decryption, which is in effect, what they have done. They are bypassing the encryption you are attempting to put on your work.
XDInd
Yahoo among others will solicit TLS but don't really support it and will bounce mail.
I've made the mistake 'respecting' TLS solicitations from third parties only for them to bounce my mail....
I would be surprised if this was malicious and expect they are stripping it out because its an absolute pain to properly support (thanks to bad players like Yahoo)
**Yahoo may have changed their game....its been a while since I tried it
https://protonmail.ch/
Basic blurb, from the website (I have no interest in the product other than as a user).
[quote]
Swiss Based -- Protected by Swiss Privacy Laws.
ProtonMail is incorporated in Switzerland and our servers are located in Switzerland. We are outside of US and EU jurisdiction and user data is protected by strict Swiss data protection laws.
Zero Access -- We can't read your data.
Because of our end-to-end encryption, your data is already encrypted by the time it reaches our servers. We cannot decrypt your encrypted messages and as result, we cannot share them with third parties.
Easy to Use -- Encryption without the headache.
Backwards Compatible
ProtonMail works out of any modern web browser, there is nothing to install. We are also backwards compatible with other email providers so you can continue sending and receiving emails from friends who are not using ProtonMail.
Forever Free
Available for everyone.
We believe privacy is a fundamental human right and should be available for everyone. That's why we offer multi-tiered pricing including a free version that anyone can use. Let's bring privacy back to the people!
Stay Anonymous
We don't track our users.
We do not keep permanent logs or require any personal information to sign up. We even accept anonymous payment methods (such as Bitcoin) so even paid users have their privacy rights protected.
Cross Platform
Mobile and tablet friendly.
ProtonMail works on all devices, including desktops, laptops, tablets, and smartphones. It's as simple as visiting our site and logging in. There are no plugins or apps to install - simply use your favorite web browser.
[/quote]
I still don't understand. It limited the government's power to control people's bodies. How is that Uncle Sam entering the wombs of fertile women? If anything, it's keeping Uncle Sam away.
Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.
Worst case they aren't breaking open the safe , they are just causing the option for the safe's door to remain open and unlocked.
FTFY
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.
But the described technique doesn't work with every email client. Therefore several providers updated there services to simplify the access.
Switch to Sprint. Verizon is not only shitty for doing this, they are a shitty carrier who cripple the capabilities of most of their phone's hardware. Verizon sucks, so jump ship on them.
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.
Check your contract, real careful like. You probably authorize it.
“He’s not deformed, he’s just drunk!”
...without the authority of the copyright owner...
Sure they don't have it?
“He’s not deformed, he’s just drunk!”
Hey, if I write an email, I own the copyright, correct?
What does it say in the ISP TOS?
I wasn't talking about the copyright. The first reply beat me to the punch(line)
“He’s not deformed, he’s just drunk!”
If the company is marketing itself as an Internet service provider and actively keeping its customers from the entire Internet then that's false advertising.
The ISP owes all of its customers who aren't getting the part of the Internet that they want to use a refund, and the company must either change its ways or change its marketing.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
... your server cannot be depended to do that.
I'm pretty sure ISPs can't hijack people's copyrights just because they transmit the data.
Copyright refers to ownership and/or permission to copy.
Copywrite is the act of copying with a pen.
Copyrite is when you do it religiously.
I didn't see anything in the Cricket Wireless TOS that requires giving permission to circumvent encryption. I skimmed through it though, so if you find something I missed, feel free to point it out.
The sender of the email presumably owns the copyright of the email. The ISP would need the senders permission to circumvent the encryption if that was the case. As per my response to the first reply that mentioned TOS, I didn't see anything in there claiming such permission.
There's a lot of medical traffic going over SMTP right now.
It goes SMTP with STARTTLS to the server, then the messages are encrypted by the server before being forwarded out via normal SMTP traffic.
If the plain text initial emails to the server are NOT getting encrypted, then we have a shiny HIPAA violation. That's some good time stuff right there, and it's not even the provider's fault.
Good times.
It's true that the DMCA could be invoked it there was intent.
But disabling the encryption support for all customers is basically not supporting it at all. So that's not intent.
What should happen is email clients need to identify email services that are no longer supporting encryption and warn the user. Likewise if an email was degraded in transit, it should notify the sender.
They are not removing encryption. Its more like you requested a secure https connection and they give you a plain http connection.
If you encrypted your email before sending it then it will remain encrypted.
This is transfer encryption when talking to an SMTP host. The server gets the full email in clear in this scenario, even if STARTTLS is left in.
Email encryption is what you do with PGP, there is not way to "strip that out", and the SMTP server cannot read the mail, just the headers.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
When does this shit start to count as criminal? Say a company encrypts all communications with their mailserver and this is part of their legal requirements to protect privacy. Can we sue the pants off them yet?
No. Because they are not removing *your* encryption. Think for a second, how could they do that, short of your ISP being the NSA. :-)
What they are failing to do is encrypt the channel between you and the ISP, its like you asked for secure https and they redirected you to plain http.
Its a non-issue for the legal and medical community since they will encrypt things as needed before it gets to the ISP.
And copywright is when you make your own airplane.
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...
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/
http://yro.slashdot.org/story/01/07/18/1136244/sklyarov-arrest-follow-up
So even a code written about by Julius Caeser (ROT) is covered by it.
They're in violating of the DMCA
Wait, they're ISPs so it doesn't apply
I've got better things to do tonight than die.
So sue them for 12 billion dollars like they do for music downloaders. (or is it just for big corporations?)
I've got better things to do tonight than die.
Hey, if I write an email, I own the copyright, correct?
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.
No, you misunderstand what is going on here.
StartTLS is something that happens when your email client connects to the mail server with an insecure protocol on a non-ssl port, and then asks the server to switch to a secure connection. Its your clue that you are doing it wrong,
Connect on a secure port over ssl (usually 465) instead of 25. Set your client up right to use a secure port and they can't deny a secure connection. (Unless they don't support security at all, in which case run away from them like your hair is on fire).
WITHOUT doing it right, your email was never secure, never encrypted, so no DMCA violation.
They aren't denying you a secure connection, they are just putting the burden on you to do it properly instead of having their servers to the extra work of switching an insecure connection to a secure one, which usually entails a whole bunch of handshake-security dance.
Set your client up the right way on the right ports.
Sig Battery depleted. Reverting to safe mode.
Finally, some on who gets it,
Set your client up right and stop all this hand wringing. Its a tempest in a teapot.
Sig Battery depleted. Reverting to safe mode.
Yeah, pretty sure.
Hey, if I write an email, I own the copyright, correct?
Then you have your client set to require encryption, not merely prefer it. And thus your client never sends an email in the clear, and thus they have not violated the DMCA or your copyright.
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.
If you do that, your emails will simply fail to send as per these guys who discovered the issue. You're right though, at least it won't fall back to unencrypted transmission.
OK so what we need is an option on mail clients "presume TLS support". Surely this is an area where open source software can demonstrate its advantage with a quick work-around
Privacy International in October 2014 made a criminal complaint to the National Cyber Crime Unit of the National Crime Agency, urging the immediate investigation of the unlawful surveillance of three Bahraini activists living in the U.K. by Bahraini authorities using the intrusive malware FinFisher supplied by British company Gamma.
Moosa Abd-Ali Ali, Jaafar Al Hasabi and Saeed Al-Shehabi, three pro-democracy Bahraini activists who were granted asylum in the U.K., suffered variously from years of harassment and imprisonment. Investigation and analysis by human rights group Bahrain Watch showed that while
Moosa, Jaafar, and Saeed were residing in the U.K., Bahraini authorities targeted the activists and had their computers infected with the surveillance Trojan FinFisher.
The complaint argues that the actions of the Bahraini authorities qualifies as an unlawful interception of communications under section 1 of the U.K.’s Regulation of Investigatory Powers Act 2000. By selling and assisting Bahraini authorities, the complaint argues that Gamma is liable as an accessory under the Accessories and Abettors Act 1861 and/or encouraged and assisted the offence under the Serious Crime Act 2007.
( Two PCs were infected and a Apple computer system was infected. They turned up at a meeting in their own country and was arrested. They have been given multiple life sentences and will never see the light of day again. All for the lack of an interactive firewall and an up-to-date virus scanner and a basic understanding of PC security ).
No, what it is doing (to borrow the analogy from an eralier posting) is opening every letter in an evelope, putting the contents in a see-through bag and adding a new addres label.
So, it will be perfectly OK is I figure out how to convince Blu ray players not to encrypt their HDMI outputs and I sell a solution to the general public?
Most email is not copyrightable; emails that contain just facts or business dealings.
Business email for example almost never is, therefor the footer that many companies append are a lie, and one could sue them for claiming copyright on something that can't be.
I wouldn't hang too much on the DMCA requirement that the protection method must be effective. In practice, the bar for effective isn't just low, it's buried under the sub-basement floor.
How can this work? Wouldn't the client notice that the STARTTLS command did not complete successfully and/or that the session is not encrypted?
I started using email!back!in!the!days!when!you!had!to!know!the!route, so I've never assumed emails are encrypted unless I use PGP or some equivalent tool.
I do not fail; I succeed at finding out what does not work.
Well, no no and no. See, by refusing to pass this header along to the next node, they're preventing encryption. They're not removing it. If you actually encrypted the message payload with PGP or similar, that stays encrypted.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The ISPs are not decrypting encrypted email. They are removing the flag in the header that tells the server to use encrypted connections between itself and other servers or clients.
This is a non-issue for those who encrypt their email contents.
Well played!
If I send clear text to the internet, it is because I don't give a damn who reads it.
However, when I wish my communications to remain private, I encrypt it myself before it ever leaves my local network.
If you don't care enough to encrypt things you wish to remain private, then you are the only one responsible for allowing _anyone_ to read your mail. Don't rely on some nebulous third party to provide _your_ protection against eavesdroppers. Take charge of your life dammit, and quite whining.
tl;dr: Encrypt it yourself and then it doesn't matter if the transport channel is encrypted or not. Stand up on your own and be responsible for yourself!
Surely it's an attempt at defamation by his ISP tampering with his traffic.
Ezekiel 23:20
I always assume that playwrights are toy RC plane makers.
Ezekiel 23:20
But it is a circumvention against an effective means of encrypting copyright'ed data. They are in violation of the DMCA and should be sued under a class action lawsuit.
Hey, if I write an email, I own the copyright, correct?
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.
No it isn't, because they encrypt it, not you. STARTTLS is encryption implemented by the provider. The message is only encrypted during passage from your mail program to their server, and from their server to another STARTTLS server, but that's it. The end receiver gets the message unencrypted in his or her mail program. It can be worse. If the provider from the receiver does not use STARTTLS, the message is not delivered encrypted.
And THAT boys and girls is why you should NEVER relay on a server side encryption. Encryption needs to ALWAYS be on the client side, and ALWAYS under the clients control and NEVER using an encryption tool provided by your ISP.
I wonder if Rogers (Canada) does this. My wife was unable to send email over SMTP from Thunderbird last night all of a sudden.
This is not as much of an issue when using PGP or something that encrypts the e-mail before it is sent to the server.
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
Well at least one of them will be write.
blindly antisocialist = antisocial
Email is an insecure medium. Anybody that pretends it isn't is going to have a bad time. Sure we might have some tricks to secure messages along some of the paths it's going to traverse, but if you expect it to be secured end-to-end, you're naive. If you absolutely must send something via email that contains sensitive information, GPG-encrypt the message first and then send it, otherwise seek a more secure medium.
If it's been identified one time, it's likely been happening on a larger scale but as yet undetected. It's becoming very easy to be either paranoid or self censoring. I don't have anything to hide, but being sliced/diced/dissected/analyzed by the big data cloud does get a little bit old. It's easy to see the results of this overreaching data collection, just research a medical condition (especially one that has a name brand pharmaceutical treatment), research a popular consumer appliance, research a new vehicle, etc... then pay attention to the advertisements that appear on websites over the next couple days... do you notice anything... like ads for what you researched?
I occasionally poison my search results by just doing random searches. I pick a person/place/thing that I have no real interest in, and watch the ad world turn. It must really throw off the "kevin by the beach" bucket when I search for Vespa parts, the latest gay romance novel, women named ISIS, and the 10 day weather for geopolitical sites of interest. http://www.weather.com/weather...
I guess "deactivate" and "impair" would fit the case?
No, what it is doing (to borrow the analogy from an eralier posting) is opening every letter in an evelope, putting the contents in a see-through bag and adding a new addres label.
Except that's not what it's doing. You're handing the letter to them and asking them to put it in an envelope, preferably one of those fancy ones that make it harder to see the contents, and send it. They're pretending like they don't have any of those fancy envelopes and instead putting it in a clear plastic bag. If you want it in a fancy envelope, make sure you specify that it has to be rather than that's what you'd like it to be.
Or, better yet, mask the contents yourself at the application layer rather than relying on the transport layer. X.509 and PGP are both pains, but they do work and would make this a total non-issue.
Life has many choices. Eternity has two. What's yours?
Actually, that depends strongly on the jurisdiction, "tampering with email" is a crime e.g. in Germany.
Well, you have to sell it under a brand that sounds like "Cisco" ;)
Curious if this affects HTTPS/TLS webmail. I use Fastmail.
Thanks...
Better safe than sorry.
Somewhere, something incredible is waiting to be known. -Carl Sagan
Seriously, my ears are bleeding because common sense is trying to murder them. If this isn't circumvention, I don't know what is.
It's not circumvention, because the e-mail was never encrypted in the first place. Seriously, why is that so hard to understand?
People have gone to jail before for doing man in the middle attacks to gain higher levels of access; even if this is not considered breaking encryption there should be plenty of other laws that have applied to hacking which apply here... except it's an ISP not a teen, researcher, or worst of all-- some kind of activist.
The encryption is a method I use to keep others from reading said copyrited work, correct?
Nope. In this case, the work is not itself encrypted, the communication channel to but one mail server is.
Apply GPG, GPG, or S/MIME encryption and your message body is still safe.
I like that argument and I hope it gets heard in front of a judge. I do wonder though since it is actually the packet from the upstream server that is modified and the sender is downgrading their security to accommodate, then sending an unmodified message is there a violation? Is their any legal protection that would stop an ISP from modifying the parameters, but not substance of the upstream mail server's packet? It seams like the upstream mail service provider is the one truly being wronged because the intent of their transmission has not been honored and has been modified without consent such as their ability to provide a secure service to their customer has been harmed.
So "copyrite" is when I see my neighbor sacrificing goats to a pagan god, and I do the same?
Hear that rumbling? That is the sound of millions of people joining a class action if this happens any more
Modder didn't get the joke did they?
If you encrypt your e-mail prior to sending, sure. But SSL and TLS aren't part of your e-mail. They components of the system for transmitting your email. Not part of the message you wrote.
Only boring people are ever bored.
AIUI, they are not tampering the client-to-MSA connection —where the client is often configured to require STARTTLS, port 465, or whatever— but the MSA-to-MX one. There are no guarantees that encription is available between eny two hops along the mail path, and there have never been.
Sorry, I was wrong. They intercept the client-to-MTA (or MUA-to-MTA) connection, the article says.
Port 25 is mainly used for relaying (which is what confused me). Malware doing direct-to-MX SMTP does in fact use port 25. Modern clients should be configured to use port 587 instead. Since port 587 (MSA) requires sender authentication, there would be no reason to block/intercept it.