Closed malexmave closed 10 years ago
malexmave
commented
10 years ago The devs just announced Tor integration as an upcoming feature on Twitter. I'll close the issue since there seems to be no interest in a discussion about what should and should not be possible via Tor, but if it is ever needed, feel free to reopen it.
BjarniRunar
commented
10 years ago I think there is definitely interest in discussing, we're just overwhealmed with things to look at and it's a weekend. Reopening, this is a very exciting topic. :-)
ghost
commented
10 years ago Maybe someone could give an overview of what can actually be done with Tor regarding e-mails. As far as I understand Tor (and I'm not an expert on this), it mostly obfuscates the journey (and destination) that a package makes through the interwebs.
So if I send an e-mail via a non-encrypted connection the benefit would be virtually zero because anyone could intercept the e-mail, extracting recipients (and other metadata) and contents (unless it was encrypted). However if the e-mail travels via an encrypted connection (e.g. SSL) the attacker would have to follow the e-mail to its destination in order to attempt another attack (perhaps it has the private key of the receiving party). In this case the Tor layer would increase the required effort for a successful attack.
Is this assessment correct or have I misunderstood the way Tor, encryption and/or e-mail works?
lottspot
commented
10 years ago since its not possible to encrypt headers, I'm not seeing Any security benefit from sending out mail on the tor network. unless I'm completely overlooking something, the email is always going to show every single MTA it passed through on its journey to someone's inbox. so at that point your email is being delivered more slowly with not one iota of additional anonymity.
malexmave
commented
10 years ago Yes, but if the Attacker is a MITM (like, for example, your ISP), you can obfuscate the fact that you sent a mail. In general, it is impossible to hide the fact that you sent a mail from your MTA, as it is kind of impossible to send mail without using it. But you can make it harder for govs, ISPs and attackers inside your network to find out if and what mails you sent.
Edit: I do however agree that a list should be made, I just don't have the time to do it right now. Tying in with #122, this would be a great use case for the Wiki.
lottspot
commented
10 years ago since your ISP is the next hop for every packet that leaves your router, and you'll be traversing 2 or 3 hops of the ISP no matter what, I don't even see this as a good obfuscation tool. you will never be able to protect yourself against your ISP being the 'man in the middle', because the only way to have internet connectivity is to pay them to be exactly that. and my point about it being impossible to encrypt the email headers is still not mitigated, as it points out that this is a 0 benefit attempt at obfuscation. The headers will still show every hop along the 'real' path that the email took, and there is no way to prevent an ISP from intercepting that information if they want to. It would make more sense to keep development efforts focused on real security measures, such as establishing an encryption infrastructure that can make encrypting message contents achievable for anyone.
malexmave
commented
10 years ago Please to not see this as an attack on you personally, but there are a few things wrong with your argument, and I'll try to point them out.
you will never be able to protect yourself against your ISP being the 'man in the middle', because the only way to have internet connectivity is them to be exactly that
True, but you can reduce the information a malicious ISP / MITM in general gets by encrypting your connection...
and my point about it being impossible to encrypt the email headers is still not mitigated, as it points out that this is a 0 benefit attempt at obfuscation
...and Tor encrypts all traffic within the network. As Mailpile would be the first node in the chain, all traffic leaving your home network will already be within the Tor network and as such encrypted.
Net benefit of using Tor: Your ISP does not know you are communicating at all (as opposed to seeing you comminicate when using SSL or even seeing the metadata when not using SSL). The ISP of your exit node will (possibly) be able to see the metadata, but will not be able to correlate that data to your IP address as your ISP would. Combined with stripping some sensitive information from the mail headers, you are successfully masking your location that way. This is the way Torbirdy works.
It would make more sense to keep development efforts focused on real security measures, such as establishing an encryption infrastructure that can make encrypting message contents achievable for anyone.
These things are not mutually exclusive. There are many good places to use Tor (Updating your keyring, for example), so Tor should be integrated either way. It is comparatively trivial to also allow sending mails via Tor without taking too much time away from the "core" development goals of making encryption easy to use.
lottspot
commented
10 years ago Please to not see this as an attack on you personally, but there are a few things wrong with your argument, and I'll try to point them out.
No personal offense taken, I see value in a good discussion
As Mailpile would be the first node in the chain
That is definitely the piece that I wasn't putting together properly. This is making sense now, and I understand how you would see this feature being implemented.
Combined with stripping some sensitive information from the mail headers, you are successfully masking your location that way.
I would think it particularly important to keep the headers in tact if email was going to pass through a network like tor. Headers can provide very valuable information to administrators, and I suspect some of the information you are referring to as sensitive may be some of the most useful information for troubleshooting mailflow issues. The headers will already look a bit mangled after the 'nexthop' mta receives them off of the tor network.
These things are not mutually exclusive. There are many good places to use Tor (Updating your keyring, for example), so Tor should be integrated either way. It is comparatively trivial to also allow sending mails via Tor without taking too much time away from the "core" development goals of making encryption easy to use.
In my mind, it's not a question of mutual exclusivity, but more one of opportunity cost. Time spent developing one function necessarily means there is time not spent developing another. While I do now understand why this has been proposed, this still appears to be more of an obscurity measure than a security measure. Particularly since email as a protocol does not really lend itself to anonymity. You yourself touch on this when you mentioned
Your ISP does not know you are communicating at all (as opposed to seeing you comminicate when using SSL or even seeing the metadata when not using SSL). The ISP of your exit node will (possibly) be able to see the metadata, but will not be able to correlate that data to your IP address as your ISP would.
There isn't a very good security argument to be made for the benefit of a random, arbitrary ISP having access to the email message metadata over your isp. The fact that they won't know the IP address of the originating SMTP server is rather off-set by the fact that there is an MX record which will lead directly back to where your email can be received at. While it is of course possible, and indeed in many cases likely, that these two servers are not the same, that matters rather little, as the overalll idea is that they have access to you. This goes back to email not being a protocol which lends itself to anonymity.
Furthermore, there is a whole other issue which we haven't even touched on, that being the impact that sending email through the tor network would have on spam flagging of your email. Firstly, this makes it impossible to implement a reliable SPF record. While obviously DKIM could still be implemented, not having an SPF record is not an option for most legitimate email senders, and is on its own enough to have your mail rejected by certain providers. Secondly, since email will show as originating from any one of a number of random nodes, you have no way of knowing what the reputation of that node is like with RBLs, whether the exit node is in a residential IP range (enough to get you spam flagged by most major providers), etc. In the world of email, sender reputation relies on having a consistent, easily traceable, vouched for IP address.
It really makes a lot more sense to focus discussion on email security around strategies for securing message content rather than trying to implement anonymity measures in a protocol which anonymity was not really meant to exist.
malexmave
commented
10 years ago I would think it particularly important to keep the headers in tact if email was going to pass through a network like tor. Headers can provide very valuable information to administrators, and I suspect some of the information you are referring to as sensitive may be some of the most useful information for troubleshooting mailflow issues.
Well, yes. But then again, if you are an activist in [insert country with orpressive regime], you may not want your Mail headers to contain your IP if you go to all the trouble of sending it through the Tor network. And if you are being hunted by one gov or another, you may not even want your Timezone to be in your mail headers, because that may give away in which area of the globe you are. It's all a case of threat modelling. I think having the options to strip these headers out when using Tor would be a good thing, as you may agree that having a harder time troubleshooting issues may be worth it in this kind of tradeoff.
There isn't a very good security argument to be made for the benefit of a random, arbitrary ISP having access to the email message metadata over your isp.
Well, this is pretty much how Tor works. You don't want your ISP / Gov / ... to know what sites you visit, so you let another one (that is hopefully trustworthy) know about it. But I see where you are coming from, as eMail headers will instantly de-anonymize you no matter what. But then again, you probably have a SSL connection to your mail server, so the hops between the exit and your MTA should be unable to read your metadata anyway (under the assumption that no one has cracked open another CA). Yes, in that case, your own ISP would not be able to read the metadata, but there are some people who want to hide everything they do for some reason or another, and it would be nice to have the option for them to do just that using Mailpile.
Furthermore, there is a whole other issue which we haven't even touched on, that being the impact that sending email through the tor network would have on spam flagging of your email. [...]
I think we currently have different architectures in mind. In my model, I was still working with the assumption that your mail server is sitting in some data center while you are at home. In that case, spam flags would not be a problem, as the mail is getting delivered to be sent from your Mail server, which does not perform SPF / DKIM-Checks before sending your mail on, as far as I know (I may be wrong here, I don't have a deep knowledge of the inner workings of eMail). I think you are already working with the final Version of Mailpile that should, at some point, possibly contain its own eMail server. I agree that in that case, there may be a bunch of problems with DKIM / Spam flags, and that your MX record will de-anonymize your IP.
In my mind, it's not a question of mutual exclusivity, but more one of opportunity cost.
I think, in this case opportunity cost is pretty low. It all comes down to "being able to send mail via a proxy", which we need anyway. Tor brings its own proxy, so the opportunity cost is basically "implement a checkbox that will set the proxy for all network actions to the local Tor node". And if we want Tor anyway (because of the aforementioned public key refresh, for example), this cost amounts to 30 minutes including testing, which is probably fine.
Stripping eMail headers is another issue, but if the data structure for eMails in Mailpile is decently built (which I'll just assume), it should amount to scrambling / removing a few fields from a dictionary / list. That's another 30 minutes.
Once Mailpile adds its own Mail server, then things get complicated. But I think for now, it should be comparatively trivial to add this functionality if you were adding Tor either way.
BjarniRunar
commented
10 years ago Hey guys! Sorry for chipping in so late, but here are the ideas us Mailpile devs have about Tor integration at the moment.
Executive summary: Tor can solve some important security problems for us, enable secure p2p communication built on standard protocols and pave the way for remote access to the Mailpile UI. The main downsides to integrating with it have to do with the fact that it is a rather massive external dependency, the fact that it may complicate the UI, and the fact that it Tor is considered a suspicious source of spam and other questionable traffic by many mail providers.
Most people use Tor as a way to anonymously connect to the Internet and surf the web without being spied upon by their ISP and without service providers knowing where they are coming from. This is what has mostly been discussed in previous comments, using anonymous routing to download or deliver e-mail.
In practice I fear it will probably become impossible to deliver e-mail this way due to existing anti-spam policies which reject or discard mail coming from the Tor network. We'll need to try it, but I am not optimistic.
Downloading mail using SSL encrypted IMAP or POP3 over Tor may have value and is trivial to support. The downside is this adds a lot of complexity and new failure modes, so we will need to do some tests and cost/benefit analysis to figure out whether this is worth doing or not.
Tor supports something called "hidden services", which are basically standard network services which are only visible within the Tor network (using addresses ending in .onion). Since connections to Tor hidden services never leaves the Tor network, such services have very strong anonymity and security benefits for data in transit.
Neither your ISP, nor the NSA, nor malicious exit-node operators can monitor this traffic. Also, since Tor takes care of the routing, hidden services can run on devices which would otherwise be inaccessible from the wider Internet due to firewalls and IP address shortages.
It could be very useful for MailPile to take advantage of this feature in a few ways:
Features 1. and 2. would close the loop on fixing SMTP insecurity, as delivery would be completely peer-to-peer (no 3rd party storage) and prevent metadata analysis by protecting the headers and SMTP envelope in transit. We don't need to invent any new protocols to do this, just interact with normal SMTP servers on .onion addresses. This very cool!
These features would have implications for the user interface, as Mailpile will need to understand and show the user that addresses ending in .onion are more secure than other addresses, but are not usable to people who are not connected to Tor (unless we get all the ISP mail relays in the world onto Tor, which would be kinda neat but not likely to happen overnight). These are the same usability issues as we will encounter supporting other non-SMTP transports for delivering mail.
Feature 3. provides a way for users to safely access their Mailpile UI from afar without needing a static IP or reconfiguring their router. The downsides are a) the URL is ugly and impossible to remember, hard to type and b) they need to connect to the Tor network first so this is not fully backwards compatible with the "normal Internet". For non-technical users, this is currently the best known alternative to PageKite connections to make Mailpile's web server globally accessible.
malexmave
commented
10 years ago Great to see that you have been thinking about this.
The massive dependency plus the need to get it platform independent is a huge PITA, that's for sure.
In practice I fear it will probably become impossible to deliver e-mail this way due to existing anti-spam policies which reject or discard mail coming from the Tor network.
This will only become relevant once you implement the full mail server into Mailpile, right? (I'm not suggesting to implement something that will have to be ripped out a year later, I'm just curious on how harsh the anti-spam-policy situation has become).
Also, you will get problems with those either way, as most big providers have home internet IPs blacklistet to block all the bots on the thousands of infected home PCs from sending in spam.
they need to connect to the Tor network first so this is not fully backwards compatible with the "normal Internet"
Well, there is still Tor2Web, if you want to trust it...
lottspot
commented
10 years ago This will only become relevant once you implement the full mail server into Mailpile, right?
Unfortunately not the case. Which piece of software is responsible for sending mail is irrelevant in the spam flagging process. Which IP address the mail came from, on the other hand, is hugely relevant. And if the email appears to have originated from an exit node, and tor exit nodes are listed as spamming IP addresses (which I did not realize that they were until Bjarni mentioned it), then this is an insurmountable problem for external email delivery through the tor network.
- Sending mail directly to an address on a Tor hidden service SMTP server: bob@12345.onion
- Provide a built-in SMTP server with a Tor address, so receive as: alice@56789.onion
- Provide access to the built-in web-mail as a Tor hidden service: http://abcdefg.onion/
This is really good stuff! IMO This is by far the best way to leverage tor's functionality. This looks very similar to the roll which would a VPN would play, but without the need for a centralized hub, and with the added benefit of being able to conceal headers and still perform delivery.
Speaking of such things, building in an easy interface for connecting mailpile servers via a VPN might not be such a bad idea itself...
lottspot
commented
10 years ago Speaking of such things, building in an easy interface for connecting mailpile servers via a VPN might not be such a bad idea itself...
I'll run through the issues list and check if this is on there yet, and open a new feature request if it isn't. You guys can feel free to do what you will with it from there :)
lottspot
commented
10 years ago I think we currently have different architectures in mind. In my model, I was still working with the assumption that your mail server is sitting in some data center while you are at home. In that case, spam flags would not be a problem, as the mail is getting delivered to be sent from your Mail server, which does not perform SPF / DKIM-Checks before sending your mail on, as far as I know (I may be wrong here, I don't have a deep knowledge of the inner workings of eMail).
Just wanted to quickly straighten out the minor misunderstanding here about SPF/DKIM. It is not the sending server that performs the SPF/DKIM checks. Rather, the sending server performs the DKIM signing, and the sending server is listed in the SPF record. It is the receiving server which performs the actual checks against an SPF record/DKIM signature. Because to the recipient server, the email will appear to have originated from a tor exit node, rather than from your mail server sitting in a datacenter somewhere, and it is the server off sitting in the datacenter somewhere rather than the tor exit node which is presumably listed in the SPF record (as it would be impossible to list the exit node in the SPF record, do to the inability to predict the IP address of your exit node), mail delivered through the tor network would fail an SPF check every single time. For that reason, it would be impossible to maintain an SPF record in a setup which delivers outgoing mail through the tor network. This would not be a problem in the case of DKIM, as DKIM relies only on the signature being valid for the sending domain, and is not in any way dependent on IP addresses.
uktu
commented
10 years ago @BjarniRunar and @smari ,
There are two simple issues regarding Tor integration that may have been overlooked.
I. anonymity not privacy : javascript
It is important that people be able to register for and use email anonymously. This is not about privacy. While the ultimate policy decision lies with the provider, mailpile should be Tor-agnostic, so that it can be used with providers that want to allow registration by Tor users.
There is one simple way to ensure that mailpile and the Tor Browser Bundle are compatible: mailpile login and some minimal set of features should be usable without javascript or other browser plugins. Two recent busts of Tor hidden services demonstrated that using javascript on TBB is a major hazard.
II. spam
In practice I fear it will probably become impossible to deliver e-mail this way due to existing anti-spam policies which reject or discard mail coming from the Tor network.
Do existing anti-spam policies rely on the IP stored in the header? Is this required by RFC 2822? Can we leave it blank?
bnvk
commented
10 years ago Closing this thread. It was VERY useful in ideation of incorporating TOR into Mailpile. We've implemented various rudimentary implementations of this as of 145225583d7b4e1a8c58068f925261555d5b5573
BjarniRunar
commented
10 years ago For posterity, the SMTP over Tor stuff is fleshed out further and documented on this Wiki page: https://github.com/pagekite/Mailpile/wiki/SMTorP
olokos
commented
4 years ago I wanted to fix this issue https://github.com/syrusakbary/validate_email/issues/76 But sadly the issue is on another repo.
Also a topic mentioned by the Mailpile-team on twitter in a conversation with @ioerror. Let's discuss this here, so everyone can participate. A few questions to start this off: