Suggestion to make Tor usage more disguised
Hi, I am writing this message to make a simple suggestion that could help driving more adoption to Tor by making using tor less obvious for a network administrator. This suggestion tries to address the user case of a common Tor usage, in which the user is not being attacked nor mitm, he is just using tor in his work for example. The network admin of the office is not searching actively for Tor users in his network but one day he log-in in the router panel and he sees this: - Current conexions - WORKSTATION-98 38.29.00.2 [torproxy10.teaxxcu.com] Is obvious that is using tor. The network admin was not looking for Tor usage in his network but it saw this without looking for it. Now this worker can be in serious trouble for using Tor. So my suggestion is to set-up a custom hostname an a Tor-explaining html index ONLY in TOR EXIT nodes. They are the only nodes that can get in trouble and its helpful to advertise that they are tor nodes. ENTRY GUARD nodes should not advertise neither in the hostname nor in a HTML-index-page that they are Tor nodes. This way the network admin would only see an IP and a common hostname, that is a normal behaviour for a HTTPS request. So, having said that *I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page*. That could help a lot of Tor users to not draw unwanted attention. Obviously a network-admin can get a list of Tor relays and check if you are connecting to one of them but most of network-admins just take a look at his router info page without further investigation. Thanks for your time. TL;DR: I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page.
Why would someone get into trouble for using Tor? Furthermore, have you have heard of pluggable transports for Tor? On Sat, Jan 16, 2016 at 1:31 PM, Raúl Martínez <rme@rme.li> wrote:
Hi, I am writing this message to make a simple suggestion that could help driving more adoption to Tor by making using tor less obvious for a network administrator.
This suggestion tries to address the user case of a common Tor usage, in which the user is not being attacked nor mitm, he is just using tor in his work for example.
The network admin of the office is not searching actively for Tor users in his network but one day he log-in in the router panel and he sees this:
- Current conexions -
WORKSTATION-98 38.29.00.2 [torproxy10.teaxxcu.com]
Is obvious that is using tor. The network admin was not looking for Tor usage in his network but it saw this without looking for it. Now this worker can be in serious trouble for using Tor.
So my suggestion is to set-up a custom hostname an a Tor-explaining html index ONLY in TOR EXIT nodes. They are the only nodes that can get in trouble and its helpful to advertise that they are tor nodes.
ENTRY GUARD nodes should not advertise neither in the hostname nor in a HTML-index-page that they are Tor nodes. This way the network admin would only see an IP and a common hostname, that is a normal behaviour for a HTTPS request.
So, having said that I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page. That could help a lot of Tor users to not draw unwanted attention.
Obviously a network-admin can get a list of Tor relays and check if you are connecting to one of them but most of network-admins just take a look at his router info page without further investigation.
Thanks for your time.
TL;DR: I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Most of people are uneducated about what is Tor and what is used for. That can lead to trouble. I have used pluggable transports but they are too slow (50KB/s) 2016-01-16 15:00 GMT+01:00 David Stainton <dstainton415@gmail.com>:
Why would someone get into trouble for using Tor? Furthermore, have you have heard of pluggable transports for Tor?
On Sat, Jan 16, 2016 at 1:31 PM, Raúl Martínez <rme@rme.li> wrote:
Hi, I am writing this message to make a simple suggestion that could help driving more adoption to Tor by making using tor less obvious for a network administrator.
This suggestion tries to address the user case of a common Tor usage, in which the user is not being attacked nor mitm, he is just using tor in his work for example.
The network admin of the office is not searching actively for Tor users in his network but one day he log-in in the router panel and he sees this:
- Current conexions -
WORKSTATION-98 38.29.00.2 [torproxy10.teaxxcu.com]
Is obvious that is using tor. The network admin was not looking for Tor usage in his network but it saw this without looking for it. Now this worker can be in serious trouble for using Tor.
So my suggestion is to set-up a custom hostname an a Tor-explaining html index ONLY in TOR EXIT nodes. They are the only nodes that can get in trouble and its helpful to advertise that they are tor nodes.
ENTRY GUARD nodes should not advertise neither in the hostname nor in a HTML-index-page that they are Tor nodes. This way the network admin would only see an IP and a common hostname, that is a normal behaviour for a HTTPS request.
So, having said that I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page. That could help a lot of Tor users to not draw unwanted attention.
Obviously a network-admin can get a list of Tor relays and check if you are connecting to one of them but most of network-admins just take a look at his router info page without further investigation.
Thanks for your time.
TL;DR: I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page.
_______________________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Well, you are forgetting that all TOR relays are using an IP, and these IP's are stored in a public list. So you do not have to check your logs as a network admin, you just have to download the list every 24H and wright and a simple script (and make use of iptables on a Unix Server) to deny the initiative connection to a TOR entry node, simple as that. It is more an attitude of the network setup and corporate understanding towards TOR. Best regards, elrippo Am 16. Jänner 2016 15:02:18 MEZ, schrieb "Raúl Martínez" <rme@rme.li>:
Most of people are uneducated about what is Tor and what is used for. That can lead to trouble.
I have used pluggable transports but they are too slow (50KB/s)
2016-01-16 15:00 GMT+01:00 David Stainton <dstainton415@gmail.com>:
Why would someone get into trouble for using Tor? Furthermore, have you have heard of pluggable transports for Tor?
On Sat, Jan 16, 2016 at 1:31 PM, Raúl Martínez <rme@rme.li> wrote:
Hi, I am writing this message to make a simple suggestion that could help driving more adoption to Tor by making using tor less obvious for a network administrator.
This suggestion tries to address the user case of a common Tor usage, in which the user is not being attacked nor mitm, he is just using tor in his work for example.
The network admin of the office is not searching actively for Tor users in his network but one day he log-in in the router panel and he sees this:
- Current conexions -
WORKSTATION-98 38.29.00.2 [torproxy10.teaxxcu.com]
Is obvious that is using tor. The network admin was not looking for Tor usage in his network but it saw this without looking for it. Now this worker can be in serious trouble for using Tor.
So my suggestion is to set-up a custom hostname an a Tor-explaining html index ONLY in TOR EXIT nodes. They are the only nodes that can get in trouble and its helpful to advertise that they are tor nodes.
ENTRY GUARD nodes should not advertise neither in the hostname nor in a HTML-index-page that they are Tor nodes. This way the network admin would only see an IP and a common hostname, that is a normal behaviour for a HTTPS request.
So, having said that I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page. That could help a lot of Tor users to not draw unwanted attention.
Obviously a network-admin can get a list of Tor relays and check if you are connecting to one of them but most of network-admins just take a look at his router info page without further investigation.
Thanks for your time.
TL;DR: I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page.
_______________________________________________ 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 mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQJcBAEBCgBGBQJWmlGuPxxlbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0 ZWQpIDxlbHJpcHBvQGVscmlwcG9pc2xhbmQubmV0PgAKCRAkQ93r2VDR671hD/9D h+AZRwBkJB/TC13zjWjVe6WxqAWfwGtZRofFVlb6mr2t8wJdM5MS6BzpTrPjxFk/ 2gSm8HY0OmZVIKoj2FM92BuoBk0AVYImVdp/Vg5z9+OPleZPzyJebYhDfPGn7aRQ tAPGWIbpP6KCKmqekI+IhhbXBozcWMUtnCjnB6snOs6brHwKilEG6lLke/2f4Vv9 GLqOw1Wx7t7bPRTyd2G0ZvCuLm4TdF4plKINs4NZ5z7rb7TnugoW/FxHJb72dI7z F5B1HueQqYsZgiQoRi8Gg24oq8Sx2VY8M9hOxcaSuSJYTgNj1EuggWDyghndJz3i yG94SwNZr9A4LtVZghdVszsdHyxgm9kUIMFiCv6RO8IA3uhbuHs3rd8W3hmRKIrC zBehvON9M+IfAFHzL5AUh95KftZNQd4dJAQcsqsVSbSH2bDu6I9LQw16e0ccmyyc 0l3KrpTrrJqV666m8FH9ZR3VIdhLpFPcjMSsze0h/ZEOz6T/xU3qRVUDvSfG1Tjw 7MWzoQG4Q3WDp6PLJGFUDGuIBWuy+VAMnavyBfq3ZIM6RH7gfWvYQTG86MNEhlB6 lns3uqVvEq0lRFKkCBlQh6QboCSTFxOnKzkcN4yYeTgGpQHBHEJGBH3ti2Oqj9O4 n41W5TzFRkuAEv/tRvCeop6s5NoNeeOiG0qL6ZfjVg== =5K7d -----END PGP SIGNATURE-----
On 01/16/2016 05:20 AM, Elrippo wrote:
Well, you are forgetting that all TOR relays are using an IP, and these IP's are stored in a public list. So you do not have to check your logs as a network admin, you just have to download the list every 24H and wright and a simple script (and make use of iptables on a Unix Server) to deny the initiative connection to a TOR entry node, simple as that. It is more an attitude of the network setup and corporate understanding towards TOR.
Exactly. Furthermore, Tor clients make connections to Tor directory authorities in order to fetch the consensus documents, in the event that the client doesn't have the necessary network information. The IP addresses of the dirauths are hard-coded into Tor clients. System administrators can simply look for connections to these dirauths to discover new Tor clients. Existing clients can fetch new consensus data from existing Tor relays. There are several ways to detect if someone is using Tor, and most of those methods can be thwarted by using a bridge with a pluggable transport, like obfs4. Tor relays should have reverse DNS and a nice landing page, possibly even one they wrote themselves. It just makes the whole network more friendly for the rest of the Internet. It's "Tor", not "TOR". -- Jesse V
On Sat, 16 Jan 2016 15:02:18 +0100 Raúl Martínez <rme@rme.li> wrote:
Most of people are uneducated about what is Tor and what is used for. That can lead to trouble.
I have used pluggable transports but they are too slow (50KB/s)
So run your own fast bridge? It's relatively easy, and I assume that's the main reason why it's slow since all of the non-meek transports are relatively lightweight. Anyway, I don't see the point of this. People that care about masking Tor use should use Bridges with pluggable transports and expect to take a performance hit for the extra obfuscation. People that do not use such things should assume that it is trivial to figure out if they are using Tor. It's worth noting that the obfuscation isn't perfect and people should assume that it's possible to figure out if they're using Tor if they are being actively targeted as well, but the various transports do raise the bar by varying amounts. Apart from the cases involving Bridges and PTs, explicitly hiding Tor use is not in Tor's threat model either (and probably can't be without a major re-design of how the network works, which is unlikely to happen). Regards, -- Yawning Angel
participants (5)
-
David Stainton -
Elrippo -
Jesse V -
Raúl Martínez -
Yawning Angel