Re: [tor-relays] Simplifying ExoneraTor
On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker josh@tucker.wales wrote: I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) How about Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...) where: Never means the relay has never allowed exiting to any port or IP; Unrestricted means the relay currently allows exiting to all ports and IPs; Restricted means the relay currently allows exiting to some ports and IPs, enough to get the exit flag; Unlikely means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag; Former means the relay allowed exiting to something at some time in the past, but doesn't anymore. And in all cases you can click for more details. (The '(details...)' is literal.) zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/15 17:40, Zack Weinberg wrote: On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker josh@tucker.wales wrote: I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) How about Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...) Yes, I could imagine adding more states than just Yes and No. where: Never means the relay has never allowed exiting to any port or IP; Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this. Unrestricted means the relay currently allows exiting to all ports and IPs; Plausible, though there are hardly any relays permitting all ports. Restricted means the relay currently allows exiting to some ports and IPs, enough to get the exit flag; I'd simply call this Yes. All relays with the Exit flag would have this state. Unlikely means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag; This is probably what I'd call Restricted or Limited. That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag. Former means the relay allowed exiting to something at some time in the past, but doesn't anymore. This has the same issues as Never. We'd also need No for the reject 1-65535 case. And in all cases you can click for more details. (The '(details...)' is literal.) See my earlier response about more details. We can probably explain three or four possible states in easy-to-understand terms. So, yes, this seems plausible, if we can keep it simple. What states should we use, and how should we document those in user language? All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVm/yJAAoJEJD5dJfVqbCrNSQH/1q3hS7aMvEPcgCp+E/cLwjy fmYHEilAgOa1hYwf+wZshljQqDQmMxzHCAheIR+db2pPa7ZZfguwR7tZ0Z4NfvIU rwgQrgpGg+W5Zd9bl/2mW7eZFHAAQRpdDzMPy5zlDUHd2pR6tCQNvudhGXhbrlau ZBgaegsnT40dncMu0lChOvy9WHscKVCw3Ip3y9jVd5A01gY95cCS5RNKs3Ma0A6T OFxDZ9dzApika+zbDaTGVb/bYeWuM3QwAcKfjHcg4hf0GkMC8W/FnK/6X1Sfsjp8 omYRvLmispKkMYlvcYPBSGAMLXKcCyrrBTj5LtnPyIyUnmBM05FCIhNPH7KxNe4= =dd+a -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I agree with the fact that I think we could accomplish all of this through better documentation. I'm not a massive fan of those five different states - I just feel it's a little too confusing for users. Regards, Joshua Lee Tucker @tuckerwales On Tue, Jul 7, 2015 at 5:21 PM, Karsten Loesing kars...@torproject.org wrote: - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/15 17:40, Zack Weinberg wrote: On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker josh@tucker.wales wrote: I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) How about Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...) Yes, I could imagine adding more states than just Yes and No. where: Never means the relay has never allowed exiting to any port or IP; Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this. Unrestricted means the relay currently allows exiting to all ports and IPs; Plausible, though there are hardly any relays permitting all ports. Restricted means the relay currently allows exiting to some ports and IPs, enough to get the exit flag; I'd simply call this Yes. All relays with the Exit flag would have this state. Unlikely means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag; This is probably what I'd call Restricted or Limited. That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag. Former means the relay allowed exiting to something at some time in the past, but doesn't anymore. This has the same issues as Never. We'd also need No for the reject 1-65535 case. And in all cases you can click for more details. (The '(details...)' is literal.) See my earlier response about more details. We can probably explain three or four possible states in easy-to-understand terms. So, yes, this seems plausible, if we can keep it simple. What states should we use, and how should we document those in user language? All the best, Karsten - -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVm/yJAAoJEJD5dJfVqbCrNSQH/1q3hS7aMvEPcgCp+E/cLwjy fmYHEilAgOa1hYwf+wZshljQqDQmMxzHCAheIR+db2pPa7ZZfguwR7tZ0Z4NfvIU rwgQrgpGg+W5Zd9bl/2mW7eZFHAAQRpdDzMPy5zlDUHd2pR6tCQNvudhGXhbrlau ZBgaegsnT40dncMu0lChOvy9WHscKVCw3Ip3y9jVd5A01gY95cCS5RNKs3Ma0A6T OFxDZ9dzApika+zbDaTGVb/bYeWuM3QwAcKfjHcg4hf0GkMC8W/FnK/6X1Sfsjp8 omYRvLmispKkMYlvcYPBSGAMLXKcCyrrBTj5LtnPyIyUnmBM05FCIhNPH7KxNe4= =dd+a - -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -BEGIN PGP SIGNATURE- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVnBJVCRB1zCF5iNk2lwAAGbYP/iefpIjrTjn4+CJP+TGs NYhUEp5KVMAjOb1kGKjlUPZvh/6irQYmUqZo2A/qNgCIma71Nc3//FA9GN9l dOAYkuQ+seYzy9+OgZmCnkB11JGTTi1/A/nlyo/TAtxgQ6zYNGwa741ZhoSv dGRN4XzvCJjc8Supgpfeb6Aw/av9BGu4UBjdf0BWNuZ66AgcUPdtsC4ldwaN 2/IP3nvHVzU0IA2KyilV+9cpNeAU4xYivCCAo1yLWaOV4AWr9x0CwuxscoV2 mOPdI5/Og0fhoeDKBew3h610p0z1atF8m5flNVL3aUsBBmJzQdYWTOtoYvtD rmAZSiXAm8tZtLYLiWD/sD8ThonNXkzg+8+uRo27TUR7Mem4mZSGeq+nvUAO UTc+K2+03TxqYMIgjFZuEfV9SzcuabI6m2Nhy9T30E7cTKam9/pjHwGV6Qcl o98k1X2zBuGHvYAz8Wnb5x8NBwCAi4Otliewqf9bVKcnD59r4fQunVeys+8/ qGPX/N1dkxhAGOaxx2q/eSbZMxUvFOCNeNbRVwIB88ES2pTNWRyqCFPmyhlv ndrxwkDu1Ib8aFSM2jDFe76D6B07NfbSFjZm9Ifb0z0fW9RZ7RL14QbVQhj6 GkqsgyYZ62b7ThjMnREgIZ6U1LO4FBp8MgKDxV0haVP18AknU24rxInXAPao wNu4 =MmQA -END PGP SIGNATURE- On Tue, Jul 7, 2015 at 5:21 PM, Karsten Loesing kars...@torproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/15 17:40, Zack Weinberg wrote: On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker josh@tucker.wales wrote: I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) How about Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...) Yes, I could imagine adding more states than just Yes and No. where: Never means the relay has never allowed exiting to any port or IP; Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this. Unrestricted means the relay currently allows exiting to all ports and IPs; Plausible, though there are hardly any relays permitting all ports. Restricted
Re: [tor-relays] Simplifying ExoneraTor
On 7 Jul 2015, at 07:48, Karsten Loesing kars...@torproject.org wrote: On 07/07/15 03:45, teor wrote: On 7 Jul 2015, at 09:46 , josh@tucker.wales wrote: From the perspective of someone investigating abuse, I think it's important that 'not an exit relay' means 'not capable of exiting on any port at all'. Ergo I think your option c) is the way to go. I also think this (c) is the best option. I agree that it's important to be able to determine, from an investigatory perspective, whether or not a relay was capable of exiting on any port. Okay, let's do c). And, if we are going to implement Exit as any port, it should also be *any* IP, not just an IPv4 /8 as in the Ext flag definition. For c), we'd just check if there's a p reject 1-65535 line or not. I think this is a perfectly OK way of doing this considering the use case. Here's the updated design mockup: https://people.torproject.org/~karsten/volatile/exonerator-mockup/ Looks great Karsten, good job! Regards, Joshua Lee Tucker @tuckerwales ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/15 03:45, teor wrote: On 7 Jul 2015, at 09:46 , josh@tucker.wales wrote: From the perspective of someone investigating abuse, I think it's important that 'not an exit relay' means 'not capable of exiting on any port at all'. Ergo I think your option c) is the way to go. I also think this (c) is the best option. I agree that it's important to be able to determine, from an investigatory perspective, whether or not a relay was capable of exiting on any port. Okay, let's do c). And, if we are going to implement Exit as any port, it should also be *any* IP, not just an IPv4 /8 as in the Ext flag definition. The issue of such a definition would be that we couldn't rely on what's written in the network status consensus, but we'd have to parse server descriptors. If possible, I'd only want to use what's in the consensus for ExoneraTor's Exit column. Here's the information we can learn from the consensus: r TorLand1 4ekiogr2CHKIJKYgutxu/Iy4wrg ZzWUBT9yjZyg/SBXixf0Ll9VlZk 2015-07-06 19:13:14 37.130.227.133 443 80 a [2a02:2498:e001:3c::133]:443 s Exit Fast Guard HSDir Running Stable V2Dir Valid v Tor 0.2.6.7 w Bandwidth=166000 p accept 20,23,43,53,79-81,88,110,143,194,220,389,443,464,531,543-544,554,563,636,706,749,873,902-904,981,989-995,1194,1220,1293,1500,1533,1677,1723,1755,1863,2082-2083,2086-2087,2095-2096,2102-2104,3128,3389,3690,4321,4643,5050,5190,5222-5223,5228,5900,6660-6669,6679,6697,8000,8008,8074,8080,8087-8088,8332-8333,8443,,9418,-1,11371,12350,19294,19638,23456,33033,64738 For c), we'd just check if there's a p reject 1-65535 line or not. Here's the updated design mockup: https://people.torproject.org/~karsten/volatile/exonerator-mockup/ Thanks, everyone, for the very useful feedback so far! All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVm3YfAAoJEJD5dJfVqbCr9cgH/iBRWNAFA0TJhNBrJa5TtOXD b0F9DmwMbdiDixCkwpBfk+8Dik7HljPXY35fM3zZsmreG4ygoDSwc2enpTMhlYSw lqt4r1KBj5VG8L8sAg3F4EIRseho7wC3BP1eZEwj0oVtjmzTIQPBafDD7EoBszJT UKw3wiBx9wV73StJGTCbhqRl7NbeEe30pJ5IN9t1QrYDoeGCOCS0Wt8wPuhGh2Pn TKv1OEUrxA89j1l8/QN2MvQkiqWhgiaHNVp6Iom/cpZdTnYUI4EGLsKmedLy+Q1b qnnVouatFTyzdYVq7ZQjky9nr9YaTF6HdeHewi50EV9tVVJ7jo01zn2w74fOl3M= =Lklj -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running a relay in the Netherlands
NL is perfectly safe, probably one of the safest countries on the planet for running Tor relays and exits. No need to worry about the legality of it much, as long as you appropriately keep your own traffic and Tor traffic separate. [IANAL!!!] Raspberry Pis aren't very fast, so it won't help the network much. Tom TorOps schreef op 07/07/15 om 20:12: Hello, I am about to move to the Netherlands and will, as part of the move, decommission the server my relay is currently running on. I'd like to be able to continue to help, though, so I wonder how the legal climate is for Tor relays and/or exit nodes in the Netherlands? On a related topic, how smart/efficient/possible is it to run a relay/exit on a Raspberry Pi? Thanks for any info. smime.p7s Description: S/MIME-cryptografische ondertekening ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jul 7, 2015 at 7:27 PM, David Serrano t...@dserrano5.es wrote: Throwing this idea out there instead of keeping it to myself: what about modifying the form to ask also for the destination port? So the investigator would enter source IP, dest port and date. Can be somewhat confusing due to the source/dest mix, but the Exit column in this case would be pretty clear because it would refer only to the required port. I actually quite like this idea, I think that could work. Anyone else have an opinion on this? Joshua Lee Tucker @tuckerwales -BEGIN PGP SIGNATURE- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVnCQvCRB1zCF5iNk2lwAAgbUQAMGDJXpWR790PofLtztI HZx96jpFHlBZ8VUrPntstDhFApFvNes9AdSKgIv9CTQ4T2M8C9gckI7RSvWb 0Es30mRjcAYEwey0tBAPRKupzV7TwQ50ol1c6TCKv83KDe1UskV5BoGj8d6k BkrL6HuCPXi7Gi9qOUvMmPkEdkoehMBiBuqvxO3tRh//SRoabdMDsVpYVFBN cPIHd0xrrSC8w7T3OcExKyxEUKg1pfAtuUkFHrZ3v8YoVfVKLvGda56p2i1G LGVAQ4DmT2SZ6kwZq1OXb8ZOKUQR/wo6xXGIK8jWHHl88chaD0wZoQOTH475 8gA9dho/xOyb5HntFD/R5/LZ/m8PZoVm4tKFL92Gk6rIdOOZz52WZlEtCFfW p2IjkBHB5EyrW01i05PbcHRM7NVQUZKGQ2i1CNPCFgYqa1t8VpD1cpQzx+vG +Bl8rrJgSPAB/acDiVsb/kRylTFVXb8BvNuXAezFMG+2qAUZY3Eob5Ipp4vc MeIgN31xOtspwyfb3ba5nOiP5gb+xZuZxvHkOCTDpztCY/MbZYFtw80rjhPy 8uDXoFfLO1kG80hlISJp/XSRmUm55sZGp838P/K4UTnG1popR8uhp61kgnwR 3wWTtanu2tfTqBXqt4bk1Ml5F6nPPLlPs+W40zAt/4YF0vQtVU6peeN0d8Tk fBg6 =jw3J -END PGP SIGNATURE- On Tue, Jul 7, 2015 at 7:27 PM, David Serrano t...@dserrano5.es wrote: On 2015-07-07 15:19:18 (+0100), Joshua Lee Tucker wrote: On 7/7/15, teor teor2...@gmail.com wrote: Organisation X experiences an attack on their website via an IP address Organisation X experiences a SSH login/password scan via an IP address We could split the Exit column in two (web ports, other ports) I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) Throwing this idea out there instead of keeping it to myself: what about modifying the form to ask also for the destination port? So the investigator would enter source IP, dest port and date. Can be somewhat confusing due to the source/dest mix, but the Exit column in this case would be pretty clear because it would refer only to the required port. -- David Serrano PGP: 1BCC1A1F280A01F9 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Running a relay in the Netherlands
Hello, I am about to move to the Netherlands and will, as part of the move, decommission the server my relay is currently running on. I'd like to be able to continue to help, though, so I wonder how the legal climate is for Tor relays and/or exit nodes in the Netherlands? On a related topic, how smart/efficient/possible is it to run a relay/exit on a Raspberry Pi? Thanks for any info. -- Regards, StairNetTor Operator ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On Tue, Jul 7, 2015 at 12:21 PM, Karsten Loesing kars...@torproject.org wrote: On 07/07/15 17:40, Zack Weinberg wrote: where: Never means the relay has never allowed exiting to any port or IP; Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this. The thing is, putting myself in the shoes of someone trying to investigate an incident, I think the distinction among this relay has _never_ allowed any sort of exiting, this relay _does_ allow exiting right now, and this relay _did_ allow exiting at some point in the past but doesn't right now is critical. More important than whatever its current policy is wrt any given port or IP address. Re-importing the entire descriptor archive therefore strikes me as yeah, if that's what it takes, you should do that. Moreover, when digging deeper, I would want to be able to know the exact exit policy at a specific time in the past, which I believe would entail having the entire descriptor history available anyway? Unrestricted means the relay currently allows exiting to all ports and IPs; Plausible, though there are hardly any relays permitting all ports. Maybe the right distinction is between relays that allow more than the common reduced exit policy, and those that allow no more than that? I'd simply call this Yes. All relays with the Exit flag would have this state. I do not think using Yes as a member of an N-way distinction (N2) is good design. Unlikely means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag; This is probably what I'd call Restricted or Limited. That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag. I hesitate to use Restricted or Limited because people might think it referred to the reduced exit policy. I wanted a single word which expressed technically an exit, but a client would have had to override the default circuit generation policy to have used it as an exit. I'm not happy with Unlikely but I can't think of anything better. If five states is too many, I'd drop the unrestricted/restricted distinction first (i.e. now/former/never/now but only with special circuit generation). zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On 2015-07-07 15:19:18 (+0100), Joshua Lee Tucker wrote: On 7/7/15, teor teor2...@gmail.com wrote: Organisation X experiences an attack on their website via an IP address Organisation X experiences a SSH login/password scan via an IP address We could split the Exit column in two (web ports, other ports) I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) Throwing this idea out there instead of keeping it to myself: what about modifying the form to ask also for the destination port? So the investigator would enter source IP, dest port and date. Can be somewhat confusing due to the source/dest mix, but the Exit column in this case would be pretty clear because it would refer only to the required port. -- David Serrano PGP: 1BCC1A1F280A01F9 signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running a relay in the Netherlands
Hi, A Raspberry Pi is actually a pretty nice device to run a relay on - it's pretty capable of running with a throughput of about 2-4mbps (which isn't bad, considering the clock speed). This might be a useful resource for you regarding Tor Raspberry Pi: https://lists.torproject.org/pipermail/tor-relays/2013-August/002384.html Regards, Joshua Lee Tucker @tuckerwales On Tue, Jul 7, 2015 at 7:20 PM, Tom van der Woerdt i...@tvdw.eu wrote: NL is perfectly safe, probably one of the safest countries on the planet for running Tor relays and exits. No need to worry about the legality of it much, as long as you appropriately keep your own traffic and Tor traffic separate. [IANAL!!!] Raspberry Pis aren't very fast, so it won't help the network much. Tom TorOps schreef op 07/07/15 om 20:12: Hello, I am about to move to the Netherlands and will, as part of the move, decommission the server my relay is currently running on. I'd like to be able to continue to help, though, so I wonder how the legal climate is for Tor relays and/or exit nodes in the Netherlands? On a related topic, how smart/efficient/possible is it to run a relay/exit on a Raspberry Pi? Thanks for any info. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/15 16:19, Joshua Lee Tucker wrote: On 7/7/15, teor teor2...@gmail.com wrote: Organisation X experiences an attack on their website via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 80. (This is a very likely scenario.) Organisation X experiences a SSH login/password scan via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 22. (This is perhaps a less likely scenario, but still well worth knowing about.) We could split the Exit column in two (web ports, other ports), but I'd prefer to provide the list of ports in a detail page, and let the analyst do their own triage. But if we only have one page, perhaps the split is worthwhile. I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the Exit: Yes clickable?) I think this improves not just readibility, but also keeps the main page as simple as possible. Well, I'd like to keep the main page as simple as possible, and I'd also prefer not to add a details page at all. The only output that users should see is a single page that they can print out and file to close a case (in favor of having more time for the 9 other open cases where ExoneraTor returned a negative result). Adding more details, even on a separate page, would only confuse users and not help much. Regarding documentation, it's already there on the same page, so that it will be printed out on the same page as lookup results. If we can phrase things better, please let's do that. But let's not add another page with explanations. Does that make sense? All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVm/nYAAoJEJD5dJfVqbCrY+AH/jPyecTbzvZcql5Txd5LHXA1 udkPpG6CtarFaLlh0MSdRQpHTd2gBjQs953hat0fDX9Tldi6XgeM5o/BVMsJxmn9 ZBb9qoB7gxEdOn3zh8COD5KHI19EW2ZtCH3RgK+p3qMgBisFLnFke3V3N3GdT9+V CK8N+ibLZLwnTIP6bWlFDmL4J4xJfXts/0nqRkglbyI7K7QSYkWtUwg5+hMO/IMv XfkCRlJEx/X/486xW2/o5IyIqIttjXFDShdCIRP1CSLN4jz0tQR0wZZhfdYUp2ND d+yxzMGQ+Rk8l42dh1pDdgU+dZ4K9URc31+DqJqa6rrRS7BXjfMIE5SId7ODqKk= =nlXx -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On Tue, Jul 7, 2015 at 4:50 PM, Geoff Down geoffd...@fastmail.net wrote: On Tue, Jul 7, 2015, at 07:47 PM, Zack Weinberg wrote: The thing is, putting myself in the shoes of someone trying to investigate an incident, I think the distinction among this relay has _never_ allowed any sort of exiting, this relay _does_ allow exiting right now, and this relay _did_ allow exiting at some point in the past but doesn't right now is critical. More important than whatever its current policy is wrt any given port or IP address. Re-importing the entire descriptor archive therefore strikes me as yeah, if that's what it takes, you should do that. If someone only has an IP address for an incident but no exact time, they barely have the basis for a complaint, let alone something more formal like a prosecution. What is the relevance of the relay's status at any time other than that of the incident? That's just the point I'm trying to make. If the relay's status at the (past) time of the incident was different from the relay's status at the (present) time of the investigation, that should be immediately obvious when you look at its page; it should not be a thing buried in a details screen. zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On Tue, Jul 7, 2015, at 07:47 PM, Zack Weinberg wrote: The thing is, putting myself in the shoes of someone trying to investigate an incident, I think the distinction among this relay has _never_ allowed any sort of exiting, this relay _does_ allow exiting right now, and this relay _did_ allow exiting at some point in the past but doesn't right now is critical. More important than whatever its current policy is wrt any given port or IP address. Re-importing the entire descriptor archive therefore strikes me as yeah, if that's what it takes, you should do that. If someone only has an IP address for an incident but no exact time, they barely have the basis for a complaint, let alone something more formal like a prosecution. What is the relevance of the relay's status at any time other than that of the incident? Moreover, when digging deeper, I would want to be able to know the exact exit policy at a specific time in the past, which I believe would entail having the entire descriptor history available anyway? Karsten has already linked to the entire descriptor history - having that link as a footnote to Exonerator should suffice. We *are* trying to simplify here. Respectfully, Geoff -- http://www.fastmail.com - Or how I learned to stop worrying and love email again ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On Tue, Jul 7, 2015, at 10:12 PM, Zack Weinberg wrote: On Tue, Jul 7, 2015 at 4:50 PM, Geoff Down geoffd...@fastmail.net wrote: If someone only has an IP address for an incident but no exact time, they barely have the basis for a complaint, let alone something more formal like a prosecution. What is the relevance of the relay's status at any time other than that of the incident? That's just the point I'm trying to make. If the relay's status at the (past) time of the incident was different from the relay's status at the (present) time of the investigation, that should be immediately obvious when you look at its page; it should not be a thing buried in a details screen. zw But Exonerator at present (and as proposed) requires a datestamp to produce any output at all. An investigator will input the datestamp of the incident. You still have not explained why you think an investigator will want easily to be able to access the status at some other time (other than pure curiosity) - any more than they would want to know e.g the user of a dynamic IP at some time other than that of an incident . Regards, Geoff -- http://www.fastmail.com - A fast, anti-spam email service. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Faravahar authority key expired
Hi, Sina (Faravahar's operator) has already been notified. In fact, he's getting notified each hour. :P https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/ Interestingly this made me realize DocTor has a bug. He got two week warnings about the cert expiration [1], but looks like the one week warnings weren't sent. Cheers! -Damian [1] https://lists.torproject.org/pipermail/tor-consensus-health/2015-June/005936.html On Tue, Jul 7, 2015 at 5:25 PM, starlight.201...@binnacle.cx wrote: The authority node Faravahar's key expired and it dropped off the consensus. Looks purposeful. Does anyone know why? Are authority public keys embedded in the relay code or learned? New release required for new key? Is this usual? Just curious. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Faravahar authority key expired
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt line 1138-1139: Authorities MUST generate a new signing key and corresponding certificate before the key expires. ??? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On 7 Jul 2015, at 23:23 , josh@tucker.wales wrote: For c), we'd just check if there's a p reject 1-65535 line or not. I think this is a perfectly OK way of doing this considering the use case. I agree, as long as we document what Exit means, and that there are edge cases where a relay could be used to exit to a small number of IPs, yet not have yes in the Exit column. (A false negative.) It may be worth documenting the false positives as well, that is, that there are many ways a packet could appear to be from an IP, yet not have come via Tor. Are we going to provide a list of exit ports, or does Exonerator not go into that level of detail? I'm also a little concerned by this, but I think the acceptable solution is: If a relay can exit on any port at all, it should have Exit: Yes, because from an investigatory point of view, it CAN act as an exit. However, I'm a little worried that this will lead people to think that the relay can act as a general exit to the web (80, 443). I think it's important that we specify the ports that existed in the exit policy for that relay at that point in time. What's your opinion on this Karsten, Tim? Consider two use cases: Organisation X experiences an attack on their website via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 80. (This is a very likely scenario.) Organisation X experiences a SSH login/password scan via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 22. (This is perhaps a less likely scenario, but still well worth knowing about.) We could split the Exit column in two (web ports, other ports), but I'd prefer to provide the list of ports in a detail page, and let the analyst do their own triage. But if we only have one page, perhaps the split is worthwhile. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
For c), we'd just check if there's a p reject 1-65535 line or not. I think this is a perfectly OK way of doing this considering the use case. I agree, as long as we document what Exit means, and that there are edge cases where a relay could be used to exit to a small number of IPs, yet not have yes in the Exit column. (A false negative.) It may be worth documenting the false positives as well, that is, that there are many ways a packet could appear to be from an IP, yet not have come via Tor. Are we going to provide a list of exit ports, or does Exonerator not go into that level of detail? I'm also a little concerned by this, but I think the acceptable solution is: If a relay can exit on any port at all, it should have Exit: Yes, because from an investigatory point of view, it CAN act as an exit. However, I'm a little worried that this will lead people to think that the relay can act as a general exit to the web (80, 443). I think it's important that we specify the ports that existed in the exit policy for that relay at that point in time. What's your opinion on this Karsten, Tim? Thanks, Joshua Lee Tucker @tuckerwales ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
I just want to chime in with my own consensus weight problem. FF1678164E0FFF1DACA45E3DCDE16E49FF1374BE has been running for over 70 days and still has a consensus of 20, I don't think it has ever changed since it was started. Looking at the consensus it is unmeasured=1 by every authority. Any ideas? -- Carlin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
Hey Josh, (The following is the only sentence that matters in this email) I was just curious about the statement that it takes a full 2 weeks for the new-relay cap to be aged-out. (The following is only background information in case you were curious, because it's been a hell of a long standing issue.) Oh, damn near all of them. If I recall correctly, it all started in March, and just got worse and worse, and by the time May rolled around I was just wasting money. However, I let about 5 exits slide on their renewal this month as all but 2 non-exit relays lost consensus completely, perpetually locked at 20. At one point, I was merrily pumping well over 200Mbit upload and download, over 400Mbit/s total over all the relays. Then one day, literally 1 day, I was not so merrily pumping ~100k/s total over all relays. A few months have now lapsed, and I've mostly given up. I now just try things and report in the hopes that it will jog someones memory or give some insight into what's going on. Doing everything I could, limited though it may be, to keep my fastest relay running, which at one point was doing 125Mbit each way, over a period of over a month I tried resetting the keys, updating the software, resetting the keys again, then finally upgrading to the 0.2.7.x alpha, resetting the keys again, and still nothing. Consensus weight = 20 == nothing. Then I got upset and complained, and starlight said I had to wait 2 weeks for the new-relay cap to be released, which I knew to be untrue as I had never experienced that before, because I have fond memories of times long ago when my relays worked. So for fun, I re-spun one of my working relays. Fresh install, new onion keys. It gained consensus after ~48 hours, instead of the 336 hours (2wks) starlight indicated. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On 7 Jul 2015, at 17:01 , josh@tucker.wales wrote: On 7 Jul 2015, at 07:48, Karsten Loesing kars...@torproject.org wrote: On 07/07/15 03:45, teor wrote: On 7 Jul 2015, at 09:46 , josh@tucker.wales wrote: From the perspective of someone investigating abuse, I think it's important that 'not an exit relay' means 'not capable of exiting on any port at all'. Ergo I think your option c) is the way to go. I also think this (c) is the best option. I agree that it's important to be able to determine, from an investigatory perspective, whether or not a relay was capable of exiting on any port. Okay, let's do c). And, if we are going to implement Exit as any port, it should also be *any* IP, not just an IPv4 /8 as in the Ext flag definition. For c), we'd just check if there's a p reject 1-65535 line or not. I think this is a perfectly OK way of doing this considering the use case. I agree, as long as we document what Exit means, and that there are edge cases where a relay could be used to exit to a small number of IPs, yet not have yes in the Exit column. (A false negative.) It may be worth documenting the false positives as well, that is, that there are many ways a packet could appear to be from an IP, yet not have come via Tor. Are we going to provide a list of exit ports, or does Exonerator not go into that level of detail? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Simplifying ExoneraTor
On Tue, Jul 7, 2015 at 6:12 PM, Geoff Down geoffd...@fastmail.net wrote: On Tue, Jul 7, 2015, at 10:12 PM, Zack Weinberg wrote: On Tue, Jul 7, 2015 at 4:50 PM, Geoff Down geoffd...@fastmail.net wrote: What is the relevance of the relay's status at any time other than that of the incident? That's just the point I'm trying to make. If the relay's status at the (past) time of the incident was different from the relay's status at the (present) time of the investigation, that should be immediately obvious when you look at its page; it should not be a thing buried in a details screen. But Exonerator at present (and as proposed) requires a datestamp to produce any output at all. An investigator will input the datestamp of the incident. I may have gotten this project mixed up with the one that is replacing Atlas/Onionoo, for which a dashboard showing the relay's status at the present time is the entry point. Still, I think that an investigator might indeed want to know whether the behavior of the relay is different now than it was at the time of the incident. For instance, there would be no point to complaining about exit traffic emanating from a relay that *was* an exit, but isn't anymore. And a relay that was only an exit for a brief window of time, that happens to coincide with an incident, should be suspected to have been hacked. zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
On 7 July 2015 at 09:04, Carlin Bingham c...@viennan.net wrote: I just want to chime in with my own consensus weight problem. FF1678164E0FFF1DACA45E3DCDE16E49FF1374BE has been running for over 70 days and still has a consensus of 20, I don't think it has ever changed since it was started. Looking at the consensus it is unmeasured=1 by every authority. Any ideas? It's actually only unmeasured by two: http://131.188.40.189/tor/status-vote/current/authority (gabelmoo) http://199.254.238.52/tor/status-vote/current/authority (longclaw) The other two have measured it: http://171.25.193.9:443/tor/status-vote/current/authority (maatuska, 330) http://128.31.0.34:9131/tor/status-vote/current/authority (moria, 325) -tom ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
