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 Dawney Smith 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 > > Just so people know. I'm not going to let this discussion die off until > I've had a definitive yes or no from the people who are responsible for > setting the default exit policy. Can someone point me in the direction > of who that might be please? I get the feeling it's one of those topics > that the people developing Tor want to avoid... So is there going to be a change to the default Exit Policy? Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIurmNcoR2aV1igfIRAhu3AKC/jejouMRPgbRB9HZILW2H2PTOyACgpyrf vVdqlscHYsEMuBil/P2dM7M= =R9zE -END PGP SIGNATURE-
Re: xB Mail: Anonymous Email Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Anderson wrote: 2.) Obfuscate the data sent in the EHLO so it doesn't leak the hostname/ip >>> >>> I'll have to check how thunderbird implements smtp. >> >> It must be possible as TorButton manages to do it. > > BTW: Wouldn't it be good to have a local privacy mail-relay, like a > "Prilay", which is to mail clients what Privoxy is to browsers? They > would work with any client. I had thought about that idea. It wouldn't be as flexible as a Socks proxy though as you'd need to configure it to connect to a particular SMTP server over Tor. Perhaps in your torrc: SMTPPort 25 SMTPRelaysmtp.gmail.com:465 SMTPRelaySSL On SMTPRelayUser username SMTPRelayPass password It could strip a variety of headers, check for keywords, obfuscate the timezone in the Date header etc etc. You could even configure it to reject mail that isn't pgp signed or encrypted. Could give it a whitelist of addresses that you're allowed to email. That sort of thing. That would be neat. I'm not sure if anyone would be willing to put in the work though. I wish I could code C. Or of course, you could have an entirely separate application to do all that, ala privoxy/polipo. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIro0VcoR2aV1igfIRAlBsAJ9MtZ1MD5VC+1tDNPjYFhCse89YMgCfRnZU M/z4TgadC7uY83IDKjKFR1o= =VWCh -END PGP SIGNATURE-
Re: Update to default exit policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dawney Smith 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 Just so people know. I'm not going to let this discussion die off until I've had a definitive yes or no from the people who are responsible for setting the default exit policy. Can someone point me in the direction of who that might be please? I get the feeling it's one of those topics that the people developing Tor want to avoid... - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIroqkcoR2aV1igfIRAu3rAKCXva6OtdpWebDRCF32c02zZFNA7ACgtuwY vQFVBcPDUt6mpZ5jg+EqJJ4= =Ou4o -END PGP SIGNATURE-
Re: xB Mail: Anonymous Email Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arrakis wrote: >> 2.) Obfuscate the data sent in the EHLO so it doesn't leak the hostname/ip > > I'll have to check how thunderbird implements smtp. It must be possible as TorButton manages to do it. >> 7.) Turn off return receipts and Junk filtering > > Junk filtering is sticky. Because we are going to use thunderbird, we > can create bayesian filters in token form, and push token updates to > the client. It would be kind of amazing if the latest paris hilton > spam was blocked before the user had to read it. The management program > could update such a token over https, un-anonymized, every x time. The main reason I mentioned this one is because it is an unknown quantity to me. I'm not sure if Thunderbird leaks any information with it's Spam filtering. Even if it doesn't now, I'm not sure if an upgrade wouldn't cause it to in future. So to be safe, I leave it off. >> 8.) For convenience rather than security, I'd make it automatically turn >> on the options to download the full messages to disk. > > Thats one of those distasteful things about mail, and one of the reasons > I prefer IMAP over POP. POP is fine if you're encrypting your message > base, but if not, IMAP is preferable. But I tell you what... i really > *could* encrypt the messagebase on thunderbird. No telling how secure > that would really be in windows implementation, but it is certainly > a fun idea. Yeah, I prefer IMAP, but I like a local copy of the mail so it doesn't need to connect to the server over Tor every time I want to read a message. Encrypted on disk would be a nice option. Another thing worth looking at would be how Thunderbird performs automatic extension updates. Oh, and generating a list of extensions that are safe/unsafe to use with Thunderbird. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIronWcoR2aV1igfIRAnhxAJdeawiNTbd1ZRG+4JAE4LzQMfvLAKCYxDHu U1/xQbKTtgbFiNFn4VWt1A== =IZ+7 -END PGP SIGNATURE-
Re: xB Mail: Anonymous Email Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Bennett wrote: > The more I understand email threats/issues over Tor > the better. I am aware that there are only occasionally > any exit servers allowing port 25, but if we are > forcing SSL/TLS, then it won't matter what port they > pick. So any preferences for extensions and behavior are > welcome. Here are some suggestions. Some of them ere also mentioned in the other thread about changing the default exit policy. 1.) Block remote image loading 2.) Obfuscate the data sent in the EHLO so it doesn't leak the hostname/ip 3.) Even using an obfuscated EHLO, that can still leak information. If you're using TLS rather than SSL on connect when sending an email, the exit node can see what is sent in the EHLO. The fact that you send the same EHLO every time could potentially let the exit node identify you if you come back. Therefore, although it's not the standard, SSL on connect on port 465 is preferable to TLS on port 587/25 when submitting email over Tor. >>> IANA has assigned port 465 to another function. Why do you believe >>> that a conflicting use should be supported or encouraged? >> I provided my reasons in the explanation directly above. > > I see an explanation of what would be secure, which it certainly appears > to be. I don't see an explanation of why that particular port (465) should > be used for mail when it has been assigned to another purpose. Me.) Port 465 should be used because it's more secure You.) Why do you believe it should be used Me.) Because it's more secure You.) I don't see an explanation of why you think it should be used. Errr > After all, should we use 995 for SSH? That would be secure, too. No idea what the point you're trying to make there is. Many services (including gmail) offer an ssl on connect service on port 465 for mail, for legacy reasons. I'm just saying, use it if you can. Running SSH on port 995 really isn't irrelevant to that. >>> I'd stick with >>> 587 and 25 until such time as another mail port is assigned. If you think >>> that might take forever, you could try campaigning for it, I suppose. Of >>> course, if a campaign is successful, it might only take forever minus a >>> year or two. :-) >> I'll stick with 465 as long as it's supported so I get a completely >> encrypted connection. Given a choice, why would you use 587 over Tor? > > Simply because they *is* a mail port. I happen to want a smtps port, > too, but one has yet to be assigned. Stealing a port assigned to another > purpose is not usually justified. The Internet isn't that simple. People who provide a mail service can run it on whatever port they want. They don't have to justify that choice to anyone. Stealing doesn't come into it. It can cause interoperability problems in certain circumstances. This isn't one of them. I'm not talking in theoretical terms here, I'm discussing the reality of the situation. 4.) The "Use secure connection" account settings should never be "TLS if available" as a mitm attack could stop you from negotiating SSL without realising. 5.) The "Check for new messages every" option could leak to the exit node that it is the same client coming back, if you set it to an unusual value like 17 minutes for example. Changing from the default should be dissuaded. 6.) If people use a Torified account alongside a non Torified account (I'd make it advise people to use a separate profile). But if they do, do that, then it needs to make sure the two accounts don't share the same LDAP server. 7.) Turn off return receipts and Junk filtering 8.) For convenience rather than security, I'd make it automatically turn on the options to download the full messages to disk. Oh. It would also be nice if you could add a list of keywords that Thunderbird shouldn't allow you to send in an email, in case you accidently sign a message with your own name for example. >>> Except for the aforementioned push to use the urd port for [S]SMTP, >>> the rest of the above seem good to me. >> Pragmatically speaking. 465 is going to be a service provided by many >> mail systems for a long time to come, and it has clear advantages over >> Tor compared to port 587. > > I guess that's sort of the old "possession is 9/10 of the law" > attitude. It may work, but also has unwanted consequences. >> All I'm saying is, the implications of using one over the other should >> be made clear to the user, so they can then make their own decision. >> > 100% agreed. My concern is only over using a port for mail that > is already assigned to another service. There are lots of unused, secured > ports (i.e., numbers < 1024) that could be reserved. Actually, I have no > real idea how much bureaucratic red tape and delay is involved in getting > a port assigned
Re: xB Mail: Anonymous Email Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Bennett wrote: >>> The more I understand email threats/issues over Tor >>> the better. I am aware that there are only occasionally >>> any exit servers allowing port 25, but if we are >>> forcing SSL/TLS, then it won't matter what port they >>> pick. So any preferences for extensions and behavior are >>> welcome. >> Here are some suggestions. Some of them ere also mentioned in the other >> thread about changing the default exit policy. >> >> 1.) Block remote image loading >> 2.) Obfuscate the data sent in the EHLO so it doesn't leak the hostname/ip >> 3.) Even using an obfuscated EHLO, that can still leak information. If >> you're using TLS rather than SSL on connect when sending an email, the >> exit node can see what is sent in the EHLO. The fact that you send the >> same EHLO every time could potentially let the exit node identify you if >> you come back. Therefore, although it's not the standard, SSL on connect >> on port 465 is preferable to TLS on port 587/25 when submitting email >> over Tor. > > IANA has assigned port 465 to another function. Why do you believe > that a conflicting use should be supported or encouraged? I provided my reasons in the explanation directly above. > I'd stick with > 587 and 25 until such time as another mail port is assigned. If you think > that might take forever, you could try campaigning for it, I suppose. Of > course, if a campaign is successful, it might only take forever minus a > year or two. :-) I'll stick with 465 as long as it's supported so I get a completely encrypted connection. Given a choice, why would you use 587 over Tor? >> 4.) The "Use secure connection" account settings should never be "TLS if >> available" as a mitm attack could stop you from negotiating SSL without >> realising. >> 5.) The "Check for new messages every" option could leak to the exit >> node that it is the same client coming back, if you set it to an unusual >> value like 17 minutes for example. Changing from the default should be >> dissuaded. >> 6.) If people use a Torified account alongside a non Torified account >> (I'd make it advise people to use a separate profile). But if they do, >> do that, then it needs to make sure the two accounts don't share the >> same LDAP server. >> 7.) Turn off return receipts and Junk filtering >> 8.) For convenience rather than security, I'd make it automatically turn >> on the options to download the full messages to disk. >> >> Oh. It would also be nice if you could add a list of keywords that >> Thunderbird shouldn't allow you to send in an email, in case you >> accidently sign a message with your own name for example. >> > Except for the aforementioned push to use the urd port for [S]SMTP, > the rest of the above seem good to me. Pragmatically speaking. 465 is going to be a service provided by many mail systems for a long time to come, and it has clear advantages over Tor compared to port 587. All I'm saying is, the implications of using one over the other should be made clear to the user, so they can then make their own decision. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrXwccoR2aV1igfIRAusXAJ9OmFtnb0Hxph6POg3O7Q4XVzLGwACaA0CT 6ZywREMJQB9jpBKO3r+sMjQ= =2JLP -END PGP SIGNATURE-
Re: xB Mail: Anonymous Email Client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arrakis wrote: > The more I understand email threats/issues over Tor > the better. I am aware that there are only occasionally > any exit servers allowing port 25, but if we are > forcing SSL/TLS, then it won't matter what port they > pick. So any preferences for extensions and behavior are > welcome. Here are some suggestions. Some of them ere also mentioned in the other thread about changing the default exit policy. 1.) Block remote image loading 2.) Obfuscate the data sent in the EHLO so it doesn't leak the hostname/ip 3.) Even using an obfuscated EHLO, that can still leak information. If you're using TLS rather than SSL on connect when sending an email, the exit node can see what is sent in the EHLO. The fact that you send the same EHLO every time could potentially let the exit node identify you if you come back. Therefore, although it's not the standard, SSL on connect on port 465 is preferable to TLS on port 587/25 when submitting email over Tor. 4.) The "Use secure connection" account settings should never be "TLS if available" as a mitm attack could stop you from negotiating SSL without realising. 5.) The "Check for new messages every" option could leak to the exit node that it is the same client coming back, if you set it to an unusual value like 17 minutes for example. Changing from the default should be dissuaded. 6.) If people use a Torified account alongside a non Torified account (I'd make it advise people to use a separate profile). But if they do, do that, then it needs to make sure the two accounts don't share the same LDAP server. 7.) Turn off return receipts and Junk filtering 8.) For convenience rather than security, I'd make it automatically turn on the options to download the full messages to disk. Oh. It would also be nice if you could add a list of keywords that Thunderbird shouldn't allow you to send in an email, in case you accidently sign a message with your own name for example. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrSd9coR2aV1igfIRAhNDAKCllAhgp2bJpBBpqdfvFz9ysL9fgACgzoCG zb0P2K9ybh98czG6LWv6I7M= =hUmD -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 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 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 krishna e bera wrote: > I'm not clear on how authentication (on any port) stops spam, > other than the ISP cutting off a given userid after complaints. > A lot of spam already comes from malware infected computers > via their legitimately configured email. > Those computers are probably not using Tor, let alone transparent proxy, > but malware could grab their credentials and then > use Tor on another host to send out spam over port 587, > if that port was allowed in exit policies. 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. Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqurucoR2aV1igfIRAkx0AJ9opGDSoyy3blMWvNzxx/IgzPFWhgCfd+Zy 858fyCn0IVyYtfYp/YPxtTA= =IJtA -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-
Re: Update to default exit policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xiando 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 > > Are you absolutely positivily sure that you can not misconfigure e-mail MTAs > who use smtps (465) and submission (587) to be open relays? Of course people can misconfigure their mail servers. > My understanding is from my quick search on this topic is that IF you setup > an > open relay then that relay can be used regardless of the connection coming > through a SSL encrypted connection or a plain-text connection on port 25. Well, yes, but that's not really relevant. The default exit policy of blocking port 25 has nothing to do with stopping the abuse of open relays. > Plain-text (25) or encrypted (465) has nothing to do with authentication, > just > like you can visit many websites using http (80) and https (443) without > actually logging in. > > I am not sure having them open by default would be a good thing. Lets assume port the exit policy is updated, and the ports opened, and I want to send a spam to a gmail user. Tor prevents me making a direct connection to their MX on port 25 to deliver the spam to them. That's the point of blocking 25 by default. Open relays don't come into it. Opening port 465 or 587 doesn't change that. The only way I could "abuse" ports 465/587 through Tor was if I found a misconfigured open relay running on those ports. If a misconfigured open relay sends a load of spam, people block the open relay, and don't concern themselves with the initiating IP. If an open relays sends a load of spam, it is the admin's fault of that relay for not locking it down properly. Abusing an open relay through Tor is no different to abusing a website through Tor. - -- Dawn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIpxhAcoR2aV1igfIRAtcUAKCcn9jo6ICFMy22Ku/nfGWn9FeFwwCggCS0 PbRcQbjcpSp3RPTanXcK+IU= =XO7L -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: 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-
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-
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-
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-
