Opened 8 years ago

Closed 6 years ago

#451 closed enhancement (wontfix)

HTTP client does not have persistent client key interface

Reported by: dream Owned by: zzz
Priority: minor Milestone: 0.9
Component: apps/i2ptunnel Version: 0.8.4
Keywords: tunnel persistent client key eepsite http Cc:
Parent Tickets:

Description

The user interface for all client i2ptunnels in i2ptunnel have an option for "Use persistent key" except the HTTP client. Thus all HTTP client i2ptunnels created will have options.persistentClientKey=false and no way to configure it to be true except editing the advanced config manually. The UI needs to be updated so that HTTP client i2ptunnels offer a clear option to make their own persistent private key.

This only applies to "HTTP client" i2ptunnels. "HTTP Bidir" i2ptunnels are always persistent and have the same key as used to reach their server. Simply changing the "HTTP Web Server" to a bidir type would allow for users to have a persistent client key to use for authentication on eepsites (example http://33pz6wn6qqntoxs4hfrhjiinihmse6w2uhdwcrwjqwma7icz5qaa.b32.i2p/login/ ) while also having the same identification for their own eepsite.

Subtickets

Change History (4)

comment:1 Changed 8 years ago by zzz

Indeed. It only appears for standard, IRC, and SOCKS IRC client types.

I guess my thinking at the time was that the above types were the only ones where persistence was useful. In fact, enabling it for the HTTP client proxy seems a little dangerous for the user. But it is an advanced option, I guess.

Is it a reasonable use case to use it for eepsite authorization? Instead of standard login-and-cookie?

comment:2 Changed 8 years ago by dream

Having persistence disabled by default is probably a good idea, whether HTTP, IRC, or SOCKS. I think it is an excellent use-case for eepsite authorization though. Login-and-cookie system has many problems. First the user's password must be stored on the server. Generally single sign on is rather out of the question, since servers don't just trust each other with password information. Second, the user must type in their username and password every time they login, which is inconvenient enough that many browser extensions have been written to try to ameliorate the process. Third, since it's a password the user types, it might be a weak password, subject to dictionary attacks. Again there are browser add-ons to ameliorate this, but still not ideal. Fourth, many users are concerned with cookies which are notoriously difficult to manage, to copy from one computer to the other, to tell if it's an old cookie or not, or to utilize for more than one domain, or outside the realm of hierarchical DNS domains at all. I can tell you that CookieSafe? asks me if I want to accept all cookies from "b32.i2p" and that's not the best of situations for the end user IMO.


The i2p streaming library (I think?) provides built-in automatic public key authentication, by signing every packet with the return destination. The resulting headers provided by i2ptunnel can be trusted much better than a password. The server has no power to authenticate just knowing the public key too, so they can share it with anyone without consequences, unlike a password. Single sign ons! And i2p destination keys are much, much longer than a password the user would type, or even a hashed password that some Firefox extension might generate, so a dictionary attack against them is practically unthinkable. Private keys may be copied easily from one computer to the other. They aren't password protected, yet. They're universal outside the realm of the DNS. What I assert is that basically public key authentication, which i2p provides automatically, is superior to login cookies in every shape and form. The only concern might be people unwittingly corellating their browsing between one eepsite and another, which is eliminated if you make persistent keys not the default, but still an available option.

comment:3 Changed 8 years ago by zzz

  • Milestone changed from 0.8.5 to 0.9
  • Owner set to zzz
  • Status changed from new to assigned
  • Type changed from defect to enhancement

comment:4 Changed 6 years ago by zzz

  • Resolution set to wontfix
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.