There's been a spirited debate on irc, so I thought I would try and capture my thoughts in long form. I think it's important to look at the long-term goals rather than how to get there, so that's where I'm going to start, and then at each item maybe talk a little bit about how to get there. So I think the Tor Project and Tor Browser should:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site b) Consider how Mixed Content should interact with .onion browsing c) Get .onion IANA reserved d) Address the problems that Facebook is/was concerned about when deploying a .onion e) Consider how EV treatment could be used to improve poor .onion readability
(If you're not familiar with DV [Domain Validated] and EV [Extended Validation] certificates and their UI differences, you should take a peek. For example [0]. There are other subtleties and requirements on EV certs like OCSP checking that removes the indicator, and the forthcoming CT effort in Chrome, but that's mostly orthogonal.)
-------------------- a) Self Signed Errors on .onion
A .onion specifies the key needed. As far as little-t tor is concerned, it got you to the correct endpoint safely, so whatever SSL certificate is presented could be considered valid.
However, if the Hidden Service is on box A and the webserver on box B - you'd need to do some out-of-application tricks (like stunnel) to prevent a MITM from attacking that connection. So as Roger suggested, perhaps requiring the SSL certificate to be signed by the .onion key would be a reasonable choice. But if you make that requirement, it also implies that HTTP .onions are less secure than HTTPS .onions. Which may or not be the case - you don't know.
I'm not religious about anything other than getting rid of the error: I don't like that users are trained to click through security errors.
This is a weakly held opinion right now - but I think it's fair to give DV treatment to http://.onion because it is, from little-t tor's point of view, secure. Following that conclusion, it is therefore fair to accept self-signed certificates and _not_ require a certificate for a https://.onion be signed by the .onion key. (Because otherwise, we're saying that SSL on .onion requires more hoops to achieve security than HTTP on .onion, which isn't the case.)
-------------------- b) Mixed Content on .onion
This is a can of worms I'm not going to open in this mail. But it's there, and I think it's worth thinking about whether a .onion requesting resources from http://.com or https://.com is acceptable.
-------------------- c) Get .onion IANA reserved
I think this is fairly apparent in itself, and is in the works [1]. Not sure its status but I would be happy to lend time in whatever IETF group/work is needed if it will help.
-------------------- d) Address the problems that Facebook is/was concerned about when deploying a .onion
There are reasons, technical and political, why Facebook went and got a HTTPS cert for their .onion. I've copied Alec so hopefully he'll agree, refute, or add. But from my perspective, if I were Facebook or another large company like that:
i) I don't want to train my users to click through HTTPS warnings. (Conversely, I like training my users to type https://mysite.com) ii) I don't want to have to do the development and QA work to cut my site over to be sometimes-HTTP if it's normally always HTTPS iii) It would be convenient if I didn't have to do stunnel tricks to encrypt the connection between my Hidden Service server and (e.g.) load balancer, which is on another box iv) I'd really like to get a green box showing my org name, and it's even better that it'd be very difficult a phisher to get that
(iii) can contradict with (A) above of course. Because I came to the conclusion of allowing invalid certificates, a MITM could attack Facebook between the HS server and load balancer. I'm not sure there is an elegant solution there. One would probably have to tunnel the connection over a mutually authenticated stunnel connection to prevent a MITM. But frankly, if we assume users are used to clicking through self-signed certs and we want to start the process of training them _not_ to, Facebook would have to do this now _anyway_. So... =/ I guess documenting the crap out of this concern and providing examples may be the best solution based off my mindset right now.
It's awesome that Facebook set up a Hidden Service. I'd love to get a lot more large orgs doing that. We should reach out and figure out what the blockers are, what's painful about it, and what we can do to help. I would love doing that, it would be awesome. (And I'm not afraid to NDA myself up if necessary, seeing as I'm under NDA with half of the Bay Area anyway.)
-------------------- e) Consider how EV treatment could be used to improve poor .onion readability
This is the trickiest one, and it overlaps the most with the question of "Should we encourage CAs to issue certificates?"
EV treatment in Tor Browser is a tool in the toolbox. I think it would be wasteful of written code and users who are accustomed to seeing it to not make use of it. I also think it dovetails nicely with how unreadable HS addresses are and how much more unreadable they're going to get soon when they get longer.
I don't want a system that _requires_ participating in the DNS or CA model. Free or Paid, you still have to provide identifying information - and for an anonymity project I think we can all agree that's unacceptable. But as we hopefully expand hidden services to more and more corporate services - these organizations are legitimately concerned about (e.g.) phishing, and it's unreasonable to expect users to meticulously validate a .onion address. (Let alone how you find what the address should be validated against.)
But a problem is that if we allow a .onion to certify anything it wants, it can certify any fraudulent information it wants. Bootstrapping off the other axis of Zooko's Triangle (Secure and Human Meaningful, but Centralized) is a way to combat that fraudulent information. (Not the only way, but a way.)
Syrup-tan had an idea on irc: Have a DV certificate sign a certificate that is valid for the .onion URL, and display the URL of the DV certificate. This doesn't eliminate phishing - I can register facebok.com and then get that displayed. But doing bootstapping off DNS and DV certificates is a fairly low bar in terms of the cost to a .onion operator. (There are other concerns here, I'm not completely comfortable with repurposing the EV indicator in this way. Asa on irc had the good point that if we did this, maybe we'd want to change the EV green to another color just to be a little bit different. Not that I really expect users to notice that though...)
Allowing an organization to purchase an EV certificate from a CA, and display the organization's name in the address bar, is another way - albeit a very high bar in terms of cost to an onion operator.
A petname system based off who-knows-what (for example the namecoin/sovereign-keys like system of a land-grab, first-to-the-name approach) is a third, and would meet the goal of not requiring participating in the DNS and CA systems. but a high bar in terms of engineering effort for Tor.
I think Tor Browser should do several of them. I think the EV certificates + partnering with CAs is dead simple and requires no engineering effort on behalf of Tor Browser. So that's a win, and I think worth doing. But there should be at least one more solution in the short to long term (e.g. a petname approach). Unfortunately, if the time between now and the 'long term' solution is too long, it locks out everyone who can't get an EV cert - which is a legitimate concern. Perhaps after there's a spec Tor likes, some large organization concerned about preventing phishing could throw some engineering time at the problem.
Anyway, if it's not clear, I am volunteering to work on these things as I'm able.
-tom
[0] https://ftt-uploads.s3.amazonaws.com/browser-ssl-ui-comparison.png [1] https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/
Hi Tom, thanks for the great summary.
I want to comment on one element of your writeup, the hidden service on box A, webserver on box B. My weak belief is that this is no different than the "SSL added and removed here" issue which impacts many 'secure sites.'
Imposing a requirement that a person must swat away error messages which may or may not be accurate seems like a good way to train people to further ignore those messages, or dive into the ratholes of making it hard to do so.
Adam
On Fri, Nov 14, 2014 at 11:08:38AM -0600, Tom Ritter wrote: | There's been a spirited debate on irc, so I thought I would try and | capture my thoughts in long form. I think it's important to look at | the long-term goals rather than how to get there, so that's where I'm | going to start, and then at each item maybe talk a little bit about | how to get there. So I think the Tor Project and Tor Browser should: | | a) Eliminate self-signed certificate errors when browsing https:// on | an onion site | b) Consider how Mixed Content should interact with .onion browsing | c) Get .onion IANA reserved | d) Address the problems that Facebook is/was concerned about when | deploying a .onion | e) Consider how EV treatment could be used to improve poor .onion readability | | (If you're not familiar with DV [Domain Validated] and EV [Extended | Validation] certificates and their UI differences, you should take a | peek. For example [0]. There are other subtleties and requirements on | EV certs like OCSP checking that removes the indicator, and the | forthcoming CT effort in Chrome, but that's mostly orthogonal.) | | -------------------- | a) Self Signed Errors on .onion | | A .onion specifies the key needed. As far as little-t tor is | concerned, it got you to the correct endpoint safely, so whatever SSL | certificate is presented could be considered valid. | | However, if the Hidden Service is on box A and the webserver on box B | - you'd need to do some out-of-application tricks (like stunnel) to | prevent a MITM from attacking that connection. So as Roger suggested, | perhaps requiring the SSL certificate to be signed by the .onion key | would be a reasonable choice. But if you make that requirement, it | also implies that HTTP .onions are less secure than HTTPS .onions. | Which may or not be the case - you don't know. | | I'm not religious about anything other than getting rid of the error: | I don't like that users are trained to click through security errors. | | This is a weakly held opinion right now - but I think it's fair to | give DV treatment to http://.onion because it is, from little-t tor's | point of view, secure. Following that conclusion, it is therefore | fair to accept self-signed certificates and _not_ require a | certificate for a https://.onion be signed by the .onion key. | (Because otherwise, we're saying that SSL on .onion requires more | hoops to achieve security than HTTP on .onion, which isn't the case.) | | -------------------- | b) Mixed Content on .onion | | This is a can of worms I'm not going to open in this mail. But it's | there, and I think it's worth thinking about whether a .onion | requesting resources from http://.com or https://.com is acceptable. | | -------------------- | c) Get .onion IANA reserved | | I think this is fairly apparent in itself, and is in the works [1]. | Not sure its status but I would be happy to lend time in whatever IETF | group/work is needed if it will help. | | -------------------- | d) Address the problems that Facebook is/was concerned about when | deploying a .onion | | There are reasons, technical and political, why Facebook went and got | a HTTPS cert for their .onion. I've copied Alec so hopefully he'll | agree, refute, or add. But from my perspective, if I were Facebook or | another large company like that: | | i) I don't want to train my users to click through HTTPS warnings. | (Conversely, I like training my users to type https://mysite.com) | ii) I don't want to have to do the development and QA work to cut my | site over to be sometimes-HTTP if it's normally always HTTPS | iii) It would be convenient if I didn't have to do stunnel tricks to | encrypt the connection between my Hidden Service server and (e.g.) | load balancer, which is on another box | iv) I'd really like to get a green box showing my org name, and it's | even better that it'd be very difficult a phisher to get that | | (iii) can contradict with (A) above of course. Because I came to the | conclusion of allowing invalid certificates, a MITM could attack | Facebook between the HS server and load balancer. I'm not sure there | is an elegant solution there. One would probably have to tunnel the | connection over a mutually authenticated stunnel connection to prevent | a MITM. But frankly, if we assume users are used to clicking through | self-signed certs and we want to start the process of training them | _not_ to, Facebook would have to do this now _anyway_. So... =/ I | guess documenting the crap out of this concern and providing examples | may be the best solution based off my mindset right now. | | It's awesome that Facebook set up a Hidden Service. I'd love to get a | lot more large orgs doing that. We should reach out and figure out | what the blockers are, what's painful about it, and what we can do to | help. I would love doing that, it would be awesome. (And I'm not | afraid to NDA myself up if necessary, seeing as I'm under NDA with | half of the Bay Area anyway.) | | -------------------- | e) Consider how EV treatment could be used to improve poor .onion readability | | This is the trickiest one, and it overlaps the most with the question | of "Should we encourage CAs to issue certificates?" | | EV treatment in Tor Browser is a tool in the toolbox. I think it would | be wasteful of written code and users who are accustomed to seeing it | to not make use of it. I also think it dovetails nicely with how | unreadable HS addresses are and how much more unreadable they're going | to get soon when they get longer. | | I don't want a system that _requires_ participating in the DNS or CA | model. Free or Paid, you still have to provide identifying information | - and for an anonymity project I think we can all agree that's | unacceptable. But as we hopefully expand hidden services to more and | more corporate services - these organizations are legitimately | concerned about (e.g.) phishing, and it's unreasonable to expect users | to meticulously validate a .onion address. (Let alone how you find | what the address should be validated against.) | | But a problem is that if we allow a .onion to certify anything it | wants, it can certify any fraudulent information it wants. | Bootstrapping off the other axis of Zooko's Triangle (Secure and Human | Meaningful, but Centralized) is a way to combat that fraudulent | information. (Not the only way, but a way.) | | Syrup-tan had an idea on irc: Have a DV certificate sign a certificate | that is valid for the .onion URL, and display the URL of the DV | certificate. This doesn't eliminate phishing - I can register | facebok.com and then get that displayed. But doing bootstapping off | DNS and DV certificates is a fairly low bar in terms of the cost to a | .onion operator. (There are other concerns here, I'm not completely | comfortable with repurposing the EV indicator in this way. Asa on irc | had the good point that if we did this, maybe we'd want to change the | EV green to another color just to be a little bit different. Not that | I really expect users to notice that though...) | | Allowing an organization to purchase an EV certificate from a CA, and | display the organization's name in the address bar, is another way - | albeit a very high bar in terms of cost to an onion operator. | | A petname system based off who-knows-what (for example the | namecoin/sovereign-keys like system of a land-grab, first-to-the-name | approach) is a third, and would meet the goal of not requiring | participating in the DNS and CA systems. but a high bar in terms of | engineering effort for Tor. | | I think Tor Browser should do several of them. I think the EV | certificates + partnering with CAs is dead simple and requires no | engineering effort on behalf of Tor Browser. So that's a win, and I | think worth doing. But there should be at least one more solution in | the short to long term (e.g. a petname approach). Unfortunately, if | the time between now and the 'long term' solution is too long, it | locks out everyone who can't get an EV cert - which is a legitimate | concern. Perhaps after there's a spec Tor likes, some large | organization concerned about preventing phishing could throw some | engineering time at the problem. | | Anyway, if it's not clear, I am volunteering to work on these things | as I'm able. | | -tom | | [0] https://ftt-uploads.s3.amazonaws.com/browser-ssl-ui-comparison.png | [1] https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ | _______________________________________________ | tor-dev mailing list | tor-dev@lists.torproject.org | https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
c) Get .onion IANA reserved
It doesn't look like that's going to happen.
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ is expired & I haven't been able to find anything indicating it's still being considered.
See the "existing requests/RFC 6761 process:" section here https://tools.ietf.org/wg/dnsop/minutes?item=minutes-89-dnsop.html
Regards, Lee
On 11/14/14, Tom Ritter tom@ritter.vg wrote:
There's been a spirited debate on irc, so I thought I would try and capture my thoughts in long form. I think it's important to look at the long-term goals rather than how to get there, so that's where I'm going to start, and then at each item maybe talk a little bit about how to get there. So I think the Tor Project and Tor Browser should:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site b) Consider how Mixed Content should interact with .onion browsing c) Get .onion IANA reserved d) Address the problems that Facebook is/was concerned about when deploying a .onion e) Consider how EV treatment could be used to improve poor .onion readability
(If you're not familiar with DV [Domain Validated] and EV [Extended Validation] certificates and their UI differences, you should take a peek. For example [0]. There are other subtleties and requirements on EV certs like OCSP checking that removes the indicator, and the forthcoming CT effort in Chrome, but that's mostly orthogonal.)
a) Self Signed Errors on .onion
A .onion specifies the key needed. As far as little-t tor is concerned, it got you to the correct endpoint safely, so whatever SSL certificate is presented could be considered valid.
However, if the Hidden Service is on box A and the webserver on box B
- you'd need to do some out-of-application tricks (like stunnel) to
prevent a MITM from attacking that connection. So as Roger suggested, perhaps requiring the SSL certificate to be signed by the .onion key would be a reasonable choice. But if you make that requirement, it also implies that HTTP .onions are less secure than HTTPS .onions. Which may or not be the case - you don't know.
I'm not religious about anything other than getting rid of the error: I don't like that users are trained to click through security errors.
This is a weakly held opinion right now - but I think it's fair to give DV treatment to http://.onion because it is, from little-t tor's point of view, secure. Following that conclusion, it is therefore fair to accept self-signed certificates and _not_ require a certificate for a https://.onion be signed by the .onion key. (Because otherwise, we're saying that SSL on .onion requires more hoops to achieve security than HTTP on .onion, which isn't the case.)
b) Mixed Content on .onion
This is a can of worms I'm not going to open in this mail. But it's there, and I think it's worth thinking about whether a .onion requesting resources from http://.com or https://.com is acceptable.
c) Get .onion IANA reserved
I think this is fairly apparent in itself, and is in the works [1]. Not sure its status but I would be happy to lend time in whatever IETF group/work is needed if it will help.
d) Address the problems that Facebook is/was concerned about when deploying a .onion
There are reasons, technical and political, why Facebook went and got a HTTPS cert for their .onion. I've copied Alec so hopefully he'll agree, refute, or add. But from my perspective, if I were Facebook or another large company like that:
i) I don't want to train my users to click through HTTPS warnings. (Conversely, I like training my users to type https://mysite.com) ii) I don't want to have to do the development and QA work to cut my site over to be sometimes-HTTP if it's normally always HTTPS iii) It would be convenient if I didn't have to do stunnel tricks to encrypt the connection between my Hidden Service server and (e.g.) load balancer, which is on another box iv) I'd really like to get a green box showing my org name, and it's even better that it'd be very difficult a phisher to get that
(iii) can contradict with (A) above of course. Because I came to the conclusion of allowing invalid certificates, a MITM could attack Facebook between the HS server and load balancer. I'm not sure there is an elegant solution there. One would probably have to tunnel the connection over a mutually authenticated stunnel connection to prevent a MITM. But frankly, if we assume users are used to clicking through self-signed certs and we want to start the process of training them _not_ to, Facebook would have to do this now _anyway_. So... =/ I guess documenting the crap out of this concern and providing examples may be the best solution based off my mindset right now.
It's awesome that Facebook set up a Hidden Service. I'd love to get a lot more large orgs doing that. We should reach out and figure out what the blockers are, what's painful about it, and what we can do to help. I would love doing that, it would be awesome. (And I'm not afraid to NDA myself up if necessary, seeing as I'm under NDA with half of the Bay Area anyway.)
e) Consider how EV treatment could be used to improve poor .onion readability
This is the trickiest one, and it overlaps the most with the question of "Should we encourage CAs to issue certificates?"
EV treatment in Tor Browser is a tool in the toolbox. I think it would be wasteful of written code and users who are accustomed to seeing it to not make use of it. I also think it dovetails nicely with how unreadable HS addresses are and how much more unreadable they're going to get soon when they get longer.
I don't want a system that _requires_ participating in the DNS or CA model. Free or Paid, you still have to provide identifying information
- and for an anonymity project I think we can all agree that's
unacceptable. But as we hopefully expand hidden services to more and more corporate services - these organizations are legitimately concerned about (e.g.) phishing, and it's unreasonable to expect users to meticulously validate a .onion address. (Let alone how you find what the address should be validated against.)
But a problem is that if we allow a .onion to certify anything it wants, it can certify any fraudulent information it wants. Bootstrapping off the other axis of Zooko's Triangle (Secure and Human Meaningful, but Centralized) is a way to combat that fraudulent information. (Not the only way, but a way.)
Syrup-tan had an idea on irc: Have a DV certificate sign a certificate that is valid for the .onion URL, and display the URL of the DV certificate. This doesn't eliminate phishing - I can register facebok.com and then get that displayed. But doing bootstapping off DNS and DV certificates is a fairly low bar in terms of the cost to a .onion operator. (There are other concerns here, I'm not completely comfortable with repurposing the EV indicator in this way. Asa on irc had the good point that if we did this, maybe we'd want to change the EV green to another color just to be a little bit different. Not that I really expect users to notice that though...)
Allowing an organization to purchase an EV certificate from a CA, and display the organization's name in the address bar, is another way - albeit a very high bar in terms of cost to an onion operator.
A petname system based off who-knows-what (for example the namecoin/sovereign-keys like system of a land-grab, first-to-the-name approach) is a third, and would meet the goal of not requiring participating in the DNS and CA systems. but a high bar in terms of engineering effort for Tor.
I think Tor Browser should do several of them. I think the EV certificates + partnering with CAs is dead simple and requires no engineering effort on behalf of Tor Browser. So that's a win, and I think worth doing. But there should be at least one more solution in the short to long term (e.g. a petname approach). Unfortunately, if the time between now and the 'long term' solution is too long, it locks out everyone who can't get an EV cert - which is a legitimate concern. Perhaps after there's a spec Tor likes, some large organization concerned about preventing phishing could throw some engineering time at the problem.
Anyway, if it's not clear, I am volunteering to work on these things as I'm able.
-tom
[0] https://ftt-uploads.s3.amazonaws.com/browser-ssl-ui-comparison.png [1] https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 11/15/14, Griffin Boyce griffin@cryptolab.net wrote:
Lee wrote:
c) Get .onion IANA reserved
It doesn't look like that's going to happen.
Yeah. Though the biggest use-case for cert+onion is when trying to match a clearnet service to a hidden service -- such as Facebook or Erowid.
That is false. Using TLS has many use-cases - one that is critically important is stronger defense in depth.
All the best, Jacob
Fair. What are your thoughts about possible trade-offs with anonymity when using a CA-signed cert?
On November 14, 2014 9:38:02 PM EST, Jacob Appelbaum jacob@appelbaum.net wrote:
On 11/15/14, Griffin Boyce griffin@cryptolab.net wrote:
Lee wrote:
c) Get .onion IANA reserved
It doesn't look like that's going to happen.
Yeah. Though the biggest use-case for cert+onion is when trying to match a clearnet service to a hidden service -- such as Facebook or Erowid.
That is false. Using TLS has many use-cases - one that is critically important is stronger defense in depth.
All the best, Jacob _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 11/15/14, Griffin Boyce griffin@cryptolab.net wrote:
Fair. What are your thoughts about possible trade-offs with anonymity when using a CA-signed cert?
I have many. It won't impact client anonymity from where I stand and it will ease usability for certain use cases.
All in all, I welcome the CA cartels signing .onion domains and encouraging the adoption of warning/error free TLS in browsers or other programs, such as mail or IM clients.
All the best, Jacob
On 11/15/14, Lee ler762@gmail.com wrote:
c) Get .onion IANA reserved
It doesn't look like that's going to happen.
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ is expired & I haven't been able to find anything indicating it's still being considered.
It's still something that we're working on it. We should update it and post a new revision. Seth Schoen recently went to the latest IETF in Hawaii to discuss it with some folks in person and we're going to update it after we review his feedback.
All the best, Jacob
On 11/14/14, Jacob Appelbaum jacob@appelbaum.net wrote:
On 11/15/14, Lee ler762@gmail.com wrote:
c) Get .onion IANA reserved
It doesn't look like that's going to happen.
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ is expired & I haven't been able to find anything indicating it's still being considered.
It's still something that we're working on it. We should update it and post a new revision. Seth Schoen recently went to the latest IETF in Hawaii to discuss it with some folks in person and we're going to update it after we review his feedback.
Are you keeping it with the DNS Ops WG?
Lee
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/14/2014 08:37 PM, Jacob Appelbaum wrote:
On 11/15/14, Lee ler762@gmail.com wrote:
c) Get .onion IANA reserved
It doesn't look like that's going to happen.
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/
is expired & I haven't been able to find anything indicating it's
still being considered.
It's still something that we're working on it. We should update it and post a new revision. Seth Schoen recently went to the latest IETF in Hawaii to discuss it with some folks in person and we're going to update it after we review his feedback.
All the best, Jacob
Good to hear that it's still being worked on; the Namecoin guys were getting a little worried that the current public draft had expired. Looking forward to seeing a new draft.
- -Jeremy Rand
On Fri, Nov 14, 2014 at 12:08 PM, Tom Ritter tom@ritter.vg wrote:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site
No, please don't. Browsers throw cert errors for good reasons. If you don't want to deal with it, just click accept or otherwise pin them out in your trust store. Blind acceptance of certs just because the TLD says .onion is just as dumb as trusting .com. And if Joe and Jane's cluster of services wishes to publish a CA or any other form of trustweb you're going to break that too. Don't do that. If you don't think trust has the similar uses in anon networks as on clearnet, or will never appear there, you need to open your eyes.
On Mon, Nov 17, 2014 at 05:48:26PM -0500, grarpamp wrote:
On Fri, Nov 14, 2014 at 12:08 PM, Tom Ritter tom@ritter.vg wrote:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site
No, please don't. Browsers throw cert errors for good reasons. If you don't want to deal with it, just click accept or otherwise pin them out in your trust store. Blind acceptance of certs just because the TLD says .onion is just as dumb as trusting .com. And if Joe and Jane's cluster of services wishes to publish a CA or any other form of trustweb you're going to break that too. Don't do that. If you don't think trust has the similar uses in anon networks as on clearnet, or will never appear there, you need to open your eyes.
Well, I think I'm significantly less opposed to this idea than you seem to be. I also think, sadly, this idea conflates two distinct issues.
Do you know what happens when my grandmother sees a certificate warning? She panics and freezes. I expect this happens more often than people ignorantly clicking through the warning. This also may be a generational habit, where we're conditioning the younger generation to click-through, while the older generations are still worried about breaking their computer. In either case, I think this is mostly irrelevant for what we're trying to accomplish.
Eliminating self-signed certificate errors when connecting to hidden service sites will be a significant usability improvement. Personally, I will probably never pay for a CA signed cert for my hidden service, but I also want my grandmother to have a pleasant experience when she visits the site. How can we solve this dilemma?
Question 1: What is my cert trying to prove/what problem is my cert trying to solve?
In reality, if I only use a self-signed cert it proves nothing, but it does provides another layer of encryption. Defense-in-depth, as Jacob said. This is the only thing I can provide. There is no assertion that the hidden service connected to *my* website.
Question 2: What if Joe and Jane publish a CA or <blah>?
They are atypical and all users will still received a certificate validation error when they try connecting to the cluster because the CA isn't...trusted. This error message does not solve the problem. It is scary and breaks the usability of (potentially) secure communication. We should absolutely fail closed, but we should make the common-case usable.
Question 3: How do we solve this problem?
I think step 1 is removing the PKI TTP. The CA is a hazard and complicates the problem. The proposed solution with the most potential is signing the cert with the hidden service's key, thus coupling the two and certifying the TLS cert. Cross-certification is more difficult, and arguably out-of-scope for Tor. With the next-gen service implementation coming soon, it may be helpful to consider how we can integrate this functionality and how difficult it will be to verify an ed25519 sig in Tor Browser.
I'm considering the feasibility of delegating verification to tor over the control port, but this is quite risky and it may be better to handle this directly in the browser. Not sure.
I admit, it may be useful to use a CA in some situations, but then the hidden service's key can simply sign the CA cert or an intermidiate cert, instead of signing each leaf cert directly. In either case, the end result is the same.
Tom Ritter tom@ritter.vg writes:
There's been a spirited debate on irc, so I thought I would try and capture my thoughts in long form. I think it's important to look at the long-term goals rather than how to get there, so that's where I'm going to start, and then at each item maybe talk a little bit about how to get there. So I think the Tor Project and Tor Browser should:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site b) Consider how Mixed Content should interact with .onion browsing c) Get .onion IANA reserved d) Address the problems that Facebook is/was concerned about when deploying a .onion e) Consider how EV treatment could be used to improve poor .onion readability
Thanks for all the thoughts Tom!
This is hard topic and I don't really have strong opinions on this.
Some notes:
- Allowing self-signed certs sounds like a potentially good idea to me. However, I can hear grarpamp's concerns and it's not obviously clear to me that it's something we should do.
In general, the whole user education part of this is quite hard to evaluate, and I don't think I understand the problem well enough to take a stance.
- In general, having CAs sign onion certificates seems like a good thing for now. There are threat models that would really benefit from this, so we should make it a possibility and work with CAs to get the best out of it.
- I'm not very afraid of CA certificates getting out of control, that is the community evolving to a point that if an HS doesn't have a CA certificate it's not considered secure.
This doesn't seem like something that will happen any time soon, and if it ever happens and we really want to stop it, well it's good we have a Firefox fork ;)
Personally, I would let this issue develop organically:
In the short-term future, we should help CAs make their certs useful for the onionspace, and we should also make some trac tickets and plans for any Tor modifications we want to do (for example, trusting self-signed certs signed by the HS identity key seem like a generally good idea).
I encourage anyone with good ideas and opinions to get involved with the CA community and help them make this useful. As I understand it, part of the discussion is happening here: https://cabforum.org/pipermail/public/2014-November/004569.html
Thanks George - that is where the discussion is happening. Unfortunately, public participation is really limited in the CAB Forum. However, if you want to help, please reach out to the individuals advocating against the proposal (or submit your suggestions to me) to see if we can get a secure, but useful, process adopted.
-----Original Message----- From: tor-dev [mailto:tor-dev-bounces@lists.torproject.org] On Behalf Of George Kadianakis Sent: Tuesday, November 18, 2014 10:55 AM To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Of CA-signed certs and .onion URIs
Tom Ritter tom@ritter.vg writes:
There's been a spirited debate on irc, so I thought I would try and capture my thoughts in long form. I think it's important to look at the long-term goals rather than how to get there, so that's where I'm going to start, and then at each item maybe talk a little bit about how to get there. So I think the Tor Project and Tor Browser should:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site b) Consider how Mixed Content should interact with .onion browsing c) Get .onion IANA reserved d) Address the problems that Facebook is/was concerned about when deploying a .onion e) Consider how EV treatment could be used to improve poor .onion readability
Thanks for all the thoughts Tom!
This is hard topic and I don't really have strong opinions on this.
Some notes:
- Allowing self-signed certs sounds like a potentially good idea to me. However, I can hear grarpamp's concerns and it's not obviously clear to me that it's something we should do.
In general, the whole user education part of this is quite hard to evaluate, and I don't think I understand the problem well enough to take a stance.
- In general, having CAs sign onion certificates seems like a good thing for now. There are threat models that would really benefit from this, so we should make it a possibility and work with CAs to get the best out of it.
- I'm not very afraid of CA certificates getting out of control, that is the community evolving to a point that if an HS doesn't have a CA certificate it's not considered secure.
This doesn't seem like something that will happen any time soon, and if it ever happens and we really want to stop it, well it's good we have a Firefox fork ;)
Personally, I would let this issue develop organically:
In the short-term future, we should help CAs make their certs useful for the onionspace, and we should also make some trac tickets and plans for any Tor modifications we want to do (for example, trusting self-signed certs signed by the HS identity key seem like a generally good idea).
I encourage anyone with good ideas and opinions to get involved with the CA community and help them make this useful. As I understand it, part of the discussion is happening here: https://cabforum.org/pipermail/public/2014-November/004569.html
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Tue, Nov 18, 2014 at 05:55:29PM +0000, George Kadianakis wrote:
Tom Ritter tom@ritter.vg writes:
There's been a spirited debate on irc, so I thought I would try and capture my thoughts in long form. I think it's important to look at the long-term goals rather than how to get there, so that's where I'm going to start, and then at each item maybe talk a little bit about how to get there. So I think the Tor Project and Tor Browser should:
a) Eliminate self-signed certificate errors when browsing https:// on an onion site b) Consider how Mixed Content should interact with .onion browsing c) Get .onion IANA reserved d) Address the problems that Facebook is/was concerned about when deploying a .onion e) Consider how EV treatment could be used to improve poor .onion readability
Thanks for all the thoughts Tom!
Ditto. I agree this was a very nice summary.
This is hard topic and I don't really have strong opinions on this.
Some notes:
Allowing self-signed certs sounds like a potentially good idea to me. However, I can hear grarpamp's concerns and it's not obviously clear to me that it's something we should do.
In general, the whole user education part of this is quite hard to evaluate, and I don't think I understand the problem well enough to take a stance.
In general, having CAs sign onion certificates seems like a good thing for now. There are threat models that would really benefit from this, so we should make it a possibility and work with CAs to get the best out of it.
I also agree with this. In the past I was hesitant to suggest supporting TLS with hidden services, but the more I thought about this topic and the more others voiced their opinion, I think supporting usable e2e application-controlled transport-layer crypto is important.
I'm not very afraid of CA certificates getting out of control, that is the community evolving to a point that if an HS doesn't have a CA certificate it's not considered secure.
This doesn't seem like something that will happen any time soon, and if it ever happens and we really want to stop it, well it's good we have a Firefox fork ;)
This seems like a risky plan, but there is great reward if this succeeds.
Dear furture-self and Tor community, I'm sorry if this failed, but it was worth trying.
Personally, I would let this issue develop organically:
In the short-term future, we should help CAs make their certs useful for the onionspace, and we should also make some trac tickets and plans for any Tor modifications we want to do (for example, trusting self-signed certs signed by the HS identity key seem like a generally good idea).
Definitely, we should start opening trac tickets.
It seems the main blocker/objection to accepting the current proposal (aside from some other minor details which can be worked out) is IANA reserving the TLD. If anyone can help support the acceptance of the proposed RFC, that would significantly help[0]. It was also proposed that the CAB Forum should progress this under the assumption that .onion will become a reserved TLD[1], but getting this in-place is quite important.
[0] https://cabforum.org/pipermail/public/2014-November/004576.html [1] https://cabforum.org/pipermail/public/2014-November/004616.html
I encourage anyone with good ideas and opinions to get involved with the CA community and help them make this useful. As I understand it, part of the discussion is happening here: https://cabforum.org/pipermail/public/2014-November/004569.html
+1
On Tue, Nov 18, 2014 at 12:55 PM, George Kadianakis desnacked@riseup.net wrote:
plans for any Tor modifications we want to do (for example, trusting self-signed certs signed by the HS identity key seem like a generally good idea).
If the HS pubkey and the onion CN were both in the cert, and signed over by that same key all corresponding to the url the TBB is currently attempting to validate, that would seem fine to me. No interaction with the controller (which may not even be accessible [1]) needed to get the HS descriptor (pubkey). Security is limited to 80-bits, or the future wider proposal. It's also a TBB specific extension. All other browsers pointed at socks5 somewhere will still rightly fail, unless adopted upstream (which MSIE won't do) or via standards. Note that this is not 'turning off the warnings for all .onion', it's recognizing that attestation of the HS key is sufficient to show ownership of that service. Whereas under various attacks a traditional selfsigned cert is not.
M. Finkel: habit, where we're conditioning the younger generation to click-through,
It's suggested the right training is to teach the contexts in which they should care... banking, email, accounts, etc... and then to in fact just click through (everyday browsing) unless they're under a context where they actually care. Even though you have the helmet, you train and care wear a helmet for racing, not walking. The mandantory warnings are there for people who care about their context, not those who don't. My beef is that it requires more than one click in FF to get through.
Grandma panics and freezes because that's the response you trained her to give. Grandma also didn't grow up with a padlock icon on her iphone, she had rotary landline. So forget about the grandma argument ok, that'll be gone in a generation, till then it's cryptos who must give elder care.
Question 2: What if Joe and Jane publish a CA or <blah>? They are atypical and all users will still received a certificate validation error when they try connecting to the cluster because the CA isn't...trusted.
Again, you cannot break this by ignoring all of .onion. If they want to be their own CA and give a root to their users, that's their right and expectation of browser standards. It's precisely the in house CA model commonly used in corporate internals and other priviledged or separate cases. It's their choice to opt in and supply the above HS pubkey exception cert for bypass by TBB. Not TBB to remove capabilities from them.
the hidden service's key can simply sign the CA cert or an intermidiate
Multiple services would need to include multiple HS keys and sigs in the CA cert... it's literally a sizable mess and likely not worth it when you can singly opt in or go private CA or buy digicert on your own.
I'm considering the feasibility of delegating verification to tor over the control port
See [1] above.
On 18 November 2014 21:53, grarpamp grarpamp@gmail.com wrote:
On Tue, Nov 18, 2014 at 12:55 PM, George Kadianakis desnacked@riseup.net wrote:
plans for any Tor modifications we want to do (for example, trusting self-signed certs signed by the HS identity key seem like a generally good idea).
If the HS pubkey and the onion CN were both in the cert, and signed over by that same key all corresponding to the url the TBB is currently attempting to validate, that would seem fine to me. No interaction with the controller (which may not even be accessible [1]) needed to get the HS descriptor (pubkey). Security is limited to 80-bits, or the future wider proposal. It's also a TBB specific extension. All other browsers pointed at socks5 somewhere will still rightly fail, unless adopted upstream (which MSIE won't do) or via standards. Note that this is not 'turning off the warnings for all .onion', it's recognizing that attestation of the HS key is sufficient to show ownership of that service. Whereas under various attacks a traditional selfsigned cert is not.
If I've put a .onion url into the address bar in Tor Browser, and it connects me - absent a bug in tor, 80-bit collision, or 1024-bit factoring I know I'm talking to an endpoint on the other side that is authoritative for the public key corresponding to the onion address. At that point, they can tell me whatever they want, and I know I'm still talking to the correct endpoint - like you said, the .onion resolving and succeeding in connecting attested to the service.
So I'm not sure I understand the attacks you're talking about. It's true that if, on the relay hosting the HS, you forwarded it to another machine and that connection was attacked (between your webserver and your HS relay) - the connection would be insecure. But I consider that to be outside Tor. You had a responsibility to make your application secure and you didn't, same as if you had SQL injection.
You mention "All other browsers pointed at socks5 somewhere will still rightly fail" - that's still the case. I'm not talking about putting this .onion SSL bypass stuff into little-t tor, I'm talking about making it a Tor Browser Extension - if that crossed our wires.
-tom
On Wed, Nov 19, 2014 at 1:05 AM, Tom Ritter tom@ritter.vg wrote:
At that point, they can tell me whatever they want
Some of them will ;)
So I'm not sure I understand the attacks you're talking about.
this .onion SSL bypass stuff into little-t tor, I'm talking about making it a Tor Browser Extension - if that crossed our wires.
Cert infrastructures can make linkphisher proxies harder and gives options to users and operators as well as an actual layer of traditional browser to webserver crypto. Disabling warnings there for all of .onion doesn't. And certainly disabling them for pinned certs and CA's wouldn't.
As before, extending TBB to skip warnings for HS pubkey signed certs of respective single onions seems fine.
It's true that if, on the relay hosting the HS, you forwarded it to another machine and that connection was attacked (between your webserver and your HS relay) - the connection would be insecure.
Your webserver can/should enforce TLS for that connection regardless if it's on localhost or the other side of the planet via clearnet or some other transport.
On Tue, Nov 18, 2014 at 10:53:30PM -0500, grarpamp wrote:
On Tue, Nov 18, 2014 at 12:55 PM, George Kadianakis desnacked@riseup.net wrote:
plans for any Tor modifications we want to do (for example, trusting self-signed certs signed by the HS identity key seem like a generally good idea).
If the HS pubkey and the onion CN were both in the cert, and signed over by that same key all corresponding to the url the TBB is currently attempting to validate, that would seem fine to me. No interaction with the controller (which may not even be accessible [1]) needed to get the HS descriptor (pubkey). Security is limited to 80-bits, or the future wider proposal. It's also a TBB specific extension. All other browsers pointed at socks5 somewhere will still rightly fail, unless adopted upstream (which MSIE won't do) or via standards. Note that this is not 'turning off the warnings for all .onion', it's recognizing that attestation of the HS key is sufficient to show ownership of that service. Whereas under various attacks a traditional selfsigned cert is not.
Ah, great. Adding the pubkey to the cert is a nice idea, as well.
M. Finkel: habit, where we're conditioning the younger generation to click-through,
It's suggested the right training is to teach the contexts in which they should care... banking, email, accounts, etc... and then to in fact just click through (everyday browsing) unless they're under a context where they actually care. Even though you have the helmet, you train and care wear a helmet for racing, not walking. The mandantory warnings are there for people who care about their context, not those who don't. My beef is that it requires more than one click in FF to get through.
Understood and I agree (though I'm not sure that analogy is great but oh well ;) ). With regard to the warning, I think I'm most opposed to it because it's so unuseful to most people. We're already using TOFU for this, so if there was a single button that makes it simple for the common-case, then I'd be happy with that.
This still raises the unfortunate question of whether anyone knows what to do if they get the invalid cert warning from their bank's website, but that's for another thread.
To be clear, I think it's critically important that the user is told when security assumptions are broken, but I'm opposed to keeping the current error page if we have the ability to make it better. I hope this was understood in my email, but maybe I failed at that. I don't want to get rid of the error message, but I want Tor to be able to provide a way for operators to use TLS certs where these certs provide the necessary assurances and don't cause the error condition. Where, as a result, a user will only see the cert error if the operator intended them to see it or if the connection was MITM. I think we all agree on this.
Yes, I did say "Eliminating self-signed certificate errors when connecting to hidden service sites will be a significant usability improvement.". I guess that was poorly worded and I didn't take into account operators/administrators who want their users to see the error and add a special exception for their cert, sorry. I simply want a way for a HS operator to be able to create a self-signed cert for their website and not force every visitor to their site to add an exception for that cert.
-
Adam Shostack -
George Kadianakis -
grarpamp -
Griffin Boyce -
Jacob Appelbaum -
Jeremy Rand -
Jeremy Rowley -
Lee -
Matthew Finkel -
Tom Ritter