Moritz Bartl wrote:
I was wondering the same when I saw the instructions published by mailbox.org last week:
They operate an exit relay, and suggest to use MapAddress statements and the exit notation to use heir exit for *.mailbox.org. I didn't see this previously, and they also don't explicitly enable exit notation, so I wondered if that actually works.
It works. You have to enable exit notation only, if you want to enter it in the URL bar of the browser. MapAddresses with exit notation defined in torrc are working with default settings. grarpamp wrote:
Using the 'router <nickname>' in '.exit' or 'mapaddress' notation is nondeterministic... anyone can poof a relay with the same name....
Yes - you are right. I changed the German tutorials at https://support.mailbox.org/knowledge-base/articles/tor-service and replaced the name with fingerprint of the Tor node. But have a look at Tor docs: https://www.torproject.org/docs/tor-manual.html.en
For example, if you always want connections to www.example.com to exit via torserver (where torserver is the nickname of the server), use "MapAddress www.example.com www.example.com.torserver.exit".
It is not suggested, that fingerprints are possible and more secure. May be, somebody can update the Tor docs too. grarpamp wrote:
Follow this autoresponder if you want...
Thank you for you advice to the discussion here. I closed the ticket because we can discuss it here directly and it is not required to include the first-level support of mailbox.org. I will do the recommended steps. I will try to learn... ;-) Greetings Karsten N.
On 13 Feb 2016, at 06:44, karsten.n@secure.mailbox.org wrote:
grarpamp wrote:
Using the 'router <nickname>' in '.exit' or 'mapaddress' notation is nondeterministic... anyone can poof a relay with the same name....
Yes - you are right. I changed the German tutorials at https://support.mailbox.org/knowledge-base/articles/tor-service and replaced the name with fingerprint of the Tor node.
But have a look at Tor docs: https://www.torproject.org/docs/tor-manual.html.en
For example, if you always want connections to www.example.com to exit via torserver (where torserver is the nickname of the server), use "MapAddress www.example.com www.example.com.torserver.exit".
It is not suggested, that fingerprints are possible and more secure. May be, somebody can update the Tor docs too.
Logged as #18132. https://trac.torproject.org/projects/tor/ticket/18312 <https://trac.torproject.org/projects/tor/ticket/18312> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
I know that a select few public SSL certificates have been issued for .onion domains, but I understand that the status of those certs is tenuous. Has anyone considered implementing a custom certificate service just for .onions? If the Tor Browser shipped with an additional root certificate, that certificate could be used to sign .onion domains. Proof of ownership of .onion domains is relatively easy to ascertain. I haven't looked at the problem in detail, but I believe that a fully-automated process could issue certs for arbitrary .onion domains encrypted with the domain's public key. Only the domain owner would have the private key to decrypt and install the certificate. torproject.org would have to be willing to ship the Tor Browser with the necessary root certificate, but the root would not need the blessing of the CA/Browser Forum or any other authority figure. I realize that just having the Tor Browser recognize the certs wouldn't bring all the benefits of SSL to hidden services, but it would be a good start and could be done without involving politically fractious standards bodies outside the Tor community. Am I late to the party? Has anyone been thinking along these lines? Peace... --Ron
I think it's an interesting idea. It would be a great fit for Let's Encrypt, and it seems they have already been thinking about it: https://community.letsencrypt.org/t/if-when-will-le-support-onion-addresses/... Keep in mind traffic to .onion hidden services is already encrypted via Tor. This limits the usefulness of SSL/TLS somewhat.
Hi Ron! I know that a select few public SSL certificates have been issued for .onion domains, but I understand that the status of those certs is tenuous. Apologies for contradicting you, but there is nothing "tenuous" about Onion certificates. They are fully fledged, official certificates, and the domain-related issues have all been solved. The open issue, if any, is that such certificates are "EV"-style, and as such are only really open to companies because background checks. I outline the issue here: http://dropsafe.crypticide.com/article/11697 - take note especially of the comments, which leads to some commentary on the relevant maillist from key members of CABForum. Has anyone considered implementing a custom certificate service just for .onions? If the Tor Browser shipped with an additional root certificate, that certificate could be used to sign .onion domains. My feelings regards such a proposal are "that would work, yes, but that would put Onions into a 'SSL Ghetto' and inhibit adoption of Onion technologies by 'normal' browsers". Further than that, I believe that the proper approach is to obtain CABForum backing for DV, AV or IV certificates for Onion sites. See http://dropsafe.crypticide.com/article/11697 for explanation of unfamiliar acronyms. Proof of ownership of .onion domains is relatively easy to ascertain. Ballot-144 https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ describes two methods to do so, but in truth at least one of them is not as good as I would like to see. Note also the concerns expressed by Ryan Sleevi at https://cabforum.org/pipermail/public/2015-November/006213.html These are concerns which must be addressed (or constructively negated) to _some_ extent, to pursue Onion DV certs a-la LetsEncrypt. I haven't looked at the problem in detail, but I believe that a fully-automated process could issue certs for arbitrary .onion domains encrypted with the domain's public key. Only the domain owner would have the private key to decrypt and install the certificate. Yes, that could happen. That's one of the methods suggested in Ballot-144. The CABForum have somewhat justified concerns with that mechanism, mostly regards revocation, Onion certificate theft, and SHA hash-collisions. The Certificate/CABForum world has grown up in partnership with capabilities like taking domain-name dispute resolution to some kind of arbiter, but Onionspace lacks such - onions are much more binary, hinging upon possession of the Onion key. This means that CABForum needs gentle introduction to wholesale change. The establishment of more 'official' SSL/EV keys in Onionspace will make an argument for further growth. torproject.org<http://torproject.org> would have to be willing to ship the Tor Browser with the necessary root certificate, but the root would not need the blessing of the CA/Browser Forum or any other authority figure. In summary, I repeat, I feel this would address a short-term, TorBrowserBundle need, but cause harm elsewhere to the greater world's adoption of Onions. -a
On Feb 22, 2016, at 06:18, Alec Muffett <alecm@fb.com> wrote:
Apologies for contradicting you, but there is nothing "tenuous" about Onion certificates.
I don't mind being contradicted. I was responding to articles like this one, which said "these .onion certificates are considered internal name certificates. The CA/Browser Forum has deprecated the use of public SSL Certificates for internal names and they will no longer be allowed after November 1, 2015. " https://blog.digicert.com/the-current-state-of-onion-certificates-and-what-h... I realize that situation has changed in the past year, with the IETF's official recognition of the .onion space. Thanks for the references. They'll help me get up to speed on the current state of things. Though I agree about the risk of ghettoization of the .onion space, I also see an opportunity here to avoid some of the pitfalls of the current SSL certificate trust model, specifically with regards to rogue authorities and stolen/forged signing keys. Again, thanks... --Ron
Can anyone explain the advantages of .onion certs? As far as I understand the onionservice architecture, the traffic between the onion service and the client is EndtoEnd-encrypted? I thought it was a political goal to get recognized (thanks for doing that) and a userinterface/experience goal to get this shiny green bar, when connecting to an .onion service. cheers shadow On 22.02.2016 17:12, Ron Risley wrote:
On Feb 22, 2016, at 06:18, Alec Muffett <alecm@fb.com> wrote:
Apologies for contradicting you, but there is nothing "tenuous" about Onion certificates.
I don't mind being contradicted. I was responding to articles like this one, which said "these .onion certificates are considered internal name certificates. The CA/Browser Forum has deprecated the use of public SSL Certificates for internal names and they will no longer be allowed after November 1, 2015. "
https://blog.digicert.com/the-current-state-of-onion-certificates-and-what-h...
I realize that situation has changed in the past year, with the IETF's official recognition of the .onion space.
Thanks for the references. They'll help me get up to speed on the current state of things.
Though I agree about the risk of ghettoization of the .onion space, I also see an opportunity here to avoid some of the pitfalls of the current SSL certificate trust model, specifically with regards to rogue authorities and stolen/forged signing keys.
Again, thanks...
--Ron _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
-- best regards | viele Gruesse, shadow@systemli.org receive my key: gpg --keyserver zimmermann.mayfirst.org --recv-keys 0x5C6B6ED4248C1F32
On Feb 25, 2016, at 15:33, shadow <shadow@systemli.org> wrote:
Can anyone explain the advantages of .onion certs?
Having SSL Certificates for Onion addresses can help answer questions like: 1) "how do I know that this onion address is run by the *real* <insert-company-name>?" 2) "how do I know that <www-onion-address> and <cdn-onion-address> are run by the same <organisation>?" 3) "what can I do about <bad people> who set up a look-alike phishing onion site and try fooling people into thinking it's mine?" 4) "my existing website codebase relies heavily upon 'secure cookies' which can only go over HTTPS; how can I launch an onion site without doing a lot of expensive refactoring of my code merely to support an experiment with Tor?" 5) "new features in upcoming browsers are going to be locked to HTTPS access - some already are, eg: webcam access - how can i futureproof?" And because Ballot-144 was thought about by a bunch of sensible people: 6) "Onion SSL Certificates are EV-only. But I need a wildcard certificate! Oh, wait, Onion-EV certificates are wildcard-enabled? Cool!" -a
Thanks for this brief explanation, so the main goal of SSL addresses the problem of impersonation. Isn't there an easier way to implement that somehow in the Tor code, than to rely on the (kind of broken) SSL system? But that would only address point 1), 2), 3) and 6) cheers shadow On 25.02.2016 17:17, Alec Muffett wrote:
On Feb 25, 2016, at 15:33, shadow <shadow@systemli.org> wrote:
Can anyone explain the advantages of .onion certs?
Having SSL Certificates for Onion addresses can help answer questions like:
1) "how do I know that this onion address is run by the *real* <insert-company-name>?"
2) "how do I know that <www-onion-address> and <cdn-onion-address> are run by the same <organisation>?"
3) "what can I do about <bad people> who set up a look-alike phishing onion site and try fooling people into thinking it's mine?"
4) "my existing website codebase relies heavily upon 'secure cookies' which can only go over HTTPS; how can I launch an onion site without doing a lot of expensive refactoring of my code merely to support an experiment with Tor?"
5) "new features in upcoming browsers are going to be locked to HTTPS access - some already are, eg: webcam access - how can i futureproof?"
And because Ballot-144 was thought about by a bunch of sensible people:
6) "Onion SSL Certificates are EV-only. But I need a wildcard certificate! Oh, wait, Onion-EV certificates are wildcard-enabled? Cool!"
-a
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
-- best regards | viele Gruesse, shadow@systemli.org receive my key: gpg --keyserver zimmermann.mayfirst.org --recv-keys 0x5C6B6ED4248C1F32
On 26 February 2016 at 14:53, shadow <shadow@systemli.org> wrote:
Thanks for this brief explanation,
so the main goal of SSL addresses the problem of impersonation.
Actually, from my perspective, to focus on a "main goal" (rather than a primary benefit) and then question it, doesn't really seem to make sense. You say "(kind of broken) SSL system" - any yes, there are many criticisms that can be laid at SSL's feet, and many flaws; but when you're building a secure system it's a matter of synthesis - it's a bit like cooking, you add the ingredients which make sense for what you want to achieve. And re: point 4, for instance, when you have many megabytes of code which expect to be dealing with HTTPS Secure Cookies, perhaps *that* is more important to you than point 1; or perhaps point 5 is. But let me put that argument to one side for the moment, and address your question as-stated: Isn't there an easier way to implement that somehow in the Tor code,
than to rely on the (kind of broken) SSL system? But that would only address point 1), 2), 3) and 6
The answer to that is "maybe"; there's an informative comparison here to be made with IPsec Authentication Headers*, commonly known as "AH"; it provides an authentication framework but leaves you (again) to bootstrap your notion of "identity"; you have to work out your own preferred solution for host identity and validation. Also: in the traditional internet we're used to the idea of "1 IP Address => 1+ Websites"; you can run a bunch of different websites with different domain names on a single machine with a single IP address, but in that model IPsec fails** because it authenticates *IP addresses* rather than DNS domain names. In Tor we traverse almost all boundaries between ISO Layer 3 and 7 - the Layer-3-alike Onion address provides AH-like authentication but is as visible to the user as a Layer 6? (7?) DNS domain names; and it's arguable that Onion site HSDirs are their own version of Layer-2 ARP, likewise. Tor is basically a separate networking stack to TCP/IP, and should maybe be treated as one - but this raises the question: "What <element of the network stack> are you trying to authenticate/validate, in some proposed SSL-replacement?" And that is a question, the answer to which should be up to the implementer: - People who want to use Tor like a VPN/IPSec Replacement may put trust in Onions to assure the endpoint they are connecting to. - People who want to use Tor as a SSL Replacement can amend their browser to treat onionsites as equivalents to HTTPS; but then they have to change all the other software in the world to bring it into line / know that "onion == SSL" else the sites will misbehave; but practically this is unlikely to happen. Thus the status quo: treat Tor like a TCP circuit in a different address space, and permit people to put whatever they want over it. Including SSL, if they wish. Or an alternative, if they wish to innovate. -a * http://www.tcpipguide.com/free/t_IPSecAuthenticationHeaderAH.htm ** Aside: with the emergence of IP6 we now have enough space again for "1 IP Address === 1 Website", so maybe it's time elsewhere for an IPsec reboot? -- http://dropsafe.crypticide.com/aboutalecm
Thank you for clarifying that. It totally makes sense to me now. cheers shadow On 26.02.2016 17:24, Alec Muffett wrote:
On 26 February 2016 at 14:53, shadow <shadow@systemli.org <mailto:shadow@systemli.org>> wrote:
Thanks for this brief explanation,
so the main goal of SSL addresses the problem of impersonation.
Actually, from my perspective, to focus on a "main goal" (rather than a primary benefit) and then question it, doesn't really seem to make sense.
You say "(kind of broken) SSL system" - any yes, there are many criticisms that can be laid at SSL's feet, and many flaws; but when you're building a secure system it's a matter of synthesis - it's a bit like cooking, you add the ingredients which make sense for what you want to achieve.
And re: point 4, for instance, when you have many megabytes of code which expect to be dealing with HTTPS Secure Cookies, perhaps *that* is more important to you than point 1; or perhaps point 5 is.
But let me put that argument to one side for the moment, and address your question as-stated:
Isn't there an easier way to implement that somehow in the Tor code, than to rely on the (kind of broken) SSL system? But that would only address point 1), 2), 3) and 6
The answer to that is "maybe"; there's an informative comparison here to be made with IPsec Authentication Headers*, commonly known as "AH"; it provides an authentication framework but leaves you (again) to bootstrap your notion of "identity"; you have to work out your own preferred solution for host identity and validation.
Also: in the traditional internet we're used to the idea of "1 IP Address => 1+ Websites"; you can run a bunch of different websites with different domain names on a single machine with a single IP address, but in that model IPsec fails** because it authenticates *IP addresses* rather than DNS domain names.
In Tor we traverse almost all boundaries between ISO Layer 3 and 7 - the Layer-3-alike Onion address provides AH-like authentication but is as visible to the user as a Layer 6? (7?) DNS domain names; and it's arguable that Onion site HSDirs are their own version of Layer-2 ARP, likewise. Tor is basically a separate networking stack to TCP/IP, and should maybe be treated as one - but this raises the question: "What <element of the network stack> are you trying to authenticate/validate, in some proposed SSL-replacement?"
And that is a question, the answer to which should be up to the implementer:
- People who want to use Tor like a VPN/IPSec Replacement may put trust in Onions to assure the endpoint they are connecting to.
- People who want to use Tor as a SSL Replacement can amend their browser to treat onionsites as equivalents to HTTPS; but then they have to change all the other software in the world to bring it into line / know that "onion == SSL" else the sites will misbehave; but practically this is unlikely to happen.
Thus the status quo: treat Tor like a TCP circuit in a different address space, and permit people to put whatever they want over it. Including SSL, if they wish. Or an alternative, if they wish to innovate.
-a
* http://www.tcpipguide.com/free/t_IPSecAuthenticationHeaderAH.htm
** Aside: with the emergence of IP6 we now have enough space again for "1 IP Address === 1 Website", so maybe it's time elsewhere for an IPsec reboot?
-- best regards | viele Gruesse, shadow@systemli.org receive my key: gpg --keyserver zimmermann.mayfirst.org --recv-keys 0x5C6B6ED4248C1F32
participants (7)
-
Alec Muffett -
Alec Muffett -
Green Dream -
karsten.n＠secure.mailbox.org -
Ron Risley -
shadow -
Tim Wilson-Brown - teor