
ISPs Removing Their Customers' Email Encryption - erkose
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
======
Animats
This might be illegal under the anti-circumvention provisions of section 1201
of the the Digital Millennium Copyright Act.

See:
"[http://copyright.gov/title17/92chap12.html"](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.

~~~
0942v8653
Ah, but under the ISP's Terms of Service your protections are presumably nil.

~~~
dalek_cannes
Isn't a contract that violates a law, Bad in Law?

~~~
pyre
The law says that they can't circumvent, but you are well within your rights
to sign a contract stating that the ISP is allowed to circumvent or that the
ISP shares copyright with you. I'm pretty sure that such a contract would not
necessarily be illegal unless a judge decided that it was too one-sided
towards the ISP.

------
eksith
Before the conspiracy theories start, I think this has less to do with mass-
surveillance and more to do with stopping spam. As hinted :

    
    
      "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."
    

When faced with a large volume, companies usually aim for the quickest fix in
lieu of the best. And I couldn't help notice the bigger problem here :

    
    
      "Adoption of PGP has been slow because of its highly technical 
      interface and difficult key management." 
    

When non-technical people are involved, the number of technical people who
dismiss or downlplay this offhand is getting annoying. In fact, just the other
day, the replies to this :
[https://twitter.com/SwiftOnSecurity/status/53081882403604070...](https://twitter.com/SwiftOnSecurity/status/530818824036040704)

Surely, there's a simpler way to manage keys and send/receive encrypted email
with PGP or something better?

~~~
josho
This is the lamest approach to fighting spam.

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.

~~~
bsder
This is the lamest approach to network security.

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.

~~~
brongondwana
[https://www.ietf.org/rfc/rfc2476.txt](https://www.ietf.org/rfc/rfc2476.txt)

December 1998

It's hardly your ISP's fault that you are 16 years behind best practice.

~~~
nitrogen
_[https://www.ietf.org/rfc/rfc2476.txt](https://www.ietf.org/rfc/rfc2476.txt)

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?

~~~
tedunangst
> Port 587 is reserved for email message submission as specified in this
> document.

------
Someone1234
Unfortunately STARTTLS is broken beyond repair.

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.

~~~
spindritf
_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._

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.

~~~
iancarroll
HSTS preloads fixes this problem on modern browsers. Google literally has a
site where you can add your site to Chrome's list (which Mozilla clones) in a
few weeks.

If you're using other browsers, the problem still exists but a large majority
is covered by this.

~~~
dublinben
There's only 500 sites on that list. None of the largest banks in the US are
even included. This problem is hardly solved.

~~~
iancarroll
(There are a lot more in Canary/Beta)

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?

------
mike-cardwell
My mobile provider (T-Mobile in the UK), used to send spoofed RST packets back
to you if you connected to something on port 465, disrupting the TCP
connection.

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_...](https://grepular.com/Punching_through_The_Great_Firewall_of_TMobile)

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.

------
G3E9
The lack of HTTPS when using Comcast's XFINITY web mail is still beyond me.
HTTPS is used when logging in, however everything else after that prompt is
over basic HTTP (session IDs, inbox data, message data, contacts list, etc). I
do not communicate much with my provided Comcast email, but I know others who
tie a lot of services to it. Until Comcast provides standard web security,
they endanger their customers as well as whoever else involved (paying Comcast
or not).

Careful what you share with user@comcast.net.

------
feld
Easy solution: don't permit STARTTLS. Only allow email clients to connect over
993 and 465 using end to end SSL. That's what Fastmail does and I now
understand why.

~~~
spindritf
You're thinking of end clients. This is server to server communication and
Fastmail supports STARTTLS of course.

    
    
        $ 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 8BITMIME

~~~
kijin
The article is about end clients on residential and/or business lines. There
is no reason for client-to-server communication to rely on STARTTLS on port
25.

~~~
zurn
There's also no reason to discount server-to-server SMTP on residential or
business lines. Especially since this is part of the larger net neutrality
discussion.

~~~
feld
I worked at an ISP and no, net neutrality aside, SMTP on residential is bad
bad bad. It should be permitted only at the customer's request, but probably
won't fix the fact that their subnet is on a global spam blacklist.

~~~
zurn
The point of NN is that the ISP shouldn't get to make that decision. Even
"allow on request" is very problematic because it's a slippery slope. Many
people run SMTP at home mostly to receive mail, because the ISP is legally
obligated to retain mail logs for law enforcement etc. (EU data retention law)

------
josho
Why is mail so broken? We send so much confidential information over email,
yet have no reliable way to secure the information. We insist on https, so why
are we ok with the current lame security around mail?

Folks go out and get S/MIME setup, it's not ideal, but a start at least.

~~~
atmosx
I'm no expert but it's most likely that like FTP, SMTP was NOT designed for
the _internet_. It was designed for LANs or MANs.

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.

~~~
josho
Yup, I get that. Same can be said of http--so we solved that problem and
created https. I just don't get why folks like IBM, Microsoft, et al never
bothered to push secure email standards. I'm surprised their customers never
pushed them to do it.

SMTP with starttls is not secure because as an end user I have no idea if my
mail is getting sent securely.

~~~
throwawayaway
You have to go back to the export controls thing in the nineties to understand
that:

[http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor....](http://www.ussrback.com/crypto/nsa/lotus.notes.nsa.backdoor.txt)

------
giancarlostoro
I'm surprised nobody is working on making PGP simpler to use. Living in
fantasy land where we trust servers to never be compromised is always
ridiculous to me. If you really want your privacy invest in tools that
simplify PGP use, forget trusting a server, I thought we learned from events
like heartbleed?

~~~
LeoPanthera
> I'm surprised nobody is working on making PGP simpler to use.

[https://keybase.io](https://keybase.io)

~~~
TillE
Key exchange is a small part of the difficulty in using GPG. Go install
Enigmail and count the myriad ways in which the UX could be vastly simpler and
clearer, starting by just changing some stupid defaults.

------
kijin
This is why I never use STARTTLS on port 25 or 587 when connecting to my mail
server. For me, it's 465 or GTFO.

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.

~~~
mike-cardwell
I'm not aware of any mail clients which (when configured to use encryption),
will downgrade to not use encryption for any particular reason, when using
mail submission port 587.

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?

~~~
kijin
> what the hell are you talking about?

Old example:
[https://news.ycombinator.com/item?id=8593115](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.

~~~
uxp
> For most people, "better compatibility" sounds like a pretty convincing
> excuse.

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.

~~~
kijin
The reason I call STARTTLS "stupid" is because it superceded a perfectly good,
fully encrypted, transport layer protocol: SMTP over SSL/TLS on port 465.

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.

------
willvarfar
If, say, Thunderbird is configured to use STARTTLS to talk to the IMAP and
SMTP servers, can this attack strip it or will Thunderbird refuse to connect
to an unencrypted server?

~~~
asutherland
In very old versions of Thunderbird (pre-mercurial), there was an option akin
to "TLS, if available" which would be vulnerable. But Thunderbird has not
offered it as an option for new accounts for quite some time.

------
dangrossman
I haven't been able to send e-mails when connected to T-Mobile for, oh, a year
at least? My e-mail provider (Rackspace) only supports STARTTLS and SSL/TLS,
and T-Mobile appears to break the authentication no matter which I choose. I
can receive e-mail, but not send it on 465 or 993. As soon as I get home and
switch to wifi, everything in my outbox gets sent. It's mighty annoying.

~~~
rahimnathwani
993 is for IMAP, not SMTP. Try 587.

~~~
dangrossman
My mistake, just a typo. The app fills in the port itself depending on what
authentication mode is chosen. It's 465/587.

------
rikkus
To raise awareness of this and force the ISPs' hands, perhaps it would be best
to use the media's own trope and cry about ISPs 'hacking email'. Whether or
not that's the correct technical term isn't really an issue; it is valid under
the current common use of the term.

------
iolsantr
At least nobody thinks MITM attacks are only of concern to big corps,
militaries and paranoiacs now.

~~~
cm2187
And with mobile and wifi everywhere this is even likely to become a direct
annoyance for consumers

------
higherpurpose
Ok, _maybe_ I can live with the excuse that NSA is forcing the carriers' hands
at giving them data, but _actively helping NSA_ break people's encryption?
What the hell.

~~~
hadoukenio
Yeah, this smells like it was by design.

------
delinka
"...the flag indicating that a server supports STARTTLS is not itself
encrypted..."

I'm thinking signatures would have been a nice start.

~~~
brongondwana
Exactly. This fuzzy thinking in security is really frustrating me with the
supposed security experts talking in this space. I was at Inbox Love a couple
of weeks ago, listening to Ladar Levison talking about security, and he gave
an example which conflated encryption with digital signatures, saying that the
lack of encryption in his incoming email would allow people to send him
executables which were unknown viruses.

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)

~~~
throwawayaway
You know what you are right. I've bookmarked your post. I think you should
make a "Applications" style blog post and submit it.

------
igonvalue
Can someone explain exactly how this works, and how an end-user might figure
out that this was happening in real time?

------
plg
i can haz gnupg?

~~~
chuso
AFAIK, GnuPG and S/MIME only encrypt message body, but not its headers such as
sender, receipt, date, subject, ...

~~~
plg
Yes that's true

~~~
riking
... email account passwords ...

