Re: [tor-dev] Onion Client Auth on v3 descriptor via Control port
Hi George, On Wed, Jun 17, 2020 at 12:37:18PM +0300, George Kadianakis wrote: > > Hmm, this is a bit embarassing for both of us, but if I'm not mistaken > ONION_CLIENT_AUTH_ADD only controls the client-side of client auth > credentials. This is not obvious at all by the command name, and it only > becomes a bit clearer by reading the control-spec.txt... > > We added that control port command so that the browser could present a > UX for client authorization. Ahahahah. Riiight, thanks for that clarification. This whole time I indeed thought this was a novel way for adding Client Auth for v3 onions via the control port. I had been reading the rend-spec-v3 https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt G.2.1 'Service side' says '[XXX figure out control port command format]' and I figured it just hadn't been updated to reflect the new command. I hadn't even thought to read the control spec.. > > AFAIK there is no control port command for adding service-side client > auth credentials. You will need to do this using the filesystem by using > the '/authorized_clients/' directory as displayed by > the "CLIENT AUTHORIZATION" section of the manual... Or you will need to > implement the control port commands in tor :/ > > Sorry for the sad news here... :/ Okay, thanks for all the clarification. Indeed, OnionShare uses purely ephemeral onions, so the standard filesystem method won't work (unless we switch to that). A shame it can't be as easy as the basic_auth method for v2 onions! But it's not the same auth, so I understand :) > PS: All this confusion stems from the name of this feature being "client > authorization". The fact that the name includes the string "client" > makes it confusing to specify whether functionality is client-side > or service-side... We should rename that feature, but making it > simply "authorization" is weird because then people are gonna wonder > whether onion services offer no authentication by default. Perhaps > we need to find a cooler name for this feature... > OnionShare called v2 client auth 'Stealth Mode'. But that was really just because it was understood that v2 descriptors were discoverable. On the other hand, OnionShare now uses HTTP basic auth for both v2 and v3 onions, so it's not all bad. Cheers, Mig signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onion Client Auth on v3 descriptor via Control port
Miguel Jacq writes: > Hi George, > > On Wed, Jun 17, 2020 at 12:37:18PM +0300, George Kadianakis wrote: >> >> Hmm, this is a bit embarassing for both of us, but if I'm not mistaken >> ONION_CLIENT_AUTH_ADD only controls the client-side of client auth >> credentials. This is not obvious at all by the command name, and it only >> becomes a bit clearer by reading the control-spec.txt... >> >> We added that control port command so that the browser could present a >> UX for client authorization. > > Ahahahah. Riiight, thanks for that clarification. This whole time I indeed > thought this was a novel way for adding Client Auth for v3 onions via the > control port. > > I had been reading the rend-spec-v3 > https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt > > G.2.1 'Service side' says '[XXX figure out control port command format]' and > I figured it just hadn't been updated to reflect the new command. I hadn't > even thought to read the control spec.. > >> >> AFAIK there is no control port command for adding service-side client >> auth credentials. You will need to do this using the filesystem by using >> the '/authorized_clients/' directory as displayed by >> the "CLIENT AUTHORIZATION" section of the manual... Or you will need to >> implement the control port commands in tor :/ >> >> Sorry for the sad news here... :/ > > Okay, thanks for all the clarification. Indeed, OnionShare uses purely > ephemeral onions, so the standard filesystem method won't work (unless we > switch to that). > Right Seems like v2 supports adding client auth credentials through the control port using the ADD_ONION command, but that's not the case for v3... Just a simple matter of programming as always ;) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onion Client Auth on v3 descriptor via Control port
Miguel Jacq writes: > Hi, > > I'm one of the OnionShare developers, looking at what can be done to support > Client Auth with v3 onions. > > OnionShare depends on Stem for all its interaction setting up ephemeral > onions, so we need Stem to support that fierst. > > So I have been working on adding support for ONION_CLIENT_AUTH_ADD to Stem. I > actually have it working as far as getting a 250 OK back from the controller! > Nice. > > But I'm puzzled, because despite successfully adding the client auth, I can > access my onion service *without* auth in Tor Browser. > > > > So that all looks good. But what is weird, is if I go to > http://gmdo3idszymnvfbuf2fm6miepearldgwbo7qfc4lsrw2kact2ka77kqd.onion/ , I > see my 'hello world', I never had to add any client auth to Tor Browser. > > What am I doing wrong? How do I make the onion auth actually be 'required' > since I succeeded at adding it? I was under the impression that as soon as I > ran ONION_CLIENT_AUTH_ADD and got a success, from that point on, client auth > would be *needed*. > > Maybe it's a problem with how I'm generating the keys? I had a bit of trouble > figuring out how to send the base64 encoded private key. Even so, it accepts > the private key, and yet it allows access without auth, which surprised me... > > It's probably really obvious but I've been working on this a while so I'm > tired :) Time to embarass myself on a public mailing list.. > > Thanks in advance! > Hmm, this is a bit embarassing for both of us, but if I'm not mistaken ONION_CLIENT_AUTH_ADD only controls the client-side of client auth credentials. This is not obvious at all by the command name, and it only becomes a bit clearer by reading the control-spec.txt... We added that control port command so that the browser could present a UX for client authorization. AFAIK there is no control port command for adding service-side client auth credentials. You will need to do this using the filesystem by using the '/authorized_clients/' directory as displayed by the "CLIENT AUTHORIZATION" section of the manual... Or you will need to implement the control port commands in tor :/ Sorry for the sad news here... :/ PS: All this confusion stems from the name of this feature being "client authorization". The fact that the name includes the string "client" makes it confusing to specify whether functionality is client-side or service-side... We should rename that feature, but making it simply "authorization" is weird because then people are gonna wonder whether onion services offer no authentication by default. Perhaps we need to find a cooler name for this feature... ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Onion Client Auth on v3 descriptor via Control port
Hi, I'm one of the OnionShare developers, looking at what can be done to support Client Auth with v3 onions. OnionShare depends on Stem for all its interaction setting up ephemeral onions, so we need Stem to support that fierst. So I have been working on adding support for ONION_CLIENT_AUTH_ADD to Stem. I actually have it working as far as getting a 250 OK back from the controller! Nice. But I'm puzzled, because despite successfully adding the client auth, I can access my onion service *without* auth in Tor Browser. Here is a link to a PoC script. Note that it doesn't do the ONION_CLIENT_AUTH_ADD via Stem here yet. I have that working locally, but this issue isn't with my Stem implementation I don't think... https://gist.github.com/mig5/2e95a3fbe157e1f78764f7a718bf93b9 Here's the output if I run the script with python3 create-v3-service-and-keys.py user@onionshare:~$ python3 create-v3-service-and-keys.py http service: http://127.0.0.1:8080/ starting onion service with: key_type='NEW', key_content='ED25519-V3' http://4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd.onion/ private base64: wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= public base32: WJJTONEA5SRZKVHHAYY2EHIF5LNF3526RCLYSC7ZZRCPVPIFA6PA private base32: YJELEM2W2A3WOSHDOPX2DNTHNQ7TW4GQMX6KC4VNZ4NWTHGJHL6Q Now, if in another terminal I telnet to the control port and manually add the onion auth, I get a 250, I can view the auth etc: user@onionshare:~/git/stem$ sudo -u debian-tor telnet 127.0.0.1 9051 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Authenticate "" 250 OK ONION_CLIENT_AUTH_ADD 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd x25519:wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= 250 OK ONION_CLIENT_AUTH_VIEW 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd 250-ONION_CLIENT_AUTH_VIEW 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd 250-CLIENT 4sa6jhqf2atg7edi2nzqun4o5kyughmwvjyrb7sfxe7d6ypqyh7f6nqd x25519:wkiyM1bQN2dI43PvobZnbD87cNBl/KFyrc8baZzJOv0= 250 OK So that all looks good. But what is weird, is if I go to http://gmdo3idszymnvfbuf2fm6miepearldgwbo7qfc4lsrw2kact2ka77kqd.onion/ , I see my 'hello world', I never had to add any client auth to Tor Browser. What am I doing wrong? How do I make the onion auth actually be 'required' since I succeeded at adding it? I was under the impression that as soon as I ran ONION_CLIENT_AUTH_ADD and got a success, from that point on, client auth would be *needed*. Maybe it's a problem with how I'm generating the keys? I had a bit of trouble figuring out how to send the base64 encoded private key. Even so, it accepts the private key, and yet it allows access without auth, which surprised me... It's probably really obvious but I've been working on this a while so I'm tired :) Time to embarass myself on a public mailing list.. Thanks in advance! Mig signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
