Opened 6 years ago

Last modified 4 years ago

#1131 open enhancement

Add SSL mutual authentication support

Reported by: zzz Owned by:
Priority: minor Milestone:
Component: api/i2cp Version: 0.9.8.1
Keywords: privacy Cc:
Parent Tickets: Sensitive: no

Description

i.e. only accept client certs that are in your trust store

Primarily for I2CP server-side but could also be used for console, and i2ptunnel clients once SSL is added there.

Marking component as I2CP but most of work would be in utility classes. See e.g. #1106 for locations of SSL lib classes.

========================

<dinamic> zzz: what is the general stand on beeing backward compatible with changes ?
<zzz> the stand is "yes"
<dinamic> zzz: would it be preferrable to keep samv3 tunnel as is and during version handshake go into TLS
<dinamic> zzz: or would it be better with a new tunnel pure SSL ?
<dinamic> i kind of like the TLS approach but
<zzz> I don't know how to do the former in Java.
<zzz> We just open an SSL socket instead of a standard socket, that implements the latter. Easy peasy.
<zzz> SSL or not configured with an option.
<dinamic> there is some bad things about it..
<dinamic> the sam tunnel can be identified

<dinamic> were a pure ssl wont take you to the sam handshake if you dont have the correct client cert
<dinamic> which prevents identification

<dinamic> how about the authentication
<dinamic> cert or shared key ?
<dinamic> using cert, ssl handshake will end if not the required client cert is presented
<dinamic> that is in early state of connection..
<dinamic> the latter using shared key..
<dinamic> opens up that anyone can connect to the ssl socket and is presented with a protocol

<dinamic> which easy ups the identification
<dinamic> of service behind
<dinamic> i dont like that
<zzz> the "correct client cert" part of it is what I mentioned yesterday I hadn't researched or implemented yet

<dinamic> i would prefer required client cert
<dinamic> instead of shared key
<zzz> we now have centralized lib classes and have implemented SSL in about 5 different places in the code
<dinamic> ah nice
<dinamic> i read some backlog on your site about it..

<zzz> server: console and i2cp. client: i2cp, eepget, i2ptunnel
<dinamic> any thougths about ca ?
<zzz> what aboutit
<dinamic> the client cert part works in that way that client cert should be issued by the correct root cert

<zzz> as I keep saying, I know nothing about authentication by client cert
<dg> ssl and sam is a little pointless imo
<dg> or at least, no high priority
<dinamic> dg: how so ?
<dinamic> i have a decent use case of it
<dg> dinamic: SAM is expected to run on a local router that should be secured already
<dg> ok, what is it?
<dinamic> make my sam port public accessable
<zzz> if you would like, please enter a ticket with your use case for auth by client certs
<dinamic> from internet
<dg> That seems like a very bad idea.
<dinamic> dg: how soo ?

<dg> Hm. maybe not. The problem I'm thinking of would reside in streaming.
<dg> (local connections skip I2P and go straight to the dest)

<dg> dunno. maybe zzz has a reason it's bad.
<dg> For me, it's counter intuitive and users should IMO run an I2P router themselves

<zzz> dont put this on me
<dinamic> dg: you cant connect to anything if you dont run the router
<dinamic> the main issue with this is..
<dg> run a router then
<dinamic> identification of what data is going over the SSL
<dg> I imagine it like opening a tor control port
<dg> just seems bad.. the point of I2P is to be anonymous
<dinamic> dg: wait i didnt tell you was, why i want to make it public
<dg> if you forward streams through someone else's SAM, it is not anon
<dinamic> dg: you could write phone/tables app that uses sam

<dinamic> dg: ?? i dont understand what you mean
<dg> dinamic: "phone/tables app".. ? I'm not getting it.
<dinamic> instead of running a router on your phone, other device
<dinamic> you open up a tunnel to sam
<dg> oh. I guess.
<dinamic> if your device have the correct client cert ofcourse
<dinamic> anyone else cant access the port
<dinamic> you can have SSL tunnels wich requires that client have an certificate issued by a specific issure
<dinamic> anyone else just drops due to the client doesnt present the correct cert
<dg> password/ip check(whitelist?) maybe?
<dinamic> this means
<dinamic> in the router i can generate a "device" cert
<dinamic> and deploy it on my phone
<dinamic> use a SAM application
<dg> I see your idea now. I don't agree entirely though.. we're working on Android and it's promising. It could just run SAM?
<dinamic> and acces i2p from every where
<zzz> http://docs.oracle.com/javaee/6/tutorial/doc/glien.html
<iRelay> Title: Authentication Mechanisms - The Java EE 6 Tutorial (at docs.oracle.com)
<dinamic> zzz: the mutual cert auth is what i talking about
<dinamic> if this is done..
<dinamic> none with the correct cert on device
<dinamic> can connect and identify the protocol/service on the tunnel
<dinamic> if shared key is used a protocol must be exposed

<dinamic> dg: performance, battery drain etc.. my approach will be 10 times better then running i2p on android tablet/phone
<dg> hm
<dg> maybe
<dinamic> yes
<dinamic> :)

<zzz> str4d is already planning a client-only app
<dinamic> which will be secure enough to expose to internet ?
<zzz> with the interface between android and the router being I2CP, not SAM
<iRelay> <jenkins@kytv> Starting build #397 for job I2P
<zzz> i.e. you put SAM and streaming on the phone
<dinamic> str4d: ? What do you have in mind ?
<dg> ah, i see
<zzz> so it's one socket
<dinamic> zzz: streaming ?
<dinamic> reight..

  • dg finds docs, dinamic

<zzz> our tcp-like protocol layer
<dinamic> i know..
<dinamic> just my language barrier that played trick on me
<zzz> http://www.i2p2.i2p/protocols.html
<zzz> you fooled me there was a barrier :)
<dinamic> uha
<zzz> i2cp supports SSL and user/pw now
<iRelay> Title: Protocol Stack - I2P (at www.i2p2.i2p)
<dinamic> didnt understand that..
<dinamic> so
<dinamic> i2cp with mutual cert and im all happy
<zzz> yeah I doubt SSL + user/pw is very robust now
<dinamic> does i2p have any cert handlings ? (self signing with a router cert ?)
<zzz> you have a trac login yet?
<dinamic> nope
<dg> you can sign destinations with another dest key. I think that's it.
<zzz> I'll paste all this in a ticket then you can register and add to it
<iRelay> <jenkins@kytv> Project I2P build #397:SUCCESS in 5 min 12 sec: http://jenkins.killyourtv.i2p/job/I2P/397/
<dinamic> dg: thats another protocol layer
<dinamic> i ment for ssl parts

Subtickets

Change History (2)

comment:1 Changed 5 years ago by str4d

Keywords: privacy added
Milestone: 0.9.12

comment:2 Changed 4 years ago by str4d

Status: newopen
Note: See TracTickets for help on using tickets.