HSFETCH fails on basic auth services
Hello everyone, I seem to have found an issue (bug?) with the controller HSFETCH command - I can't seem to be able to fetch hidden service descriptors for services that use basic authentication. Tor appears to want to decrypt the introduction points for some reason and also fails to look at the HidServAuth directive. Connections (via SOCKS proxy for instance) to said service work fine, so Tor is configured correctly, but HSFETCH fails and Tor outputs this in the logs: *Jun 29 20:08:53.000 [warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data.* *Jun 29 20:08:53.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.* Is this a known issue? Is there another way to fetch the descriptor of a hidden service? I really don't want it to be published since I'm rewriting it anyway, but I need to fetch it somehow. I can use "PublishHidServDescriptors 0" to stop it from publishing the service at all but I have no idea how to fetch it from the local cache. Any controller commands for that? To summarize - HSFETCH appears to fail for hidden services with basic auth and I couldn't find a way to obtain the hidden service descriptor from the hidden service machine itself before publishing. Any advice would be appreciated. Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
BTW, I have also tried the GETINFO command from the controller to fetch the hidden service descriptor directly from the host that has published it, but that doesn't work either. Fetching from the client side (after a connection) works fine: AUTHENTICATE 250 OK GETINFO hs/client/desc/id/js2usypscw6y6c5e 250+hs/client/desc/id/js2usypscw6y6c5e= rendezvous-service-descriptor 7codget3fmkzj4z3oqia37iknu5iespk version 2 permanent-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBAMPwmou0Pjcmanw3GW7cpXgX3wiKmeND8A7kShodBfqGDIHkkHRpHuwe NTCtjAsnVzLqtFNCYpwg6HlyDRn557LHCO/GGvVQNvsPSl8v2N+XnuQ6NJ3Jy+AF bM1vqrFL6p02QRobtHBlbOkD4fWjC7lP6hYOKHQzt7lwDirtPZMdAgMBAAE= -----END RSA PUBLIC KEY----- secret-id-part d7xhm4st3puvu2zz7yjtluwmzt7iafnb publication-time 2016-06-29 19:00:00 protocol-versions 2,3 introduction-points -----BEGIN MESSAGE----- AQEI7yt3VSr/3LfUtCiXgcm9D3DGCC7Y1fOmB8mLk3ohO8e0OIHKBxtLM01WGq1N 5OHPcpTXD0Vjovc3lplKuoI6aLXVIrSd6lhTLIuybU5mi1GsE+PJXpHdmmDw9vCe 5dH1x6lkX6V0iUgKfqLAbpNvESxi+IQgG7p6VKEOrmMiH/TvCAH3MDdPFv6jjI17 2dju7V69/Mb6wk+KJtZYDLj/jckdzfpntEywg5VO+HR72OGtJ7CjZI49amgG3YF9 SM4ZXCz2XxL9vKXGhwQGZYchFuNbKMOonkw9BZ5Br2moMBl0awOBNoYbwNvCAhf4 iF2xOHKqTj5lV1u4AVwE8GvOPx8lR+qmFsMJQppjgwPbrVayvbMw9TdK+s+kGUiS 3B6tB7c+AMYIbjJ9kL7+sCQWSz00aXuMDJjyxz6NHVYc/x+VdKuMsWiUWj5O6GrA 2kLEEE4N2QvXRPO3w+diLqdT4StYUIpGGUrrWEl+C3yAN7Vb7rllNznaxZdPQJ4T 6Q3e/b8qAOqECqb5RNacY7u31vC3Q5SJtoPZozvpTxN4YWv0OmMhCy5JZ6goAMer xnwQcDqtRmgmRSoZCxfyaJQ0R7cnnPDN2pEsPNzr///4K69SS9xIchxWwGIxx4Y4 L3td/vrTr24ve78bSirXrjR9tc2w4Ksy3ZMINKR1OWggo2YnJkM3jtkq26njRkgB 7QyuIrBjv3ETWCL0F+7tu6afI895G6jtbS9SpySR3aSeZWFqmDLPbF43PVfbduIr dST/9mUOXyTW2jmtSm7M+Z8VlbqJw9O7b2PlbDl2lmKNiGUaqq11J3BKXgWQNKk4 qdsccxt0ohPienfVeMQTlLY00+ZL9gWDruJIpIfjq+KeFIvIlqOUSJWip8D/rYWN xZdkWqnr9Bs+MC+SlM3sbepEhn4hFIx3Jfc3BeatIvfkZB2vj4/sHOfoCNz4KFBV d+DsDWY6r2/A607ER2uT9oRSaljLhwPAIGS21ROidKKrK2YCCXoUUrKYHsMOLuht 50rUr/Ar0XvKdf7rOX+LmVEjpP05U1AIo8aVYSziMYYlr8qwRizrFbtq6t5M7FuR ORL74WvtLjHn/tAdm7A5jVwvWPF3vswBy8eFCNMTV3XEwJHmLBk6znsg2RuxdZ2G TASr2GrBx4J8MxtMN90R3n5RanV2YnAd1RYihK9BzBT5vFHO7wcQ3dOowrolZ83A Q0MQGoHT2lvvciKHahjn9HsWvuLVo25tnejvAIVGlD/ayfx8pOXztk9l+RN3N0pS ZkS63XHE9nQleOFrwYebZkeCQOOaVH+//c+agO+4JV82KBmP1/irmNyiIvuWAXxY /+SFxro7FJU4yROLkGkKJkVg9bdM3QQ+kQfM+Nci/dmrzmzyt41ClPsk1d2WOySw /Pd71YaNP76BstkpiUCpFtr8PQV+3UkGe5HWmrs0ZabGyzLKEwDjChs7z+zFp6Od aNNB3bB+Jrrqu8ZBJpwVjXxsaLb2dMB7Wi7b2E/zWZHr2E2Akh0I0lo3XIU86Eeu tKeM2xTn1yGNc5InPYln1dcfZ67l41zdN3X1P1DilEfT55hg2uIg0f2UbMXd5Db0 I68Zu3n1PWAaNEHE6m3k1PrLSIVs9bfIucuQacQQtkArT9t+lfkv/2CHGCrdHEfU 0R2tzNw+DnO/nZRIRmwxIUqbpvBKnmyfvbekB6JXvSZBWRboV4YHPZSDtZ7C8JpM YO9mCBbjhboGcujDFBUf+X0ansOIhOrjAPCvE15h0EKJkS8733AvhxwwkUwhL+Pz /RUCRe+rD5MCEvQhg9+oXhrnZwjzsvsrZGITuv5su34KumPJ3bqvp1lVxr16owwq KjLREhBBSIvl96fahGnV1ol6Lik5rUI3NhdmPMW3D0bydidYH3u6ZdOEplfoAUlo DvT7u+0Apl+Rd2jKutCagHjcLjTzOtk6OpWxgfaR3x/Ds+eUt6kS+FAzSrDPx8A7 t84Ga24xKwZowIdJZqjroRnzpZRkV4Y29m47+OpzBS2LYDZR1mPRaywPcX956miV mY1D9ci4L8l4jQiK/zeY4A/mUJEIlGNaRiUY1UVgiCQeO5fISBjrk0TVKqZaIbZC G/K5EJsX11XSbJz5+PzWCyZv/JjbHBTzbf2ocafCdz+aDJ5ekWMNfK3dR4PcS9n5 mFX7KLDjpSfkAPMW6LuCXFf732/tsqcxvf87QX2aWchwqTvUgXq2EZD19GPL4sr+ +tEkKNJuQ7wG5zDMlX030jSQ4WKhC5639LHYcg/TDv+CH6GfRZuQSYZgrCevWbLr GTWRhsXKKqfcysfw7WNa09AKK/3q+ohON0gcFHtLOjGsiLMs6D0UYc0o5U2KOi22 HOlhpVpTuQ85oNixNKhOkJkAleRKY49Jm/JPWbHf0Qhyb55SeIO0l7pfsO41xw5d aNvQRLDINUj5BRKFGS70vP+D7Aek294pOpJhXDx11AIaWzmUyCge0Y1QdCu7ywnZ dhKqpMSmCPbuZ5EmcFNovYmtfPzR3q2CKPbYISPsDwqXInEm2IKSN+qHFwxgfWv9 9Q9lyxv3Op/t9aDHmqZwVB3nTMJyDb5lZFkALkyQdHAudHcU8dq53PbwTzRqkW0H n9not+bht53bZpo9yjJZ5qXmMsT7CNFAL76iKgTRFEopFtPl7clQhTIbhgigvqL9 e9HhGOpXd3fVC3iD6yuvIxRVHJX6YCQ2OLqkvnaKTOCyVz+hVDy45SpkoAh7UjVn GPnSUKdS0wUBwvqik1GO2etpC+DjZqLqlHQaDiXn/L+1HxNga/HShK+bnkBID5bj FTMrn1AVyUU29WZlZWRRIFAlQ7FD/JcXALTi0KvFzjlGeuiLOXZo//BNeYdBblFn GW3wK0BX4AdDHvLcImPRCVUBrz+LOn7687ZQbTUAZ7tq2LQ= -----END MESSAGE----- signature -----BEGIN SIGNATURE----- VWIK/LZRvSeFNpEkgadnNGZb7G/mOsATZ7GN8COif92ytQADTiWr32FBRN5t/UJ/ wVyQXBqxJ9/LeRjEuJcGCKrrRR2DG932ZjK2SUAkgWnodIlBmpPF5r/btKEUVy3b hbCdWF5ZNCcjLEJ4T25k74TdIUwo8BXvG94EQPl35/g= -----END SIGNATURE----- . 250 OK Fetching from the server side though .... *GETINFO hs/service/desc/id/js2usypscw6y6c5e* *552 Unrecognized key "hs/service/desc/id/js2usypscw6y6c5e"* Any ideas? I'm running Tor 0.2.7.6 btw. This also appears to happen with non-authenticated services, but the hs/service/desc/id/<ADDR> was supposed to have been merged back in 0.2.7.1 (??). Razvan On Wed, Jun 29, 2016 at 11:14 PM, Razvan Dragomirescu < razvan.dragomirescu@veri.fi> wrote:
Hello everyone,
I seem to have found an issue (bug?) with the controller HSFETCH command - I can't seem to be able to fetch hidden service descriptors for services that use basic authentication. Tor appears to want to decrypt the introduction points for some reason and also fails to look at the HidServAuth directive. Connections (via SOCKS proxy for instance) to said service work fine, so Tor is configured correctly, but HSFETCH fails and Tor outputs this in the logs:
*Jun 29 20:08:53.000 [warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data.*
*Jun 29 20:08:53.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.*
Is this a known issue? Is there another way to fetch the descriptor of a hidden service? I really don't want it to be published since I'm rewriting it anyway, but I need to fetch it somehow. I can use "PublishHidServDescriptors 0" to stop it from publishing the service at all but I have no idea how to fetch it from the local cache. Any controller commands for that?
To summarize - HSFETCH appears to fail for hidden services with basic auth and I couldn't find a way to obtain the hidden service descriptor from the hidden service machine itself before publishing. Any advice would be appreciated.
Thank you, Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
On 30 Jun 2016, at 06:42, Razvan Dragomirescu <razvan.dragomirescu@veri.fi> wrote:
BTW, I have also tried the GETINFO command from the controller to fetch the hidden service descriptor directly from the host that has published it, but that doesn't work either. Fetching from the client side (after a connection) works fine:
AUTHENTICATE 250 OK GETINFO hs/client/desc/id/js2usypscw6y6c5e 250+hs/client/desc/id/js2usypscw6y6c5e= rendezvous-service-descriptor 7codget3fmkzj4z3oqia37iknu5iespk ... . 250 OK
Fetching from the server side though ....
GETINFO hs/service/desc/id/js2usypscw6y6c5e 552 Unrecognized key "hs/service/desc/id/js2usypscw6y6c5e"
Any ideas? I'm running Tor 0.2.7.6 btw. This also appears to happen with non-authenticated services, but the hs/service/desc/id/<ADDR> was supposed to have been merged back in 0.2.7.1 (??).
Perhaps GETINFO only looks in the HS cache, but hidden services don't cache their own descriptors?
On Wed, Jun 29, 2016 at 11:14 PM, Razvan Dragomirescu <razvan.dragomirescu@veri.fi> wrote: Hello everyone,
I seem to have found an issue (bug?) with the controller HSFETCH command - I can't seem to be able to fetch hidden service descriptors for services that use basic authentication. Tor appears to want to decrypt the introduction points for some reason and also fails to look at the HidServAuth directive. Connections (via SOCKS proxy for instance) to said service work fine, so Tor is configured correctly, but HSFETCH fails and Tor outputs this in the logs:
Jun 29 20:08:53.000 [warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data.
Jun 29 20:08:53.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Is this a known issue? Is there another way to fetch the descriptor of a hidden service? I really don't want it to be published since I'm rewriting it anyway, but I need to fetch it somehow. I can use "PublishHidServDescriptors 0" to stop it from publishing the service at all but I have no idea how to fetch it from the local cache. Any controller commands for that?
To summarize - HSFETCH appears to fail for hidden services with basic auth and I couldn't find a way to obtain the hidden service descriptor from the hidden service machine itself before publishing. Any advice would be appreciated.
Perhaps HSFETCH only looks in the HS cache, but hidden services don't cache their own descriptors? Perhaps HSFETCH doesn't look at HidServAuth? Perhaps HSFETCH shouldn't try to decrypt the descriptor before delivering it? Perhaps it should? I encourage you to log an issue for each of these in our bug tracker at https://trac.torproject.org/ Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
Thank you Tim! For the record, GETINFO works ok in 0.2.8.4-rc (unstable). HSFETCH still doesn't and I'll file a bug for it. Razvan On Thu, Jun 30, 2016 at 1:28 AM, Tim Wilson-Brown - teor <teor2345@gmail.com > wrote: > > > On 30 Jun 2016, at 06:42, Razvan Dragomirescu < > razvan.dragomirescu@veri.fi> wrote: > > > > BTW, I have also tried the GETINFO command from the controller to fetch > the hidden service descriptor directly from the host that has published it, > but that doesn't work either. Fetching from the client side (after a > connection) works fine: > > > > AUTHENTICATE > > 250 OK > > GETINFO hs/client/desc/id/js2usypscw6y6c5e > > 250+hs/client/desc/id/js2usypscw6y6c5e= > > rendezvous-service-descriptor 7codget3fmkzj4z3oqia37iknu5iespk > > ... > > . > > 250 OK > > > > > > Fetching from the server side though .... > > > > GETINFO hs/service/desc/id/js2usypscw6y6c5e > > 552 Unrecognized key "hs/service/desc/id/js2usypscw6y6c5e" > > > > Any ideas? I'm running Tor 0.2.7.6 btw. This also appears to happen with > non-authenticated services, but the hs/service/desc/id/<ADDR> was supposed > to have been merged back in 0.2.7.1 (??). > > Perhaps GETINFO only looks in the HS cache, but hidden services don't > cache their own descriptors? > > > On Wed, Jun 29, 2016 at 11:14 PM, Razvan Dragomirescu < > razvan.dragomirescu@veri.fi> wrote: > > Hello everyone, > > > > I seem to have found an issue (bug?) with the controller HSFETCH command > - I can't seem to be able to fetch hidden service descriptors for services > that use basic authentication. Tor appears to want to decrypt the > introduction points for some reason and also fails to look at the > HidServAuth directive. Connections (via SOCKS proxy for instance) to said > service work fine, so Tor is configured correctly, but HSFETCH fails and > Tor outputs this in the logs: > > > > Jun 29 20:08:53.000 [warn] Failed to parse introduction points. Either > the service has published a corrupt descriptor or you have provided invalid > authorization data. > > > > Jun 29 20:08:53.000 [warn] Fetching v2 rendezvous descriptor failed. > Retrying at another directory. > > > > Is this a known issue? Is there another way to fetch the descriptor of a > hidden service? I really don't want it to be published since I'm rewriting > it anyway, but I need to fetch it somehow. I can use > "PublishHidServDescriptors 0" to stop it from publishing the service at all > but I have no idea how to fetch it from the local cache. Any controller > commands for that? > > > > To summarize - HSFETCH appears to fail for hidden services with basic > auth and I couldn't find a way to obtain the hidden service descriptor from > the hidden service machine itself before publishing. Any advice would be > appreciated. > > Perhaps HSFETCH only looks in the HS cache, but hidden services don't > cache their own descriptors? > Perhaps HSFETCH doesn't look at HidServAuth? > Perhaps HSFETCH shouldn't try to decrypt the descriptor before delivering > it? Perhaps it should? > > I encourage you to log an issue for each of these in our bug tracker at > https://trac.torproject.org/ > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > ricochet:ekmygaiu4rzgsk6n > > > > > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >
participants (2)
-
Razvan Dragomirescu -
Tim Wilson-Brown - teor