[EMAIL PROTECTED]: Re: SSL fro hidden services]
- Forwarded message from loki tiwaz [EMAIL PROTECTED] - From: loki tiwaz [EMAIL PROTECTED] Date: Thu, 20 Oct 2005 22:57:24 + To: [EMAIL PROTECTED] Subject: Re: SSL fro hidden services Reply-To: [EMAIL PROTECTED] hi, That said, the certificate naming scheme may be way off, since there's no concept of a valid certificate (I doubt verisign will want to sign one for 786237261871621.onion :) i am considering running an onion-based CA which could be used... i simply need to make a script which allows a user to sign a certificate signing request and produce a signed server key. the server key only needs to have its onion address as content, nothing more is required, and a link to import the CA key into the browser so that it can be trusted automatically by the browser. However, assuming the user installs your self-signed cert, it *should* work the same unless there's something I'm missing.) Of course, you're really just protecting content from being sniffed between the user and the entry node (usually, the same machine, but not always), and the exit node and the hidden service (presumably, you control both). This is my understanding of it -- if someone has a better one please step on me without hesitation :) yes, this is the case, and it is a valid reason to use ssl. in my opinion, since tor already uses multi-layered encryption anyway, one more layer at the core is not going to create that much of an extra load on the server, and it means that there is no way the traffic can be sniffed at any point - for example a trojan could sniff localhost traffic. also, using onion routing defeats the one way in which SSL can be attacked, by man-in-the-middle intermediaries on the network pathway, which of course cannot be known within the tor network. Also, it should be noted that tor exit nodes could potentially be modified to become men-in-the-middle, although this would not be possible without compromising the key of the server being contacted - another aspect of the advantage of using tor. onion addresses are impossible to remember though - which brings me to another idea - of a name resolution system within the tor network so simpler names can be used. this would require a second directory system, i don't know if it is practical or not, but i thought i should put the idea out there because i2p has name resolution systems, and benig able to type in oniondomainname.onion rather than u15syoa125au.onion would be nice. it would increase the rate of take-up of hidden services, both use and hosting. onion domains could be propagated throughout the onion network, so that every tor node can translate a name into an onion hashed address. there would also need to be a system to prevent name spoofing... how to ensure there is no collisions of names would be tricky - very likely it would require a set of authoritative name servers similar to how there is authoritative onion directory servers. ah dammit, i am always ideas ideas ideas and so little action... prioritising goals is something i find difficult... i think i should make this idea a priority, however, which means joining the dev effort and, at the very least, defining a protocol, if not implementing code... well, anyway, i have put the idea out now. i think that the idea is a good one. tor is coming of age now and ideally tor should aim to provide all of the features one would expect in an internet layer, but with the guiding principle of protecting anonymity always ascendant. an onion-based CA would work much better if the name-resolution system were in place, so i think it should be the priority. loki _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: SSL fro hidden services]
- Forwarded message from Dan Mahoney, System Admin [EMAIL PROTECTED] - From: Dan Mahoney, System Admin [EMAIL PROTECTED] Date: Thu, 20 Oct 2005 19:18:08 -0400 (EDT) To: [EMAIL PROTECTED] Subject: Re: SSL fro hidden services Reply-To: [EMAIL PROTECTED] On Thu, 20 Oct 2005, loki tiwaz wrote: hi, That said, the certificate naming scheme may be way off, since there's no concept of a valid certificate (I doubt verisign will want to sign one for 786237261871621.onion :) i am considering running an onion-based CA which could be used... i simply need to make a script which allows a user to sign a certificate signing request and produce a signed server key. the server key only needs to have its onion address as content, nothing more is required, and a link to import the CA key into the browser so that it can be trusted automatically by the browser. However, assuming the user installs your self-signed cert, it *should* work the same unless there's something I'm missing.) Of course, you're really just protecting content from being sniffed between the user and the entry node (usually, the same machine, but not always), and the exit node and the hidden service (presumably, you control both). This is my understanding of it -- if someone has a better one please step on me without hesitation :) yes, this is the case, and it is a valid reason to use ssl. in my opinion, since tor already uses multi-layered encryption anyway, one more layer at the core is not going to create that much of an extra load on the server, and it means that there is no way the traffic can be sniffed at any point - for example a trojan could sniff localhost traffic. also, using onion routing defeats the one way in which SSL can be attacked, by man-in-the-middle intermediaries on the network pathway, which of course cannot be known within the tor network. Also, it should be noted that tor exit nodes could potentially be modified to become men-in-the-middle, although this would not be possible without compromising the key of the server being contacted - another aspect of the advantage of using tor. onion addresses are impossible to remember though - which brings me to another idea - of a name resolution system within the tor network so simpler names can be used. this would require a second directory system, i don't know if it is practical or not, but i thought i should put the idea out there because i2p has name resolution systems, and benig able to type in oniondomainname.onion rather than u15syoa125au.onion would be nice. it would increase the rate of take-up of hidden services, both use and hosting. The other thing that could be interesting of course is an onion-only search engine, which could either compliment or reduce the need for vanity names. Still, I don't see why the directory servers can't maintain this info. It would have to (for the most part) be first-come first-served, and I suppose some sort of uptime monitoring should also play a part (i.e. if you don't use it for say 6 months, you lose it). Shame there's not a whole lot of clients that make use of SRV records, as an onion specifier in there could prove remarkably useful in some way. -- If you aren't going to try something, then we might as well just be friends. We can't have that now, can we? -SK Dan Mahoney, December 9, 1998 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
