Re: Email tapping by ISPs, forwarder addresses, and crypto proxies
Thomas Shaddack writes:
Reading some news about the email wiretapping by ISPs, and getting an idea.
There are various email forwarding services, which are nothing more than a SMTP server with pairs of recipient@forwarder.com -- recipient@hiscurrentisp.com.
Right, mostly for use as disposable email addresses. I've used spamgourmet to good effect, myself.
Messages in storage have much lower judicial protection than messages in transit. (This does not have much technical merit, in the current atmosphere of "damn the laws - there are terrorists around the corner", but can be seen as a nice little potential benefit.)
One thing I haven't understood in all the commentary is whether law enforcment still needs a warrant to access emails stored in this way. Apparently the ISP can read them without any notice or liability, but what about the police? Also, what if you run your own mail spool, so the email is never stored at the ISP, it just passes through the routers controlled by the ISP (just like it passed through a dozen other routers on the internet). Does this give the ISP (and all the other router owners) the right to read your email? I don't think so, it seems like that would definitely cross over the line from "mail in storage" to "mail in transit".
There can be an easy enhancement for such forwarder service; GnuPG proxy. Every email that arrives to the forwarder address, before it is forwarded to the real recipient, is piped through a GnuPG script; the recipient has then to upload his public key during the registration of the target address, otherwise the function is the same.
That's a great idea. You'd want to be sure and encrypt the whole message including headers, and make the whole thing an encrypted attachment. Has the added side benefits of compressing the email, and you could even have the server do some spam filtering.
For added benefit, the forwarder should support SMTP/TLS (STARTTLS) extension, so the connections from security-minded owners of their own mailservers would be protected.
STARTTLS support at the proxy should pretty much go without saying these days, so you might as well do it, but if you're already PGP encrypting then it's not adding that much security. Well, maybe it does, but you're talking about a different threat. For the problem that ISPs can read your email in storage, STARTLS doesn't help much because it will only protect the email until it gets to your local ISP, who will store your email for you and can read it then (which is where the PGP comes in). Where STARTTLS would help is with power users who run their own mail servers. But those people don't suffer from the problem we are talking about here, legal access to the email by the ISP (I think, see above). Nevertheless a mail-receiving proxy that uses STARTTLS connections to power users would be kind of cool because it would keep anyone local from knowing anything about the incoming mail. Hopefully, STARTTLS will eventually become so widespread that this functionality will be redundant, but we are not there yet.
The recipient himself then can either run his own mailserver and download mails through fetchmail, or receive mails using SMTP/ETRN (both methods allow automated decryption of such wrapped mail during its receiving), or use a POP/IMAP decryption proxy, or have a plugin in mail client.
(I know, auto-decryption is dangerous, but we now talk about the system for one's grandma, transparent to use.)
Absolutely, look at the threat model. You're not worried about someone breaking into your computer, you're worried about your ISP legally reading your email. To address this threat, auto-decryption is a perfect solution. Recently there was a proposal for a nym receiving service, http://www.freehaven.net/doc/pynchon-gate/, by Bran Cohen and Len Sassaman. They have a complicated protocol for downloading email anonymously. To hide the complexity, they propose to set up a POP compatible mail server agent on the user's computer running as a daemon process (Windows service). He would configure his mailer to connect to localhost:4949 or whatever, just like any other POP server. The service would periodically go out and poll for email using the fancy protocol, but then it would make it available to the local mail agent in perfectly vanilla form. The point is that this architecture hides the complexity and makes it transparent for end users to use arbitrarily complex crypto for mail receiving. Something similar would be perfect for your idea.
The only vulnerable parts of the mail route then will be the sender's computer, the pathway between the sender and the forwarder server (if SMTP/TLS is not used correctly or at all), the forwarder server (if compromised), and the recipient's computer. The way between the forwarder and the recipient's ISP, including the recipient's mailbox, is secured.
What do you think about this scheme?
I think it's a great idea. Of course as you say there is still the problem that the forwarding server could read your email, so you have only moved the threat from the ISP to another operator. The difference I suppose is that the forwarder would be selling privacy services, hence different ones would compete to get a good reputation. Any cheating might be detected by insider whistle blowers or perhaps some kind of audit. Hal Finney
On Tue, 6 Jul 2004, Hal Finney wrote:
There are various email forwarding services, which are nothing more than a SMTP server with pairs of recipient@forwarder.com -- recipient@hiscurrentisp.com.
Right, mostly for use as disposable email addresses. I've used spamgourmet to good effect, myself.
I wrote the patch for qmail's fastforward for similar purposes. Everything in the name that is beyond the specified wildcard is ignored when resolving the mail alias (but stays there for procmail processing). As added benefit, the addresses that receive spam can be used for teaching bogofilter.
Messages in storage have much lower judicial protection than messages in transit. (This does not have much technical merit, in the current atmosphere of "damn the laws - there are terrorists around the corner", but can be seen as a nice little potential benefit.)
One thing I haven't understood in all the commentary is whether law enforcment still needs a warrant to access emails stored in this way. Apparently the ISP can read them without any notice or liability, but what about the police?
Let's expect them so as well. The ISP can hand them over to the police anyway, like a nosy neighbour fink finding your grass stash.
Also, what if you run your own mail spool, so the email is never stored at the ISP, it just passes through the routers controlled by the ISP (just like it passed through a dozen other routers on the internet). Does this give the ISP (and all the other router owners) the right to read your email? I don't think so, it seems like that would definitely cross over the line from "mail in storage" to "mail in transit".
If it passes through their SMTP servers, I am not sure. If it goes only through their routers, I'd think it's definitely in transit.
There can be an easy enhancement for such forwarder service; GnuPG proxy. Every email that arrives to the forwarder address, before it is forwarded to the real recipient, is piped through a GnuPG script; the recipient has then to upload his public key during the registration of the target address, otherwise the function is the same.
That's a great idea. You'd want to be sure and encrypt the whole message including headers, and make the whole thing an encrypted attachment. Has the added side benefits of compressing the email, and you could even have the server do some spam filtering.
The original idea I based it on was encrypting everything including the headers on the sender, then decrypting it on the receiver relay, and adding the data about the decryption of the message into the headers in some unspoofable way (eg. if the headers were there already when the message arrived to the decrypting script, prepend X- to them - not really bulletproof but rather decent).
For added benefit, the forwarder should support SMTP/TLS (STARTTLS) extension, so the connections from security-minded owners of their own mailservers would be protected.
STARTTLS support at the proxy should pretty much go without saying these days, so you might as well do it, but if you're already PGP encrypting then it's not adding that much security. Well, maybe it does, but you're talking about a different threat.
It hides the fact encrypted comm is in use. Which may be handy on its own.
For the problem that ISPs can read your email in storage, STARTLS doesn't help much because it will only protect the email until it gets to your local ISP, who will store your email for you and can read it then (which is where the PGP comes in).
That's true. But it protects the data in transit nearly for free.
Where STARTTLS would help is with power users who run their own mail servers. But those people don't suffer from the problem we are talking about here, legal access to the email by the ISP (I think, see above). Nevertheless a mail-receiving proxy that uses STARTTLS connections to power users would be kind of cool because it would keep anyone local from knowing anything about the incoming mail. Hopefully, STARTTLS will eventually become so widespread that this functionality will be redundant, but we are not there yet.
STARTTLS is by far not widespread. Few people use it, including the knowledgeable ones. :(((
(I know, auto-decryption is dangerous, but we now talk about the system for one's grandma, transparent to use.)
Absolutely, look at the threat model. You're not worried about someone breaking into your computer, you're worried about your ISP legally reading your email. To address this threat, auto-decryption is a perfect solution.
It's always better to select overly restrictive threat model and then loose it when necessary, than the other way. An omission then results in more work instead of a security hole.
He would configure his mailer to connect to localhost:4949 or whatever, just like any other POP server.
With a local SMTP server, you can run such service as a daemon (or from cron) with function similar to fetchmail. Whatever is downloaded is fed to local mail delivery.
The service would periodically go out and poll for email using the fancy protocol, but then it would make it available to the local mail agent in perfectly vanilla form. The point is that this architecture hides the complexity and makes it transparent for end users to use arbitrarily complex crypto for mail receiving. Something similar would be perfect for your idea.
Proxies rock :) I designed the idea with procmail and sendmail/qmail in mind. Didn't think much about Windows, as it's a pain to develop for them, but it shouldn't be too difficult to port it.
What do you think about this scheme?
I think it's a great idea. Of course as you say there is still the problem that the forwarding server could read your email, so you have only moved the threat from the ISP to another operator.
That's very true, however there can be operators you trust more than your ISP, eg. a group of friends running such forwarder offshore. Especially if your ISP is untrustful or restrictive, eg. an university, a bigger corporation, or anything with a potential for nosing or censoring.
The difference I suppose is that the forwarder would be selling privacy services, hence different ones would compete to get a good reputation. Any cheating might be detected by insider whistle blowers or perhaps some kind of audit.
I didn't think about it as a sellable thing, though it's definitely possible. Instead of several paid services I thought more along the lines of thousands little servers for a handful of people each. But it's pretty likely to be marketable. The key here is low resource requirements and low cost of operation - which a combo of a small SMTP server and procmail could meet pretty well.
At 02:47 PM 7/6/2004, Hal Finney wrote:
Thomas Shaddack writes:
There are various email forwarding services, which are nothing more than a SMTP server with pairs of recipient@forwarder.com -- recipient@hiscurrentisp.com.
Right, mostly for use as disposable email addresses. I've used spamgourmet to good effect, myself.
They're also marketed as permanent addresses you can keep when you change ISPs, for example pobox.com was one of the first ones. Unfortunately, as far as I know, none of the forwarders let you forward mail from recipient+tag@forwarder.com to recipient+tag@currentISP.com, which means that they don't support tag-based spam protection. When I want disposable addresses, I either use free providers, or I use tagged addresses at free / cheap providers like fastmail.fm.
One thing I haven't understood in all the commentary is whether law enforcment still needs a warrant to access emails stored in this way. Apparently the ISP can read them without any notice or liability, but what about the police?
Councilman currently only affects the First Circuit (the Northeast), and it was only the three-judge-panel version of the Appeals Court, so he could appeal it to the full court before going to the Supremes. My reading of the opinions is that the two majority judges totally failed to grasp the technology, while the dissenting judge got it, so even if the opinion stands, it's very narrow in scope - but it's a strong reminder that the current laws don't protect stored email very well, and that if judges aren't technical enough to understand it when it's laid out in front of their faces, they're certainly not going to be sufficiently uncooperative when police try to get warrants or subpoenas (or at least it probably won't be hard for police to find a cooperative judge.) Also, in the Steve Jackson Games case, the courts and Feds got away with declaring that the ECPA didn't apply to mail that had arrived in mailboxes, only to mail that was in transit. It's not clear that ISPs in general can read mail without any notice or liability - just that the obvious readings of the law that Councilman sued them under don't currently work in the 1st Circuit. He might have tried various business-related torts successfully, but the wiretapping laws looked like a slam-dunk. But that doesn't usually work against police, just businesses. Police reading mail like this really is a different case - they either need some kind of court papers to hand the ISP (though these days the Patriot Act seems to be used to justify almost anything and place a gag order on the activity, and a subpoena is easier to get than a warrant), or they need some bogus justification that the ISP has to obey "administrative requests" that aren't court-issued, or they need to wiretap the bits legally.
Also, what if you run your own mail spool, so the email is never stored at the ISP, it just passes through the routers controlled by the ISP (just like it passed through a dozen other routers on the internet). Does this give the ISP (and all the other router owners) the right to read your email? I don't think so, it seems like that would definitely cross over the line from "mail in storage" to "mail in transit".
One scary thing about Councilman was that it happened in a case where the government was vaguely neutral and responsible for protecting the citizen's privacy - when the prosecutors are _trying_ to get outrageously twisted anti-privacy rulings they're more likely to win. In particular, does a message count as "in transit" if you're only hauling IP packets around with parts of the message rather than the whole message, or does each part count as "in storage" when it's gotten to a router that has to queue it before forwarding it on to the next hop? Or if the whole message is queued in your ISP's sendmail queue because you've got an MX there? What about _outgoing_ mail queued at your ISP, who's being a good anti-spammer and forcing you to use their mail transfer agent instead of sending directly to the destination?
There can be an easy enhancement for such forwarder service; GnuPG proxy.
There are several different threat models to think about - - Greedy ISP reading your mail for their own purposes - ISP responding to court-ordered wiretapping - ISP collaborating enthusiastically with police - Police wiretapping without court orders - All of the above, but for stored mailboxes, not in-transit - All of the above, but for traffic analysis / headers, not content Mail-handling services don't prevent any of the in-transit threats, but they can eliminate most of the threats to stored mailboxes, and they do let you move your vulnerability to a different jurisdiction, which can potentially reduce the likelihood that they'll wiretap you there. For instance, if you're using your local cable modem company for mailbox services, and you annoy your local police, they may try to tap you, but police in Anguilla will probably only try to tap you if you've gotten the US Feds or MI5/MI6 annoyed. Police in Sealand might not respond to wiretaps at all, but any unencrypted mail going there would have been watched closely. Spooks in the UK proper might wiretap you as a favor to the US spooks, and data privacy laws might or might not apply if you're a non-subject. Google's Gmail is an interesting case. Unlike Councilman's ISP, who were sneaky greedy wiretapping bums, Google tells you that they'll grep your mail for advertising material, and tells you how much of that they'll leak to the advertisers and makes you some promises not to leak more. The data's just sitting there waiting for a subpoena, and there's not much point in having it all encrypted because the cool features of Gmail aren't much use on cyphertext.
For added benefit, the forwarder should support SMTP/TLS (STARTTLS) extension, so the connections from security-minded owners of their own mailservers would be protected.
STARTTLS support at the proxy should pretty much go without saying these days, so you might as well do it, but if you're already PGP encrypting then it's not adding that much security. Well, maybe it does, but you're talking about a different threat.
STARTTLS is helpful because it can protect mail from the sender's ISP. Almost by definition, that's unencrypted mail, because otherwise you wouldn't be so worried about it getting tapped.
I think it's a great idea. Of course as you say there is still the problem that the forwarding server could read your email, so you have only moved the threat from the ISP to another operator. The difference I suppose is that the forwarder would be selling privacy services, hence different ones would compete to get a good reputation. Any cheating might be detected by insider whistle blowers or perhaps some kind of audit.
It might. Unless of course the service is really run by narcs. ---- Bill Stewart bill.stewart@pobox.com
On Wed, Jul 07, 2004 at 01:11:58AM -0700, Bill Stewart wrote:
Google's Gmail is an interesting case. Unlike Councilman's ISP, who were sneaky greedy wiretapping bums, Google tells you that they'll grep your mail for advertising material, and tells you how much of that they'll leak to the advertisers and makes you some promises not to leak more. The data's just sitting there waiting for a subpoena, and there's not much point in having it all encrypted because the cool features of Gmail aren't much use on cyphertext.
FYI here's something I wrote in April... --Declan http://news.com.com/Is+Google+the+future+of+e-mail%3F/2010-1032_3-5187543.ht... If Google wanted to veer in a more privacy-protective direction, it could look to the intriguing model of Vancouver, Canada-based Hush Communications, which runs the Hushmail Web mail system. Unlike rivals, Hush encrypts mail sent between Hush users. It uses a Java-based technique that allows for only its intended recipient--and not Hush employees--to decrypt a scrambled e-mail message. If a subpoena arrives, or if a security breach ever happens, disclosure would be limited. Hush offers 2-megabyte-limit free accounts and pay accounts, and it said 900,000 accounts have been created since its May 1999 launch. The company also lets users store files in an encrypted volume and this week plans to announce a feature that permits encrypted volumes to be shared among multiple users. Hush's patent No. 6,154,543 covers some aspects of encrypted e-mail. The company said it'd happy to license it to Google. Originally, Hush Chief Technology Officer Brian Smith said, the patent was quite broad, but "we have narrowed the patent to apply only to e-mail and messaging systems. The modifications were accepted but don't yet appear" on the U.S. Patent and Trademark Office's Web site. True, if the archived e-mail is encrypted, Gmail won't be able to search message bodies very efficiently, but users might be willing to give up that feature and even pay a monthly charge in exchange for additional security. "We'll think about it," said Google's Rosing. "We don't have any explicit plans right now...If someone really needs to encrypt a lot of e-mail, maybe they should be putting that on their laptop. We're trying to provide a service that offers some utility to our users. If you change the service to take away all the value of the service, you're back where you started." Maybe. But until that happens, would-be users of Gmail or any similar service should recognize that their so-called free e-mail comes at a price.
This is somewhat related to what ZKS did in their version 1 [1,2] mail system. They made a transparent local pop proxy (transparent in that it happened at firewall level, did not have to change your mail client config). In this case they would talk to your real pop server, decrypt the parts (they were reply-block like onions), remove duplicates (as with mixmaster etc you can send duplicates via separate remailers to improve reliability). So the transparent proxy would leave alone your normal mail that you received in the pop box and remove duplicates only from the reply-block delivered pseudonymous mail. Actually they implemented the reply-block from scratch, it always seemed to me it would have been less development work to use mixmaster (it was implemented before I started). The ZKS reply block did not even use chunking (ala mixmaster) so traffic analysis would have been trivial as the message size would show through. At least that's what I recall, no chunking. However I am finding the security issues paper [1] says otherwise. The 1.0 architecture document [2] is ambiguous, there is no mention of chunking. (I've sent mail to one of the original developers to check I have it right). It was also unreliable because it did not use SMTP, it used its own transport AMTP and its own retry-semantics on nodes called MAIPs. (Mail AIPs, an AIP is an "Anonymous Internet Proxy"). Then we implemented a replacement version 2 mail system that I designed. The design is much simpler. With freedom anonymous networking you had anyway a anonymous interactive TCP feature. So we just ran a standard pop box for your nym. Mail would be delivered to it directly (no reply block) for internet senders. Freedom senders would send via anonymous IP again to get sender anonymity. Used qmail as the mail system. Unfortunately they closed down the freedom network pretty soon after psuedonymous mail 2.0 [3] was implemented. There is an interesting trade-off here. The interactive communications are perhaps more vulnerable to real-time powerful adversary traffic analysis than mixmaster style mixed chunked delivery. However they are less vunerable to subpoena because they are forward-secret on a relativey short time-frame. (1/2 hr if I recall; however more recent designs such as chainsaw internal prototype, and cebolla [4] by ex-ZKSer Zach Brown change keys down to second level by using a mix of backward-security based on symmetric key hashing (and deleting previous key) and forward security using DH.) It would be nice to get both types of anonymity, but I suspect for most typical users the discovery / subpeona route is the major danger, and if that is thwarted it is unlikely that their activities would warrant the effort of real time analysis. Well we have carnivore now, so they could potentially do real-time traffic analysis more routinely if they were to distribute enough collaborating analysis carnivore plugins. Adam [1] http://www.homeport.org/~adam/zeroknowledgewhitepapers/security-issues.pdf [2] http://www.homeport.org/~adam/zeroknowledgewhitepapers/arch-notech.pdf [3] http://www.cypherspace.org/adam/pubs/freedom2-mail.pdf [4] http://www.cypherspace.org/cebolla/ On Tue, Jul 06, 2004 at 02:47:43PM -0700, "Hal Finney" wrote:
Recently there was a proposal for a nym receiving service, http://www.freehaven.net/doc/pynchon-gate/, by Bran Cohen and Len Sassaman. They have a complicated protocol for downloading email anonymously. To hide the complexity, they propose to set up a POP compatible mail server agent on the user's computer running as a daemon process (Windows service). He would configure his mailer to connect to localhost:4949 or whatever, just like any other POP server. The service would periodically go out and poll for email using the fancy protocol, but then it would make it available to the local mail agent in perfectly vanilla form. The point is that this architecture hides the complexity and makes it transparent for end users to use arbitrarily complex crypto for mail receiving. Something similar would be perfect for your idea.
At 01:09 PM 7/7/2004, Adam Back wrote:
Then we implemented a replacement version 2 mail system that I designed. The design is much simpler. With freedom anonymous networking you had anyway a anonymous interactive TCP feature. So we just ran a standard pop box for your nym. Mail would be delivered to it directly (no reply block) for internet senders. Freedom senders would send via anonymous IP again to get sender anonymity. Used qmail as the mail system.
Unfortunately they closed down the freedom network pretty soon after psuedonymous mail 2.0 [3] was implemented.
I wonder if the mail 2.0 code could be publicly released so it could be used with the forthcoming i2p IP overlay http://www.i2p.net/ ? steve
You could try sending an email to Austin Hill
I wonder if the mail 2.0 code could be publicly released so it could be used with the forthcoming i2p IP overlay http://www.i2p.net/ ?
steve
At 01:09 PM 7/7/2004, Adam Back wrote:
Then we implemented a replacement version 2 mail system that I designed. The design is much simpler. With freedom anonymous networking you had anyway a anonymous interactive TCP feature. So we just ran a standard pop box for your nym. Mail would be delivered to it directly (no reply block) for internet senders. Freedom senders would send via anonymous IP again to get sender anonymity. Used qmail as the mail system.
Unfortunately they closed down the freedom network pretty soon after psuedonymous mail 2.0 [3] was implemented.
participants (6)
-
Adam Back -
Bill Stewart -
Declan McCullagh -
hal＠finney.org -
Steve Schear -
Thomas Shaddack