ISPs Removing Their Customers' Email Encryption(eff.org)
eff.org
ISPs Removing Their Customers' Email Encryption
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
18 comments
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.
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.
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.
If you're using other browsers, the problem still exists but a large majority is covered by this.
There's only 500 sites on that list. None of the largest banks in the US are even included. This problem is hardly solved.
(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?
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?
Hell, banks are some of the biggest offenders of requiring SSL3, with no TLS option...
STARTTLS was never intended to thwart MITM however. We need to keep that in mind. It allows a way to start a secure channel that is backwards compatible under the assumption that an attacker can eavesdrop but not manipulate the contents of the channel. In this regard it is some measure of an improvement.
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).
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).
But TLS is too often advocated as a replacement for SSL. It just isn't. It is something else, less secure.
TLS is just a new name for SSL from version 3.1 onwards. It's much more secure then those older SSL versions.
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.
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.
How is TLS less secure? Accepting unsecured connections is a problem of the client, not the protocol.
using STARTTLS is not a good replacement for using a connection that is secure from the start, but TLS _is_ a replacement for SSL.
STARTTLS is perfectly fine.
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?
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?
We are working on a workaround for this:
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.
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.
The thing is that STARTTLS is only one of two things that need to be fixed. Until DNSSEC is used, no smtp client/server is certain that it is delivering an email to who it is supposed to deliver it to and mitm attacks against its clients remain trivial to an ISP (I can't believe we even got there...).
Enable DNSSEC on your resolver, install Postfix, and turn DANE on in Postfix. Then when you email me @grepular.com, today, your connection to me is guaranteed to be encrypted, and guaranteed to be encrypted with a certificate matching the fingerprint that I've published in my signed DNS.
Exim will soon also be getting DANE support. Not sure if it is being worked on by other mail server teams or providers.
Exim will soon also be getting DANE support. Not sure if it is being worked on by other mail server teams or providers.
DNSSEC creates many more problems than it solves. See http://cr.yp.to/talks/2009.08.10/slides.pdf for an (incomplete) overview of several issues.
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
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
- DNSSEC enables and facilitates reflected DoS attacks by amplifying attackers' bandwidth;
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.
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.
>ISPs are likely "MitM"-ing their own traffic (which by definition isn't a MitM)
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.
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.
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.
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 8BITMIMEThe 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.
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.
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.
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)
Port 465 (SSMTP) is deprecated and the port number has been reassigned. The standard says to use SMTP on port 25 (with STARTTLS) for server-to-server communcation and Submission on port 587 (with STARTTLS) for client mail submission.
But the standard is less secure that what it is meant to replace. How can you replace SSL with optional, third party downgradable encryption?
That's incorrect. Mail submission using SSL on port 465 is no more secure than using STARTTLS on port 587. If my client connects to my server on port 587 and does an EHLO and sees no mention of STARTTLS in the response, or can't negotiate encryption for any other reason, then it will not continue, not authenticate, and not send email. That is normal behaviour for mail clients that have been configred to use encryption. I'm not aware of any mail clients which will automatically downgrade to not use encryption when configured to use encryption.
It's also worth pointing out that if its your mail _server_ then you can also configure similar.
My exim setup doesn't even present the user with LOGIN options until after they've started TLS, so even with a bad client its impossible for them to leak their credentials.
Not quite. When the MITM strips out "STARTTLS" from the EHLO response, they could also add "AUTH PLAIN", causing your theoretical "bad client" to attempt authentication.
This is what I was trying to get at. It's silly to even offer plaintext communications in the first place.
We were talking about a theoretical bad client. No client I have ever used to talk to port 587 would behave that way. They would all encrypt or fail. Regardless of if "AUTH PLAIN" was inserted prior to encryption and/or STARTTLS removed.
IPsec, maybe? SSL and TLS always seemed silly to me as a link-level encryption (when no client certificates are used).
Before the conspiracy theories start, I think this has less to do with mass-surveillance and more to do with stopping spam. As hinted :
Surely, there's a simpler way to manage keys and send/receive encrypted email with PGP or something better?
"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?
No conspiracy theories here, just utterly baffled at the fact that a communications provider would happily tamper with user data that he has zero reason (and technical justification) to access or change.
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.
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.
He just told you there _is_ a reason to do this: stop said ISP's users from sending spam. In the best case scenario, the ISP analyzes each email and drop them when their spamminess is too high. That's a legitimate concern for the ISP.
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.
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.
It's not the job of the ISP to do that. Full stop.
I'd argue that spammy e-mails are fine as long as you don't send too many of them. That's easy enough to track without breaking encryption. But it also makes it difficult to distinguish the officially "non-spam" yet still awfully spammy marketing automation that makes the ISPs boatloads of money, so I can see their tradeoff.
I find these attacks outrageous and an absolute disdain for the protection of their customers but I wouldn't go as far as justifying spam. To be honest I am less shocked by the fact that the ISP do this than by the fact that it is even possible. Email is broken in so many levels.
you don't need conspiracy theories to put forth that disabling encryption (for whatever reason) enables dragnet/any surveillance by whichever parties have access to the transmission medium. the NSA will be happy to collect your unencrypted data regardless of whether they had any part in disabling the encryption.
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.
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.
> A better approach is for the ISP to block outgoing port 25 from their network
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?
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?
To keep you from denying internet (i.e, email) access to everyone else, they should block the port by default, then unblock it if you demonstrate that you know what you're doing by calling them up and asking them to unblock it.
Seems harmless enough. Agreed?
Seems harmless enough. Agreed?
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.
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.
https://www.ietf.org/rfc/rfc2476.txt
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.
It is my ISP's fault for BLOCKING THOSE PORTS.
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.
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.
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?
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?
> Port 587 is reserved for email message submission as specified in this document.
Does that actually change anything? If everyone used 587 for MSAs, then the ISPs would have to block 587 and use their own relay to prevent spam (under GP's solution). I mean, it doesn't change anything, does it?
Using 587/MSA implies[1] authentication which implies that the client is using a server that is responsible for the email sent through it.
[1]: http://en.wikipedia.org/wiki/SMTP_Authentication
[1]: http://en.wikipedia.org/wiki/SMTP_Authentication
You cannot enforce something just because it's 'best practice'. Why should the ISP restrict a user form running HTTP on port 25 and SMTP on port 80?
It is my ISP's fault if my ISP blocks a port and doesn't let me any way to unblock it, whatever I do with my port. My ISP's job is to forward packets, not something else.
A third of the ISP don't even support TLS/SSL on their outgoing traffic. Gmail publishes some interesting stats on that. Having to go through your ISP smtp is nearly as bad as no encryption at all.
Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah.
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.
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.
Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config.
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.
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.
<rant>
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>
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>
Continuing in your rant: technically, you still expect the server to behave correctly and ask your browser for the encrypted text through a special <textarea>. If the server doesn't want to send the it, it won't.
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.
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.
Sure. The site shouldn't be able to imitate your textarea. First, it should have no access to your keyring and whatever, so it won't be able to crudely imitate the UI. Then, browser should have some sort of indication outside of site's control, that shows whenever you're editing text in a secure area or not.
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 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.
> All what's necessary is to provide an API and browser plugin
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.
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.
Whatever, this part doesn't really matter. Just something that works within the browser and is completely isolated from any websites except for well-defined, narrow, simple and secure communication channels. However it's implemented - as a plugin or as a module within the browser's codebase or somehow else - this part is mostly irrelevant.
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.
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.
Yeah sorry, I meant that Flash, like Java plugins, is basically dying.
It is, but I believe it's not because of its plugin nature, but for another reasons. It's just that Flash had served its role but got replaced with better solutions and is mostly unnecessary anymore.
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.
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.
This is also the default behavior for ASAs, so it's really just not bothering to configure them. Probably because email works, so why screw with it?
Why would I want that if I have Gmail? Also I wouldn't trust Cisco's arguments in such situations. Cisco is the one that invented "lawful intercept"/backdoors in routers.
"...the flag indicating that a server supports STARTTLS is not itself encrypted..."
I'm thinking signatures would have been a nice start.
I'm thinking signatures would have been a nice start.
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)
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)
You know what you are right. I've bookmarked your post. I think you should make a "Applications" style blog post and submit it.
[deleted]
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.
Folks go out and get S/MIME setup, it's not ideal, but a start at least.
There were people thinking about security in the 1970s, but the proposals were quashed. A comment from this past August from Karl Auerbach, who was there:
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...
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...
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.
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.
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.
SMTP with starttls is not secure because as an end user I have no idea if my mail is getting sent securely.
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....
> We insist on https, so why are we ok with the current lame security around mail?
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.
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.
Yup, it's going to be hard--lets just not bother.
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 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'm not advocating either way, I'm just saying that it's a problem with a higher barrier to clear since it requires far more buy-in to be meaningfully implemented. You can go and encrypt your email right now but unless you get an organisation with an incredible degree of power to back you you'll be sending messages most people can't read and recieving unencrypted stuff in return.
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.
Yeah, this smells like it was by design.
NSA?
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?
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.
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.
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.
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?
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?
> 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.
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.
> 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.
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.
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.
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.
People who configure their clients to use encryption optionally, will find that their clients, use encryption optionally.
This is not evidence that 465 is more secure than 587. This is evidence that some clients come with strange options.
This is not evidence that 465 is more secure than 587. This is evidence that some clients come with strange options.
Fair point. It is, however, evidence that strange protocols beget strange clients.
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.
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.
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 [email protected].
Careful what you share with [email protected].
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.
I wasted a bit of time yesterday trying to get a .NET application to send email using SSL/TLS via Rackspace.
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:
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
993 is for IMAP, not SMTP. Try 587.
My mistake, just a typo. The app fills in the port itself depending on what authentication mode is chosen. It's 465/587.
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"
"(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: "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.
All creative* work, which when fixed, is copyrightable. That's been the case world-wide for decades
* There is some disagreement over what's covered, but email would be.
* There is some disagreement over what's covered, but email would be.
Ah, but under the ISP's Terms of Service your protections are presumably nil.
Isn't a contract that violates a law, Bad in Law?
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.
this is them actively circumventing protection that you set up, not them failing to provide protection
Did your ISP make an illegal copy of your email?
They don't need to make a copy to fall foul of the anti-circumvention parts of the law.
See also unlocking phones to any carrier where no copying was involved. https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone-
See also unlocking phones to any carrier where no copying was involved. https://www.eff.org/deeplinks/2009/04/dmca-hearings-phone-
Not sure that's entirely comparable. SSL stripping doesn't make any long term modifications to your device or program. In particular, it takes place before the protected work is transmitted. Cracking encryption would more clearly be circumvention of a protected work, but if the protected work doesn't yet exist, can circumvention exist?
It doesn't matter if it's making long term modifications to devices or software. The law is about "circumventing", not about "long term modification".
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.
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.
Still not convinced this would hold up. The lack of encryption is apparent to the sender before the DATA is transmitted; the decision to proceed even so could be construed as consent.
Imagine you were shipping something large and top-secret across country. Then, after the trucking company picks up your shipping container, they paint with a substance that makes it transparent. They're not copying or even looking inside to see what's there, but they've defeated your ability to hide your secrets as they are in transit. What would you think of that situation?
I think it's possible for SSL stripping to simultaneously be a bad thing and not a DMCA violation.
Wouldn't you think the shipping company is circumventing your countermeasures, despite not having copied your cargo?
If that's what were happening, sure. But it's not. This is akin to the shipping company saying "sorry, only clear containers are permitted. Do you still want to ship it?" And then you saying "sure, go ahead."
You're thinking about the Computer Fraud and Abuse Act. This is a different law.
The DMCA is so biased that it doesn't matter.
That's the beauty of it. It's hard to waive the anti-circumvention provisions of the DMCA. The law says "no person shall circumvent", not "no person shall circumvent without permission". I just sent a note on this to the EFF.
Yes but those parts of the law are only designed to be applied to the weak, and no one will be able to file a suit against an ISP using your arguments and win.
Too bad the government only cares about the copyrighted material of the media companies and not the voters.
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?
> I'm surprised nobody is working on making PGP simpler to use.
https://keybase.io
https://keybase.io
Thanks for the link! Looks interesting, though it is far from easy-to-use (for vast majority of users).
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.
Can someone explain exactly how this works, and how an end-user might figure out that this was happening in real time?
[deleted]
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_...
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.
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.
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.
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.