Slashdot Mirror


ISPs Removing Their Customers' Email Encryption

Presto Vivace points out this troubling new report from the Electronic Frontier Foundation: Recently, Verizon was caught tampering with its customer's web requests to inject a tracking super-cookie. Another network-tampering threat to user safety has come to light from other providers: email encryption downgrade attacks. In recent months, researchers have reported ISPs in the U.S. and Thailand intercepting their customers' data to strip a security flag — called STARTTLS — from email traffic. The STARTTLS flag is an essential security and privacy protection used by an email server to request encryption when talking to another server or client.

By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted. Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.

245 comments

  1. DMCA by Overzeetop · · Score: 3, Interesting

    This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.

    --
    Is it just my observation, or are there way too many stupid people in the world?
    1. Re:DMCA by Anonymous Coward · · Score: 0

      Shouldn't it fall under "disabling an encryption mechanism"?

    2. Re:DMCA by CreatureComfort · · Score: 4, Insightful

      Quick test:

      1. Does it violate user expectations and privileges? Not a DMCA violation.
      2. Does it expand provider powers or control? Not a DMCA violation.
      3. Does it interfere with provider profits or government investigations? DMCA violation!!! Kill it!! Kill IT immediately!!!!!

      --
      "Unheard of means only it's undreamed of yet,
      Impossible means not yet done." ~~ Julia Ecklar
    3. Re:DMCA by rtb61 · · Score: 1

      It actually trips over a couple of crimes. Firstly freedom of speech, the STARTTLS being your electronic speech, so invasion of privacy, illegal warrant less search and seizure as in searching your message and seizing the STARTTLS message. As your message is copyrighted and it is you intent to protect you copyright via encryption in disrupting your chosen encryption method, considering it is a private network communication between you and another party, they are hacking your network for which you and another party have rented access. So really a whole bunch of laws are tripped.

      --
      Chaos - everything, everywhere, everywhen
    4. Re:DMCA by MillionthMonkey · · Score: 1

      Would Verizon really get in trouble for a DMCA violation? I think the the users with compromised emails have more to fear from the DMCA.

    5. Re:DMCA by rotaryexpress · · Score: 1

      Sadly, it's not.

      The "STARTTLS" flag is send plain text with the email header. Removing data that isn't even attempted to be encrypted does not violate DMCA.

      See: http://www.samlogic.net/articl...

    6. Re:DMCA by Anonymous Coward · · Score: 0

      The damn DMCA has nothing to do with this - it's covered under the computer misuse acts and wire-tapping laws.

    7. Re:DMCA by gstoddart · · Score: 1

      If ISPs were common carriers, like Obama wants them to be ... they would probably be breaking the law.

      As it stands, where they're whatever they claim thy are this week, then I very much doubt this is anything other than "this is how we run our networks, suck it bitches".

      If they were common carriers, injecting their super cookie would already be illegal.

      This is precisely why they shouldn't be left in whatever state they are now, in which they can do anything they want to.

      Between governments wanting to undermine encryption to spy on us, and private industry wanting to undermine it for analytics and commercial purposes, the end user is pretty much a commodity who has little say in this.

      Besides, you and I can violate the DMCA, not the people who paid for it. It seems to have been written such that a corporation has so many loop holes that they can do anything they want to.

      Because it's not a law intended to protect us, or to apply to us the same as it does a corporation. It's a tool intended to be used against us -- which is why it was so badly written in the first place.

      Violating the DMCA, or being guilt of unauthorized computer access? That only applies if you're not a corporation or law enforcement -- because they're exempt.

      It's pretty pathetic that so many one-sided laws keep getting passed for technology. But, when your politicians are bought and paid for by corporations, it's hardly a surprise.

      --
      Lost at C:>. Found at C.
  2. Okay, so by Anonymous Coward · · Score: 1

    When does this shit start to count as criminal? Say a company encrypts all communications with their mailserver and this is part of their legal requirements to protect privacy. Can we sue the pants off them yet?

    Please, someone (insert large company here), lose all your data because of this!

    1. Re:Okay, so by CaptainDork · · Score: 3, Insightful

      This.

      Law firm emails are protected by attorney–client privilege and medical emails are protected by HIPAA, for instance.

      For another entity to expose those communications should fall under FCC jurisdiction.

      --
      It little behooves the best of us to comment on the rest of us.
    2. Re:Okay, so by Anonymous Coward · · Score: 1

      You have to go to the UK to spy on lawyers.

      http://abcnews.go.com/International/wireStory/uk-spies-target-lawyer-client-communications-26730298

    3. Re:Okay, so by mikelieman · · Score: 1

      It's well known that email is not secure for the purposes of attorney/client privilege.

      --
      Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
    4. Re:Okay, so by CaptainDork · · Score: 1

      It's well known that you don't EVEN know that.

      It's just as secure as everything else.

      And more secure than the USPS VPN, certainly.

      --
      It little behooves the best of us to comment on the rest of us.
    5. Re:Okay, so by petermgreen · · Score: 2

      It's just as secure as everything else.

      As this incident proves using a policy of "tls if available" has a serious security hole. An attacker can make encryption appear to be unavailable and then sniff the plaintext when the system sends without authentication or encryption.

      Emails multihop nature makes it very difficult to ensure that all the hops are enforcing appropriate transport encryption and authentication. If you want your emails to be secure then you need to use end to end encryption.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    6. Re:Okay, so by Albanach · · Score: 2

      It's well known that email is not secure for the purposes of attorney/client privilege.

      Do you have citation for this? A single court that has found there's no privilege simply because a communication was sent between attorney and client by email?

      After all, you say it's well known, yet all the lawyers I know use email pervasively to discuss client information.

    7. Re:Okay, so by Enigma2175 · · Score: 2

      It's easy enough to configure your mail server to not send if the STARTTLS command is ignored. It should treat it the same as a server that doesn't support TLS. If someone is concerned about email getting sniffed they will configure their server in this manner and will effectively be unable to send any mail over these networks. This should certainly fall under the Computer Fraud and Abuse Act, it's basically a denial of service attack.

      --

      Enigma

    8. Re:Okay, so by mrchaotica · · Score: 2

      When does this shit start to count as criminal?

      When someone other than a large corporation does it.

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    9. Re:Okay, so by petermgreen · · Score: 1

      If you configure your mailserver to only talk to servers that advertise TLS with a valid cert you will cut yourself off from most of the internet. So what you would actually have to do is configure your server to add special cases for the domains you want secure communication with. Make a typo in those special cases so they don't match the domain they were intended to match and you are back to the original problem of being vulnerable to "downgrade to plaintext" attacks.

      And even if you ensure the next hop after your mailserver in encrypted and authenticated you have no gaurantee that later hops (for example backup MX to main MX or mail download by receiving client) are encrypted.

      Worse the retry orientated nature of email makes it much easier for a downgrade attacker to go unnoticed if he notes which domains downgrade attacks fail for and doesn't attempt them for that domain in future.

      And then there is the whole issue of the CA model being not especially secure to start with. If you can receive unencrypted email targetted at a domain you can buy a SSL cert for that domain. So the CA model really only protects against a MITM on the sending side, not against one on the receiving side.

      Don't get me wrong, I don't think these ISPs should be allowed to get away with pulling shit like this but equally transport encyrption of email should not be regarded as a high security soloution.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    10. Re:Okay, so by AK+Marc · · Score: 1

      "Exposing" communications isn't illegal. Last I checked, there were some HIPAA fines for not releasing records, but still none for exposure or leaks, despite some leak events.

    11. Re:Okay, so by AK+Marc · · Score: 1

      No, it is not. Most of my communications with my various lawyers is done over email. I trust their legal judgment more than some jackass on the Internet.

    12. Re:Okay, so by CaptainDork · · Score: 1

      Be sure to tell Snowden.

      --
      It little behooves the best of us to comment on the rest of us.
    13. Re:Okay, so by CaptainDork · · Score: 1

      I'm sorry, but you guys and gals are missing it.

      Customers don't have the control panel.

      This is carrier-side.

      --
      It little behooves the best of us to comment on the rest of us.
    14. Re:Okay, so by AK+Marc · · Score: 1

      I didn't realize the complaints against him were HIPAA related. Where did you read that?

    15. Re:Okay, so by CaptainDork · · Score: 1

      Right here:

      "Exposing" communications isn't illegal.

      So he can come on home, right?

      --
      It little behooves the best of us to comment on the rest of us.
    16. Re:Okay, so by AK+Marc · · Score: 1

      context

    17. Re:Okay, so by CaptainDork · · Score: 1

      Snowden.

      --
      It little behooves the best of us to comment on the rest of us.
    18. Re:Okay, so by petermgreen · · Score: 1

      Customers were using transport encryption on an "if available" basis.

      The ISPs did something that made the transport encyrption unavailable and so the customers systems fell back to sending unencrypted. Maybe they deliberately attacked it. Maybe they put in a rule to redirect mail through their smarthost for some reason (likely spam related) and ended up disabling encryption is a side affect.

      Had the customers used end to end encryption they would have been unaffected. Had the customers been using transport encryption with proper authentication (which is possible but problematic to do for email if all parties cooperate) then things would have stopped working until the problem was sorted out/worked arround.

      Is it bad that ISPs are messing with their customers communications in this way? yes!
      Is it bad that many areas have an effective ISP monopoly which makes it harder to take buisness away from ISPs who pull this shit? yes!
      Is it a good idea to use encryption systems that are this vulnerable for stuff that needs to be kept secret? no!

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  3. Re: DMCA (Defamation) by Anonymous Coward · · Score: 1

    No DMCA but I can make a pretty good defamation case. ISP is claiming email provider doesn't support TLS to the ISP's customer.

  4. Meh by bragr · · Score: 5, Insightful

    I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.

    1. Re:Meh by OzPeter · · Score: 3, Funny

      I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.

      For a previous job I was working onsite in a different country to my home office. For what ever reason my boss had pissed me off, so when he said he was going to email details of a salary increase I decided to yank his chain and played the "email isn't secret, and anyone could intercept it" card just to see what hoops he would jump through in order to "securely" send me this "sensitive" data.

      His solution was to send me two emails. The first email had a password protected zip file that mentioned that the salary details were inside. The second email stated that the password for the zip file was "the company name backwards". Both emails of course being sent from the company domain. Given how brain-dead his solution was I concluded that I had got my monies worth from that stunt.

      --
      I am Slashdot. Are you Slashdot as well?
    2. Re:Meh by Anonymous Coward · · Score: 0

      With that kind of attitude, I'd assume you also wouldn't care if your local GPO decided to convert all your enveloped letters to postcards.

    3. Re:Meh by SgtAaron · · Score: 3, Insightful

      I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.

      Yeah. Use gnupg or something of its ilk for end-to-end encryption. It's not like a bazillion system administrators like myself can't read all of your email anyway. TLS in this regard would be handy if you're on an open wi-fi and are sending login information to the mail server... maybe.

    4. Re:Meh by Anonymous Coward · · Score: 0

      That's a very stupid thing to say. But at least everyone knows to disregard whatever you say, now.

    5. Re:Meh by Anonymous Coward · · Score: 1

      That's because it DOES! STARTTLS only forces the SMTP connection on the first hop to use TLS. It's useful if you are passing credentials to authenticate the SMTP session. It has no other value. The SMTP server will forward your email in plain text, regardless of how that email was originally submitted to the SMTP server.

      If you want your email to be secure, you cannot use transport security like TLS. You must use S/MIME or PGP or some other form or message encryption.

      That said, any ISP that fucks with my traffic without telling me is on the shit list.

    6. Re:Meh by Anonymous Coward · · Score: 0

      I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.

      Totally agree. Every sensitive docs I send, I use at least some form encryption and provide password over phone.
      Unfortunately, at this point there is no standard email encryption protocol.

    7. Re:Meh by BradMajors · · Score: 1

      His solution will stop around 95% of all people listening in. 95% is better than 0%.

    8. Re:Meh by Anonymous Coward · · Score: 1

      I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.

      So you're not angry about your ISP fucking with your packets?

      It's not (necessarily) about what protocol they're fucking with, but the fucking in general IMHO.

    9. Re:Meh by PopeRatzo · · Score: 1

      His solution will stop around 95% of all people listening in. 95% is better than 0%.

      Since his solution would not stop anyone committed to mischief, your "95%" is functionally the same as "0%".

      Or am I thinking about it wrong?

      --
      You are welcome on my lawn.
    10. Re:Meh by Anonymous Coward · · Score: 0

      Locks on doors don't stop criminals just honest people.

    11. Re:Meh by PAjamian · · Score: 1

      TLS in this regard would be handy if you're on an open wi-fi and are sending login information to the mail server.

      Yeah, that's pretty much all that STARTTLS really accomplishes.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    12. Re:Meh by Anonymous Coward · · Score: 0

      It is disingenuous to compare a physical lock to a cryptographic algorithm. The latter can be far more secure.

    13. Re:Meh by Cramer · · Score: 1

      Wrong. Most MTAs (for a long time now) will attempt TLS if available.

    14. Re:Meh by geekmux · · Score: 2

      It is disingenuous to compare a physical lock to a cryptographic algorithm. The latter can be far more secure.

      Ah...slight correction, Anonymous grasshopper.

      The latter is assumed to be far more secure.

    15. Re:Meh by watermark · · Score: 1

      What about your username and password? Blocking TLS also sends your credentials in plaintext.

    16. Re:Meh by fustakrakich · · Score: 1

      Yep, and you probably said it was okay when you 'accepted' the service agreement. And now there's always that lurking chance of a secret law that requires stripping encryption. They sure do make it easy for us tin hatters.

      --
      “He’s not deformed, he’s just drunk!”
    17. Re:Meh by Anonymous Coward · · Score: 0

      You should be using Unix. Like Linux or FreeBSD or any other BSD.
      You should be using fetchmail and msmtp, both of which can be locked down to use *only* TLS transport. That way they can't downgrade you or cancel TLS.
      You should be using OpenPGP aka gnupg to encrypt all your emails.
      You can do that with any real Unix mail client like Mutt.
      But if you're a noob you can use Mozilla Thunderbird+Enigmail. Even newbie Windows lusers can do that because all this stuff runs there too, but use Unix, seriously.
      You should never put anything sensitive in the subject header.
      And if you want complete messaging security, you should be using a P2P messaging app with your friends and family, such as something over I2P. That way your messages *NEVER* even sit on or touch any stupid corporate/edu server, cleartext or not, ever.
      In fact, here is a whole list of more private and secure tools you can use...
      https://prism-break.org/
      https://geti2p.net/

    18. Re:Meh by aaarrrgggh · · Score: 1

      As long as there is no reference to the password being emailed separately, it is fairly reasonable basic level of security. If someone cares, the zip password protection is weak enough that it won't keep a secret long from the boogeyman.

    19. Re:Meh by Anonymous Coward · · Score: 0

      The later CAN be more secure but ISN'T more secure. The reality of the 'ISN'T' part is important.

      Regardless, the original sentiment of the comment holds as basic security regardless of ideals or technology.

    20. Re:Meh by Anonymous Coward · · Score: 0

      hashes yo

    21. Re:Meh by antdude · · Score: 1

      But many people don't use encryption for e-mails for being difficult like those computer newbies. :(

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    22. Re:Meh by dbIII · · Score: 1

      Less braindead than a HR guy I was dealing with on occasion. He would send the password in the same email as the password protected zip files. He couldn't see the problem even after some attempts at explanation since he appeared to see the encryption step as pointless busywork and he was just following a procedure.

    23. Re:Meh by Anonymous Coward · · Score: 0

      You're the grasshoppa here. I said can be. There's a perfect security proof for a one-time pad. Yes, it's not exactly feasible in most cases, but my point is that better proofs exist for cryptographic algorithms than for physical security. The physical implementation of a cryptographic algorithm is another mess.

      Learn to read.

    24. Re:Meh by geekmux · · Score: 1

      You're the grasshoppa here. I said can be. There's a perfect security proof for a one-time pad. Yes, it's not exactly feasible in most cases, but my point is that better proofs exist for cryptographic algorithms than for physical security. The physical implementation of a cryptographic algorithm is another mess.

      Learn to read.

      Physical security is always the first line of defense, and I can place an army in front of a plaintext file that makes it rather impossible for you to read it.

      Perhaps it was disingenuous to disregard the physical lock in the first place when you do not consider how well you can protect it.

      And there's a LOT of examples of physical security being plenty of protection, as evidenced by just about every military installation on the planet. With each passing day, I find myself less and less confident in crypto, no matter how much you want to tout it as "secure". Both measures of protection take time to circumvent, but only one of those is truly unknown at any given time due to the advancement in technology.

    25. Re:Meh by Anonymous Coward · · Score: 1

      That's because it DOES! STARTTLS only forces the SMTP connection on the first hop to use TLS. It's useful if you are passing credentials to authenticate the SMTP session. It has no other value. The SMTP server will forward your email in plain text, regardless of how that email was originally submitted to the SMTP server.

      We know that. But we also knows when the server is not going to forward the mail, and in those cases STARTTLS do indeed provide security.

      The extremely common case:
      I travel somewhere, and live in some hotel. Then I need to send email to others in my company. So, my PC uses the hotel wifi and contacts the company mail server. It issue STARTTLS and nobody in the hotel or involved ISPs can snoop - unless they have broken TLS that is. And the mail is for someone else in the company, so it stays on the company server. No forwarding, no confidentiality problem. Of course, now I need a mail client that fails if the server somehow fail to respond to STARTTLS.

      If you want to stop spam originating inside the company - don't do it at the firewall. Do it at the mail server itself, because it has access to the unencrypted content. All sane mail servers support such setups - for incoming as well as outgoing mail. The firewalls job will simply be to deny any mail not going through the server. Spam won't make it through the server's filters, spam (or other mail) won't make it without going through the server.

    26. Re:Meh by Anonymous Coward · · Score: 0

      Since nobody gives a flying fuck about this guy's salary increase, it effectively stopped 100% of people committed to mischief.

    27. Re:Meh by Anonymous Coward · · Score: 0

      35 bf 02 56 6c 39 51 a8 7d e2 2e 75 9b 0b 58 ec
      76 6d 28 f8 d3 db 57 1b ef c2 8e 39 01 bd 73 3b
      ea 78 1e e3 59 c4 28 f8 d6 cb 63 3f 50 43 f7 77
      ac 0e a1 83 ec 3e c5 11 7e 08 cb 43 8e a7 c1 22
      90 94 4e 7a 0a 48 42 f0 c4 97 0d b1 29 c0 54 ac
      9b b3 48 86 d7 4f 0e e3 83 8f 6b eb d6 55 50 10
      64 c8 43 18 f2 12 da 59 c1 eb 10 96 b0 d3 fc ce
      c7 91 b7 5c cb e1 75 52 1b 97 2f 23 dd a3 33 ba

      I don't need to put an army in front of it. You can drill a lock or kill a person, but ye canna change the laws of physics.

      Go ahead. Decrypt it.

      Yeah, didnt think so. Nice try.

    28. Re:Meh by geekmux · · Score: 1

      35 bf 02 56 6c 39 51 a8 7d e2 2e 75 9b 0b 58 ec 76 6d 28 f8 d3 db 57 1b ef c2 8e 39 01 bd 73 3b ea 78 1e e3 59 c4 28 f8 d6 cb 63 3f 50 43 f7 77 ac 0e a1 83 ec 3e c5 11 7e 08 cb 43 8e a7 c1 22 90 94 4e 7a 0a 48 42 f0 c4 97 0d b1 29 c0 54 ac 9b b3 48 86 d7 4f 0e e3 83 8f 6b eb d6 55 50 10 64 c8 43 18 f2 12 da 59 c1 eb 10 96 b0 d3 fc ce c7 91 b7 5c cb e1 75 52 1b 97 2f 23 dd a3 33 ba

      I don't need to put an army in front of it. You can drill a lock or kill a person, but ye canna change the laws of physics.

      Go ahead. Decrypt it.

      Yeah, didnt think so. Nice try.

      I will likely know when the lock has been tampered with, especially when there's an army of dead people lying in front of it. I will at least know my level of vulnerability after that.

      You will likely never know if your crypto remains 100% secure. Today, or tomorrow. For neither you nor I will ever be privy to all of the possible ways to break the "unbreakable". Quantum Cryptography is perhaps 100% secure in theory. It's the application that's a bitch. Seems we still have limitations in the physical world to securely implement that "perfect" system for the imperfect user.

    29. Re:Meh by JourneymanMereel · · Score: 1

      Wrong. Most MTAs (for a long time now) will attempt TLS if available.

      Not really wrong... more like right. Heck, you even validated what he said when you qualified your statement with if available... if it's not available, it will simply send it in plain text. It won't notify you. It won't notify the next person down the line, etc. Neither you nor your recipient will have any way to know if the message was transmitted at some point in plain text. And it's a guarantee that it sat on every mail server it touched unencrypted.

      Therefore, the safe option is to assume it will not be encrypted at any point unless you use some kind of end-to-end encryption (X509, PGP, etc).

      --
      Life has many choices. Eternity has two. What's yours?
  5. Big Brother is listening by FudRucker · · Score: 0

    DO NOT TRUST your email or internet connection, and DO NOT TRUST your cellphone

    there is no privacy anymore, none, nowhere to be found anywhere, thanks to a government that has used terrorism as an excuse to snoop on EVERYBODY and EVERYTHING, George Orwell was a prophet, 1984 is here and now

    --
    Politics is Treachery, Religion is Brainwashing
    1. Re:Big Brother is listening by xaotikdesigns · · Score: 1

      So your solution is to just let everybody read your email then? Not to fix the problem, but to just give up?

      --
      XDInd
    2. Re:Big Brother is listening by FudRucker · · Score: 1

      nope, i just use the computer and cellphones for trivial low level communications, if i need to communicate securely i would rather meet in person where we wont be listened to or recorded

      --
      Politics is Treachery, Religion is Brainwashing
    3. Re:Big Brother is listening by Anonymous Coward · · Score: 0

      nope, i just use the computer and cellphones for trivial low level communications, if i need to communicate securely i would rather meet in person where we wont be listened to or recorded

      Better get a cone of silence because Siri and Google Now are listening --so is google Glass. Better get some tin foil for your phone because stores are starting to tag phones as we walk by (forget if it's a mac address but we don't have to do anything to get tagged as our phones look for new APs). Better get some cloaking tech for you and your friend, because the cameras are already here. I recall hearing that you get taped about 20 times a day if you walk around Manhattan. Seeing the cameras at work, subway stations, buses (and coming up soon, train cars), as well as the people who are all too ready to point their phones at us (sometimes to their detriment like the guy who got stabbed in NYC this week because of filming someone's overt abuse of someone else).

      We're in too deep to stop depending on these things. The only truly safe place is your mind, or whatever is left of it.

    4. Re:Big Brother is listening by j127 · · Score: 1

      The only truly safe place is your mind, or whatever is left of it.

      Sorry: http://www.scientificamerican....

    5. Re:Big Brother is listening by PopeRatzo · · Score: 2

      if i need to communicate securely i would rather meet in person where we wont be listened to or recorded

      OK, so you've never had the need to communicate securely with someone who didn't live in your town. Lots of people do have that need, though, on a regular basis.

      --
      You are welcome on my lawn.
    6. Re:Big Brother is listening by Anonymous Coward · · Score: 0

      DO NOT TRUST your email or internet connection

      Learn how to tunnel, how to do your own encrypting, and how to use any number of somewhat secure chat options. Essentially, it will depend on just how sensitive the material you wish to communicate actually is.

      and DO NOT TRUST your cellphone

      https://whispersystems.org

    7. Re:Big Brother is listening by Anonymous Coward · · Score: 0

      Just wear a T-shirt with the anti-copy dot constellation which are used on bank notes to stop programs like photoshop and copy machines to work with images containing the constellation.

    8. Re: Big Brother is listening by Anonymous Coward · · Score: 0

      You can't fix it. Ever. Privacy is dead, over, finished. It was doomed the very moment it was possible to kill it. You can't fight City Hall, much less the State. Give it up.

  6. Not much worse than by Anonymous Coward · · Score: 1

    Not setting *require TLS* in your mail client. Anyone else could do the same, not just your ISP

  7. Which is why ... by Anonymous Coward · · Score: 1

    ... encryption should begin on YOUR computer and end on the recipient's. This is why your data should not be stored in the cloud. This is why people need to pull their heads out of their asses and learn how to protect themselves and not rely on others (companies) to do it for them.

  8. Always RTFA by Overzeetop · · Score: 1

    It sounds a lot less like the summary in terms of transmitting unencrypted mail data; from TFA (which, naturally, I didn't read before commenting), it sounds like they just got a failed connection over TLS, which is a lot different than "faking" that your data is encrypted and transmitting it as plaintext.

    --
    Is it just my observation, or are there way too many stupid people in the world?
    1. Re:Always RTFA by MightyMartian · · Score: 5, Insightful

      If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    2. Re:Always RTFA by jopsen · · Score: 1

      If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.

      Security holes and poor security does not make it legal to take advantage of suck security holes.

    3. Re:Always RTFA by khchung · · Score: 3, Insightful

      If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.

      That's the point of using DMCA, it didn't require "doing it right". Even if ROT13 was used, DMCA still applies.

      --
      Oliver.
    4. Re:Always RTFA by David_Hart · · Score: 2

      If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.

      This....! Anyone who trusts a network to pass traffic untouched, maintaining privacy, etc. that is not owned by them is just fooling themselves.

    5. Re:Always RTFA by Anonymous Coward · · Score: 0

      The proper answer for this it to configure the e-mail client to require SSL/TLS – for IMAP, that'd mean using port 993 (IMAPS, i.e. IMAP tunneled in SSL), or providing an option that aborts the connection if the server doesn't advertise STARTTLS. Optional encryption (where the server advertises support and the client uses it only if it's advertised) is broken by design and will always be vulnerable to a MITM attack like this.

    6. Re:Always RTFA by arcade · · Score: 1

      Oh come on.

      It's always hilarious when people pretending to be techies on slashdot discuss technical matters without understanding the matter at hand.

      There is no encryption being removed here. What is being removed is the negotiation of encryption. There's a huge difference.

      What happens here is that modern MTAs that are configured to use TLS will issue a STARTTLS command to the receiving email server. If the receiving email server is configured to accept TLS connection, it will respond in kind. If it rejects the command, the conversation continues unencrypted.

      Most email servers are still not configured to use TLS.

      What happens in this case is removal of ngeotiation of opportunistic encryption. It's of course very very wrong to do this, but it does not remove existing encryption - it prevents it from happening in the first place. It makes the parties believe that neither side supports it.

      --
      "Rune Kristian Viken" - http://www.nwo.no - arca
    7. Re:Always RTFA by vux984 · · Score: 1

      There is no encryption being removed here. What is being removed is the negotiation of encryption. There's a huge difference.

      So there would have been encryption, but due to their MITM attack there isn't.

      As a reasonable person, that sounds like "removing the encryption" to me.

      Just as my wife might say she removed the salt from a meal she prepared, even if she simply elected not to put the salt specified by the recipe into it.

      The salt isn't there. Normally it would be. Enough said. We generally all understand the semantics, and I've never felt the need to call her out on it.

      I'd say the semantics are the same here. Removing the STARTLS request from the client's traffic is effectively removing the encryption; in the same way ignoring the recipe's instructions to add a salt is removing the salt.

      Sure, perhaps a more precise term would be 'omitting the salt'. But "removing the salt" is well understood by all.

    8. Re:Always RTFA by dotancohen · · Score: 1

      If you're relying on the MTA to keep your email communications secure, you're doing it wrong. If data is important enough to encrypt, encrypt it at the sender side first.

      In this case, sending email over TLS is akin to browsing the web over TLS: You let the browser / MTA handle the encryption at a lower OSI layer than the application layer. Thus, it works transparently and without hassle to the end user. Would you suggest using GPG to manually encrypt and decrypt all your communication with any HTTPS website?

      Note that the STARTTLS command is a fix for using port 587 to send encrypting mail instead of the port which is dedicated to it: port 465. It is like sending HTTPS down port 80 with a special flag. Properly configured MTAs should be using port 465 for email over TLS instead of port 587 with a "special flag".

      --
      It is dangerous to be right when the government is wrong.
    9. Re:Always RTFA by david_thornley · · Score: 1

      If I get extremely drunk and walk through the worst part of town while flashing large amounts of money and jewelry, and expect to go untouched, I may well be fooling myself. However, anybody who hits me over the head and robs me is still committing a serious crime. Just because I can expect a crime to be committed doesn't mean it isn't illegal.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  9. subject to eavesdropping and interception by fustakrakich · · Score: 3, Insightful

    Okay.. I assume that's the reason. The people who believe in encryption will just have to encrypt their mail before it leaves the machine. That's just the way it is. How many times does it need to be said? If you want something done right...

    How is it that anybody trusts their providers with the kind of history they have? I mean, can we tawk?

    --
    “He’s not deformed, he’s just drunk!”
    1. Re:subject to eavesdropping and interception by MrNemesis · · Score: 1

      So let's say you do go to the bother of setting up a nice GPG system between yourself and third parties and you're happily transmitting your alphanumeric gobbledeygook to your mail server via STARTTLS... ...along comes Verizon or whomever. They strip out the TLS negotiation and now your mail client is authenticating to your mail server in plaintext. Any MITM attacker will then sniff your credentials and start playing funny games with your mail. Blackholing your GPG encrypted mails? Randomising each sig block it sees every time? Replacing signature.asc on all of the mails with their own? Sending fake messages saying "I can't get this stupid encryption thing to work, can we just talk normally please?!"? Worse still is that Alice and Bob will now have a false sense of security whilst Charlie laughs all the way to the Nigerian Bank/NSA/HMRC/GEFAFWISP. GPG in the context where a MITM is blatantly trying to undermine the authentication process is a bit like putting a secure padlock on a paper bag.

      In short: just encrypting your mail at the source isn't really a solution to what is a blatant MITM attack. Hopefully server and client software will start mandating TLS instead of STARTTLS very soon... wish it had been the default for years.

      --
      Moderation Total: -1 Troll, +3 Goat
    2. Re:subject to eavesdropping and interception by Charliemopps · · Score: 1

      Okay.. I assume that's the reason. The people who believe in encryption will just have to encrypt their mail before it leaves the machine. That's just the way it is. How many times does it need to be said? If you want something done right...

      How is it that anybody trusts their providers with the kind of history they have? I mean, can we tawk?

      No, this is just firewall management.
      The problem is on the emails server side. Failed connections shouldn't default to plain text for Christs sake.
      STARTTLS is a way to run encrypted traffic on a plain text port. ISPs are not going to allow that.
      You can still send encrypted email, just not over that port.
      This is a failure on the email providers side, not the ISPs.

  10. Re: DMCA (Defamation) by xaotikdesigns · · Score: 5, Interesting
    Hey, if I write an email, I own the copyright, correct?

    The encryption is a method I use to keep others from reading said copyrited work, correct?

    This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.

    --
    XDInd
  11. Most severs shouldn't be vulnerable by MrEricSir · · Score: 0

    By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted.

    Look, most severs these days are configured in such a way that STARTTLS runs on a different port than the plain-text connection. The server will reject login requests until the STARTTLS handshake is completed.

    So sure, a few old, badly configured servers will continue over an unencrypted connection. But take it from a guy who worked on an email client, this is not a typical setup these days.

    (Also: STOP USING STARTTLS!!!)

    --
    There's no -1 for "I don't get it."
    1. Re:Most severs shouldn't be vulnerable by LessThanObvious · · Score: 1

      I'm glad Yahoo uses a different port as you mentioned if you POP you mail down encrypted. This at least allowed me to to pull multiple years worth of email off of Yahoo's servers which obviously can't be trusted anymore.

      When you say stop using STARTTLS are you advocating PGP as the alternative?

    2. Re:Most severs shouldn't be vulnerable by _merlin · · Score: 3, Insightful

      Maybe he's suggesting to just use plain SSL without the initial plaintext exchange and initiation.

    3. Re:Most severs shouldn't be vulnerable by PAjamian · · Score: 5, Informative

      Look, most severs these days are configured in such a way that STARTTLS runs on a different port than the plain-text connection.

      Wrong. STARTLS specifically allows for both plain text and TLS on the same port.

      The server will reject login requests until the STARTTLS handshake is completed.

      Partially correct. A well configured server will behave this way on the *submission* port (587) but if the MX port (25) were configured this way then you would be blocking a lot of legitimate email from old servers on the internet that do not support STARTTLS and as such is is not recommended to require STARTTLS for port 25 MX to MX communication. Also even when STARTTLS is used the connection is still plain text until STARTTLS is negotiated.

      But take it from a guy who worked on an email client

      Thanks for giving me a link to yet another piece of software written by someone who doesn't understand the technology behind it.

      (Also: STOP USING STARTTLS!!!)

      Wrong again. The only way to have an encrypted SMTP submission channel without STARTTLS (other than tunnelling through ssh or something like that) is via SMTPS (port 465). SMTPS is long ago deprecated and should not be used. Port 465 was *never* officially registered for this use and was essentially "hijacked" and there are only a very small number of old email clients that support SMTPS but do not support STARTTLS. You *should* be using STARTTLS over port 587 which is the submission port. Also STARTTLS is the only legitimate means of encryption between a submission server and an MX.

      Of note (which I've also said elsewhere), the real reason the author of the original article had problems is because he is trying to use port 25 for submission. He should be using the submission port (587) and it is highly unlikely that his ISP would be blocking the STARTTLS flag on that port.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    4. Re:Most severs shouldn't be vulnerable by PAjamian · · Score: 1

      That would be SMTPS which is deprecated.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    5. Re:Most severs shouldn't be vulnerable by _merlin · · Score: 2

      Just being deprecated doesn't mean it's necessarily a bad idea. I still prefer IMAPS/POP3S/SMTPS over this silly STARTTLS nonsense. For one it can't be hijacked as easily as these ISPs are doing.

    6. Re:Most severs shouldn't be vulnerable by PAjamian · · Score: 2

      For one it can't be hijacked as easily as these ISPs are doing.

      ...which they're *not* doing. This article is a farce written by someone who can't even configure his email client to use the correct port for submission. He's trying to use port 25 which is only for MX to MX communication and not for submission, he should be using 587 and if he did there would very likely be no problems.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    7. Re:Most severs shouldn't be vulnerable by cbiltcliffe · · Score: 2

      For one it can't be hijacked as easily as these ISPs are doing.

      ...which they're *not* doing. This article is a farce written by someone who can't even configure his email client to use the correct port for submission. He's trying to use port 25 which is only for MX to MX communication and not for submission, he should be using 587 and if he did there would very likely be no problems.

      Bell Sympatico in Canada uses port 25 for encrypted client to server connections Port 587 times out. Completely non-standard fuckery, I realize, but it's certainly possible that this guy's ISP does something similarly stupid.

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
    8. Re:Most severs shouldn't be vulnerable by MrEricSir · · Score: 1

      Maybe he's suggesting to just use plain SSL without the initial plaintext exchange and initiation.

      Yup. Nobody needed to reinvent traditional TLS/SSL secure sockets in order to send email.

      What's wrong with STARTTLS? To quote the original RFC: "...a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error."

      So in other words, if you're writing an SMTP stack you have to handle a severe security edge case by parsing a string instead of getting an exception from your secure socket library. What could possibly go wrong! Oh right... there's a reason this is on Slashdot.

      --
      There's no -1 for "I don't get it."
    9. Re:Most severs shouldn't be vulnerable by Jesrad · · Score: 2

      A well configured server will behave this way on the *submission* port (587) but if the MX port (25) were configured this way then you would be blocking a lot of legitimate email from old servers on the internet that do not support STARTTLS

      That's what we do here on the big-gov't email servers. Filtering for non-auth'd relays curbs spam quite cheaply. We already have an answer for ISPs who'd complain about rejection: "Tough."

      --
      Maybe we deserve this world ?
    10. Re:Most severs shouldn't be vulnerable by Anonymous Coward · · Score: 1

      You should see what happened at a previous job a decade ago when I showed the CTO we could cut our spam/filter budget by 95%, *AND* save bandwidth on the mailserver if I simply immediately rejected /all/ connections with connections geolocating to China with only 2 false positives a year going back in recorded history...

      Admittedly, most spam isn't from there, and possibly never was... but at least for our corp, and hack/relay attempts... it actually cut op-ex. Hopefully they've turned that off by now...

      I stand with you "old server? Guess they should have asked for a patch budget..."

    11. Re:Most severs shouldn't be vulnerable by Anonymous Coward · · Score: 0

      Of note (which I've also said elsewhere), the real reason the author of the original article had problems is because he is trying to use port 25 for submission. He should be using the submission port (587) and it is highly unlikely that his ISP would be blocking the STARTTLS flag on that port.

      Ha ha ha. I certainly hope this was meant to be funny, since I'd be rather surprised if they didn't try to do this on all ports. Luckily some of us take deliberate action to get ISPs that don't do shit like this.

    12. Re:Most severs shouldn't be vulnerable by Jesrad · · Score: 1

      I'm trying to get them to block-list all of Nigeria off the Webmail. With 120000 users we get about a couple compromised accounts each month, which I think is actually good. And 99% of the time it's from a 41.xxx address.

      --
      Maybe we deserve this world ?
  12. Requiring encryption server-side by Todd+Knarr · · Score: 4, Insightful

    I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate. The IMAP server also requires encryption and won't accept unencrypted connections. If my ISP starts pulling anything that disables encryption, my e-mail will start failing with errors. I'd recommend all mail servers be configured this way.

    It's disappointing that we're increasingly having to treat our ISPs as obstructions to be worked around or opponents that need to be defeated for things to work right. We're paying them that monthly subscription to carry our traffic, we oughtn't have to jump through hoops to get our traffic carried without interference.

    1. Re:Requiring encryption server-side by kiite · · Score: 1

      I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate.

      So, when the client sends AUTH PLAIN <b64-encoded username+password>, and your server rejects the request because it isn't encrypted, you're happy with this result?

    2. Re:Requiring encryption server-side by Anonymous Coward · · Score: 0

      Ideally the client would be correctly configured too.

    3. Re:Requiring encryption server-side by kiite · · Score: 1

      Ideally the client would be correctly configured too.

      If all clients were somehow correctly configured (which they won't be, because Users), then OP wouldn't have any need to configure his mail server to reject unencrypted authentication attempts in the first place.

    4. Re:Requiring encryption server-side by Todd+Knarr · · Score: 1

      If any AUTH command comes in from a client over an unencrypted connection, yes it'll be rejected. This is by design, my server requires encrypted connections to the client to prevent eavesdropping on e-mail. If that command comes in over an encrypted connection, it won't be rejected.

      The server also advertises TLS when receiving mail and prefers TLS when sending mail for the same reason. It'll use unencrypted server-to-server connections if the other side absolutely insists on it, but that's not it's first choice.

    5. Re:Requiring encryption server-side by Orgasmatron · · Score: 1

      Typically, the mail server won't even advertise the AUTH command until after the connection is encrypted.

      If your mail client is sending unadvertised commands, you should probably file a bug report.

      --
      See that "Preview" button?
    6. Re:Requiring encryption server-side by kiite · · Score: 1

      Since you're having trouble reading between the lines, I'll explain:

      1. Unfortunate client is set to prefer (not require) encryption.
      2. Client connects to server.
      3. Client sends STARTTLS request.
      4. MITM rejects STARTTLS request.
      5. Client sends AUTH command, with username and password, over unencrypted channel.
      6. Server rejects unencrypted AUTH command.
      7. MITM issues STARTTLS request.
      8. MITM issues AUTH command with the password it just stole.

      This can, incidentally, be done over any public network by a MITM. Rejecting that unencrypted AUTH command helps combat users who disable (or don't enable) encryption in their clients, simply because they'll try it once, then enable encryption when they can't send mail (hopefully it isn't too late at that point). But it does nothing against users with mail clients that are not set to require that encryption succeed. It does nothing to address the case of the ISP stripping STARTTLS requests.

    7. Re:Requiring encryption server-side by Anonymous Coward · · Score: 1

      I agree with anyone who says that this should be solved at the client level. Clients should stop accepting unencrypted fallbacks. Then this kind of chicanery will cause a break in the user's face and the problem will get solved quicker and better.

    8. Re:Requiring encryption server-side by kiite · · Score: 1

      As a man-in-the-middle, how difficult do you think it would be to add 250 AUTH PLAIN to a cleartext server response?

    9. Re:Requiring encryption server-side by Kevin+by+the+Beach · · Score: 1

      My white board at work has a permanent sketch of a generic internet/cloud services topology that my wife can refer to. All of the communications arrows between services have been centralized in the diagram and I've drawn a big red circle that encloses these connectors. The label on the circle is TRUST... if you can't TRUST the people that connect the services together you can't TRUST anything.

    10. Re:Requiring encryption server-side by Todd+Knarr · · Score: 1

      Problem is, this only works within your facility where you control the physical network. The moment you go outside the facility, where you have to run over physical wires that someone else controls, you're in a position where you don't (can't) know whether you can trust the people that connect things together. The trick then is to design things so you don't have to trust them. For instance I'd run things over SSL/TLS, create my own private CA and issue my own certificates for my systems, then remove everything but my own issuing certificates from the certificate stores on my network. It won't prevent an MITM attack, but it'll make it fail when Mallory can't present a certificate with a valid signature and I'll know there's an attack in progress.

  13. charge of espionage? by Anonymous Coward · · Score: 0

    If this is happening to businesses, not just people, wouldn't this fall under espionage?

  14. smtpd_tls_security_level=encrypt by Maow · · Score: 1

    I believe the setting for postfix smtpd to smtpd is this:

    smtpd_tls_security_level=encrypt

    And for clients:

    smtp_tls_security_level=encrypt

    Any wizards with corrections or comments welcome!

    1. Re:smtpd_tls_security_level=encrypt by PAjamian · · Score: 2

      Kind of, smtpd_* is for when postfix is the server and smtp_* is for when postfix is the client (ie when it connects to another server to relay mail). At any rate this setting should only be used for submission and not for server to server communication otherwise you will end up blocking mail to and from other servers that do not support TLS (there are many). The default setting for this is "may" which is for "opportunistic" TLS which can fall back to plain text if need be.

      If you RTFA you will see that the author is trying to submit mail to port 25 on his email server which is supposed to be for MX to MX communication only. If he were to submit to the proper submission port (587) he would likely find that the STARTTLS flg is not blocked by his ISP, in other words this whole article is a farce written by someone who doesn't know what they're talking about.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
  15. Change the email client to require encryption. by Anonymous Coward · · Score: 0

    Then complain to the isp that they have broken the email server.

  16. Re: DMCA (Defamation) by Pfhorrest · · Score: 5, Funny

    I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?

    --
    -Forrest Cameranesi, Geek of all Trades
    "I am Sam. Sam I am. I do not like trolls, flames, or spam."
  17. Anti-Spam Measure? by ewhac · · Score: 3, Insightful

    Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.

    1. Re:Anti-Spam Measure? by PAjamian · · Score: 1

      I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine

      Yes and that's exactly what's happening, FTFA:

      They determined Cricket was intercepting and blocking STARTTLS on port 25

      (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp).

      Absolutely correct, with the exception that smtps is long deprecated and only port 587 (submission) should be used for the submission of email.

      I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.

      This is fairly normal. Many ISPs simply block outbound port 25 rather than filtering out STARTTLS. Personally I think that's the better approach for these ISPs (to just block the port alltogether), but either way this article is a bunch of crap written by someone who can't even set his email client to connect to the right port.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    2. Re:Anti-Spam Measure? by Anonymous Coward · · Score: 0

      Shouldn't server-to-server communications be encrypted, too? If the only the submission hop is encrypted, it's pretty pointless.

    3. Re:Anti-Spam Measure? by dotancohen · · Score: 1

      I am aware of port 25 being depreciated, but not 465. Is there an RFC that I should be reading? I still submit mail specifically on port 465 so that I can avoid STARTTLS and require encryption. Of course, seeing how I manage the MTA I have that luxury.

      If port 465 is no longer recommended I would like to know when and why that happened. Thanks.

      --
      It is dangerous to be right when the government is wrong.
    4. Re:Anti-Spam Measure? by oobayly · · Score: 1

      I think you've got it the wrong way round - 465 (SMTPs) is deprecated, 25 is still the standard SMTP port.

    5. Re:Anti-Spam Measure? by dotancohen · · Score: 1

      MTA to MTA is still on port 25, yes, but mail submission via a MUA is no longer recommended on port 25, and many ISPs specifically block 25 as an anti-spam measure.

      MUA submission is done on:
      1) Port 587 plaintext, or
      2) Port 587 encrypted by specifying STARTTLS, or
      3) Port 465 encrypted

      I've not heard that 465 is depreciated until now, and in fact I actively avoid STARTTLS so I use it.

      --
      It is dangerous to be right when the government is wrong.
    6. Re:Anti-Spam Measure? by amxcoder · · Score: 1

      This is fairly normal. Many ISPs simply block outbound port 25 rather than filtering out STARTTLS. Personally I think that's the better approach for these ISPs (to just block the port alltogether), but either way this article is a bunch of crap written by someone who can't even set his email client to connect to the right port.

      Except when I pay for an internet connection, I would like all ~65K ports OPEN, not just some of those open. I have my own router/firewall, and can block any ports if needed on my side, I just want an open pipe, all of it. If it's ok for them to block port 25, then when they want to stop other services from working on their network, they will block other ports, and then the user isn't getting the whole internet access that they are paying for. I think it's disingenuous for any IPS to block ports on their end to a customer.

    7. Re:Anti-Spam Measure? by Slashdot+Parent · · Score: 1

      If you have a consumer connection, blocking some ports (e.g outgoing port 25) is pretty standard. I think they block a few incoming ports due to Windows security flaws, as well. If you want to ditch the hand-holding, then get a business connection.

      --
      They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
    8. Re:Anti-Spam Measure? by amxcoder · · Score: 1

      I realize this is fairly standard, however that's not the point. As any paying customer, residential or business, they shouldn't be blocking any of it. I should be able to use whatever port I want. I shouldn't have to jump through hoops if I'm running some obscure application or service that uses some port that they block just because they didn't forsee the average user using that application. That is BS.

      If they do this to port 25 and some others for our protection, what's to say that one day, when you pay an ISP for internet, they will only open up port 80 and the rest is blocked "for your protection". Oh, you want those other ports open, you need to pay us more for a business class service!

    9. Re:Anti-Spam Measure? by Rich0 · · Score: 1

      Yup, Verizon has been talking about blocking outbound 25 for ages. I send all my outgoing mail through Amazon as a result, on 587. It is a real pain though as they don't support bouncing mail from other domains in this way (useful for mail forwarding, and of course for lists). Anti-SPAM measures tend to be hard on both of those use cases.

      Even if Verizon didn't block outbound port 25, chances are everybody else is going to block it on the incoming side if you're coming from a dynamic pool, unless you're authenticated.

    10. Re:Anti-Spam Measure? by PAjamian · · Score: 1

      It's done to help with anti-spam in general on the internet. A large percentage of PCs (especially windows PCs) are compromised and blocking outbound port 25 is a standard measure by ISPs to prevent those from being used as spambots. If you have a legitimate need for outbound port 25 traffic then most ISPs will unblock it for you on request (if you have a static IP, that is). That said, even if they do you will still likely be listed on a number of different policy blacklists which you will then have to play whackamole with to get your email accepted by other servers on the internet. A much better approach is to use a relayhost or to get a cheap VPS to relay through.

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    11. Re:Anti-Spam Measure? by PAjamian · · Score: 1

      There are other options than Amazon, have a look at Madrill

      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    12. Re:Anti-Spam Measure? by PAjamian · · Score: 1
      --
      Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
    13. Re:Anti-Spam Measure? by dotancohen · · Score: 1

      Thanks. Going through this thread I do see that the consensus is against the use of port 465. I find this strange, but not the strangest thing that I've seen this week. Thank you.

      --
      It is dangerous to be right when the government is wrong.
    14. Re:Anti-Spam Measure? by thejynxed · · Score: 1

      I haven't heard of it being deprecated, but I have heard of many, many ISPs blocking self-run email services, no matter what ports you attempt to use. These blocks magically disappear however, if you upgrade to their business class service.

      --
      @Mindless Drivel: 100% of Twitter posts ever Tweeted.
    15. Re:Anti-Spam Measure? by Rich0 · · Score: 1

      There are other options than Amazon, have a look at Madrill

      Amazon wasn't my first choice. I tried using some service that turned out to use reachmail, and I got a lot of bouncing. Since I can't bounce my mail through amazon anyway, my outgoing volume ends up being super-low and so the costs aren't that high. I send most of my mail through gmail - it is really only things like mail aliases and server messages that don't go to myself that go out through Amazon.

  18. Re: DMCA (Defamation) by Anonymous Coward · · Score: 1

    I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?

    He's casting a wide net to cover all possibilities...

  19. Re:Big Brother is inside by Anonymous Coward · · Score: 0

    What the hell are you talking about? I don't see how limiting the government's power to ban people from controlling their own bodies is the same as Uncle Sam entering the wombs of fertile women. Care to explain?

  20. Isn't this illegal? by koan · · Score: 1

    It should be.

    --
    "If any question why we died, Tell them because our fathers lied."
    1. Re:Isn't this illegal? by Anonymous Coward · · Score: 0

      Not when a large corporation with lobbyists does it.

  21. Re: DMCA (Defamation) by LessThanObvious · · Score: 1

    Obnoxious as their behavior is, I don't think the copyright violation holds. Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented. If the sending side agrees to send unencrypted, then it is effectively consenting to send in the clear. No matter what happens between your client and the server there is always a chance a server in the forwarding chain will not preserve the TLS connection, nor is there any guarantee in most cases that the message recipient will access the message over an encrypted channel. God help us all, because corporations sure can't help themselves.

  22. Re:Big Brother is inside by Anonymous Coward · · Score: 0

    He could explain, but then he'd have to kill you.

  23. Computer Fraud and Abuse Act by jopsen · · Score: 1

    This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.

    Isn't this just hacking, in the criminal media-defined sense of the word.

    With recent additions from patriot to fraud act, this smells a lot like "conspire to commit" at the very least. It certainly seems like unauthorized access, as you forced access to information you were not authorized to access.
    Just because the internet protocols have lots of holes does not mean they can be legally exploited.

    Is this a crazy thought?

    1. Re:Computer Fraud and Abuse Act by Anonymous Coward · · Score: 0

      Leaving my window open does not allow you to crawl inside my home.

  24. Don't blame the ISPs for STARTTLS by MobyDisk · · Score: 1

    1) Because SSL/TLS was so poorly supported for years, many email clients default to using security only if the server supports it. Email software should simply drop support for unencrypted SMTP, or report a big warning if the server doesn't support it. We would not tolerate such a proxy for the web, so we should not tolerate it for email either.
    2) A recent Slashdot discussion revealed that the STARTTLS stripping was due to misconfigured proxy servers. I think this is a rehash of the same incident.

    1. Re:Don't blame the ISPs for STARTTLS by Anonymous Coward · · Score: 0

      Yeah, if you're relying on STARTTLS to encrypt anything for you, it's already game over for this very reason. All you have to do is politely ask it not to do the encryption and it won't. That's kid brother level security right there. And only if your kid brother is kinda slow...

    2. Re:Don't blame the ISPs for STARTTLS by jones_supa · · Score: 1

      Email software should simply drop support for unencrypted SMTP, or report a big warning if the server doesn't support it.

      Mozilla Thunderbird already shows a big scary warning when you try to set up an account without encryption.

    3. Re:Don't blame the ISPs for STARTTLS by odie5533 · · Score: 1

      If you create an account that supports encryption, but the account later silently drops the encryption, will Thunderbird warn you that the message you are sending is being sent as plain text?

    4. Re:Don't blame the ISPs for STARTTLS by jones_supa · · Score: 1

      Then Thunderbird would probably fail to connect as it can't establish the encrypted connection.

    5. Re:Don't blame the ISPs for STARTTLS by Anonymous Coward · · Score: 0

      No, Thunderbird doesn't show that warning when you set up an account with STARTTLS and it falls back to unencrypted.

    6. Re:Don't blame the ISPs for STARTTLS by jones_supa · · Score: 1

      Does it allow it to fall to unencrypted?

  25. Firewalls blocking STARTTLS by Anonymous Coward · · Score: 0

    Some firewalls do this (or at least they did in 2006-7) on inbound email. The remote server would issue the EHLO command, and the firewall would convert it to HELO so no extensions (like STARTTLS) would be supported. This made it difficult to provide a secure channel for customers to send data via email. As this was happening in the firewall of a hosting center, we were able to persuade the authorities to turn off this misfeature in the firewall, at least for our traffic.

  26. Re:Big Brother is inside by BradMajors · · Score: 2

    It is very relevant. Roe versus Wade was decided base upon the constitutional right to privacy.

  27. Authentication by kiite · · Score: 4, Informative

    Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?

    1. Re:Authentication by drinkypoo · · Score: 1

      Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption.

      And when you make assumptions, what happens?

      Still don't feel like getting angry?

      I only feel like getting angry at two people. The people who make encryption optional the default, and you — because you're making excuses for stupidity. You're enabling idiots. Stop it.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Authentication by Rich0 · · Score: 1

      Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption.

      I do this simply because many services don't accept TLS connections if the certificate isn't trusted. I still want to use TLS whenever somebody is willing to do so.

      It is a bit frustrating because right now I'm sending almost 100% of my mail unencrypted over POP3 along with credentials simply because Google refuses to use SSL with a self-signed certificate. Sure, somebody could MITM me if they did accept self-signed certificates, but now they can not only MITM me, but they can also just passively intercept everything.

  28. Re: DMCA (Defamation) by GigaplexNZ · · Score: 5, Insightful

    Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.

    That's still circumvention in my books. http://www.law.cornell.edu/uscode/text/17/1201

    to “circumvent a technological measure” means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner;

  29. Re: DMCA (Defamation) by dayton967 · · Score: 1

    One problem to the argument is that it's not actually decrypting your messages, which the topic makes the mistake on.. it's just telling the client that the server doesn't support Encryption, in which the client will then sent in the clear.

  30. Preferred Solution by PPH · · Score: 1

    Encrypt it on your system before you send it. Expect the recipient to decrypt it on theirs after receipt. Everything traveling on teh Internets is subject to interception.

    --
    Have gnu, will travel.
    1. Re:Preferred Solution by Errol+backfiring · · Score: 1

      I do not expect my mum / uncle / holiday friend or any other non-technical person to be able to even use GPG. Let alone find other ways to decrypt it. Alas, e-mail security mainly hangs on secure connections.

      --
      Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
    2. Re:Preferred Solution by PPH · · Score: 1

      That's due to a failure of the popular 'point and click' e-mail clients to provide an easy to use layer on top of GPG or similar tools. And that might be by design. Microsoft, Google and others have access to your content and a 'trust me' policy. They might have been arm-twisted into this design decision by our intelligence services.

      --
      Have gnu, will travel.
  31. Re: DMCA (Defamation) by xaotikdesigns · · Score: 1

    But you don't have to actually decrypt something to violate the DMCA. Can't you just be in violation for making a system to bypass decryption, which is in effect, what they have done. They are bypassing the encryption you are attempting to put on your work.

    --
    XDInd
  32. For the good of deliverability.... by Anonymous Coward · · Score: 0

    Yahoo among others will solicit TLS but don't really support it and will bounce mail.

    I've made the mistake 'respecting' TLS solicitations from third parties only for them to bounce my mail....

    I would be surprised if this was malicious and expect they are stripping it out because its an absolute pain to properly support (thanks to bad players like Yahoo)

    **Yahoo may have changed their game....its been a while since I tried it

  33. Protonmail FTW? by Anonymous Coward · · Score: 0

    https://protonmail.ch/

    Basic blurb, from the website (I have no interest in the product other than as a user).

    [quote]
    Swiss Based -- Protected by Swiss Privacy Laws.
    ProtonMail is incorporated in Switzerland and our servers are located in Switzerland. We are outside of US and EU jurisdiction and user data is protected by strict Swiss data protection laws.

    Zero Access -- We can't read your data.
    Because of our end-to-end encryption, your data is already encrypted by the time it reaches our servers. We cannot decrypt your encrypted messages and as result, we cannot share them with third parties.

    Easy to Use -- Encryption without the headache.

    Backwards Compatible
    ProtonMail works out of any modern web browser, there is nothing to install. We are also backwards compatible with other email providers so you can continue sending and receiving emails from friends who are not using ProtonMail.

    Forever Free
    Available for everyone.
    We believe privacy is a fundamental human right and should be available for everyone. That's why we offer multi-tiered pricing including a free version that anyone can use. Let's bring privacy back to the people!

    Stay Anonymous
    We don't track our users.
    We do not keep permanent logs or require any personal information to sign up. We even accept anonymous payment methods (such as Bitcoin) so even paid users have their privacy rights protected.

    Cross Platform
    Mobile and tablet friendly.
    ProtonMail works on all devices, including desktops, laptops, tablets, and smartphones. It's as simple as visiting our site and logging in. There are no plugins or apps to install - simply use your favorite web browser.
    [/quote]

  34. Re:Big Brother is inside by Anonymous Coward · · Score: 0

    I still don't understand. It limited the government's power to control people's bodies. How is that Uncle Sam entering the wombs of fertile women? If anything, it's keeping Uncle Sam away.

  35. Noxious not Obnoxious by Anonymous Coward · · Score: 0

    Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.

    Worst case they aren't breaking open the safe , they are just causing the option for the safe's door to remain open and unlocked.

    FTFY

  36. YANAL by lucm · · Score: 4, Insightful

    This is one of the most irritating thing in IT. People think they can figure out law, accounting, fiscality, politics, marketing or diplomacy by using what they perceive as "common sense".

    Here is the thing. All those disciplines are a gray area by nature, and the right answer is largely a matter of professional interpretation. Can you put that number in that column? Can you consider that such or such situation has caused actual damage to someone? There's no compiler to tell you if this is right or not, there's just people navigating a fuzzy field armed with their experience and knowledge. They live in a world where two people can have opposite opinions and be both right at the same time.

    Anyone with a background in applied disciplines like IT or engineering is trained to look at things with a problem-solving angle. That's a great attitude, but unfortunately it sometimes make people overestimate their grasp of concepts that are outside of their area of expertise. It's a lot like those artists who have it all figured out (war, terrorism, pollution, crime, poverty). Case in point: this "enlightened" feedback from Ben Affleck during Bill Maher show: http://www.youtube.com/watch?v...

    Don't be that guy.

    --
    lucm, indeed.
    1. Re:YANAL by wisnoskij · · Score: 1

      Primarily, this is because our laws are based on precedent, and probably no small part that law is partly decided by random civilians. There is not a single law out there that is "interpreted" at all like anyone would interpret the written law to mean. Many of them are closer to the exact opposite than a logical interpretation of the written law.

      --
      Troll is not a replacement for I disagree.
    2. Re:YANAL by tlhIngan · · Score: 1, Troll

      This is one of the most irritating thing in IT. People think they can figure out law, accounting, fiscality, politics, marketing or diplomacy by using what they perceive as "common sense".

      Call it IT doublespeak.

      IT people constantly rag on people for not wanting to learn about computers. Yet those are the same people who aren't willing to learn about law (or even details about IP law - how many have confused copyrights, trademarks and patents?), economics (there's a reason why we have both MICROeconomics and MACROeconomics and things that apply to one do not necessarily cross over), etc.

      I'm sure the lawyers and accountants and economists think computing should work according to "common sense" rules as well.

    3. Re:YANAL by arcade · · Score: 1

      No, the most annoying thing in IT is the person you're responding to, who doesn't understand how TLS for email works in the first place, but pretends to do so, and participates in discussions as if he knows the subject matter at hand.

      The error being that there is no encryption applied by the person who writes the email, but opportunistically by the email servers if both sending and receiving email servers supports TLS. This is done transparantly to the end users (ie the people who write the email).

      --
      "Rune Kristian Viken" - http://www.nwo.no - arca
    4. Re:YANAL by sjames · · Score: 1

      For most of those things, you probably have a point. But law is in the domain of the public. It is our right to make legal judgement since the law belongs to us. That's why at the end of the day it comes down to 12 jurors picked out of the general population (in theory).

    5. Re:YANAL by Anonymous Coward · · Score: 0

      Just looking at recent court decisions should make it pretty clear that common sense has nothing to do with it.... even the Supreme court decisions look pretty idiotic using common sense based on your viewpoint ( and sadly a few even when judged by time).

    6. Re:YANAL by Anonymous Coward · · Score: 0

      So because someone is outside of their field their opinion is invalid? If you're so knowedgable how about you actually put some of that into your post instead of trying to stifle conversation with your contrarian attitude.

      Also don't try to pretend that people don't try to tell IT how to do their jobs all the time as well. This "problem" is endemic to all humanity.

      I'll continue being that guy because I'm sick of your kind of attitude.

  37. s/flag/command/ by Cramer · · Score: 3, Informative

    It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.

    The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.

  38. This was also used in Germany by Anonymous Coward · · Score: 0

    But the described technique doesn't work with every email client. Therefore several providers updated there services to simplify the access.

  39. Solution: by Anonymous Coward · · Score: 0

    Switch to Sprint. Verizon is not only shitty for doing this, they are a shitty carrier who cripple the capabilities of most of their phone's hardware. Verizon sucks, so jump ship on them.

  40. Re: DMCA (Defamation) by geekmux · · Score: 3, Insightful

    Obnoxious as their behavior is, I don't think the copyright violation holds. Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.

    And this doublespeak legalese bullshit right here boys and girls, is exactly fucking why you use your own encryption.

    Seriously, my ears are bleeding because common sense is trying to murder them. If this isn't circumvention, I don't know what is.

    Here's another litmus test. If it were illegal, ANY ONE OF US would be behind bars. No questions asked.

    Here's yet another litmus test. Why is it NOT illegal to tamper with email encryption. This would be akin to the postal service purposely using steam generators on snail mail processing lines and then us overhearing "whoops, I don't know how all this mail got opened accidentally..."

    If we wouldn't stand for them doing such a thing in the physical world, I don't see why the hell we stand for it in the virtual one.

  41. Re: DMCA (Defamation) by fustakrakich · · Score: 1

    Check your contract, real careful like. You probably authorize it.

    --
    “He’s not deformed, he’s just drunk!”
  42. Re: DMCA (Defamation) by fustakrakich · · Score: 1

    ...without the authority of the copyright owner...

    Sure they don't have it?

    --
    “He’s not deformed, he’s just drunk!”
  43. Re: DMCA (Defamation) by GigaplexNZ · · Score: 1
    Yeah, pretty sure.

    Hey, if I write an email, I own the copyright, correct?

  44. Re: DMCA (Defamation) by JeffOwl · · Score: 1

    What does it say in the ISP TOS?

  45. Re: DMCA (Defamation) by fustakrakich · · Score: 1

    I wasn't talking about the copyright. The first reply beat me to the punch(line)

    --
    “He’s not deformed, he’s just drunk!”
  46. Isn't this false advertising? by davidwr · · Score: 1

    If the company is marketing itself as an Internet service provider and actively keeping its customers from the entire Internet then that's false advertising.

    The ISP owes all of its customers who aren't getting the part of the Internet that they want to use a refund, and the company must either change its ways or change its marketing.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  47. This is why you encrypt shit on the client... by Anonymous Coward · · Score: 0

    ... your server cannot be depended to do that.

  48. Re: DMCA (Defamation) by Anonymous Coward · · Score: 0

    I'm pretty sure ISPs can't hijack people's copyrights just because they transmit the data.

  49. Re: DMCA (Defamation) by Anonymous Coward · · Score: 1

    Copyright refers to ownership and/or permission to copy.
    Copywrite is the act of copying with a pen.
    Copyrite is when you do it religiously.

  50. Re: DMCA (Defamation) by GigaplexNZ · · Score: 1

    I didn't see anything in the Cricket Wireless TOS that requires giving permission to circumvent encryption. I skimmed through it though, so if you find something I missed, feel free to point it out.

  51. Re: DMCA (Defamation) by GigaplexNZ · · Score: 1

    The sender of the email presumably owns the copyright of the email. The ISP would need the senders permission to circumvent the encryption if that was the case. As per my response to the first reply that mentioned TOS, I didn't see anything in there claiming such permission.

  52. HIPAA fun... by Anonymous Coward · · Score: 0

    There's a lot of medical traffic going over SMTP right now.

    It goes SMTP with STARTTLS to the server, then the messages are encrypted by the server before being forwarded out via normal SMTP traffic.

    If the plain text initial emails to the server are NOT getting encrypted, then we have a shiny HIPAA violation. That's some good time stuff right there, and it's not even the provider's fault.

    Good times.

  53. Re: DMCA (Defamation) by Anonymous Coward · · Score: 0

    It's true that the DMCA could be invoked it there was intent.

    But disabling the encryption support for all customers is basically not supporting it at all. So that's not intent.

    What should happen is email clients need to identify email services that are no longer supporting encryption and warn the user. Likewise if an email was degraded in transit, it should notify the sender.

  54. They are not removing encryption, more like ... by perpenso · · Score: 1

    They are not removing encryption. Its more like you requested a secure https connection and they give you a plain http connection.

    If you encrypted your email before sending it then it will remain encrypted.

    1. Re:They are not removing encryption, more like ... by Anonymous Coward · · Score: 0

      And what about sending my password in clear text?

    2. Re:They are not removing encryption, more like ... by AK+Marc · · Score: 1

      They are actively using technical means to circumvent encryption.

  55. This is _not_ "email encryption"! by gweihir · · Score: 1

    This is transfer encryption when talking to an SMTP host. The server gets the full email in clear in this scenario, even if STARTTLS is left in.

    Email encryption is what you do with PGP, there is not way to "strip that out", and the SMTP server cannot read the mail, just the headers.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  56. They did not remove your encryption by perpenso · · Score: 1

    When does this shit start to count as criminal? Say a company encrypts all communications with their mailserver and this is part of their legal requirements to protect privacy. Can we sue the pants off them yet?

    No. Because they are not removing *your* encryption. Think for a second, how could they do that, short of your ISP being the NSA. :-)

    What they are failing to do is encrypt the channel between you and the ISP, its like you asked for secure https and they redirected you to plain http.

    Its a non-issue for the legal and medical community since they will encrypt things as needed before it gets to the ISP.

  57. Re: DMCA (Defamation) by Anonymous Coward · · Score: 1

    And copywright is when you make your own airplane.

  58. Re: DMCA (Defamation) by SeaFox · · Score: 2

    I'm pretty sure ISPs can't hijack people's copyrights just because they transmit the data.

    Yeah, that would be like a photo sharing site saying they have permission to use your copyrighted photos for their own promotional purposes since you agreed to the TOS for their site.

    Oh, wait...

  59. Re: DMCA (Defamation) by rthille · · Score: 5, Informative

    The headline is wrong. The ISP is removing the mail server's announcement that it supports STARTTLS, and your mail client/server sends your email unencrypted.
    The solution to that is using SMTPS on 465, where encryption is presumed, not negotiated. But that was deprecated soon after the RFC came out in favor of TLS. It's almost like someone was thinking ahead and wanted the internet to be less secure:
    http://cr.yp.to/talks/2014.10....

    --
    Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
  60. To illustrate the above point by dbIII · · Score: 1
    Sadly some years ago Adobe had Dimitry Sklyarov locked up on precisely those grounds.

    The 27-year old Russian programmer and hacker who was arrested after Defcon was last spotted at 3 pm Monday, when he made a brief court appearance in Las Vegas. He's charged with violating the 1998 Digital Millennium Copyright Act.

    http://yro.slashdot.org/story/01/07/18/1136244/sklyarov-arrest-follow-up

    so the jokes made about the DMCA before are now true: crack ROT-13, go to jail

    So even a code written about by Julius Caeser (ROT) is covered by it.

  61. Sue them by Hamsterdan · · Score: 1

    They're in violating of the DMCA

    Wait, they're ISPs so it doesn't apply

    --
    I've got better things to do tonight than die.
  62. Breaking encryption? by Hamsterdan · · Score: 1

    So sue them for 12 billion dollars like they do for music downloaders. (or is it just for big corporations?)

    --
    I've got better things to do tonight than die.
  63. Re: DMCA (Defamation) by icebike · · Score: 1

    Hey, if I write an email, I own the copyright, correct?

    The encryption is a method I use to keep others from reading said copyrited work, correct?

    This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.

    No, you misunderstand what is going on here.

    StartTLS is something that happens when your email client connects to the mail server with an insecure protocol on a non-ssl port, and then asks the server to switch to a secure connection. Its your clue that you are doing it wrong,

    Connect on a secure port over ssl (usually 465) instead of 25. Set your client up right to use a secure port and they can't deny a secure connection. (Unless they don't support security at all, in which case run away from them like your hair is on fire).

    WITHOUT doing it right, your email was never secure, never encrypted, so no DMCA violation.

    They aren't denying you a secure connection, they are just putting the burden on you to do it properly instead of having their servers to the extra work of switching an insecure connection to a secure one, which usually entails a whole bunch of handshake-security dance.

    Set your client up the right way on the right ports.

    --
    Sig Battery depleted. Reverting to safe mode.
  64. Re: DMCA (Defamation) by icebike · · Score: 1

    Finally, some on who gets it,

    Set your client up right and stop all this hand wringing. Its a tempest in a teapot.

    --
    Sig Battery depleted. Reverting to safe mode.
  65. Re: DMCA (Defamation) by sexconker · · Score: 1

    Yeah, pretty sure.

    Hey, if I write an email, I own the copyright, correct?

    Then you have your client set to require encryption, not merely prefer it. And thus your client never sends an email in the clear, and thus they have not violated the DMCA or your copyright.

  66. Re: DMCA (Defamation) by Chrisq · · Score: 3, Insightful

    I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?

    He's casting a wide net to cover all possibilities...

    Its a Mountweazel in case someone plagiarizes his wonderful post.

  67. Re: DMCA (Defamation) by GigaplexNZ · · Score: 1

    If you do that, your emails will simply fail to send as per these guys who discovered the issue. You're right though, at least it won't fall back to unencrypted transmission.

  68. OK so what we need is an option on mail clients by Chrisq · · Score: 1

    OK so what we need is an option on mail clients "presume TLS support". Surely this is an area where open source software can demonstrate its advantage with a quick work-around

    1. Re:OK so what we need is an option on mail clients by Anonymous Coward · · Score: 0

      The option is to use SSL/TLS instead of STARTTLS. What other option do you need?

    2. Re:OK so what we need is an option on mail clients by Chrisq · · Score: 1

      The option is to use SSL/TLS instead of STARTTLS. What other option do you need?

      Fine if its supported at the server end. Often it isn't

  69. Two PCs were infected and a Apple computer system by Anonymous Coward · · Score: 0

    Privacy International in October 2014 made a criminal complaint to the National Cyber Crime Unit of the National Crime Agency, urging the immediate investigation of the unlawful surveillance of three Bahraini activists living in the U.K. by Bahraini authorities using the intrusive malware FinFisher supplied by British company Gamma.

    Moosa Abd-Ali Ali, Jaafar Al Hasabi and Saeed Al-Shehabi, three pro-democracy Bahraini activists who were granted asylum in the U.K., suffered variously from years of harassment and imprisonment. Investigation and analysis by human rights group Bahrain Watch showed that while
    Moosa, Jaafar, and Saeed were residing in the U.K., Bahraini authorities targeted the activists and had their computers infected with the surveillance Trojan FinFisher.

    The complaint argues that the actions of the Bahraini authorities qualifies as an unlawful interception of communications under section 1 of the U.K.’s Regulation of Investigatory Powers Act 2000. By selling and assisting Bahraini authorities, the complaint argues that Gamma is liable as an accessory under the Accessories and Abettors Act 1861 and/or encouraged and assisted the offence under the Serious Crime Act 2007.

    ( Two PCs were infected and a Apple computer system was infected. They turned up at a meeting in their own country and was arrested. They have been given multiple life sentences and will never see the light of day again. All for the lack of an interactive firewall and an up-to-date virus scanner and a basic understanding of PC security ).

  70. Re: DMCA (Defamation) by grahamm · · Score: 1

    No, what it is doing (to borrow the analogy from an eralier posting) is opening every letter in an evelope, putting the contents in a see-through bag and adding a new addres label.

  71. Re: DMCA (Defamation) by sjames · · Score: 1

    So, it will be perfectly OK is I figure out how to convince Blu ray players not to encrypt their HDMI outputs and I sell a solution to the general public?

  72. Re: DMCA (Defamation) by Anonymous Coward · · Score: 0

    Most email is not copyrightable; emails that contain just facts or business dealings.

    Business email for example almost never is, therefor the footer that many companies append are a lie, and one could sue them for claiming copyright on something that can't be.

  73. Re: DMCA (Defamation) by sjames · · Score: 1

    I wouldn't hang too much on the DMCA requirement that the protection method must be effective. In practice, the bar for effective isn't just low, it's buried under the sub-basement floor.

  74. How can this trick work by jones_supa · · Score: 1

    How can this work? Wouldn't the client notice that the STARTTLS command did not complete successfully and/or that the session is not encrypted?

  75. I've always assumed there is no encryption by msobkow · · Score: 1

    I started using email!back!in!the!days!when!you!had!to!know!the!route, so I've never assumed emails are encrypted unless I use PGP or some equivalent tool.

    --
    I do not fail; I succeed at finding out what does not work.
  76. Re: DMCA (Defamation) by drinkypoo · · Score: 1

    Well, no no and no. See, by refusing to pass this header along to the next node, they're preventing encryption. They're not removing it. If you actually encrypted the message payload with PGP or similar, that stays encrypted.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  77. Article Title is Misleading by Anonymous Coward · · Score: 0

    The ISPs are not decrypting encrypted email. They are removing the flag in the header that tells the server to use encrypted connections between itself and other servers or clients.

    This is a non-issue for those who encrypt their email contents.

  78. Re: DMCA (Defamation) by TrentTheThief · · Score: 1

    Well played!

  79. I call, "Who gives a damn?" by TrentTheThief · · Score: 1

    If I send clear text to the internet, it is because I don't give a damn who reads it.

    However, when I wish my communications to remain private, I encrypt it myself before it ever leaves my local network.

    If you don't care enough to encrypt things you wish to remain private, then you are the only one responsible for allowing _anyone_ to read your mail. Don't rely on some nebulous third party to provide _your_ protection against eavesdroppers. Take charge of your life dammit, and quite whining.

    tl;dr: Encrypt it yourself and then it doesn't matter if the transport channel is encrypted or not. Stand up on your own and be responsible for yourself!

  80. Re: DMCA (Defamation) by K.+S.+Kyosuke · · Score: 1

    Surely it's an attempt at defamation by his ISP tampering with his traffic.

    --
    Ezekiel 23:20
  81. Re: DMCA (Defamation) by K.+S.+Kyosuke · · Score: 1

    I always assume that playwrights are toy RC plane makers.

    --
    Ezekiel 23:20
  82. Re: DMCA (Defamation) by Anonymous Coward · · Score: 0

    But it is a circumvention against an effective means of encrypting copyright'ed data. They are in violation of the DMCA and should be sued under a class action lawsuit.

  83. Re: DMCA (Defamation) by rvw · · Score: 1

    Hey, if I write an email, I own the copyright, correct?

    The encryption is a method I use to keep others from reading said copyrited work, correct?

    This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.

    No it isn't, because they encrypt it, not you. STARTTLS is encryption implemented by the provider. The message is only encrypted during passage from your mail program to their server, and from their server to another STARTTLS server, but that's it. The end receiver gets the message unencrypted in his or her mail program. It can be worse. If the provider from the receiver does not use STARTTLS, the message is not delivered encrypted.

  84. TOLD YOU by Anonymous Coward · · Score: 0

    And THAT boys and girls is why you should NEVER relay on a server side encryption. Encryption needs to ALWAYS be on the client side, and ALWAYS under the clients control and NEVER using an encryption tool provided by your ISP.

    1. Re:TOLD YOU by ledow · · Score: 1

      If you're worried about encryption, a protocol designed to be able to strip the encryption at any stage and pass it on to other servers, servers which may be out of your control, is not really encryption at all.

      Email just isn't designed to do what you might want. Email encryption is either that of the message (which requires all recipients to have keys you can use and knowledge to use them) or merely securing transit to your first-hop email server. If anyone thinks that email you can read in your client without decrypting it is in any way secure, they have zero understanding of the system (which is the most dangerous security flaw you can have).

      The problem is, as always, that we're forcing old protocols to do things they were never designed to, and relying on the goodwill of other people to follow our rules. Even if we published a policy "refuse any email server without STARTTLS en-route", it's easily ignored or bypassed in the case of a single malicious operator in the path of the message.

      The solution is really for all domains to publish a public key via DNS, for the client or first-hop server to encrypt the message to the recipient's domain with their domain key, then it DOES NOT MATTER who you hand it off to. The data is encrypted so it cannot be revealed except to the proper desired recipient.

      All we have is transit security to the first hop. We would still need that (otherwise I could easily still get an email server that sniff my credentials and uses them to spam people) but it's not the same as message encryption - not by a long shot.

      Transit security to the first hop, so your login is protected, so you can authenticate that it's YOUR email server, etc. Then send an encrypted message. Then it doesn't matter what your email server chooses to do with it - either the desired recipient receives an email only they can open, or they receive nothing at all.

      The problem is, email DOES NOT DO THIS. And backward compatibility with plain-text email means we can't do this without breaking half-the-world. The time will come, like SSH over telnet, or SFTP over FTP, when we decide that we do need to do this. But it's not happened yet.

      Sadly, when it does happen, it makes mass-spam-filtering much more difficult, vastly increases load on mail-servers and still doesn't stop spam.

  85. I wonder if Rogers (Canada) does this by Anonymous Coward · · Score: 0

    I wonder if Rogers (Canada) does this. My wife was unable to send email over SMTP from Thunderbird last night all of a sudden.

  86. PGP by naris · · Score: 1

    This is not as much of an issue when using PGP or something that encrypts the e-mail before it is sent to the server.

  87. Re: DMCA (Defamation) by sociocapitalist · · Score: 1

    I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?

    Well at least one of them will be write.

    --
    blindly antisocialist = antisocial
  88. Email is insecure by pak9rabid · · Score: 1

    Email is an insecure medium. Anybody that pretends it isn't is going to have a bad time. Sure we might have some tricks to secure messages along some of the paths it's going to traverse, but if you expect it to be secured end-to-end, you're naive. If you absolutely must send something via email that contains sensitive information, GPG-encrypt the message first and then send it, otherwise seek a more secure medium.

  89. It appears no user friendly protocol is safe. by Kevin+by+the+Beach · · Score: 1

    If it's been identified one time, it's likely been happening on a larger scale but as yet undetected. It's becoming very easy to be either paranoid or self censoring. I don't have anything to hide, but being sliced/diced/dissected/analyzed by the big data cloud does get a little bit old. It's easy to see the results of this overreaching data collection, just research a medical condition (especially one that has a name brand pharmaceutical treatment), research a popular consumer appliance, research a new vehicle, etc... then pay attention to the advertisements that appear on websites over the next couple days... do you notice anything... like ads for what you researched?

    I occasionally poison my search results by just doing random searches. I pick a person/place/thing that I have no real interest in, and watch the ad world turn. It must really throw off the "kevin by the beach" bucket when I search for Vespa parts, the latest gay romance novel, women named ISIS, and the 10 day weather for geopolitical sites of interest. http://www.weather.com/weather...

    1. Re:It appears no user friendly protocol is safe. by Anonymous Coward · · Score: 0

      I see your point, but it would be better to actually block ads, tracking beacons, etc. rather than continue to allow profiles to be built.

  90. Re: DMCA (Defamation) by yacc143 · · Score: 1

    I guess "deactivate" and "impair" would fit the case?

  91. Re: DMCA (Defamation) by JourneymanMereel · · Score: 1

    No, what it is doing (to borrow the analogy from an eralier posting) is opening every letter in an evelope, putting the contents in a see-through bag and adding a new addres label.

    Except that's not what it's doing. You're handing the letter to them and asking them to put it in an envelope, preferably one of those fancy ones that make it harder to see the contents, and send it. They're pretending like they don't have any of those fancy envelopes and instead putting it in a clear plastic bag. If you want it in a fancy envelope, make sure you specify that it has to be rather than that's what you'd like it to be.

    Or, better yet, mask the contents yourself at the application layer rather than relying on the transport layer. X.509 and PGP are both pains, but they do work and would make this a total non-issue.

    --
    Life has many choices. Eternity has two. What's yours?
  92. Re: DMCA (Defamation) by yacc143 · · Score: 1

    Actually, that depends strongly on the jurisdiction, "tampering with email" is a crime e.g. in Germany.

  93. Re: DMCA (Defamation) by yacc143 · · Score: 1

    Well, you have to sell it under a brand that sounds like "Cisco" ;)

  94. Does This Affect HTTPS/TLS Webmail? by Anonymous Coward · · Score: 0

    Curious if this affects HTTPS/TLS webmail. I use Fastmail.

    Thanks...

    1. Re:Does This Affect HTTPS/TLS Webmail? by takeya · · Score: 1

      No it does not affect Fastmail. I also use it and in fact even if you use an email client instead of webmail, they support full encryption without upgrading through STARTTLS.

      See: https://www.fastmail.com/help/...

  95. Re: DMCA (Defamation) by riis138 · · Score: 1

    Better safe than sorry.

    --
    Somewhere, something incredible is waiting to be known. -Carl Sagan
  96. Re: DMCA (Defamation) by Anonymous Coward · · Score: 0

    Seriously, my ears are bleeding because common sense is trying to murder them. If this isn't circumvention, I don't know what is.

    It's not circumvention, because the e-mail was never encrypted in the first place. Seriously, why is that so hard to understand?

  97. MAN IN THE MIDDLE ATTACK by Anonymous Coward · · Score: 0

    People have gone to jail before for doing man in the middle attacks to gain higher levels of access; even if this is not considered breaking encryption there should be plenty of other laws that have applied to hacking which apply here... except it's an ISP not a teen, researcher, or worst of all-- some kind of activist.

  98. Re: DMCA (Defamation) by unrtst · · Score: 1

    The encryption is a method I use to keep others from reading said copyrited work, correct?

    Nope. In this case, the work is not itself encrypted, the communication channel to but one mail server is.
    Apply GPG, GPG, or S/MIME encryption and your message body is still safe.

  99. Re: DMCA (Defamation) by LessThanObvious · · Score: 1

    I like that argument and I hope it gets heard in front of a judge. I do wonder though since it is actually the packet from the upstream server that is modified and the sender is downgrading their security to accommodate, then sending an unmodified message is there a violation? Is their any legal protection that would stop an ISP from modifying the parameters, but not substance of the upstream mail server's packet? It seams like the upstream mail service provider is the one truly being wronged because the intent of their transmission has not been honored and has been modified without consent such as their ability to provide a secure service to their customer has been harmed.

  100. Re: DMCA (Defamation) by OldSport · · Score: 1

    So "copyrite" is when I see my neighbor sacrificing goats to a pagan god, and I do the same?

  101. Sounds of millions getting in line by Anonymous Coward · · Score: 0

    Hear that rumbling? That is the sound of millions of people joining a class action if this happens any more

  102. Re:plaintext should be forbidden by NotInHere · · Score: 1

    Modder didn't get the joke did they?

  103. Re: DMCA (Defamation) by LinuxLuver · · Score: 1

    If you encrypt your e-mail prior to sending, sure. But SSL and TLS aren't part of your e-mail. They components of the system for transmitting your email. Not part of the message you wrote.

    --
    Only boring people are ever bored.
  104. Re: DMCA (Defamation) by ale2011 · · Score: 1

    AIUI, they are not tampering the client-to-MSA connection —where the client is often configured to require STARTTLS, port 465, or whatever— but the MSA-to-MX one. There are no guarantees that encription is available between eny two hops along the mail path, and there have never been.

  105. Re: DMCA (Defamation) by ale2011 · · Score: 1

    Sorry, I was wrong. They intercept the client-to-MTA (or MUA-to-MTA) connection, the article says.

    Port 25 is mainly used for relaying (which is what confused me). Malware doing direct-to-MX SMTP does in fact use port 25. Modern clients should be configured to use port 587 instead. Since port 587 (MSA) requires sender authentication, there would be no reason to block/intercept it.