5 ms·

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

by eksith 12y ago

Before the conspiracy theories start, I think this has less to do with mass-surveillance and more to do with stopping spam. As hinted : "Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent." When faced with a large volume, companies usually aim for the quickest fix in lieu of the best. And I couldn't help notice the bigger problem here : "Adoption of PGP has been slow because of its highly technical interface and difficult key management." When non-technical people are involved, the number of technical people who dismiss or downlplay this offhand is getting annoying. In fact, just the other day, the replies to this : https://twitter.com/SwiftOnSecurity/status/530818824036040704 https://twitter.com/SwiftOnSecurity/status/53081882403604070... Surely, there's a simpler way to manage keys and send/receive encrypted email with PGP or something better?

leeoniya 12y ago
you don't need conspiracy theories to put forth that disabling encryption (for whatever reason) enables dragnet/any surveillance by whichever parties have access to the transmission medium. the NSA will be happy to collect your unencrypted data regardless of whether they had any part in disabling the encryption.
revelation 12y ago
No conspiracy theories here, just utterly baffled at the fact that a communications provider would happily tamper with user data that he has zero reason (and technical justification) to access or change. And then to strip STARTTLS? That's the nuclear meltdown scenario of incompetence and recklessness. I guess this is another moment where people can tell us how theres too much regulation governing internet providers, after apparently a vast majority of providers can't even deliver payload unchanged. It must be tedious to keep defending an industry that can't provide the most basic of services.
- rakoo 12y ago
  He just told you there _is_ a reason to do this: stop said ISP's users from sending spam. In the best case scenario, the ISP analyzes each email and drop them when their spamminess is too high. That's a legitimate concern for the ISP. Now _of course_ doing this will be a massive problem for privacy, but again, user's privacy comes after a functioning network for the ISP.
  - couchand 12y ago
    I'd argue that spammy e-mails are fine as long as you don't send too many of them. That's easy enough to track without breaking encryption. But it also makes it difficult to distinguish the officially "non-spam" yet still awfully spammy marketing automation that makes the ISPs boatloads of money, so I can see their tradeoff.
    - cm2187 12y ago
      I find these attacks outrageous and an absolute disdain for the protection of their customers but I wouldn't go as far as justifying spam. To be honest I am less shocked by the fact that the ISP do this than by the fact that it is even possible. Email is broken in so many levels.
  - revelation 12y ago
    It's not the job of the ISP to do that. Full stop.
josho 12y ago
This is the lamest approach to fighting spam. A better approach is for the ISP to block outgoing port 25 from their network, and force their users to use their mail relay that requires authorization. Any accounts that are caught spamming can then simply be terminated as customers. This approach is also quite common.
- bsder 12y ago
  This is the lamest approach to network security. Now I can't reach MY email server which sits in a colo on port 25. So, now I have to put my mail server on port 80 just so I can get out of the network. Some of us don't trust the email servers run by the ISP.
  - brongondwana 12y ago
    https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice.
    - nitrogen 12y ago
      https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice. Could you be so kind as to point to the relevant section of RFC2476?
      - tedunangst 12y ago
        > Port 587 is reserved for email message submission as specified in this document.
    - bsder 12y ago
      It is my ISP's fault for BLOCKING THOSE PORTS. And, since I don't really have a choice of ISP, I can't change that. Some of us live in the real world where we wind up having to do things like put mail servers on port 80 or 25 because that port doesn't get blocked. Thanks for playing.
higherpurpose 12y ago
Why would I want that if I have Gmail? Also I wouldn't trust Cisco's arguments in such situations. Cisco is the one that invented "lawful intercept"/backdoors in routers.
devicenull 12y ago
This is also the default behavior for ASAs, so it's really just not bothering to configure them. Probably because email works, so why screw with it?
drdaeman 12y ago
Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah. Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface". There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.
- toyg 12y ago
  Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config. Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences". That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.
  - drdaeman 12y ago
    <rant> 2 boils down to issue 1 and is blocked by issue 3. Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible. But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good". Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed. And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak. </rant>

by eksith 12y ago

leeoniya 12y ago

you don't need conspiracy theories to put forth that disabling encryption (for whatever reason) enables dragnet/any surveillance by whichever parties have access to the transmission medium. the NSA will be happy to collect your unencrypted data regardless of whether they had any part in disabling the encryption.

revelation 12y ago

No conspiracy theories here, just utterly baffled at the fact that a communications provider would happily tamper with user data that he has zero reason (and technical justification) to access or change. And then to strip STARTTLS? That's the nuclear meltdown scenario of incompetence and recklessness. I guess this is another moment where people can tell us how theres too much regulation governing internet providers, after apparently a vast majority of providers can't even deliver payload unchanged. It must be tedious to keep defending an industry that can't provide the most basic of services.

rakoo 12y ago
He just told you there _is_ a reason to do this: stop said ISP's users from sending spam. In the best case scenario, the ISP analyzes each email and drop them when their spamminess is too high. That's a legitimate concern for the ISP. Now _of course_ doing this will be a massive problem for privacy, but again, user's privacy comes after a functioning network for the ISP.
- couchand 12y ago
  I'd argue that spammy e-mails are fine as long as you don't send too many of them. That's easy enough to track without breaking encryption. But it also makes it difficult to distinguish the officially "non-spam" yet still awfully spammy marketing automation that makes the ISPs boatloads of money, so I can see their tradeoff.
  - cm2187 12y ago
    I find these attacks outrageous and an absolute disdain for the protection of their customers but I wouldn't go as far as justifying spam. To be honest I am less shocked by the fact that the ISP do this than by the fact that it is even possible. Email is broken in so many levels.
- revelation 12y ago
  It's not the job of the ISP to do that. Full stop.

josho 12y ago

This is the lamest approach to fighting spam. A better approach is for the ISP to block outgoing port 25 from their network, and force their users to use their mail relay that requires authorization. Any accounts that are caught spamming can then simply be terminated as customers. This approach is also quite common.

bsder 12y ago
This is the lamest approach to network security. Now I can't reach MY email server which sits in a colo on port 25. So, now I have to put my mail server on port 80 just so I can get out of the network. Some of us don't trust the email servers run by the ISP.
- brongondwana 12y ago
  https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice.
  - nitrogen 12y ago
    https://www.ietf.org/rfc/rfc2476.txt https://www.ietf.org/rfc/rfc2476.txt December 1998 It's hardly your ISP's fault that you are 16 years behind best practice. Could you be so kind as to point to the relevant section of RFC2476?
    - tedunangst 12y ago
      > Port 587 is reserved for email message submission as specified in this document.
  - bsder 12y ago
    It is my ISP's fault for BLOCKING THOSE PORTS. And, since I don't really have a choice of ISP, I can't change that. Some of us live in the real world where we wind up having to do things like put mail servers on port 80 or 25 because that port doesn't get blocked. Thanks for playing.

higherpurpose 12y ago

Why would I want that if I have Gmail? Also I wouldn't trust Cisco's arguments in such situations. Cisco is the one that invented "lawful intercept"/backdoors in routers.

devicenull 12y ago

This is also the default behavior for ASAs, so it's really just not bothering to configure them. Probably because email works, so why screw with it?

drdaeman 12y ago

Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah. Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface". There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.

toyg 12y ago
Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config. Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences". That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.
- drdaeman 12y ago
  <rant> 2 boils down to issue 1 and is blocked by issue 3. Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible. But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good". Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed. And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak. </rant>