I2P Address: [http://git.idk.i2p]

Skip to content
Snippets Groups Projects
Commit 0c1a0ffd authored by zzz's avatar zzz
Browse files

proposal 135

parent 28dc87d1
No related branches found
No related tags found
No related merge requests found
=============================
Authenticated Address Helpers
=============================
.. meta::
:author: zzz
:created: 2017-02-25
:thread: http://zzz.i2p/topics/2241
:lastupdated: 2017-02-25
:status: Open
.. contents::
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.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment