Hacker News Reader

Comment by eksith | Hacker News Reader

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

  "Some firewalls, including Cisco's PIX/ASA firewall do this in order 
  to monitor for spam originating from within their network and prevent it 
  from being sent."

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

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

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

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

View on HN

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.

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.

I'd argue that spammy e-mails are fine as long as you don't send too many of them. That's easy enough to track without breaking encryption. But it also makes it difficult to distinguish the officially "non-spam" yet still awfully spammy marketing automation that makes the ISPs boatloads of money, so I can see their tradeoff.

I find these attacks outrageous and an absolute disdain for the protection of their customers but I wouldn't go as far as justifying spam. To be honest I am less shocked by the fact that the ISP do this than by the fact that it is even possible. Email is broken in so many levels.

It's not the job of the ISP to do that. Full stop.

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

This is the lamest approach to fighting spam.

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

> A better approach is for the ISP to block outgoing port 25 from their network

No thanks! My ISP's job is to provide internet access. Blocking ports violates that.

Would you condone an ISP relaying all port 80 traffic to reduce forum spam?

To keep you from denying internet (i.e, email) access to everyone else, they should block the port by default, then unblock it if you demonstrate that you know what you're doing by calling them up and asking them to unblock it.

Seems harmless enough. Agreed?

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.

https://www.ietf.org/rfc/rfc2476.txt

December 1998

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

It is my ISP's fault for BLOCKING THOSE PORTS.

And, since I don't really have a choice of ISP, I can't change that.

Some of us live in the real world where we wind up having to do things like put mail servers on port 80 or 25 because that port doesn't get blocked.

Thanks for playing.

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?

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

Does that actually change anything? If everyone used 587 for MSAs, then the ISPs would have to block 587 and use their own relay to prevent spam (under GP's solution). I mean, it doesn't change anything, does it?

Using 587/MSA implies[1] authentication which implies that the client is using a server that is responsible for the email sent through it.

[1]: http://en.wikipedia.org/wiki/SMTP_Authentication

You cannot enforce something just because it's 'best practice'. Why should the ISP restrict a user form running HTTP on port 25 and SMTP on port 80?

It is my ISP's fault if my ISP blocks a port and doesn't let me any way to unblock it, whatever I do with my port. My ISP's job is to forward packets, not something else.

A third of the ISP don't even support TLS/SSL on their outgoing traffic. Gmail publishes some interesting stats on that. Having to go through your ISP smtp is nearly as bad as no encryption at all.

Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah.

Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface".

There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.

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.

<rant>

2 boils down to issue 1 and is blocked by issue 3.

Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible.

But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good".

Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed.

And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak.

</rant>

Continuing in your rant: technically, you still expect the server to behave correctly and ask your browser for the encrypted text through a special <textarea>. If the server doesn't want to send the it, it won't.

What I see is going the other way around: have the browser detect a standard <textarea> and provide control to automatically encrypt what you typed. Something ala https://www.mailvelope.com/. No changes in the websites. You can do it today (well, if you have the good plugin/browser).

Now I think the real hard problem is not encryption itself but key distribution. You need to find a way to reliably tell other people "This is my key", but you need some interactive way so that I don't need to wait for you manually sending me your key in order for me to send you something encrypted... I believe XMPP is much better suited for that (there are ways to exchange content between people, even when they are not connected, for instance through services), so maybe Gmail could build something on top of SMTP+XMPP to exchange keys. And that still wouldn't be truly authenticated, only optimistically, because in the end trust is something only users can set.

Sure. The site shouldn't be able to imitate your textarea. First, it should have no access to your keyring and whatever, so it won't be able to crudely imitate the UI. Then, browser should have some sort of indication outside of site's control, that shows whenever you're editing text in a secure area or not.

As for key distribution - if it would work opportunistically, it would be still a great achievement. Like, all emails I send are signed, and recipient MUA can figure out my key ID from those and retrieve it automatically. Then proceed to suggesting encrypting the correspondence. If so, the UI should clearly indicate that communications are encrypted but noticeably warn that identity's not verified. That is, solving one problem at a time, I guess.

Maybe I'm wrong, though.

> All what's necessary is to provide an API and browser plugin

As soon as you say browser plugin, you've failed. Plugins mean deployment headaches, sandbox trust etc etc. It's what Java used to do, it's what Flash used to do, we know it just doesn't work in the long run. Even extensions are troublesome, what with browsers constantly breaking compatibility every other day. There is a reason big brands don't even develop simple extensions these days.

Whatever, this part doesn't really matter. Just something that works within the browser and is completely isolated from any websites except for well-defined, narrow, simple and secure communication channels. However it's implemented - as a plugin or as a module within the browser's codebase or somehow else - this part is mostly irrelevant.

And IIRC, Flash is still a browser plugin. It's just that it's more commonly shipped with browsers. Or maybe I had missed something.

Yeah sorry, I meant that Flash, like Java plugins, is basically dying.

It is, but I believe it's not because of its plugin nature, but for another reasons. It's just that Flash had served its role but got replaced with better solutions and is mostly unnecessary anymore.

I think I'd be very pleased, if, in a same manner as it happened with Flash, Enigmail would become obsolete and GPG support would be provided by Thunderbird itself.

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

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

Reply on news.ycombinator.com