Opened 5 years ago

Closed 5 years ago

#7559 closed project (fixed)

Registration via indirect URL request

Reported by: dcf Owned by: aallai
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The web server on the facilitator should be able to answer requests for URLs like

http⁠:facilitator.example.com/reg/GGX4n12cGCjOIQ45...

Where GGX4n12cGCjOIQ45... is a base64-encoded encrypted client registration (as produced by flashproxy-reg-email internally) of about 350 bytes. When such a URL is requested, the facilitator should decrypt it and do the registration.

The idea behind this is that a censored client can use any third-party URL retrieval service to register on their behalf, if the facilitator is blocked directly. For example,

  1. Client: Dear Mr. W3C Validator, please validate the page at http⁠:facilitator.example.com/reg/GGX4n12cGCjOIQ45....
  2. The validator requests the URL.
  3. The facilitator returns a 204 or empty HTML page, and in the background makes the registration.
  4. Validator: Your page checks out!

We will want a helper program that prints out a facilitator URL which the client can paste into their favorite URL retrieval service.

This could also become how flashproxy-reg-http works, rather than a POST request.

Child Tickets

Change History (15)

comment:1 Changed 5 years ago by dcf

Owner: changed from dcf to aallai
Status: newassigned

comment:2 Changed 5 years ago by aallai

Status: assignedneeds_revision

I have an implementation of the server side of this at https://github.com/aallai/flashproxy.git, branch url_reg.

comment:3 Changed 5 years ago by aallai

I have re-implemented this as a daemon separate from the CGI script. The code is at https://github.com/aallai/flashproxy.git, in the url_reg branch.

comment:4 Changed 5 years ago by aallai

Status: needs_revisionneeds_review

comment:5 Changed 5 years ago by aallai

Status: needs_reviewneeds_revision

Actually the code above is not working correctly. It decrypts the registrations properly, but then fails later in a format_addr() call.

I noticed that in the parse_addr_spec() call in facilitator-reg-url, line 79, getaddrinfo() returns ('0.0.0.1', 0) as a host-port pair, when passed something like 127.0.0.1:9000. I can't reproduce this in the python interpreter though, so I am a bit baffled...

comment:6 Changed 5 years ago by aallai

Status: needs_revisionneeds_review

The problem mentioned above has been fixed. The daemon was receiving registrations encoded in Python's internal unicode format (UTF-16 or 32), and passing the data directly to getaddrinfo(). UTF-8 is now explicitly used and getaddrinfo() is given 8-bit strings.

comment:7 Changed 5 years ago by dcf

Status: needs_reviewneeds_revision

I decided that I want to architect the local facilitator programs differently, so this ticket is pending until I do that. This is how I expect it to break down:

  • flashproxy-reg-daemon: This is a daemon that reads base64-encoded encrypted registrations and passes them to the facilitator. Basically the common parts of facilitator-email-poller and facilitator-reg-url in a standalone daemon. This is the only process with access to private key material.
  • flashproxy-reg: Unprivileged process that reads a base64-encoded encrypted client registration and passes it to flashproxy-reg-daemon.
  • flashproxy-email-poller: Calls flashproxy-reg rather than doing its own decryption.
  • flashproxy.cgi: Calls flashproxy-reg rather than making a connection directly to flashproxy-reg-daemon (or flashproxy-reg-url as it is implemented so far in the ticket).

comment:8 in reply to:  7 Changed 5 years ago by dcf

Replying to dcf:

I decided that I want to architect the local facilitator programs differently, so this ticket is pending until I do that. This is how I expect it to break down:

I've made the above changes involving flashproxy-reg-daemon and flashproxy-reg in master. flashproxy-reg-email now doesn't touch the private key and delegates registrations to flashproxy-reg. This updated master is now running on the public facilitator.

Please pull from my branch at https://gitweb.torproject.org/user/dcf/flashproxy.git/shortlog/refs/heads/url_reg, which has merged the above changes from master. Adapt your changes to facilitator.cgi to work with the new system, namely, call fac.put_reg_base64 which delegates to flashproxy-reg. You will probably have to convert the base64 alphabet before doing so. The public key in flashproxy-reg-url should now be the same as that in flashproxy-reg-email.

comment:9 Changed 5 years ago by aallai

Status: needs_revisionneeds_review

I've made the changes to facilitator.cgi, along with a few changes to flashproxy-reg-url. Tested on my local machine.

The changes are in the url_reg branch of https://github.com/aallai/flashproxy.git.

comment:10 Changed 5 years ago by dcf

Status: needs_reviewneeds_revision

Thanks for the great work. I have merged your changes.

One more thing before closing the ticket: please make a man page for flashproxy-reg-url and check that it gets installed in Makefile and anywhere else appropriate. The man page should give a sample use case: you print out the URL locally, then give it to a third party who can retrieve it for you.

comment:11 Changed 5 years ago by dcf

Something fun I found while testing: there are people in the #tor-dev channel whose IRC clients automatically retrieve URLs. I posted a flashproxy-reg-url URL to #tor-dev and I immediately got flash proxy service. Therefore an IRC channel can serve the purpose of an indirect third-party rendezvous.

comment:12 Changed 5 years ago by aallai

Status: needs_revisionneeds_review

I added the man page to my url_reg branch.

As an example I used the W3C validator. The #tor-dev rendezvous is cool, but it depends on those URL retrieving clients sticking around.

comment:13 in reply to:  12 Changed 5 years ago by dcf

Status: needs_reviewneeds_revision

Replying to aallai:

I added the man page to my url_reg branch.

As an example I used the W3C validator. The #tor-dev rendezvous is cool, but it depends on those URL retrieving clients sticking around.

Thanks Alex.

I don't want to mention any particular URL retrieval services. Please remove the W3C validator example. That's just one possible use case and I don't want to codify it. Just say that you can give the URL to someone else to get them to register on your behalf. Also use an RFC 5737 192.0.2.0/24 address in the example.

comment:14 Changed 5 years ago by aallai

Status: needs_revisionneeds_review

Done. I was wondering what the example.com of IP addresses was.

comment:15 Changed 5 years ago by dcf

Resolution: fixed
Status: needs_reviewclosed

Thanks, done.

Note: See TracTickets for help on using tickets.