The first would be to make it easy, or maybe even automatic, for CloudFlare customers to create a .onion version of their sites. These .onion sites are only accessible via the Tor network and therefore less likely to be targeted by automated attacks. This was Facebook’s solution when faced with the same problem. We think it’s elegant.
I don’t understand this logic. Paragraphs earlier they just stated how such a high percentage of Tor traffic is automated attacks, so how does moving the site into the network make it less likely to be targeted by attacks? If anything it makes it worse because now all traffic to the hidden service looks like it’s coming from 127.0.0.1, making it impossible to differentiate between users unless they are logged in. At least with exit nodes hitting your site you can ban an individual IP until the malicious traffic gets a new path and comes out a different IP.
I actually had this problem with Lobsters where some bots were spidering the site very aggressively through its .onion address and I couldn’t do much to block them without cutting off everyone legitimately using it.
As odd as it sounds, I think captchas could actually benefit Tor if implemented in the network itself somehow. Before an entry node takes traffic from an IP, and probably again after detecting a large amount of automated traffic, it could require validation of a human and only then accept its traffic. This would lead to less garbage on the Tor network, putting less strain on the relays, and the exit node IPs would have a more positive reputation leading sites like CloudFlare to stop treating them as hostile (and other sites from outright banning them).
As odd as it sounds, I think captchas could actually benefit Tor if implemented in the network itself somehow. Before an entry node takes traffic from an IP, and probably again after detecting a large amount of automated traffic, it could require validation of a human and only then accept its traffic.
This seems too application-specific (web-browser-centric, in this case) to be feasible, I’d think – or at least the UI challenges it would pose for client-side software would be tricky. With a plain HTTP request from a browser, you could interpose a CAPTCHA page or what-have-you before passing the request on, but if it’s even so much as HTTPS you don’t have any way of signaling the verification request back to the client application without triggering TLS errors. And if it’s some other protocol/application entirely (SSH, say), then you don’t even really have an available UI mechanism for it, even ignoring all the cryptographic roadblocks. Given that, it seems like the mechanism for implementing this would have to be outside the actual TCP stream seen by the client application and instead purely between the Tor instances themselves…so would the local Tor daemon proxying your traffic have to be (say) X11-aware, so it could pop up a dialog box asking for whatever input it needs? Any at-all obvious way I can see of pulling this off looks really messy.
(There’s also the fact that, while I’d certainly concede that in the case of Tor the odds are probably pretty high, automated traffic isn’t necessarily malicious.)
Back in school we used AFS (shared file system) with Kerberos v4. V4 tickets expire after 24 hours, but that wouldn’t log you out. It just meant all your filesystem privileges were revoked. cp and vi knew nothing about Kerberos, just that read/write/open wouldn’t work.
To tie this back in, tor could require some kind of token that expires occasionally in order to pass traffic. I’m fuzzy on how exactly it would, but I believe it’s possible to build a kind of anonymous trust token system.
Hmm, good comparison (and familiar, since my university department also runs AFS/Kerberos, though I don’t know off the top of my head how Kerberos v4 and v5 differ).
So, with that model, because cp and vi and so forth aren’t aware of it, the only notification you get when your ticket expires is that suddenly everything starts throwing EACCES all over the place and you get a bunch of relatively non-specific error messages. While the UI isn’t exactly great, once you’re accustomed to how AFS/Kerberos works, you’ll figure out the root cause pretty quickly – but if you’re not so familiar with the system the poor UI could cause the failure to remain completely mysterious (especially given the additional confusion between AFS ACLs and standard unix mode bits, though that’s of course completely tangential).
The obvious extension of that model to the Tor scenario would be that suddenly your connect() calls just start failing, but to your Tor-oblivious client application there’s no real way of distinguishing that from any of the myriad other potential causes of connection failure, so it’s left to the user to decipher the underlying cause – granted, that’s often the case anyway with network errors, but in this case it’s something the user can (or has to, really) address on their own, rather than calling their ISP’s help desk or just assuming the site’s down and giving up.
I think the article undervalues the “track users” approach; in particular, an explicit opt-in tracking option would be useful for two kinds of users:
People who are more worried about being tracked across sessions than within a session
People who run tor exit nodes but aren’t using tor for the particular access
I happen to be a member of the second group, and I find the captchas bearable, but annoying. I understand why they’re there and why opt-in tracking isn’t their first approach (after all, it’s building infrastructure that is potentially corruptible for minimal gain), though.
As a side note, I’ve been having troubles where only the full javascript version of recaptcha works (solving the reduced capability one doesn’t let me in to the site), and where I need to refresh multiple times before getting the full javascript one. Has anyone else experienced anything similar?
I don’t run an exit node (or tor) but I think if I did, it would be dedicated to that purpose. Mixing the streams is asking for all sorts of guilty by association trouble.
I don’t understand this logic. Paragraphs earlier they just stated how such a high percentage of Tor traffic is automated attacks, so how does moving the site into the network make it less likely to be targeted by attacks? If anything it makes it worse because now all traffic to the hidden service looks like it’s coming from 127.0.0.1, making it impossible to differentiate between users unless they are logged in. At least with exit nodes hitting your site you can ban an individual IP until the malicious traffic gets a new path and comes out a different IP.
I actually had this problem with Lobsters where some bots were spidering the site very aggressively through its
.onionaddress and I couldn’t do much to block them without cutting off everyone legitimately using it.As odd as it sounds, I think captchas could actually benefit Tor if implemented in the network itself somehow. Before an entry node takes traffic from an IP, and probably again after detecting a large amount of automated traffic, it could require validation of a human and only then accept its traffic. This would lead to less garbage on the Tor network, putting less strain on the relays, and the exit node IPs would have a more positive reputation leading sites like CloudFlare to stop treating them as hostile (and other sites from outright banning them).
This seems too application-specific (web-browser-centric, in this case) to be feasible, I’d think – or at least the UI challenges it would pose for client-side software would be tricky. With a plain HTTP request from a browser, you could interpose a CAPTCHA page or what-have-you before passing the request on, but if it’s even so much as HTTPS you don’t have any way of signaling the verification request back to the client application without triggering TLS errors. And if it’s some other protocol/application entirely (SSH, say), then you don’t even really have an available UI mechanism for it, even ignoring all the cryptographic roadblocks. Given that, it seems like the mechanism for implementing this would have to be outside the actual TCP stream seen by the client application and instead purely between the Tor instances themselves…so would the local Tor daemon proxying your traffic have to be (say) X11-aware, so it could pop up a dialog box asking for whatever input it needs? Any at-all obvious way I can see of pulling this off looks really messy.
(There’s also the fact that, while I’d certainly concede that in the case of Tor the odds are probably pretty high, automated traffic isn’t necessarily malicious.)
Back in school we used AFS (shared file system) with Kerberos v4. V4 tickets expire after 24 hours, but that wouldn’t log you out. It just meant all your filesystem privileges were revoked. cp and vi knew nothing about Kerberos, just that read/write/open wouldn’t work.
To tie this back in, tor could require some kind of token that expires occasionally in order to pass traffic. I’m fuzzy on how exactly it would, but I believe it’s possible to build a kind of anonymous trust token system.
Hmm, good comparison (and familiar, since my university department also runs AFS/Kerberos, though I don’t know off the top of my head how Kerberos v4 and v5 differ).
So, with that model, because
cpandviand so forth aren’t aware of it, the only notification you get when your ticket expires is that suddenly everything starts throwing EACCES all over the place and you get a bunch of relatively non-specific error messages. While the UI isn’t exactly great, once you’re accustomed to how AFS/Kerberos works, you’ll figure out the root cause pretty quickly – but if you’re not so familiar with the system the poor UI could cause the failure to remain completely mysterious (especially given the additional confusion between AFS ACLs and standard unix mode bits, though that’s of course completely tangential).The obvious extension of that model to the Tor scenario would be that suddenly your
connect()calls just start failing, but to your Tor-oblivious client application there’s no real way of distinguishing that from any of the myriad other potential causes of connection failure, so it’s left to the user to decipher the underlying cause – granted, that’s often the case anyway with network errors, but in this case it’s something the user can (or has to, really) address on their own, rather than calling their ISP’s help desk or just assuming the site’s down and giving up.I think the article undervalues the “track users” approach; in particular, an explicit opt-in tracking option would be useful for two kinds of users:
I happen to be a member of the second group, and I find the captchas bearable, but annoying. I understand why they’re there and why opt-in tracking isn’t their first approach (after all, it’s building infrastructure that is potentially corruptible for minimal gain), though.
As a side note, I’ve been having troubles where only the full javascript version of recaptcha works (solving the reduced capability one doesn’t let me in to the site), and where I need to refresh multiple times before getting the full javascript one. Has anyone else experienced anything similar?
I don’t run an exit node (or tor) but I think if I did, it would be dedicated to that purpose. Mixing the streams is asking for all sorts of guilty by association trouble.