Overview

This proposal adds an authentication mechanism to address helper URLs.

Motivation

Address helper URLs are inherently insecure. Anybody may put an address helper parameter in a link, even for an image, and may put any destination in the "i2paddresshelper" URL parameter. Depending on the user's HTTP proxy implementation, this hostname/destination mapping, if not currently in the addressbook, may be accepted, either with or without an interstitial for the user to accept.

Design

Trusted jump servers and addressbook registration services would provide new address helper links that add authentication parameters. The two new parameters would be a base 64 signature and a signed-by string.

These services would generate and provide a public key certificate. This certificate would be available for download and inclusion in http proxy software. Users and software developers would decide whether to trust such services by including the certificate.

On encountering an address helper link, the http proxy would check for the additional authentication parameters, and attempt to verify the signature. On successful verification, the proxy wold proceed as before, either by accepting the new entry or showing an interstitial to the user. On verification failure, the proxy could reject the address helper or show additional information to the user.

If no authentication parameters are present, the http proxy may accept, decline, or present information to the user.

Jump services would be trusted as usual, but with the additional authentication step. Address helper links on other sites would need to be modified.

Security Implications

This proposal adds security by adding authentication from trusted registration / jump services.

Specification

TBD.

The two new parameters could be i2paddresshelpersig and i2paddresshelpersigner?

Accepted signature types TBD. Probably not RSA as the base 64 signatures would be very long.

Signature algorithm: TBD. Maybe just hostname=b64dest (same as proposal 112 for registration authentication)

Possible third new parameter: The registration authentication string (the part after the "#!") to be used for additional verification by the HTTP proxy. Any "#" in the string would have to be escaped as "#" or "#", or be replaced by some other specified (TBD) URL-safe character.

Migration

Old HTTP proxies that don't support the new authentication parameters would ignore them, and pass them along to the web server, which should be harmless.

New HTTP proxies that optionally support authentication parameters would work fine with old address helper links that don't contain them.

New HTTP proxies that require authentication parameters would not allow old address helper links that don't contain them.

A proxy implementation's policies may evolve over the course of a migration period.

Issues

A site owner could not generate an address helper for his own site, as it needs the signature from a trusted jump server. He would have to register it on the trusted server and get the authenticated helper URL from that server. Is there a way for a site to generate a self-authenticated address helper URL?

Alternatively, the proxy could check the Referer for an address helper request. If the Referer were present, contained a b32, and the b32 matched the helper's destination, then it could be allowed as a self-referral. Otherwise it could be assumed to be a 3rd-party request, and rejected.