Re: [tor-dev] Tor HS keys password protection against impersonation attacks?
On 03/17/2012 02:52 AM, Fabio Pietrosanti (naif) wrote: > Hi, > thinking about Tor Hidden services, they are managed by using Hidden > Services client keys. > > The Tor HS keys are "private keys" that may require to be protected > because they represent also the "identity" of the Tor HS and if stolen, > it would be possible to carry on impersonation attack on connecting to > Tor HS. > Accepting connections on behalf of the real TorHS, with the goal to > steal passwords, provide fake data to clients, exploit them, etc. > > > The Tor HS keys are even more sensible than the X509v3, as it does provide: > - identity (similar to an internet domain name) > - routing (similar to an internet IP address) > - encryption (they provide e2e encryption, i don't know if there are > attacks on crypto if they get stolen) > > So owning a Tor HS key it's like owning a user domain name, acquiring > it's ip address and the x509v3 private key of his digital certificate > bound to his domain name. > > > As a protection schema it would be possible to create the Tor HS private > key encrypted with a passphrase, like it's possible to do for x509v3 PEM > certificates. > > That the passphrase to unlock the Tor HS key, could be provided via Tor > Control Port, so an external process (UI, scripts) could manage the > setup of the passphrase. > > That way even in case of seizure of the server running the Tor HS > it would not be possible to who seized the Tor HS Server to do actively > Impersonation attacks of the Tor HS. I think that's a great idea but also a UI nightmare; for servers, I think arm would need to support entering the key and for desktops, I think Vidalia is the obvious target. It would probably be good to have the key decryption tied together with something like scrypt[0] to make it really expensive to bruteforce. All the best, Jacob [0] http://www.tarsnap.com/scrypt.html ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor HS keys password protection against impersonation attacks?
On 3/17/12 11:02 AM, Jeroen Massar wrote: > On 2012-03-17 10:52 , Fabio Pietrosanti (naif) wrote: > [..] >> That way even in case of seizure of the server running the Tor HS >> it would not be possible to who seized the Tor HS Server to do actively >> Impersonation attacks of the Tor HS. > > If you want to protect these files, use proper full disk crypto, that > will solve all your data issues up to that level, eg somebody taking the > disk and trying to attack it from that perspective. Do note that not all > FDEs are actually truly secure... and it all depends on what one is > protecting against. > > If one can get access to a running installation so that they can > retrieve/access the file you store your keys in you have lost more than > just your identity, they can then also subvert the machine by changing > binaries on the system, inserting code into running processes etc etc or > just monitoring the thing, likely with the data that goes inside the tunnel. I mean, the password protection is not in any case to protect against such threat scenario. It's like the ability for Apache to be able to decrypt the RSA key of an X509v3 digital certificate at it's startup (or restart) by asking the administrator a password. So: - You are protected against computer seizure (that imply a shutdown) - You are not protected against intrusion Still making a little slightly difficult to retrieve it for the attacker requiring him to dump memory, dissect it, extract the key rather than just copying a file. Obviously this is not the scope of protection of adding a password protection of a Tor HS key, but against computer. -naif ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [PATCH] tor-exit-notice.html: shorten Cornell URLs
On Mar 17, 2012, at 8:37 AM, Christian Kujau wrote: > Hi, > > these ever so long law.cornell.edu URLs are now automatically redirecting > to a shorter version - let's use that in our tor-exit-notice.html as well. > > Christian. Hi, and thanks for the patch. I've filed a trac ticket[0] for this patch. Please follow up there. Thanks! Sebastian [0]: https://trac.torproject.org/projects/tor/ticket/5410 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor HS keys password protection against impersonation attacks?
On 2012-03-17 10:52 , Fabio Pietrosanti (naif) wrote: [..] > That way even in case of seizure of the server running the Tor HS > it would not be possible to who seized the Tor HS Server to do actively > Impersonation attacks of the Tor HS. If you want to protect these files, use proper full disk crypto, that will solve all your data issues up to that level, eg somebody taking the disk and trying to attack it from that perspective. Do note that not all FDEs are actually truly secure... and it all depends on what one is protecting against. If one can get access to a running installation so that they can retrieve/access the file you store your keys in you have lost more than just your identity, they can then also subvert the machine by changing binaries on the system, inserting code into running processes etc etc or just monitoring the thing, likely with the data that goes inside the tunnel. Another way to solve this is to do SSL/TLS/SSH inside the Tor connection and use that for authentication of client and server, which is probably the best thing you can do to protect your data, as the legs between your client and the Tor instance and the remote HS Tor instance and the app are not 'protected' by the layer that Tor provides oh and those legs are perfectly inspectable with tcpdump. Greets, Jeroen ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor HS keys password protection against impersonation attacks?
Hi, thinking about Tor Hidden services, they are managed by using Hidden Services client keys. The Tor HS keys are "private keys" that may require to be protected because they represent also the "identity" of the Tor HS and if stolen, it would be possible to carry on impersonation attack on connecting to Tor HS. Accepting connections on behalf of the real TorHS, with the goal to steal passwords, provide fake data to clients, exploit them, etc. The Tor HS keys are even more sensible than the X509v3, as it does provide: - identity (similar to an internet domain name) - routing (similar to an internet IP address) - encryption (they provide e2e encryption, i don't know if there are attacks on crypto if they get stolen) So owning a Tor HS key it's like owning a user domain name, acquiring it's ip address and the x509v3 private key of his digital certificate bound to his domain name. As a protection schema it would be possible to create the Tor HS private key encrypted with a passphrase, like it's possible to do for x509v3 PEM certificates. That the passphrase to unlock the Tor HS key, could be provided via Tor Control Port, so an external process (UI, scripts) could manage the setup of the passphrase. That way even in case of seizure of the server running the Tor HS it would not be possible to who seized the Tor HS Server to do actively Impersonation attacks of the Tor HS. -naif ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [PATCH] tor-exit-notice.html: shorten Cornell URLs
Hi, these ever so long law.cornell.edu URLs are now automatically redirecting to a shorter version - let's use that in our tor-exit-notice.html as well. Christian. diff --git a/contrib/tor-exit-notice.html b/contrib/tor-exit-notice.html index de3be17..8cf5c29 100644 --- a/contrib/tor-exit-notice.html +++ b/contrib/tor-exit-notice.html @@ -87,7 +87,7 @@ seize this router will accomplish nothing. Furthermore, this machine also serves as a carrier of email, which means that its contents are further protected under the ECPA. http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2707000-.html";>18 +href="http://www.law.cornell.edu/uscode/text/18/2707";>18 USC 2707 explicitly allows for civil remedies ($1000/account plus legal fees) in the event of a seizure executed without good faith or probable cause (it @@ -105,7 +105,7 @@ used to violate the DMCA, please be aware that this machine does not host or contain any illegal content. Also be aware that network infrastructure maintainers are not liable for the type of content that passes over their equipment, in accordance with http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0512000-.html";>DMCA +href="http://www.law.cornell.edu/uscode/text/17/512";>DMCA "safe harbor" provisions. In other words, you will have just as much luck sending a takedown notice to the Internet backbone providers. Please consult https://www.torproject.org/eff/tor-dmca-response";>EFF's prepared -- BOFH excuse #151: Some one needed the powerstrip, so they pulled the switch plug. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
