Hello everyone,
I've pretty much completed a proof of concept of my SIM4Things project (an IP6 overlay for the Internet of Things running on top of Tor with persistent secure cryptographic identities tied to physical SIM cards). I've developed against the current hidden service infrastructure and it appears to work like a charm, but I'm a bit worried about Prop224. That will break both the OnionBalance-like service re-registration that I'm using _and_ the OnionCat HS to IP6 mapping. I know that efforts are in place to upgrade the two in view of Prop224 but I'm wondering if there's any good reason to drop support for "old style" hidden services once Prop224 is fully deployed.
What does everyone think? My vote would obviously be to keep it around, even if it's no longer the default. Do you see any security implications in doing so? Is there any hard reason to drop the existing model altogether at some point and if so, what is the plan for transition? My hidden services would be very low traffic (Internet of Things, sensor measurements, etc) but hard to upgrade in the field. Also, by design, we have no control over the endpoints once deployed (only their owner can access them), so we cannot force an upgrade, we can just suggest it to the owner and come up with a procedure for them to do so.
Any ideas?
Thank you, Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
Hi Razvan,
Razvan Dragomirescu:
I've developed against the current hidden service infrastructure and it appears to work like a charm, but I'm a bit worried about Prop224. That will break both the OnionBalance-like service re-registration that I'm using _and_ the OnionCat HS to IP6 mapping. I know that efforts are in place to upgrade the two in view of Prop224 but I'm wondering if there's any good reason to drop support for "old style" hidden services once Prop224 is fully deployed.
No worries, prop224 is not going to break OnionBalance-like re-registration - it's just going to make it more complicated. One will have to perform cross-certification trickery in order to reassemble intropoints of another onion service. We want to avoid this plain "re-registration" since anyone can do it (for details see #15951 [1]). The way out is to add a feature into little-t-tor and to rewrite tools like OnionBalance, avant, etc to fetch intropoint list from backend services directly (via ControlPort or special onion address) thus going without posting useless descriptors to HSDirs and fetch them from HSDirs again.
Yes, in case of OnionCat onion<->IPv6 mapping we got a problem. It's just because address length is 80bit for legacy, 256bit for prop224 and <128bit for IPv6. And one have to use something additional (like DHT for cjdns) to "resolve" short IPv6 into larger Ed25519. Apparently IPv6 is good but not enough to be used as public keys. IMO we need something better* for this.
Also you'll likely have issues with migration from RSA1024 to Ed25519 on your smartcards. Most (Java) cards I know have built-in RSA engine and any additional crypto may not fit in or be slow.
So my two cents is to migrate to prop224 as soon as possible and make everyone secure (RSA1024 and SHA1 are baaaad).
* Maybe just hostnames with variable length? [1] https://trac.torproject.org/projects/tor/ticket/15951 -- Ivan Markin
Thank you Ivan! I still dont see a very good reason to _replace_ the current HS system with the one in Prop224 and not run the two in parallel. Why not let the client decide what format and security features it wants for its services?
Razvan
On 13 Sep 2016 00:37, "Ivan Markin" twim@riseup.net wrote:
Hi Razvan,
Razvan Dragomirescu:
I've developed against the current hidden service infrastructure and it appears to work like a charm, but I'm a bit worried about Prop224. That will break both the OnionBalance-like service re-registration that I'm using _and_ the OnionCat HS to IP6 mapping. I know that efforts are in place to upgrade the two in view of Prop224 but I'm wondering if there's any good reason to drop support for "old style" hidden services once Prop224 is fully deployed.
No worries, prop224 is not going to break OnionBalance-like re-registration - it's just going to make it more complicated. One will have to perform cross-certification trickery in order to reassemble intropoints of another onion service. We want to avoid this plain "re-registration" since anyone can do it (for details see #15951 [1]). The way out is to add a feature into little-t-tor and to rewrite tools like OnionBalance, avant, etc to fetch intropoint list from backend services directly (via ControlPort or special onion address) thus going without posting useless descriptors to HSDirs and fetch them from HSDirs again.
Yes, in case of OnionCat onion<->IPv6 mapping we got a problem. It's just because address length is 80bit for legacy, 256bit for prop224 and <128bit for IPv6. And one have to use something additional (like DHT for cjdns) to "resolve" short IPv6 into larger Ed25519. Apparently IPv6 is good but not enough to be used as public keys. IMO we need something better* for this.
Also you'll likely have issues with migration from RSA1024 to Ed25519 on your smartcards. Most (Java) cards I know have built-in RSA engine and any additional crypto may not fit in or be slow.
So my two cents is to migrate to prop224 as soon as possible and make everyone secure (RSA1024 and SHA1 are baaaad).
- Maybe just hostnames with variable length?
[1] https://trac.torproject.org/projects/tor/ticket/15951
Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Razvan Dragomirescu:
Thank you Ivan! I still dont see a very good reason to _replace_ the current HS system with the one in Prop224 and not run the two in parallel.
For me it's because it would make overall system more complex and thus error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in TLS and be vulnerable downgrade attacks and all kind of stuff like Sweet32 and LogJam (export-grade onions, haha).
Why not let the client decide what format and security features it wants for its services?
It's like dealing with plethora of ciphers and hashes in GnuPG:
https://moxie.org/blog/gpg-and-me/:
It’s up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish. The GnuPG man page is over sixteen thousand words long; for comparison, the novel Fahrenheit 451 is only 40k words.
When system is complex in that way someone is going make huge mistake(s). If crypto is bad, just put it into museum.
So I don't see _any_ reason to manage outdated and less secure system while we have a better option (if we already deployed it).
-- Ivan Markin
Hello Ivan,
Breaking existing (possibly automated) systems is a _very good reason_ IMHO :). Sure, warn the operators that they're using a legacy system, deprecate the option but don't disable it. https://trac.torproject.org/projects/tor/ticket/18054 sounds like a pretty sane solution btw.
Even if it's no longer officially supported, I think OnionCat in its current incarnation is a great proof of what could be done with the Tor network, other than privacy protection. I actually have this listed on one of my slides for SIM4Things - it's good for the Tor network, shows it can be used for a variety of things while putting very little stress on the network components. Very little traffic, potentially large PR impact (in a good way :) ).
Razvan
On Tue, Sep 13, 2016 at 1:29 AM, Ivan Markin twim@riseup.net wrote:
Razvan Dragomirescu:
Thank you Ivan! I still dont see a very good reason to _replace_ the current HS system with the one in Prop224 and not run the two in parallel.
For me it's because it would make overall system more complex and thus error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in TLS and be vulnerable downgrade attacks and all kind of stuff like Sweet32 and LogJam (export-grade onions, haha).
Why not let the client decide what format and security features it wants for its services?
It's like dealing with plethora of ciphers and hashes in GnuPG:
https://moxie.org/blog/gpg-and-me/:
It’s up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish. The GnuPG man page is over sixteen thousand words long; for comparison, the novel Fahrenheit 451 is only 40k words.
When system is complex in that way someone is going make huge mistake(s). If crypto is bad, just put it into museum.
So I don't see _any_ reason to manage outdated and less secure system while we have a better option (if we already deployed it).
-- Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 12 Sep (22:29:00), Ivan Markin wrote:
Razvan Dragomirescu:
Thank you Ivan! I still dont see a very good reason to _replace_ the current HS system with the one in Prop224 and not run the two in parallel.
For me it's because it would make overall system more complex and thus error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in TLS and be vulnerable downgrade attacks and all kind of stuff like Sweet32 and LogJam (export-grade onions, haha).
Why not let the client decide what format and security features it wants for its services?
It's like dealing with plethora of ciphers and hashes in GnuPG:
https://moxie.org/blog/gpg-and-me/:
It’s up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish. The GnuPG man page is over sixteen thousand words long; for comparison, the novel Fahrenheit 451 is only 40k words.
When system is complex in that way someone is going make huge mistake(s). If crypto is bad, just put it into museum.
So I don't see _any_ reason to manage outdated and less secure system while we have a better option (if we already deployed it).
Hello!
So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite complex, lots of pieces need to be glued together and prop224 will add a lot of new code (in the 10 of thousand+).
We decided a while back to have the two protocols living side by side at first that is current system (v2) and next gen (v3). Relays will need to support v2 for a while after v3 is release because well not everybody updates their tor to the latest. Lots of people have current .onion for which they need a transition to the new generation which includes telling their users about the new 52 character one and SSL certs and so on...
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to v3 or make them both happy together...? We haven't discuss this in depth and thus we need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a transition path and thus have maybe a torrc option that controls that behavior meaning allowing v2 for which we enable by default at first and then a subsequent Tor release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an other release thus offering a deprecation path.
However, we are clear that every _new_ service will be v3 and never again v2 unless it already exists that is we can find a RSA private key (considering we do the above of course). And considering both will be supported for a while, we'll have to maintain v2 security wise but all new features will go in v3.
Let's discuss it and together we can come up with a good plan! :)
Thanks! David
-- Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 9/13/2016 3:27 PM, David Goulet wrote: [SNIP]
Hello!
So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite complex, lots of pieces need to be glued together and prop224 will add a lot of new code (in the 10 of thousand+).
We decided a while back to have the two protocols living side by side at first that is current system (v2) and next gen (v3). Relays will need to support v2 for a while after v3 is release because well not everybody updates their tor to the latest. Lots of people have current .onion for which they need a transition to the new generation which includes telling their users about the new 52 character one and SSL certs and so on...
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to v3 or make them both happy together...? We haven't discuss this in depth and thus we need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a transition path and thus have maybe a torrc option that controls that behavior meaning allowing v2 for which we enable by default at first and then a subsequent Tor release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an other release thus offering a deprecation path.
However, we are clear that every _new_ service will be v3 and never again v2 unless it already exists that is we can find a RSA private key (considering we do the above of course). And considering both will be supported for a while, we'll have to maintain v2 security wise but all new features will go in v3.
Let's discuss it and together we can come up with a good plan! :)
Thanks! David
v2= old-style (RSA1024) hidden services v3= prop 224 (ed25519) hidden services
I agree with David - it will be problematic to maintain support for both v2 and v3, unlimited in the future. It's clear that we need to offer a reasonable transition period, so everyone can upgrade and move their customers/user bases to the new hidden services, but this doesn't mean v2 should work forever.
v2 hidden services already provide questionable security (from crypto point of view) and in the future things will only get worse for v2. I agree that there are a lot of third party tools working with v2 hidden services (OnionCat, OnionBalance) - these all need to be improved to support prop 224 hidden services.
Considerable resources are spent on v3 hidden services. They are better vs v2 from all points of view, I don't think keeping the v2 code and therefor allowing additional attack surface + creating the task to maintain this old code (v2) in future releases is worth it. This is how things work in software, if something gets upgraded everything upper layer should upgrade as well. Keeping parallel older versions to allow a feature of non-mandatory upgrades is not solid reason for us to do it.
Also, we need to move with Prop 245 (deprecate TAP handshake entirely) and the v2 hidden service code is the blocker for this.
So, my opinion is to deprecate v2 entirely after a sane and reasonable transition period. Apologies to whom this will create headaches - technologically everything can be adjusted to v3 hidden services, it's just some work required -- it's not going to be fun but it's the clean way for the longer term future.
I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a bit of a pipe dream.
Tor hidden services are a bit "special" because it's hard to poll their owners on their intentions. Some hidden service operators have gone to great lengths to advertise their .onion URLs (v2-style), some have even generated vanity addresses (like Facebook). Forcing a switch to v3 at some point presents a very interesting opportunity for phishing because suddenly a service known and trusted at some address (as opaque as it is) would need to move to an even more opaque address, with no way to determine if the two are really related, run by the same operator, etc. If I were a LE agency, I would immediately grab v3 hidden services, proxy content to existing v2 services and advertise my v3 URL everywhere, then happily monitor traffic.
All I'm saying is don't remove the v2 services, even if you choose to no longer support them. Some operators (like my company) may choose to continue to patch the v2 areas if required and release the patches to the community at large. Forcing us out altogether would make us drop Tor and start using an alternative network or expending the additional effort to make our services network-agnostic (so no more good PR for Tor).
Ivan was right, moving to v3 would be, at least for my project, extremely complex and unwieldy. Ed25519 is not supported by any smartcards I know (but can be "hacked" by manually defining Curve25519 params and converting back and forth). But then we'd have to modify the service re-registration (or wait for OnionBalance to do it), then add another layer for OnionCat-like lookups, etc. It would be far easier to just drop the Tor dependency at that point or centralize it a bit more.
Just my 2 cents, if any hidden service operators wish to chime in, feel free to do so. After all, it's us (them? :) ) that will have to make the changes to their services.
Razvan
On Tue, Sep 13, 2016 at 5:40 PM, s7r s7r@sky-ip.org wrote:
On 9/13/2016 3:27 PM, David Goulet wrote: [SNIP]
Hello!
So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is
quite
complex, lots of pieces need to be glued together and prop224 will add a
lot
of new code (in the 10 of thousand+).
We decided a while back to have the two protocols living side by side at
first
that is current system (v2) and next gen (v3). Relays will need to
support v2
for a while after v3 is release because well not everybody updates their
tor
to the latest. Lots of people have current .onion for which they need a transition to the new generation which includes telling their users
about the
new 52 character one and SSL certs and so on...
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to
v3 or
make them both happy together...? We haven't discuss this in depth and
thus we
need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a
transition
path and thus have maybe a torrc option that controls that behavior
meaning
allowing v2 for which we enable by default at first and then a
subsequent Tor
release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an
other
release thus offering a deprecation path.
However, we are clear that every _new_ service will be v3 and never
again v2
unless it already exists that is we can find a RSA private key
(considering we
do the above of course). And considering both will be supported for a
while,
we'll have to maintain v2 security wise but all new features will go in
v3.
Let's discuss it and together we can come up with a good plan! :)
Thanks! David
v2= old-style (RSA1024) hidden services v3= prop 224 (ed25519) hidden services
I agree with David - it will be problematic to maintain support for both v2 and v3, unlimited in the future. It's clear that we need to offer a reasonable transition period, so everyone can upgrade and move their customers/user bases to the new hidden services, but this doesn't mean v2 should work forever.
v2 hidden services already provide questionable security (from crypto point of view) and in the future things will only get worse for v2. I agree that there are a lot of third party tools working with v2 hidden services (OnionCat, OnionBalance) - these all need to be improved to support prop 224 hidden services.
Considerable resources are spent on v3 hidden services. They are better vs v2 from all points of view, I don't think keeping the v2 code and therefor allowing additional attack surface + creating the task to maintain this old code (v2) in future releases is worth it. This is how things work in software, if something gets upgraded everything upper layer should upgrade as well. Keeping parallel older versions to allow a feature of non-mandatory upgrades is not solid reason for us to do it.
Also, we need to move with Prop 245 (deprecate TAP handshake entirely) and the v2 hidden service code is the blocker for this.
So, my opinion is to deprecate v2 entirely after a sane and reasonable transition period. Apologies to whom this will create headaches - technologically everything can be adjusted to v3 hidden services, it's just some work required -- it's not going to be fun but it's the clean way for the longer term future.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a bit of a pipe dream.
Your analogy with IPv4 and IPv6 is unacceptable. IPv6 exists not because IPv4 isn't secure, but because the address space got filled up (internet grew). Of course it has some improvements compared to IPv4 but we cannot say IPv4 has questionable security. I don't think we can speak about security in IP context anyway since there are other protocols where this happens (BGP,TCP etc.). And they do exist in parallel with perspective to migrate to IPv6 entirely in the future (obviously v2 and v3 hidden services will have a migration period also, just not so large because we aren't talking about the entire internet here).
Tor hidden services are a bit "special" because it's hard to poll their owners on their intentions. Some hidden service operators have gone to great lengths to advertise their .onion URLs (v2-style), some have even generated vanity addresses (like Facebook). Forcing a switch to v3 at some point presents a very interesting opportunity for phishing because suddenly a service known and trusted at some address (as opaque as it is) would need to move to an even more opaque address, with no way to determine if the two are really related, run by the same operator, etc. If I were a LE agency, I would immediately grab v3 hidden services, proxy content to existing v2 services and advertise my v3 URL everywhere, then happily monitor traffic.
I am not sure what you mean by grabbing v3 hidden services (generating random ed25519 keys?) and how exactly you are going to proxy anything to the v2 hidden service without access to v2's private key? But regardless of how you have in mind to do this, your points are wrong.
Maintaining v2 services just because operators advertised the v2 onion url style is not an argument. RSA1024 will be easily factored in coming years. We have strong reasons to believe factoring RSA1024 at current moment is not impractical if the target is worth it enough. So, if we allow v2 services forever, we increase the chances for a LE to hijack v2 hidden services by factoring their private keys - this risk is bigger than what you are describing. For the second part, there are plenty ways to prove a v2 hidden service is tied to a v3 one, given you control v2's private key. It provides exactly the same level of cryptographic certification.
All I'm saying is don't remove the v2 services, even if you choose to no longer support them. Some operators (like my company) may choose to continue to patch the v2 areas if required and release the patches to the community at large. Forcing us out altogether would make us drop Tor and start using an alternative network or expending the additional effort to make our services network-agnostic (so no more good PR for Tor).
This doesn't sound good. Would your company ship to its users code that you do not support yourself, but relying on third parties to do so? Relying on a third party company for patches doesn't sound comfortable to me (with all due respect, I am sure your company is able to do it without problems, I just don't think it's professional this way). Rather than trying to spend time to code patches for the old v2 code why not spend that time and make your services compatible with v3 hidden services? OnionBalance and OnionCat will find ways to work with v3 hidden services.
Ivan was right, moving to v3 would be, at least for my project, extremely complex and unwieldy. Ed25519 is not supported by any smartcards I know (but can be "hacked" by manually defining Curve25519 params and converting back and forth). But then we'd have to modify the service re-registration (or wait for OnionBalance to do it), then add another layer for OnionCat-like lookups, etc. It would be far easier to just drop the Tor dependency at that point or centralize it a bit more.
Just my 2 cents, if any hidden service operators wish to chime in, feel free to do so. After all, it's us (them? :) ) that will have to make the changes to their services.
Not only clients. Also, the relays -- hidden service directories -- for example I don't want to host v2 descriptors on my relays after prop 224 is implemented.
I fully agree with the security points, I was just arguing for keeping the _option_ to list a v2 service for a longer time (possibly forever). Let's not make assumptions for the service operators - ok, make them enable the option explicitly, have them do it at compile time if you want to (like Tor2Web) but don't remove it just because you think the alternative is better. Some services (like mine) are not worthy targets for a LEA (unless they're interested in hacking your fridge), Tor is interesting to us because of its NAT traversal capabilities and cryptographic service authentication.
Don't assume that all users have the same goals and they are all fighting well funded or state-level attackers. Another option to be honest would be for us to just fork Tor at the time v2 services are removed altogether and spin a few directory authorities of our own and a few relays around the world (we send very little traffic) and call it a day. Tor can continue onwards with the v3-only services while our Tor fork would be happily using v2, separate from the main network (and less subject to attacks from well funded attackers and DDOS operators interested in revealing activists' identities and not in finding out that you're out of cheese in your fridge). I think there's potential in making a simpler, slightly less secure version of Tor but with significantly improved user experience.
Oh, and no, I wasn't planning on having the Onion Balance and OnionCat devs fix bugs for us :). I just didn't want to duplicate effort, so if they have a plan to adapt their tools to v3, I'd rather wait for their solution than do a half-baked one of our own.
Razvan
On Tue, Sep 13, 2016 at 10:31 PM, s7r s7r@sky-ip.org wrote:
On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a bit of a pipe dream.
Your analogy with IPv4 and IPv6 is unacceptable. IPv6 exists not because IPv4 isn't secure, but because the address space got filled up (internet grew). Of course it has some improvements compared to IPv4 but we cannot say IPv4 has questionable security. I don't think we can speak about security in IP context anyway since there are other protocols where this happens (BGP,TCP etc.). And they do exist in parallel with perspective to migrate to IPv6 entirely in the future (obviously v2 and v3 hidden services will have a migration period also, just not so large because we aren't talking about the entire internet here).
Tor hidden services are a bit "special" because it's hard to poll their owners on their intentions. Some hidden service operators have gone to great lengths to advertise their .onion URLs (v2-style), some have even generated vanity addresses (like Facebook). Forcing a switch to v3 at some point presents a very interesting opportunity for phishing because suddenly a service known and trusted at some address (as opaque as it is) would need to move to an even more opaque address, with no way to determine if the two are really related, run by the same operator, etc. If I were a LE agency, I would immediately grab v3 hidden services, proxy content to existing v2 services and advertise my v3 URL everywhere, then happily monitor traffic.
I am not sure what you mean by grabbing v3 hidden services (generating random ed25519 keys?) and how exactly you are going to proxy anything to the v2 hidden service without access to v2's private key? But regardless of how you have in mind to do this, your points are wrong.
Maintaining v2 services just because operators advertised the v2 onion url style is not an argument. RSA1024 will be easily factored in coming years. We have strong reasons to believe factoring RSA1024 at current moment is not impractical if the target is worth it enough. So, if we allow v2 services forever, we increase the chances for a LE to hijack v2 hidden services by factoring their private keys - this risk is bigger than what you are describing. For the second part, there are plenty ways to prove a v2 hidden service is tied to a v3 one, given you control v2's private key. It provides exactly the same level of cryptographic certification.
All I'm saying is don't remove the v2 services, even if you choose to no longer support them. Some operators (like my company) may choose to continue to patch the v2 areas if required and release the patches to the community at large. Forcing us out altogether would make us drop Tor and start using an alternative network or expending the additional effort to make our services network-agnostic (so no more good PR for
Tor).
This doesn't sound good. Would your company ship to its users code that you do not support yourself, but relying on third parties to do so? Relying on a third party company for patches doesn't sound comfortable to me (with all due respect, I am sure your company is able to do it without problems, I just don't think it's professional this way). Rather than trying to spend time to code patches for the old v2 code why not spend that time and make your services compatible with v3 hidden services? OnionBalance and OnionCat will find ways to work with v3 hidden services.
Ivan was right, moving to v3 would be, at least for my project, extremely complex and unwieldy. Ed25519 is not supported by any smartcards I know (but can be "hacked" by manually defining Curve25519 params and converting back and forth). But then we'd have to modify the service re-registration (or wait for OnionBalance to do it), then add another layer for OnionCat-like lookups, etc. It would be far easier to just drop the Tor dependency at that point or centralize it a bit more.
Just my 2 cents, if any hidden service operators wish to chime in, feel free to do so. After all, it's us (them? :) ) that will have to make the changes to their services.
Not only clients. Also, the relays -- hidden service directories -- for example I don't want to host v2 descriptors on my relays after prop 224 is implemented.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
I agree with both s7r and Lunar here. Just want to add some bits:
I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a bit of a pipe dream.
The main goal of Tor Project is privacy and security _for everyone by default_. If Tor is going to end up like PGP... it's a nightmare. ["Hey, are you using new onion or old onion?", "Hm, I don't know. Maybe it's better to go with normal Internet? At least it works.".] If you don't care much about security/privacy/anonymity and look for a "crypto-identified network" with NAT traversal - Tor is not _the_ network you're looking for. And yes, IPv4 is still around since it's "just technology" and isn't tied to security. One can use outdated technology (I do, a lot) but not use _outdated security_ ["outdated security" hardly can be called security - a white horse is not a horse]. So ISPs can use IPv4 for any reason until the Sun become a supernova and may not care about CGNAT and all this crazy stuff - it doesn't _threat_ anyone* except their budget.
Tor hidden services are a bit "special" because it's hard to poll their owners on their intentions. Some hidden service operators have gone to great lengths to advertise their .onion URLs (v2-style), some have even generated vanity addresses (like Facebook). Forcing a switch to v3 at some point presents a very interesting opportunity for phishing because suddenly a service known and trusted at some address (as opaque as it is) would need to move to an even more opaque address, with no way to determine if the two are really related, run by the same operator, etc. If I were a LE agency, I would immediately grab v3 hidden services, proxy content to existing v2 services and advertise my v3 URL everywhere, then happily monitor traffic.
It's not going to happen. You have v2 private key and your new v3 private key. Now you cross-certify them** and teach your users to use new address. If you've spent zillions of core-hours on generating a nice-looking address on top of RSA1024 (can be factored now[1]) and truncated (!) SHA-1 (someone probably can afford collisions now [2]) - congratulations.
NSA:
Attacks always get better; they never get worse.
Also, one shouldn't rely on secret keys as you've mentioned. It shouldn't be an apocalypse if you lost/compromised your key.
All I'm saying is don't remove the v2 services, even if you choose to no longer support them. Some operators (like my company) may choose to continue to patch the v2 areas if required and release the patches to the community at large. Forcing us out altogether would make us drop Tor and start using an alternative network or expending the additional effort to make our services network-agnostic (so no more good PR for Tor).
No problem, just run your personal Tor network in your corporate environment - Tor is free software. It's not as hard as you may think. And you're always welcome to contribute back. Also it's good since you may find out some edge-cases or complicated bugs that could harm The Tor Network at some point. Just for the record, probably a good choice for your use case here is to stick with cjdns [3]. It provides IPv6 "cryptoaddress" and mesh networking and other cool stuff. You don't have to have authorities and don't have to use OnionCat. It just works. But it's different from Tor in many ways. The major difference - it's not anonymous.
* Yes, it does break end-to-end principle and makes the Internet less fault-resistant etc, etc. Anyway, the Internet is already broken. Deal with it. ** It definitely needs a proposal. :) Maybe I missed one? Something like xxx-rsa1024-rend-id-migration.txt.
[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
https://media.ccc.de/v/32c3-7288-logjam_diffie-hellman_discrete_logs_the_nsa... [2] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html [3] https://github.com/cjdelisle/cjdns -- Ivan Markin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
s7r:
So, my opinion is to deprecate v2 entirely after a sane and reasonable transition period. Apologies to whom this will create headaches - technologically everything can be adjusted to v3 hidden services, it's just some work required -- it's not going to be fun but it's the clean way for the longer term future.
For what its worth, we now have a social contract [1] that can help us evaluate such decisions.
In any cases, v2 onion services are broken in several aspects. I think this is good be advertised even more (point 5, being honest about limits). The outdated crypto primitives are not my main concerns. I think the fact that an HSDir can learn onion service addresses, refuse to serve them, or track connections is really bad.
Once v3 onion services are deployed, I believe the current set of problems in v2 conflict with social contract point 6, “we will never intentionally harm our users”. Having them continue to use a technology that doesn't deliver its initial promises when a better option is available feels like intentional harm to me.
YMMV, obviously, but I think this is a good framework for having a discussion. (Should we move this to -project? Not sure.)
[1]: https://blog.torproject.org/blog/tor-social-contract [2]: https://blog.torproject.org/blog/hidden-services-need-some-love See “Attacks by Hidden Service Directory Servers”
- -- Lunar lunar@torproject.org
On 14 Sep 2016, at 00:40, s7r s7r@sky-ip.org wrote:
Also, we need to move with Prop 245 (deprecate TAP handshake entirely) and the v2 hidden service code is the blocker for this.
As an aside, if it wasn't for v2 hidden services, we could have removed TAP entirely in 0.2.9. Instead, we made ntor (the upgraded handshake) mandatory almost everywhere, except hidden service client intro and server rendezvous. (And we made ntor onion keys mandatory for relays as well.) https://trac.torproject.org/projects/tor/ticket/19163
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
Forking this thread to discuss onion service transition path.
David Goulet:
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to v3 or make them both happy together...? We haven't discuss this in depth and thus we need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a transition path and thus have maybe a torrc option that controls that behavior meaning allowing v2 for which we enable by default at first and then a subsequent Tor release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an other release thus offering a deprecation path.
We can add arbitrary fields into descriptors. So we can build up kinda "aliases". What comes to mind first:
Onion Service Operator Publishes v2 descriptor with v3 cross-certification. Publishes somewhere their v3 address and cross-cert*. v2-only client Uses v2 service. v3-compatible client Takes v3 address from a descriptor for requested v2 address. Makes a connection to v3 address that looks like a connection to v2 for the end user. There should be no v3->v2 downgrade option. One-way ticket. v3-only client Uses v3 service.
Also, there should not be any torrc options, I think. There is no behavior to control so there is no need to make this transition even more sophisticated.
* There should be a simple tool to generate and verify cross-certifications. Like signify(1) from OpenBSD. Or even simpler. Probably something that even built into TBB.
Don't know if such transparent connection thing is secure or not. It seems to be as secure as v2 services. Thoughts?
-- Ivan Markin
On 13 Sep (21:45:00), Ivan Markin wrote:
Forking this thread to discuss onion service transition path.
David Goulet:
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to v3 or make them both happy together...? We haven't discuss this in depth and thus we need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a transition path and thus have maybe a torrc option that controls that behavior meaning allowing v2 for which we enable by default at first and then a subsequent Tor release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an other release thus offering a deprecation path.
Ok Ok. I'm going to TL;DR; the previous thread here to make sense of what's down there written by Ivan.
It seems everyone agrees on a transition path from v2 to v3. There was a debate about if we should kill v2 after some time in favor of _only_ having v3. Security arguments were raised which was also tied to Tor's mission statement (thx Lunar!). From the maintaining perspective, it does NOT make sense to keep v2 over time as 1) it's broken by design and 2) the security of it is bad (RSA1024 and SHA1 and TAP). The HS subsystem is a very complex one for which we should keep maintaining only if we have confidence that it's safe to be used which fails for v2 because of 1) as for starter. So I personally believe it's Tor's duty to provide a transition path and drop a unsecure protocol else we litterally put user at risk which is bottom line for me unacceptable and supersede any other argument about how it's being used in some stable way (like let's say IoT).
That being said, if someone still doesn't agree, raise your voice with arguments that haven't been heard yet. If you also want to add more arguments in favor of dropping v2, you are welcome to do so! :)
One issue raised here by Ivan is a way to cross-certify v2 -> v3 where a service would like to provide this mechanism for client to confirm they do have the right v3 address for the great-leaking-platform.onion v2 :).
We can add arbitrary fields into descriptors. So we can build up kinda "aliases". What comes to mind first:
Onion Service Operator Publishes v2 descriptor with v3 cross-certification. Publishes somewhere their v3 address and cross-cert*. v2-only client Uses v2 service. v3-compatible client Takes v3 address from a descriptor for requested v2 address. Makes a connection to v3 address that looks like a connection to v2 for the end user. There should be no v3->v2 downgrade option. One-way ticket. v3-only client Uses v3 service.Also, there should not be any torrc options, I think. There is no behavior to control so there is no need to make this transition even more sophisticated.
I think there might be one. An operator should have the choice to cross-certify a v2 -> v3 linking the two .onion together. I for instance have lots of .onion that I might not want people to link the v3 to the v2. So I should have a way to tell Tor to leave my v2 alone during the transition period.
The thing that worries me about the approach of: "Publishes somewhere their v3 address and cross-cert*."
... is the amount of more traffic and complexity we had to the network for such a thing. I for sure don't want Tor to maintain some sorts of registry here just for a transition period that ultimately will die. Anyway, Tor shouldn't have to provide infrastructure for the actual network to work well.
What if the operator has a torrc option that says "Please use this v2 HS and cross certify it with the v3.". Out of my head (just an example):
HiddenServiceDir /my/service/one HiddenServicePort ... HiddenServiceLinkedWithV3 1
HiddenServiceDir /my/service/two HiddenServicePort ... HiddenServiceLinkedWithV3 0 /* Would be off by default to avoid linkability. */
Which adds fields to the v3 descriptor including a v2 signing key? in order to avoid the client to fetch the v2 descriptor. Something I don't like about this is that we introduce a torrc option _and_ descriptor fields that will get obsolete when v2 is dropped... and that only informed power user will be able to understand what the hell is going on (but that we can maybe fix with good documentation, blog post and good practices guide).
We should also consider if it's really Tor's job to do this. Maybe it's OK to leave this job to the operators to deal with the v2 <-> v3 advertisement by themselves?
My guts tell me that I would like to have v3 tied to v2 as little as possible really but I also want current .onion operator to be able to provide maximum security for their users _especially_ when a .onion is very difficult to give around in some harsh political context.
Thoughts? Brainstorming time! :)
Cheers! David
- There should be a simple tool to generate and verify
cross-certifications. Like signify(1) from OpenBSD. Or even simpler. Probably something that even built into TBB.
Don't know if such transparent connection thing is secure or not. It seems to be as secure as v2 services. Thoughts?
-- Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
David Goulet:
The thing that worries me about the approach of: "Publishes somewhere their v3 address and cross-cert*."
... is the amount of more traffic and complexity we had to the network for such a thing. I for sure don't want Tor to maintain some sorts of registry here just for a transition period that ultimately will die. Anyway, Tor shouldn't have to provide infrastructure for the actual network to work well.
No-no-no! By saying "somewhere" I meant "manually and out-of-band" (e.g. on the site itself, via OTR chat, wall paintings etc). There is no mechanism to notify Tor user (hopefully!) about such change. Tor just provides a transport and nothing else.
What if the operator has a torrc option that says "Please use this v2 HS and cross certify it with the v3.". Out of my head (just an example):
HiddenServiceDir /my/service/one HiddenServicePort ... HiddenServiceLinkedWithV3 1 HiddenServiceDir /my/service/two HiddenServicePort ... HiddenServiceLinkedWithV3 0 /* Would be off by default to avoid linkability. */
Personally I'm absolutely against any new torrc options. It's hard to find this file, edit it, restart tor after (okay-okay I'm biased towards Control and stateless tor here). It also introduces LengthyStingsThatAreTooHardToReadAndWhatIsToSayAboutRemember.
We should also consider if it's really Tor's job to do this. Maybe it's OK to leave this job to the operators to deal with the v2 <-> v3 advertisement by themselves?
My guts tell me that I would like to have v3 tied to v2 as little as possible really but I also want current .onion operator to be able to provide maximum security for their users _especially_ when a .onion is very difficult to give around in some harsh political context.
Agreed. To make clearer what I mean:
I meant a userspace tool (maybe embedded into little-t-tor, TBB for verification) that takes v2 private key and v3 address and creates cross-ceritification v2->v3 (a signature):
$ onionxcert /path/to/v2-private-key v3-address.onion base32-encoded-rsa-signature
Also it takes v3 private key and signs this cross-certification:
$ onionxcert /path/to/v3-private-key base32-encoded-rsa-signature base32-encoded-cross-cert
Afterwards operator publishes (as described above) this document 1024+64=1536 (~308chars) along with v3 onion address. It could be even "human-readable" (copypastable) :
llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion base32-encoded-cross-cert-2gyzmtmgxjyqyorj9qsb5r543izcwy mh2gyzmtmgxjyqyorj9qsb5r543izcwyml2gyzmtmgxjyqyorj9qsb5r 543izcwyml2gyzmtmgxjyqyorj9qsb5r543izcwyml2gyzmtmgxjyqyo rj9qsb5r543izcwyml2gyzmtmgxjyqyorj9qsb5r543izcwyml2gyzmt mgxjyqyorj9qsb5r543izcwymlml2gyzmtmgxjyqyorj9qsb5r543izc wymlml2gyzmtmgxjyqyorj9qsb
End user verifies it like this:
$ onionxcert -v2 grapelookcorewwwi -v3 llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle base32-encoded-cross-cert OK.
[Yes, it requires an HSDir fetch to get full RSA key].
Then it can also be included into v2 descriptor if the operator wishes so. (torrc option? :/ modified private key file?)
After all this stuff happened, we can make a transparent connection over verified v3 onion service that seems like it's still a v2 address for the end user. At some point users update their address book and get happy. We can also perform funny trick of v2 - publish "alias" v2 descriptors without any intropoints and thus making no v2 service.
Thoughts, comments?
... that only informed power user will be able to understand what the hell is going on (but that we can maybe fix with good documentation, blog post and good practices guide).
It's better not to break. :)
-- Ivan Markin
-
David Goulet -
Ivan Markin -
Lunar -
Razvan Dragomirescu -
s7r -
teor