ISPs Removing Their Customers' Email Encryption 245
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.
DMCA (Score:4, Interesting)
This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.
Always RTFA (Score:2)
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.
Re:Always RTFA (Score:5, Insightful)
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.
Re: (Score:2)
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.
Security holes and poor security does not make it legal to take advantage of suck security holes.
Re:Always RTFA (Score:4, Insightful)
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.
To illustrate the above point (Score:2)
http://yro.slashdot.org/story/01/07/18/1136244/sklyarov-arrest-follow-up
So even a code written about by Julius Caese
Re: (Score:2)
Oh come on.
It's always hilarious when people pretending to be techies on slashdot discuss technical matters without understanding the matter at hand.
There is no encryption being removed here. What is being removed is the negotiation of encryption. There's a huge difference.
What happens here is that modern MTAs that are configured to use TLS will issue a STARTTLS command to the receiving email server. If the receiving email server is configured to accept TLS connection, it will respond in kind. If it rej
Re: (Score:2)
There is no encryption being removed here. What is being removed is the negotiation of encryption. There's a huge difference.
So there would have been encryption, but due to their MITM attack there isn't.
As a reasonable person, that sounds like "removing the encryption" to me.
Just as my wife might say she removed the salt from a meal she prepared, even if she simply elected not to put the salt specified by the recipe into it.
The salt isn't there. Normally it would be. Enough said. We generally all understand
Re: (Score:3)
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.
Re: (Score:2)
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.
In this case, sending email over TLS is akin to browsing the web over TLS: You let the browser / MTA handle the encryption at a lower OSI layer than the application layer. Thus, it works transparently and without hassle to the end user. Would you suggest using GPG to manually encrypt and decrypt all your communication with any HTTPS website?
Note that the STARTTLS command is a fix for using port 587 to send encrypting mail instead of the port which is dedicated to it: port 465. It is like sending HTTPS down
Re:DMCA (Score:5, Insightful)
1. Does it violate user expectations and privileges? Not a DMCA violation.
2. Does it expand provider powers or control? Not a DMCA violation.
3. Does it interfere with provider profits or government investigations? DMCA violation!!! Kill it!! Kill IT immediately!!!!!
Computer Fraud and Abuse Act (Score:2)
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?
They are not removing encryption, more like ... (Score:2)
If you encrypted your email before sending it then it will remain encrypted.
Re: (Score:2)
It actually trips over a couple of crimes. Firstly freedom of speech, the STARTTLS being your electronic speech, so invasion of privacy, illegal warrant less search and seizure as in searching your message and seizing the STARTTLS message. As your message is copyrighted and it is you intent to protect you copyright via encryption in disrupting your chosen encryption method, considering it is a private network communication between you and another party, they are hacking your network for which you and anot
Re: (Score:2)
Re: DMCA (Defamation) (Score:5, Interesting)
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.
Re: DMCA (Defamation) (Score:5, Funny)
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
Re: DMCA (Defamation) (Score:4, Insightful)
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 [reference.com] in case someone plagiarizes his wonderful post.
Re: (Score:2)
Well played!
Re: (Score:2)
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 a
Re: DMCA (Defamation) (Score:5, Insightful)
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 [cornell.edu]
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;
Re: (Score:2)
Hey, if I write an email, I own the copyright, correct?
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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...
Re: (Score:2)
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.
Re: DMCA (Defamation) (Score:2)
Re: (Score:2)
Re: DMCA (Defamation) (Score:4, Insightful)
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.
Re: (Score:2)
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?
YANAL (Score:5, Insightful)
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... [youtube.com]
Don't be that guy.
Re: (Score:2)
Re: (Score:2, Troll)
Call it IT doublespeak.
IT people constantly rag on people for not wanting to learn about computers. Yet those are the same people who aren't willing to learn about law (or even details about IP law - how many have confused copyrights, trademarks and patents?), economics (there's a reason why we have both MICROeconomics and
Re: (Score:2)
No, the most annoying thing in IT is the person you're responding to, who doesn't understand how TLS for email works in the first place, but pretends to do so, and participates in discussions as if he knows the subject matter at hand.
The error being that there is no encryption applied by the person who writes the email, but opportunistically by the email servers if both sending and receiving email servers supports TLS. This is done transparantly to the end users (ie the people who write the email).
Re: (Score:2)
For most of those things, you probably have a point. But law is in the domain of the public. It is our right to make legal judgement since the law belongs to us. That's why at the end of the day it comes down to 12 jurors picked out of the general population (in theory).
Re: DMCA (Defamation) (Score:5, Informative)
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.... [cr.yp.to]
Re: (Score:2)
Finally, some on who gets it,
Set your client up right and stop all this hand wringing. Its a tempest in a teapot.
Re: (Score:2)
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 y
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Meh (Score:5, Insightful)
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.
Re:Meh (Score:4, Funny)
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.
For a previous job I was working onsite in a different country to my home office. For what ever reason my boss had pissed me off, so when he said he was going to email details of a salary increase I decided to yank his chain and played the "email isn't secret, and anyone could intercept it" card just to see what hoops he would jump through in order to "securely" send me this "sensitive" data.
His solution was to send me two emails. The first email had a password protected zip file that mentioned that the salary details were inside. The second email stated that the password for the zip file was "the company name backwards". Both emails of course being sent from the company domain. Given how brain-dead his solution was I concluded that I had got my monies worth from that stunt.
Re: (Score:2)
His solution will stop around 95% of all people listening in. 95% is better than 0%.
Re: (Score:2)
Since his solution would not stop anyone committed to mischief, your "95%" is functionally the same as "0%".
Or am I thinking about it wrong?
Re: (Score:2)
As long as there is no reference to the password being emailed separately, it is fairly reasonable basic level of security. If someone cares, the zip password protection is weak enough that it won't keep a secret long from the boogeyman.
Re: (Score:3)
It is disingenuous to compare a physical lock to a cryptographic algorithm. The latter can be far more secure.
Ah...slight correction, Anonymous grasshopper.
The latter is assumed to be far more secure.
Re: (Score:2)
Re:Meh (Score:4, Insightful)
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.
Yeah. Use gnupg or something of its ilk for end-to-end encryption. It's not like a bazillion system administrators like myself can't read all of your email anyway. TLS in this regard would be handy if you're on an open wi-fi and are sending login information to the mail server... maybe.
Re: (Score:2)
TLS in this regard would be handy if you're on an open wi-fi and are sending login information to the mail server.
Yeah, that's pretty much all that STARTTLS really accomplishes.
Re: (Score:2)
But many people don't use encryption for e-mails for being difficult like those computer newbies. :(
Authentication (Score:5, Informative)
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?
Re: (Score:2)
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.
And when you make assumptions, what happens?
Still don't feel like getting angry?
I only feel like getting angry at two people. The people who make encryption optional the default, and you — because you're making excuses for stupidity. You're enabling idiots. Stop it.
Re: (Score:2)
What about your username and password? Blocking TLS also sends your credentials in plaintext.
subject to eavesdropping and interception (Score:3, Insightful)
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?
Requiring encryption server-side (Score:5, Insightful)
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.
smtpd_tls_security_level=encrypt (Score:2)
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!
Re: (Score:3)
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 th
Re: (Score:2)
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.
So, when the client sends AUTH PLAIN <b64-encoded username+password>, and your server rejects the request because it isn't encrypted, you're happy with this result?
Re: (Score:2)
If any AUTH command comes in from a client over an unencrypted connection, yes it'll be rejected. This is by design, my server requires encrypted connections to the client to prevent eavesdropping on e-mail. If that command comes in over an encrypted connection, it won't be rejected.
The server also advertises TLS when receiving mail and prefers TLS when sending mail for the same reason. It'll use unencrypted server-to-server connections if the other side absolutely insists on it, but that's not it's first c
Re: (Score:2)
Since you're having trouble reading between the lines, I'll explain:
1. Unfortunate client is set to prefer (not require) encryption.
2. Client connects to server.
3. Client sends STARTTLS request.
4. MITM rejects STARTTLS request.
5. Client sends AUTH command, with username and password, over unencrypted channel.
6. Server rejects unencrypted AUTH command.
7. MITM issues STARTTLS request.
8. MITM issues AUTH command with the password it just stole.
This can, incidentally, be done over any public network by a MITM.
Re: (Score:2)
Typically, the mail server won't even advertise the AUTH command until after the connection is encrypted.
If your mail client is sending unadvertised commands, you should probably file a bug report.
Re: (Score:2)
As a man-in-the-middle, how difficult do you think it would be to add 250 AUTH PLAIN to a cleartext server response?
Re: (Score:2)
Ideally the client would be correctly configured too.
If all clients were somehow correctly configured (which they won't be, because Users), then OP wouldn't have any need to configure his mail server to reject unencrypted authentication attempts in the first place.
Anti-Spam Measure? (Score:4, Insightful)
Re: (Score:2)
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
Yes and that's exactly what's happening, FTFA:
They determined Cricket was intercepting and blocking STARTTLS on port 25
(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).
Absolutely correct, with the exception that smtps is long deprecated and only port 587 (submission) should be used for the submission of email.
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.
This is fairly normal. Many ISPs simply block outbound port 25 rather than filtering out STARTTLS. Personally I think that's the better approach for these ISPs (to just block the port alltogether), but either way this article is a bunch of crap written by someone who can't even set his email client to connect to the rig
Re: (Score:2)
I am aware of port 25 being depreciated, but not 465. Is there an RFC that I should be reading? I still submit mail specifically on port 465 so that I can avoid STARTTLS and require encryption. Of course, seeing how I manage the MTA I have that luxury.
If port 465 is no longer recommended I would like to know when and why that happened. Thanks.
Re: (Score:2)
I think you've got it the wrong way round - 465 (SMTPs) is deprecated, 25 is still the standard SMTP port.
Don't blame the ISPs for STARTTLS (Score:2)
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.
Re: (Score:2)
Email software should simply drop support for unencrypted SMTP, or report a big warning if the server doesn't support it.
Mozilla Thunderbird already shows a big scary warning [mozilla.net] when you try to set up an account without encryption.
Preferred Solution (Score:2)
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.
s/flag/command/ (Score:3, Informative)
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.
This is _not_ "email encryption"! (Score:2)
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.
Sue them (Score:2)
They're in violating of the DMCA
Wait, they're ISPs so it doesn't apply
Breaking encryption? (Score:2)
So sue them for 12 billion dollars like they do for music downloaders. (or is it just for big corporations?)
OK so what we need is an option on mail clients (Score:2)
How can this trick work (Score:2)
I've always assumed there is no encryption (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
It is very relevant. Roe versus Wade was decided base upon the constitutional right to privacy.
Re:Okay, so (Score:4, Insightful)
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.
Re: (Score:2)
It's well known that email is not secure for the purposes of attorney/client privilege.
Re: (Score:2)
It's well known that you don't EVEN know that.
It's just as secure as everything else.
And more secure than the USPS VPN, certainly.
Re: (Score:3)
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.
Re: (Score:3)
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 [wikipedia.org], it's basically a denial of service attack.
Re: (Score:3)
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.
Re: (Score:3)
When someone other than a large corporation does it.
They did not remove your encryption (Score:2)
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.
Re: (Score:2)
I'm glad Yahoo uses a different port as you mentioned if you POP you mail down encrypted. This at least allowed me to to pull multiple years worth of email off of Yahoo's servers which obviously can't be trusted anymore.
When you say stop using STARTTLS are you advocating PGP as the alternative?
Re:Most severs shouldn't be vulnerable (Score:4, Insightful)
Maybe he's suggesting to just use plain SSL without the initial plaintext exchange and initiation.
Re: (Score:2)
That would be SMTPS which is deprecated.
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:2)
Yup. Nobody needed to reinvent traditional TLS/SSL secure sockets in order to send email.
What's wrong with STARTTLS? To quote the original RFC [ietf.org]: "...a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error."
So in other words, if you're writing an SMTP stack you have
Re:Most severs shouldn't be vulnerable (Score:5, Informative)
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 [gnome.org]
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.
Re: (Score:3)
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."