Re: Ports 465/587 in exit policy (was Re: Update to default exit policy)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Dingledine wrote: I know this has been discussed before, but I thought I'd bring it up again. The following rules are in the default exit policy and I can't see any reason why they would be: reject *:465 reject *:587 So is there going to be a change to the default Exit Policy? Thanks for sticking with this. I'm probably the closest person there is for changing the default exit policy. I confess I still haven't worked my way through all the off-topic garbage on or-talk from a few weeks ago. Unfortunately, I'm not up on all the different ways that people screw up configuring their mail services these days. Back in 2005 when we first added 465 and 587 to the exit policies: http://archives.seul.org/or/cvs/Sep-2005/msg00090.html we did it because people showed up and explained that many sites were running services on those ports that were basically equivalent to what they run on port 25. It sounds like nobody has any objections to opening these ports back up. And it sounds like it could help those folks using gmail, etc. So I am inclined to do it. Excellent. Thank you for taking the time to look into this Roger. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwBfUcoR2aV1igfIRAroeAJ4iAjXBzh6YBdU3mWyrIX9Gt6LhtACfUgYT VP1S3GZ5F9Ab4rPmwAv7goY= =gaqi -END PGP SIGNATURE-
Re: Update to default exit policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 7v5w7go9ub0o wrote: There is a clear misunderstanding of the issue at hand by many people here. The exit policy was put in place to prevent connections between Tor users and the last hop (the end MX server), *not* to prevent connections between Tor users and SMTP relays, which is what everybody keeps repeating. There is no problem with a Tor user connecting to an SMTP relay and sending email. If they can do it using Tor, they can do it without using Tor, faster. In those cases, it is the administrator of the SMTP relay that is responsible to stop spam. Just to repeat the problem. It is Tor users connecting to the destination MX server that is the problem. Mail relay, not mail submission. Ports 465 and 587 are mail submission ports. Port 25 is for both submission *and* relay. I have a *lot* of experience with email administration on a very large scale, I know what I'm talking about. Thanks for pursuing this! No problem. Hopefully the relevant people are taking note. Who exactly is responsible for setting the default exit policy, and what is their opinion on this matter? 1. Your arguments make good technical sense. 2. In fact, many endpoints have already enabled those ports without experiencing problems. Only a couple of dozen though unfortunately. If you ignore German and US exit nodes, I can only see 4 at the moment that will let me exit on port 465. 3. Many of us routinely handle our ssl email accounts via TOR, and your proposal (open them by default) would help spread the load, as well as reasonably expanding the default functionality of TOR. Thanks Again! (p.s. this post is being sent via ssl GMAIL, which will include the posting host when using smtps. My posting host will be a TOR exit node :-) ) Ditto. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIq/NBcoR2aV1igfIRAkMeAJ9MpfCI7k48cQlU+pkVSAHibPR0nwCgo41e dwyYXKAwBuNw431g7qTolBI= =3b/V -END PGP SIGNATURE-
Re: Update to default exit policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 anonym wrote: I have a *lot* of experience with email administration on a very large scale, I know what I'm talking about. I'm sure you do. I'd love to have email work flawlessly and securly with Tor, so opening ports 465 and 587 would be great (currently I do have problems since there's few exit nodes which do that). But as I understand it, email clients + Tor might be a very bad idea ATM. Email clients leak tons of information, the most critical I know of being your IP address and/or host in the EHLO/HELO in the beginning of the SMTP(S) transaction. Lots of protocols that can be used over Tor are potentially leaky. There are tonnes of exit nodes that allow IRC traffic for example, which can easily leak your username/hostname if you don't configure it correctly. I'm not sure what makes SMTP submission special when it comes to the exit policy. Really, this isn't an argument countering your in any way, but rather a plea that the issues of using email clients with Tor are researched and resolved before that combination gets promoted (IMHO opening ports 465 and 587 is a step towards promoting it). It's very likely your average user will screw up given the current state of things. As you said, the main issue is your hostname being leaked along with the EHLO, or your client loading remote images without using Tor. Personally, I use Thunderbird inside a virtual machine which can only access the Internet via Tor and has no personally identifiable information, including a random hostname and username etc. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrAfrcoR2aV1igfIRAsyuAJ9JTHIuRJQ12qS3j2G1P5QTjHxqJACgkAQT E8DK8FuClOfL7Wuvd9A2zSQ= =oHrD -END PGP SIGNATURE-
Re: Update to default exit policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Anderson wrote: Sorry, I didn't get it: in case I'm using Thunderbird and Torbutton, and connect to the smtp server trough tor. Will my real ip adress occur in the mail headers, or the ip of the exit node? I'm guessing the ip of the exit node, right? Because if not, it would be senseless to use tor? Would be great if someone could clarify this! Both. Look at my headers (Apple Mail): Received: from [134.76.55.100] (helo=[10.100.145.215]) by serv-80-156.SerNet.DE with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1KVqPO-0002gu-4k for or-talk@freehaven.net; Wed, 20 Aug 2008 18:19:42 +0200 When using tor, 134.76.55.100 will be the tor exit node ip, and 10.100.145.215 will still be your local client ip. The only reason that your 10.100.145.215 IP appears in the headers there is because your email client sends it. Your email client doesn't need to send it, and as someone else mentioned, it's scrubbed if you're using TorButton with Thunderbird for example. Yes, it doesn't make sense to use tor with a normal mail-client. But if you are behind a NAT router, it's not as bad as it looks first. It's at least as safe as using a webmail interface if you configure your email client correctly. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrFtacoR2aV1igfIRAo8pAKCKxeN/KHtu43xN8FXSThwYDJmzvACguLJD t7heELhjiEcN1z4e7LQ9ZRM= =Ldgd -END PGP SIGNATURE-
Re: Update to default exit policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dominik Schaefer wrote: Those are ports used for mail submission, not for mail relay. They wont be abused by spammers. ISPs often block their consumer broadband users from connecting to port 25 on servers outside of their network, to prevent spam. They don't block 465 and 587, because they're not problem ports and the point of them is, that you authenticate before sending mail, unlike port 25. You wouldn't block port 443 to prevent spammers submitting mail via https://mail.google.com/ so why block these ports? Actually, it is a little more complicated. 465 is just plain SMTP-over-SSL, so not much different to non-encrypted SMTP on port 25. (BTW: AFAIR the recommened method for encrypting SMTP is to use port 25 with STARTTLS and not to use a different port, so connections to port 25 may be encrypted as well.) Concerning the submission port 587: Originally, the submission port needed neither to be encrypted, nor did it enforce authentication (see RfC 2476, http://www.faqs.org/rfcs/rfc2476.html). Authentication MAY be done before submitting mails. Only RfC 4409 (which obsoleted 2476) introduced a MUST for authentication of the sender, but is still quite recent (2006). AFAIR both RfC make no statement about the encryption of connections to port 587 for mail submission, although 3207 (STARTTLS) states it can be useful. 1.) Can anyone here show me a mail server that runs on port 587 or port 465 that doesn't require authentication to send email? 2.) Now can anyone here show me a mail server that runs on port 25 that doesn't require authentication to send email? I suspect the answer to 1 is either no, or a list of a couple of servers. I suspect the answer to number 2 is, yes, here's a list of a few hundred thousand. Lets be a little pragmatic here. After all, the exit policy in question was done for purely pragmatic and not technical reasons. Opening ports 465 and 587 will *not* cause the spam problem that blocking them was intending to prevent. The number of mailboxes that would be able to be spammed through those two ports without authentication is insignificantly small (I can't demonstrate one, can you?) Blocking those two ports by default achieves nothing. Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqpBbcoR2aV1igfIRAgWyAKCJ2cxNO2mO8PRvNMX7BKoyFnHClACeJtlp ZoylC/edpaBNmJ3ooOfRgUs= =QR4+ -END PGP SIGNATURE-
Update to default exit policy
Hi, I know this has been discussed before, but I thought I'd bring it up again. The following rules are in the default exit policy and I can't see any reason why they would be: reject *:465 reject *:587 Those are ports used for mail submission, not for mail relay. They wont be abused by spammers. ISPs often block their consumer broadband users from connecting to port 25 on servers outside of their network, to prevent spam. They don't block 465 and 587, because they're not problem ports and the point of them is, that you authenticate before sending mail, unlike port 25. You wouldn't block port 443 to prevent spammers submitting mail via https://mail.google.com/ so why block these ports? As I write this, there are only 28 exit nodes spread across 6 countries that will exit to smtp.gmail.com:465. There's no advantage to blocking this port, but a clear reduction in anonymity by limiting the nodes exiting to it. -- Dawn
Re: Vidalia exit-country
Camilo Viecco wrote: As part of the 'google summer of code'(gsoc) I was able to add some of blossom's functionality to vidalia. The project consisted of adding a 'select exit by country' option to vidalia so that users could leverage the Tor network to select the 'perspective' of the network the wished to have. The idea is that many entities select their content based on the traffic ip address 'source' and users might like to have different perspectives easily controlled by them. I just downloaded/compiled/installed the Linux version on my Ubuntu system and went to choose a country to use. The dropdown list of countries contained one country only, named (??)(626) -- Dawn
polipo - choosing an exit
Hi, I'm using polipo. When I choose an exit node by sticking node.exit on the end of a url, I think that is actually passed on with the Host header. How do I get polipo to strip that off? For example, http://www.showmyip.com.tortila.exit/; doesn't work as it has no vhost set up for www.showmyip.com.tortila.exit. Also, if the html returned by that page contained eg: img src=http://www.showmyip.com/foo.jpg; / am I correct in thinking that that request wouldn't necessarily go out via the same exit node I chose for the main page? -- Dawn
Re: Exit node connection statistics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Figuring out which exit node you are should be fairly trivial. There are about 1000 exit nodes that exit on port 80, and you are one of them. If I just send loads of http requests through half of those exit nodes to my own server one day and then check if my IP appears on your webpage, I've halved the number of possible exit nodes you are. If I then halve it again and repeat this every day, it should only take about a week and a half. I'll start with a possibility of 1024 exit nodes just for ease of maths: Day 1 : Test 512 of the 1024 remaining exit nodes Day 2 : Test 256 of the 512 remaining exit nodes Day 3 : Test 128 of the 256 remaining exit nodes Day 4 : Test 64 of the 128 remaining exit nodes Day 5 : Test 32 of the 64 remaining exit nodes Day 6 : Test 16 of the 32 remaining exit nodes Day 7 : Test 8 of the 16 remaining exit nodes Day 8 : Test 4 of the8 remaining exit nodes Day 9 : Test 2 of the4 remaining exit nodes Day 10: Test 1 of the2 remaining exit nodes - Success This process becomes quicker if you have more than 1 ip to test with. I'm making the assumption that it can't be that difficult to send enough http requests to get to the 100th or above place on your list. You don't publish total number of connections, only percentage of total, but it seems likely to me that the number of connections made to the site that is number 100 on your list should be easy to exceed. I'm not going to bother of course, because I don't care that much. But just so you know, don't use that same onion address for anything that *needs* to be anonymous, because it wont be. - -- Dawn [EMAIL PROTECTED] wrote: Hi, I don't know if somebody did this before, but I think it is quite interesting, to which hosts most of the exit connections go to. So I set up a statistics script creating a list of the top 100 hosts each day to which Tor users connect to over my node (only for ports 80 and 443). Besides just being interesting, this can also show potential security problems on the top hosts which are being exploited over Tor. For example, during the last weeks rapleaf.com was always at the top, and they keep a huge email-address database. This is probably no incident. The log data necessary for this is being deleted after one day not to compromise the anonymity of the users. I decided to make this accessible through a hidden service only, since I don't want to influence the exit node usage behaviour. This is the address: http://ob44yuhbyysk5xft.onion If you think this is a stupid idea or you have ideas for other interesting stats and for any other comment you can reach me by mplsfox02_AT_sneakemail_DOT_com. I don't know how long I will stay subscribed with or-talk, since I just wanted to seed the information. Spread it as you like. Regards, a Tor exit node operator. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgKNBcoR2aV1igfIRAs+KAJ94H26Eyc4Dm+nvRdtswIXX3rHTNACeODu8 +SgBlPvn0mX13cyGO62lrQY= =KdYI -END PGP SIGNATURE-
email hidden service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Are there any hidden service email services in existance? - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIexnDcoR2aV1igfIRAoRUAKDMM7sR1BFNPf1PE69+TTTUIMaXOQCfSesT bMFs5dH6NZi8oZGk7AO790g= =Dr+s -END PGP SIGNATURE-
Re: email hidden service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karsten N. wrote: Are there any hidden service email services in existance? Yes: http://w6kb72k2phin5grc.onion/ (Onion Boxes, Etc) http://shells3nfdn3zk5h.onion/ (shells.onion) Thanks for the information. Out of interest, how did shells.onion manage to get a .onion address that starts shells ? That can't just be a coincidence surely? - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIeyVUcoR2aV1igfIRAmqtAJ95gQNqI/ce8AQvJM8UW6SPKSgqXQCgqlqW UE7JQBdw6n+iYa0bCVu6Z8U= =2FSd -END PGP SIGNATURE-
Idle client bandwidth usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Are there any figures on how much bandwidth an idle tor client uses just to tick over? Ie, when it's not actually being used. Also, are there any configuration parameters that can be tweaked to reduce the bandwidth usage? best wishes, dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIbeRIcoR2aV1igfIRAh0YAJ4/qHr2Y1kfu/ZYdId+33HsGHinQACgpWZG c6fpkIJuaU1DlNCd6ixRY8o= =Z12O -END PGP SIGNATURE-
icann opening up of tld's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Regarding icann's announcement on Thursday about the opening up of TLD's detailed at this url: http://www.icann.org/en/announcements/announcement-4-26jun08-en.htm What would be the hidden service privacy implications of someone registering the .onion tld? Is this something the tor project should look into doing next year? dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZiDocoR2aV1igfIRAluKAKCWy3bTdWNajwY2T2reAAO5TcrGewCeKWpb X/RdeXkBNXj8mWyZyc1WQAQ= =7jGc -END PGP SIGNATURE-
