Opened 7 months ago

Last modified 7 months ago

#2773 new defect

Description of enabling SSL for the Tunnel looks misinformed

Reported by: anonymous maybe Owned by:
Priority: minor Milestone: undecided
Component: apps/i2ptunnel Version: 0.9.47
Keywords: Cc:
Parent Tickets: Sensitive: no

Description (last modified by anonymous maybe)

When you point your mouse on the SSL option in the tunnel the message describing its functionality indicating that by only enabling SSL attacker cant sniff the connection, whereas I2P actually by default encrypted and defend against sniffing.

Check the uploaded image.

Subtickets

Attachments (1)

i2pssl.png (25.2 KB) - added by anonymous maybe 7 months ago.

Download all attachments as: .zip

Change History (3)

Changed 7 months ago by anonymous maybe

Attachment: i2pssl.png added

comment:1 Changed 7 months ago by anonymous maybe

Description: modified (diff)

comment:2 Changed 7 months ago by zzz

discussion including OP on IRC #i2p-dev:

<dr|z3d_> anonymousmaybe: you need to look at the context of the tooltip help before you file bug reports. re https://trac.i2p2.de/attachment/ticket/2773/
<dr|z3d_> and the context of the SSL tooltip is when connecting to a _remote_ target in respect of running a server.
<anonymousmaybe> i still dont understand something different from what i already understood
<anonymousmaybe> can you detail more from what i got wrong?
<dr|z3d_> you want to make a server on 192.168.1.23 available on i2p. you're on 192.168.1.24
<dr|z3d_> so, if the server supports an SSL connection, you can use SSL to connect.
<dr|z3d_> that's all. nothing to do with routing over i2p.
<anonymousmaybe> but the tunnel is I2P tunnel for hidden service/server which mean already is over i2p no?
<dr|z3d_> it's an esoteric setting unlikely to be used by many.
<dr|z3d_> look at the context.
<dr|z3d_> you're configuring the host and port for the server you want to make available over i2p.
<anonymousmaybe> i dont claim to be good at english but if its correct hopefully it can be rephrased to something easier to digest
<hmm> anonymousmaybe: i think what he means is that although the connection through I2P tunnel is encrypted, if your tunnel connects to a service you host that exists on a different machine then that connection the tunnel makes to the backend service is unencrypted
<hmm> so lets say you have machine A which makes a connection to a service hosted on machine B that doesn't accept connections via SSL
<hmm> <you> —-i2p_tunnel—→A—-non_ssl_conn—→B
<hmm> if someone can sniff the traffic from A → B, and its not over SSL then they can get access to the data
<hmm> now if the service you are running on machine B, is running on machine A accepting traffic over localhost
<hmm> then it doesn't really matter if its using SSL
<hmm> thats my interpretation of the conversation at least
<anonymousmaybe> Ai2pclient → 1outgoing → 2outgoing → 1incoming → 2incoming → Bserver (vice versa from B to A)
<anonymousmaybe> so what i understood from that SSL is just another layer on the I2P connection (because i2p support ssl for its eepsite)
<hmm> ah i see, uhm in that case you probably dont need SSL
<hmm> im not sure how much of a benefit that would provide, barring some sort of vulnerability in the way i2p encrypts data or something
<anonymousmaybe> yeah whether someone need or not, the description of protecting from sniffing when enabling it is ambiguous. Thats why i raised it as a bug to get rephrased
<hmm> ah i see, yea that makes sense

Note: See TracTickets for help on using tickets.