ISPs Removing Their Customers' Email Encryption
eff.org
eff.org
See: "http://copyright.gov/title17/92chap12.html"
"(1)(A) No person shall circumvent a technological measure that effectively controls access to a work protected under this title." That's one of the sections the RIAA and MPAA like, and it's written to favor the copyright holder. It seems to apply here.
- Is your email copyrighted? Yes, under the "born copyrighted" provisions of the Copyright Term Extension Act.
- Was it protected by a "technological measure"? Yes.
- Was that technical measure circumvented? Yes.
- Can you bring a suit yourself? Yes.
- What are the damages? Minimum of $200 per circumvention.
- Can they be aggregated? Yes.
See also unlocking phones to any carrier where no copying was involved. https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone-
Again, this is not about copying the email; it doesn't matter that the circumvention is done before the copy-righted work is transmitted.
Encrypting your email is preventing access to those emails. Thus, it seems to be covered by DMCA anti-circumvention.
http://www.copyright.gov/legislation/dmca.pdf
> Section 1201 divides technological measures into two categories: measures that prevent unauthorized access to a copyrighted work and measures that prevent unauthorized copying of a copyrighted work. Making or selling devices or services that are used to circumvent either category of technological measure is prohibited in certain circumstances, described below. As to the act of circumvention in itself, the provision prohibits circumventing the first category of technological measures, but not the second.
* There is some disagreement over what's covered, but email would be.
"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."
"Adoption of PGP has been slow because of its highly technical
interface and difficult key management."
Surely, there's a simpler way to manage keys and send/receive encrypted email with PGP or something better?
And then to strip STARTTLS? That's the nuclear meltdown scenario of incompetence and recklessness.
I guess this is another moment where people can tell us how theres too much regulation governing internet providers, after apparently a vast majority of providers can't even deliver payload unchanged. It must be tedious to keep defending an industry that can't provide the most basic of services.
Now _of course_ doing this will be a massive problem for privacy, but again, user's privacy comes after a functioning network for the ISP.
A better approach is for the ISP to block outgoing port 25 from their network, and force their users to use their mail relay that requires authorization. Any accounts that are caught spamming can then simply be terminated as customers. This approach is also quite common.
Now I can't reach MY email server which sits in a colo on port 25.
So, now I have to put my mail server on port 80 just so I can get out of the network.
Some of us don't trust the email servers run by the ISP.
December 1998
It's hardly your ISP's fault that you are 16 years behind best practice.
December 1998
It's hardly your ISP's fault that you are 16 years behind best practice.
Could you be so kind as to point to the relevant section of RFC2476?
And, since I don't really have a choice of ISP, I can't change that.
Some of us live in the real world where we wind up having to do things like put mail servers on port 80 or 25 because that port doesn't get blocked.
Thanks for playing.
No thanks! My ISP's job is to provide internet access. Blocking ports violates that.
Would you condone an ISP relaying all port 80 traffic to reduce forum spam?
Seems harmless enough. Agreed?
Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface".
There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.
Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences".
That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.
2 boils down to issue 1 and is blocked by issue 3.
Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible.
But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good".
Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed.
And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak.
</rant>
What I see is going the other way around: have the browser detect a standard <textarea> and provide control to automatically encrypt what you typed. Something ala https://www.mailvelope.com/. No changes in the websites. You can do it today (well, if you have the good plugin/browser).
Now I think the real hard problem is not encryption itself but key distribution. You need to find a way to reliably tell other people "This is my key", but you need some interactive way so that I don't need to wait for you manually sending me your key in order for me to send you something encrypted... I believe XMPP is much better suited for that (there are ways to exchange content between people, even when they are not connected, for instance through services), so maybe Gmail could build something on top of SMTP+XMPP to exchange keys. And that still wouldn't be truly authenticated, only optimistically, because in the end trust is something only users can set.
As for key distribution - if it would work opportunistically, it would be still a great achievement. Like, all emails I send are signed, and recipient MUA can figure out my key ID from those and retrieve it automatically. Then proceed to suggesting encrypting the correspondence. If so, the UI should clearly indicate that communications are encrypted but noticeably warn that identity's not verified. That is, solving one problem at a time, I guess.
Maybe I'm wrong, though.
As soon as you say browser plugin, you've failed. Plugins mean deployment headaches, sandbox trust etc etc. It's what Java used to do, it's what Flash used to do, we know it just doesn't work in the long run. Even extensions are troublesome, what with browsers constantly breaking compatibility every other day. There is a reason big brands don't even develop simple extensions these days.
And IIRC, Flash is still a browser plugin. It's just that it's more commonly shipped with browsers. Or maybe I had missed something.
I think I'd be very pleased, if, in a same manner as it happened with Flash, Enigmail would become obsolete and GPG support would be provided by Thunderbird itself.
STARTTLS is sent via the unprotected SMTP channel. The biggest problem with this isn't the lack of encryption, but more the lack of MitM protections.
Imagine if when you wanted to connect to your bank over HTTPS you first had to send a HTTP request which asks permission to "upgrade" to HTTPS. Obviously any bad guy worth their salt is going to intercept that unprotected HTTP traffic, strip out the STARTTLS, and then leave you using the HTTP channel they can monitor or alter.
So while, yes, in this case ISPs are likely "MitM"-ing their own traffic (which by definition isn't a MitM), it still leaves you open to bad guys on your side of the connection (e.g. the insecure WiFi problem). But even if ISPs weren't someone else could be.
This actually happens a lot. Most people most of the time don't painstakingly type in h-t-t-p-s-:-/-/... but rather just the domain name and the server on the other end returns a (plaintext) redirect to https. Which is why sslstrip works so well.
Sure, we have bookmarks, HSTS, tell people to look for a lock icon in the address bar but it's far from being a solved problem.
If you're using other browsers, the problem still exists but a large majority is covered by this.
Banks have the ability to do it, so I wouldn't exactly pin it on a new solution being needed. If they won't adopt pinning or HSTS, then why would they adopt anything else?
For the record I do not think it is a final solution (what is). I do often have mixed feelings about 'the perfect being the enemy of the good'. With STARTTLS my feelings aren't as mixed. A measurable improvement to passive surveillance for minimal changes and no new infrastructure. Swell.
Again, not going to condone it as a panacea - but it's never advertised itself as one.
Let's keep using it until there's something better. And let's get furious at ISPs that strip it (or modify our traffic in any significant way).
STARTTLS, a protocol used to negotiate SSL/TLS in some plain text protocols, is problematic if it isn't enforced. Some software stupidly abbreviates STARTTLS to TLS in the GUI, which is a source of constant confusion.
https://github.com/EFForg/starttls-everywhere
I'm not sure one could say that this makes STARTTLS non-broken, but it will help mitigate the MITM risk.
Exim will soon also be getting DANE support. Not sure if it is being worked on by other mail server teams or providers.
In brief,
- DNSSEC enables and facilitates reflected DoS attacks by amplifying attackers' bandwidth;
- Using DNSSEC allows anyone to enumerate any of the zones of your subdomain, effectively turning on public DNS transfers for anyone who asks (see the paper for attacks against NSEC and NSEC3);
- Most importantly, no common resolver validates or enforces the validity of DNSSEC records. Chromium closed the pull request as WontFix: https://code.google.com/p/chromium/issues/detail?id=50874 and Mozilla have no current plans to implement it: https://bugzilla.mozilla.org/show_bug.cgi?id=672600
That's a problem today, without DNSSEC, and requires fixing regardless, whether or not DNSSEC becomes wide-spread.
- Using DNSSEC allows anyone to enumerate any of the zones of your subdomain, effectively turning on public DNS transfers for anyone who asks (see the paper for attacks against NSEC and NSEC3);
I thought NSEC3 fixed that, but I wouldn't be surprised if there were attacks against it. I don't think that's an insurmountable problem.
- Most importantly, no common resolver validates or enforces the validity of DNSSEC records. Chromium closed the pull request as WontFix: https://code.google.com/p/chromium/issues/detail?id=50874 and Mozilla have no current plans to implement it: https://bugzilla.mozilla.org/show_bug.cgi?id=672600
Chicken and egg. shrug There's no reason an OS can't come with such a resolver built in. Personally I take the 60 seconds or so required to do an "apt-get install unbound" to get this functionality whenever I build a system.
What's the definition of a MitM? If you're trying to talk to Google, and your ISP is modifying what you say, I would consider that a MitM. Wikipedia mentions a router MitMing its users. I don't see how that can be considered a MitM but not this.
STARTTLS is simply a method for establishing a TLS connection through the same TCP port as the backward compatible connections that don't use TLS. It's the job of TLS to provide authentication, and thus to protect from MiTM--it would be braindead to have a second authentication layer beneath it to "protect STARTTLS against MitM". If you establish a "direct" TLS connection, the TCP beneath also doesn't protect against MitM, obviously.
That some clients will accept both TLS and non-TLS connections is completely orthogonal to STARTTLS, and has its roots in backward compatibility. Good clients should provide a way for the user to enforce TLS, though.
And yes, as others have pointed out, HTTP(S) does actually work exactly that way: Unless the user asks the browser to enforce TLS (by typing https://), the browser will connect without TLS, and if the server prefers TLS, it will redirect, subject to the same MitM as opportunistic STARTTLS.
Also, I think it's kinda confused to think of your customer's traffic as your own. How does that work? Are telecom companies also allowed to listen to "their own" calls that customers make, and the post office to read "their own" letters that customers have written? Also, you have considered that your ISP's ISP then presumably also could consider all your traffic their own? So, there essentially wouldn't be anyone left who couldn't claim the traffic to be their own, so MitMs wouldn't be possible simply by definition?
They also used to do that if you connected on port 587, but only if, and not until, you sent "STARTTLS" down the wire.
I wrote about it here: https://grepular.com/Punching_through_The_Great_Firewall_of_...
You could only send mail if you disabled encryption or used a VPN. They didn't discriminate, they even did this if you were connecting to GMails mail submission service.
Careful what you share with user@comcast.net.
$ dig mx fastmail.com +short
10 in1-smtp.messagingengine.com.
20 in2-smtp.messagingengine.com.
$ telnet in2-smtp.messagingengine.com. 25
Trying 82.221.106.241...
Connected to in2-smtp.messagingengine.com.
Escape character is '^]'.
220 tlxc1.messagingengine.com ESMTP . No UCE permitted.
ehlo my.hostname
250-tlxc1.messagingengine.com
250-PIPELINING
250-SIZE 73000000
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIMEFolks go out and get S/MIME setup, it's not ideal, but a start at least.
Security was not one of the core features. Same goes with many old protocols... But that's expected the drama is when new protocols are designed with the same flaws.
SMTP with starttls is not secure because as an end user I have no idea if my mail is getting sent securely.
http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor....
I worked on TCP/IP security systems back in the 1970's. In fact one of the threads that led to IP being peeled off from the then monolithic TCP was done on my blackboard at SDC in 1974. The reason we did that was to insert a security/encryption protocol over the packet layer - if it sounds like DNSSEC it should. But in 1974. But it was on a project done for "the government" so it never saw the public light of day.
And:
We made a huge mistake back in the 1970s when we failed to require a mandatory packet security layer between IP and the protocols over it. (We knew even then that we needed it - and had existence proofs of running code - but the gov't wouldn't let those who knew out into the wild to evangelize the concept. So in some sense the problem we have today is do to excessive closure by certain governmental authorities. Even today I am not at all sure what I can say about this stuff.
(He's still under some security prohbitions).
https://plus.google.com/106435630686948313794/posts/i4KmivYf...
Think how many points you have to change if you want your email to be encrypted among your list of common correspondents vs if a website wants to support HTTPs. You have to change a lot more in one go for email to be secure than you do for a given website.
I get it, you've got to update SMTP, the mail client, and likely other points (mail storage). But that's no reason not to try. Look at DKIM and SPF--we've maid steps to protect against forgeries.
I understand the need for backward compatibility in server-to-server mail transport, but there is absolutely no need for client-to-server mail submission to rely on a hack like STARTTLS.
Whoever decided to deprecate STMPS on port 465 made a big mistake. That was back in 1998, when most people didn't fully grasp the dangers of unencrypted communication. I think SMTPS should be reinstated as a standard for mail submission, and mail services should stop encouraging their customers to move to STARTTLS. That way, you won't have to worry about your mail client's undocumented behavior when a STARTTLS negotiation fails.
If you are, tell us what they are so we can issue bug reports. If you can't, then what the hell are you talking about?
Old example: https://news.ycombinator.com/item?id=8593115
Current example: K-9 Mail has two options for TLS: "TLS (if available)" and "TLS (always)". If you choose the first option, K-9 will transparently downgrade to unencrypted connections.
Even worse, some ISPs will happily instruct users to select the first option if they're having trouble with configuration. For most people, "better compatibility" sounds like a pretty convincing excuse. Which is probably why this stupid option exists in the first place.
This is not evidence that 465 is more secure than 587. This is evidence that some clients come with strange options.
Had the protocol not permitted optional encryption in the first place, no client would have implemented optional encryption, because any attempt to access mail using optional encryption would reliably fail.
Security has always been a compromise between protection and convenience. The most secure computer is one that is turned off and stored in a safe, but it's difficult to write a letter to your boss explaining why you weren't able to complete your assignment on time in that state.
With the not-surprising revelations about the NSAs spying programs and state sanctioned hacking and malware distribution, I think we're starting to see that we need computers to be a little less convenient and users to be a bit more literate on how to secure their communications, but to call a "If Available" encryption option stupid doesn't take in account the state of the world 14ish years ago. We, HN readers, can be on the forefront of deprecating the option of maybe and forcing an all or nothing approach, but it will still take time to get our users to accept it.
I once had a career in an entirely different field repairing mechanical technology hundreds of years old. At my technical school, my instructor was constantly telling us that we weren't in the field of mechanical watch repair, but in education. Whenever a customer would come to us and complain that their multi-thousand dollar watch was running ~30 seconds slow a week (compounded to a noticeable couple minutes per month), it was our job to educate them on the physical limits of the timepiece. Some watches are only so accurate. Now that I'm in Software Development, I see that the premise has not changed. Even though I'm paid to write software and enable business users to make loads of money using magical things, my daily job consists of educating those users on the capabilities of that system and showing them that there isn't some magical switch that I keep hidden that makes everything run fast and without issue just to piss them off. If you start to educate your users on what is good and what is impossible, then you can start to change how they use it and what they expect from it.
That was 16 years ago. Even back then, plenty of people seem to have been on the right track when it comes to how to encrypt a stream. People back then were also aware of the difference between the needs of mail transport and the needs of mail submission; the distinction was codified in RFC 2476 in 1998. Despite all of this, some people went ahead and implemented an "if available" encrypted protocol in the name of compatibility, deprecated the fully encrypted and widely supported alternative, and even went so far as to revoke port 465.
Two years ago, it may have sounded crazy to suggest that some three-letter agency was behind this. Now, I'm not so sure.
It turns out that .NET System.Net.Mail doesn't support implicit SSL, only explicit SSL.
You'd think that Microsoft would have solved that by now. The reasoning:
This is not considered a bug, it’s a
feature request. There are two types of
SSL authentication for SMTP, and we only
support one (by design) – Explicit SSL
I'm thinking signatures would have been a nice start.
I actually raised my hand and said "surely digital signatures confirming the sender are really what's needed" and he replied that if it was encrypted, the MITM wouldn't know what was being sent to modify it. For real. As if the attacker can't just replace the whole email with something else encrypted to your public key and containing a virus.
I lost a lot of respect for his security credentials in that moment, and I've lost a lot of respect for the EFF reading this posting. Not a _single_ mention of password theft, which is by far the highest risk to most users of having STARTTLS stripped. The ability for their email to be read over the backbone is bad, but the ability for hackers to get into their email and randomly delete or modify it is far more insidious.
(plus the ability to use the email account to trigger password resets on third party services and all sorts of other exciting stuff you can do once you own somebody's email account)