Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser
Hi all, The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages. Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted. In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP. I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports. There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits. I'd like to hear any and all feedback, suggestions or criticism of this proposal. Kind Regards, Donncha [1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-no...
It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it. How would you communicate this for .onion links or bitcoin text? These fields are static text and would not be interacted with in the same way as a password field. A link could indeed be clicked - so that's a hook for UX... A bitcoin address would probably be highlighted for copying so that's another hook... But what should it do? -tom On 28 March 2017 at 10:31, Donncha O'Cearbhaill <donncha@donncha.is> wrote:
Hi all,
The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages.
Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted.
In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP.
I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports.
There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits.
I'd like to hear any and all feedback, suggestions or criticism of this proposal.
Kind Regards, Donncha
[1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-no...
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Tom Ritter:
It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it.
Depending on how "intrusive" you want to be you could hide the bitcoin/onion addresses with an overlay similar how NoScript (used to?) hide flash content and make it visible after clicking on it and acknowledging a warning.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Tom Ritter:
It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it.
How would you communicate this for .onion links or bitcoin text? These fields are static text and would not be interacted with in the same way as a password field.
A link could indeed be clicked - so that's a hook for UX... A bitcoin address would probably be highlighted for copying so that's another hook... But what should it do?
-tom
Bitcoin has a URL scheme that is increasingly used, so the UI mechanism could be the same as for .onion links. However, for both .onion links and for bitcoin: links, there's a risk that the website will simply ask the user to manually copy the .onion URL or Bitcoin address -- I doubt that most users will recognize this as an attempt to evade detection. So any UI mechanism will probably need to recognize any string that looks like a .onion URL or a Bitcoin address, even if they're not links. Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4GYXAAoJELPy0WV4bWVwz60P/2cOYAiRLaTx5wjy+pyqQCUn N4+mZv9+YmW7OiqJKEylywyTcdhLeAAVlQPafawvN+9K1EObqiF5GtHdHOaOE+EJ 43iUbpRzMsZOlPGspP6YUrJw6zjLev021qMyyZv1r0EMPgi3d+jbfvrgPHcgw7AD aA5hDy1bVAoLovwIWL1w/62MK+gsMHroE3oDOYNI3i6uLJHVtsdTdCVit8rwshey BKOBY0xgh2pvMDGwB4hdK4K0GHAUcef6ErDXhrpKFPDjuJnLi6g5i3oPbgaI9YuR ONIb3eK2K81oblpEmRxQgEJHby7sMKfqRqpsabcTDn6WUlN0z91JTqRtJWvyZYYC rabdeLrEqlOA7IGG7S4w3hUlWi7Ql/iwUM3/9b3SNztwcWrC/VmCjDPpiZ/aJpI9 QP5/Y2SC5TYQ0+DRLe3HynI/zc5WHpRW6TU570BnJc+V5Y1uf8GH2g6WMNRegTKm ++cCx2SLGn2CaqHCubos7FVtx2Yi443vlL9kNE1bgsZIZBa8PGx6m3MjpZ8K9NLt e1HkTbCGQaB09pVvMMRiazqc6r3sJcvogcmdct21P6ElyEW4D9L+grWqESNSM+gm mlAIrMsfYeZnpl7vgmKVQ2TqirCxvLMA0movYjhISkyKIsPTSHc8Qoc00WHt2MvX lus5voupc4tmsDtB/8z0 =L3v2 -----END PGP SIGNATURE-----
On 28 Mar (11:19:45), Tom Ritter wrote:
It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it.
How would you communicate this for .onion links or bitcoin text? These fields are static text and would not be interacted with in the same way as a password field.
A link could indeed be clicked - so that's a hook for UX... A bitcoin address would probably be highlighted for copying so that's another hook... But what should it do?
I do believe this could be an important safety improvement even if not perfect. I'm unsure how Tor Browser team operates for this kind of features but Tom's request here is a logical start that is try to come up with a proposal of what the UI would look like and then we can go in ticket land I guess... I'm no UI expert nor even good at judging them but I have a feeling we should go towards something "intrusive" in order to make SURE users notice the potential danger and actually gets annoyed by it to the point they want to *avoid* HTTP sites in order to not deal with that. nusenu idea of going like NoScript does is appealing to me. Covering the .onion/bitcoin address on HTTP clearnet site and then you have to click on it to see it with a big ass warning saying "Make sure you understand that this address could have been changed in transit" kind of thing (with very low technical terms ofc). That way, users will clearly see that getting an address on an HTTP site is _harmful_ over Tor and that should be what we convey to the users using that annoying mechanism. Might sound kind of radical here but safety first! I really don't see a compromise nor an argument for "usability" here if we believe that it's basically dangerous. Cheers! David
-tom
On 28 March 2017 at 10:31, Donncha O'Cearbhaill <donncha@donncha.is> wrote:
Hi all,
The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages.
Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted.
In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP.
I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports.
There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits.
I'd like to hear any and all feedback, suggestions or criticism of this proposal.
Kind Regards, Donncha
[1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-no...
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- h4Neylkd5WBoXhbKp3jB2fYUAy2NrRar7O7oyNaGg4M=
Tom Ritter:
It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it.
How would you communicate this for .onion links or bitcoin text? These fields are static text and would not be interacted with in the same way as a password field.
A link could indeed be clicked - so that's a hook for UX... A bitcoin address would probably be highlighted for copying so that's another hook... But what should it do?
Thank you all for the suggestions in this thread. I agree that we need to tie down a preliminary UI. I'm seeing two key hooks that we could use: * Detecting navigation from an insecure page to an onion URL or bitcoin:// address. * Reading and alerting to Bitcoin or onion addresses in the clipboard buffer. I've been working on a proof-of-concept extension which implements both of these hooks. The "clipboardRead" permission is needed to read the contents of the clipboard from a Firefox extension. This was implemented in Firefox 54 (2017-02-13) in Mozilla bug #1312260 [1]. Unfortunately it will be quite some time before Firefox 54 is included in an ESR release. The Mozilla patch for this permission is < 100 lines. Is this a feature that the TBB team might consider back-porting to Tor Browser? I agree with David, this UI should be as intrusive as possible to prevent users from shooting themselves in the foot. IMO navigation to onion URLs from HTTP should be completely blocked. I also think that we should wipe the users clipboard buffer if we detect a valid Bitcoin address in it. The UI could suggest that a user manually retypes the Bitcoin or onion address if they are certain that it is correct. I hope this type of intrusive warning will reduce risky behaviour and encourage any Tor related web services to move to TLS only. I'll try to report back with a demo for testing next week. Please reply if you have any comments or suggestions. Regards, Donncha [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1312260
On 6 April 2017 at 07:53, Donncha O'Cearbhaill <donncha@donncha.is> wrote:
Tom Ritter:
It seems reasonable but my first question is the UI. Do you have a proposal? The password field UI works, in my opinion, because it shows up when the password field is focused on. Assuming one uses the mouse to click on it (and doesn't tab to it from the username) - they see it.
How would you communicate this for .onion links or bitcoin text? These fields are static text and would not be interacted with in the same way as a password field.
A link could indeed be clicked - so that's a hook for UX... A bitcoin address would probably be highlighted for copying so that's another hook... But what should it do?
Thank you all for the suggestions in this thread. I agree that we need to tie down a preliminary UI. I'm seeing two key hooks that we could use:
* Detecting navigation from an insecure page to an onion URL or bitcoin:// address. * Reading and alerting to Bitcoin or onion addresses in the clipboard buffer.
I've been working on a proof-of-concept extension which implements both of these hooks.
The "clipboardRead" permission is needed to read the contents of the clipboard from a Firefox extension. This was implemented in Firefox 54 (2017-02-13) in Mozilla bug #1312260 [1]. Unfortunately it will be quite some time before Firefox 54 is included in an ESR release. The Mozilla patch for this permission is < 100 lines. Is this a feature that the TBB team might consider back-porting to Tor Browser?
I agree with David, this UI should be as intrusive as possible to prevent users from shooting themselves in the foot. IMO navigation to onion URLs from HTTP should be completely blocked. I also think that we should wipe the users clipboard buffer if we detect a valid Bitcoin address in it.
The UI could suggest that a user manually retypes the Bitcoin or onion address if they are certain that it is correct. I hope this type of intrusive warning will reduce risky behaviour and encourage any Tor related web services to move to TLS only.
[no hats] Please no. Please give any sort of intrusive whatever I have to click through but do not make me manually retype a bitcoin or onion address. This is a usability nightmare, I would prefer you completely hide the value entirely, so the user thinks it's a problem with the website rather than hating Tor Browser. Here's another idea besides click-through banners: using the extension, create some sort of scratchpad that auto-populates the bitcoin/onion address (and the user's Exit Node). Then reload the page in a new circuit. Detect or prompt the user to compare them. If they're the same, say "Phew, okay everything seems to be okay" and if they're not, say "Jinkies! Would you consider pasting this information in a bug report so we can investigate?" Caveat: I don't know how common it is for HTTP websites with bitcoin addresses to auto-generate payment addresses for privacy. -tom
Although I don't have a concrete suggestion for the UI, I think this is a good idea. Similarly, it would be good to give people a clear way to tell us what exit node they were using at the time (by fingerprint). Maybe this could look like a "report possibly bad exit node behavior" option in the dropdown. Ideally with shorter text ;) and a *very clear* indication of what data will be sent (e.g. maybe you're fine with reporting the URL, but probably not).
On Tue, Mar 28, 2017 at 11:31 AM, Donncha O'Cearbhaill <donncha@donncha.is> wrote:
The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages.
Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which are being targeted.
In Firefox 51, Mozilla started to highlight HTTP pages containing password form fields as insecure [1]. This UI clearly and directly highlights the risk involved in communicating sensitive data over HTTP.
I'd like to investigate ways that we can extend a similar UI to Tor Browser which highlight Bitcoin and onion addressed served over HTTP. I understand that implementing this type of Bitcoin and onion address detection would be less reliable than Firefox's password field detection. However even if unreliable it could increase safety and increase user awareness about the risks of non-secure transports.
There is certainly significant design work that needs to be done to implement this feature. For example, .onion origins need be treated as secure, but only if they don't included resources from non-secure origins. We would also need to make the onion/bitcoin address detection reliable against active obfuscation attempts by malicious exits.
https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-no...
Search OnionGatherer on this list for ui stuff.
participants (7)
-
David Goulet -
Donncha O'Cearbhaill -
grarpamp -
Jeremy Rand -
meejah -
nusenu -
Tom Ritter