figure out i2p support

[slingamn]

Right now we have basic support for I2P by treating it the same as Tor (i.e., treating each connection as totally anonymous).

@mogad0n points out that i2pd has some protocol-specific support for IRC, including sending WEBIRC with a variable proxied IP value:

https://i2pd.readthedocs.io/en/latest/tutorials/irc/#running-anonymous-irc-server

https://github.com/PurpleI2P/i2pd/blob/a8e1cd9a13d14978af7a6df8e9ccded9bb8f4dd1/libi2pd_client/I2PTunnel.cpp#L448

This support is unusable as-is because it doesn't send the WEBIRC secure flag. Questions:

1. What is GetIdentHash()? Is it based on the client's cryptographic I2P address? How stable are these addresses under normal conditions? How easy are they to change (i.e., are they of any use as an anti-spam measure?)
2. Assuming the peer's I2P address has the relevant desirable properties, could we use it as an authentication mechanism (via SASL EXTERNAL, similar to a client certificate?)

[prdes]

This is probably not the help you wanted but I was intending to write one for my docs and userguide anyway, so here ya go.
@tacerus knows a tad bit more about generating the address and the keys but you'll know that anyway

i2pd ergoIRCd Server & Client Guide Gist

[tacerus]

Hi,

I'll do some motr testing and then get back with definite answers to the questions. Using the B32 address as a "fingerprint" for SASL sounds like an interesting feature idea.
It would help if I2P(d) supported TLS connections I2P router <-> IRCd, however I'm not sure how reasonable of a feature improvement that is to them.

[slingamn]

It would help if I2P(d) supported TLS connections I2P router <-> IRCd, however I'm not sure how reasonable of a feature improvement that is to them.

This doesn't seem necessary to me. Aren't those connections going to be on loopback anyway?

I think if it's useful for i2pd to send WEBIRC at all, then it should just unconditionally send the secure flag, because I2P provides comparable security guarantees to TLS.

[slingamn]

Just to clarify, you can get I2P working (including multiclient / reattach) right now by disabling the WEBIRC support. The use of WEBIRC is what's causing the connections to be marked as insecure: normally, connections on loopback are treated as secure, but if you send WEBIRC without the secure flag, they are treated as insecure.

[tacerus]

1. The clients B32 address is unique, as it is computed from a unique hash of a unique public key.
2. Using the B32 address for SASL authentication sounds interesting, however if one uses B32 addresses "ephemerally" (i.e. if someone regularly discards their public key in order to obscure their identity), this is not a feature to them.

It would make sense for it to send the secure flag, seeing as the connection should generally be coming from the loopback interface or at least from the local network. I am unsure whether it is in the interest of the I2P client/router software developers to add this, or whether it would not be easier to simply have the proposed ergo I2P listener add the parameter, similar as to how it is done for Tor. The dedicated I2P listener additionally has the benefit of allowing a separate hostmask to be defined for I2P clients. I suggest the latter should be optional and not enforced though, as one might prefer the I2P address displayed, especially in, for example, I2P only networks.

[slingamn]

Thanks for investigating.

I am unsure whether it is in the interest of the I2P client/router software developers to add this, or whether it would not be easier to simply have the proposed ergo I2P listener add the parameter, similar as to how it is done for Tor.

If i2pd is sending WEBIRC, then it should send the secure flag. (tor has no IRC-specific support and does not send WEBIRC.) Since i2pd is terminating the I2P connection, which is end-to-end encrypted, it's free to send the secure flag; the ircd is independently responsible for validating that the link between i2pd and it is secure, as per the spec:

Servers MUST ONLY treat the connection as secure if this flag is sent and the connection from the gateway to the server is also secure with TLS.

That said, I don't really see the point of adding special I2P support. In particular, the I2P address seems to be the worst of both worlds: for normal users, it's a supercookie that identifies them, but for malicious users, it's cheap to rotate and therefore doesn't protect against spam. So the benefits of I2P-specific support (distinguishing I2P from Tor, and displaying some form of the I2P address) seem marginal to me and not worth any increase in implementation complexity.

[slingamn]

tl;dr I would recommend to i2pd operators that they disable WEBIRC support, use a tor listener, and adjust server.tor-listeners.vhost to reflect that the connection may either be from Tor or I2P.

[slingamn]

@RNDpacman is interested in this. I think it would be sufficient to add a config option that makes WEBIRC accept the provided hostname. The secure flag issue is obviated by #2013.

[slingamn]

@RNDpacman did you get a chance to test this? If so, I'll add an I2P section to our manual. I'm adding the recommended configuration here for posterity:

14:46:37 <@slingamn> in ircd.yaml, you should:
14:46:56 <@slingamn> set server.ip-cloaking.enabled to false
14:47:08 <@slingamn> set server.lookup-hostnames to false
14:47:24 <@slingamn> and then in the relevant webirc block, set accept-hostname to true

[RNDpacman]

@RNDpacman did you get a chance to test this? If so, I'll add an I2P section to our manual. I'm adding the recommended configuration here for posterity:

14:46:37 <@slingamn> in ircd.yaml, you should:
14:46:56 <@slingamn> set server.ip-cloaking.enabled to false
14:47:08 <@slingamn> set server.lookup-hostnames to false
14:47:24 <@slingamn> and then in the relevant webirc block, set accept-hostname to true

Yes I have tested, everything works properly. thank you