-
jpk68
vtnerd - In the event that SSL is implemented for P2P traffic, how would it be possible to have an ECH handshake that doesn'
-
jpk68
-- 't leak the IP of the seed node?
-
jpk68
To my understanding, the benefit of SSL over Noise is mainly that its traffic can blend in with other SSL web traffic, whereas Noise (even with randomized ports) would look to conspicuous.
-
m-relay
<ofrnxmr:monero.social> thats only for ssl traffic on port 443
-
jpk68
Ah, I see
-
m-relay
<ofrnxmr:monero.social> Https doesnt hide the fact that the connection is going to a common monero port
-
m-relay
<ofrnxmr:monero.social> ssl would just hide the contents of the traffic, preventing an isp from knowing when your node is the origin for a tx
-
jpk68
In that case, I fail to see what benefit SSL/TLS brings over noise. Since non-standard port numbers could be used for both options, they seem equivalent in that regard, but how would ECH work?
-
jpk68
Surely it would be extremely easy to just set up some sort of network filter for default seed nodes
-
jpk68
Which can identify Monero usage, even if the rest of the traffic is encrypted from the starting point onward
-
jpk68
Whereas Noise seems to have a safer way to initiate a connection without unencrypted initial data. I haven't had the chance to read up on that yet though.
-
jpk68
Sorry for spamming -- I'm basically just wondering how the initial connection would be possible with ECH.
-
moneromooo
5
-
moneromooo
sorry
-
m-relay
<vtnerd:monero.social> jpk68: the main thing is maintenance and less dependencies. Noise would need some advantage to overcome those. The primary advantage for noise is that we may be able to get something that cannot be fingerprinted by dpi, with the caveat that this only applies to people running custom ports. And even then the custom port info is all semi-public via p2p protocol so
-
m-relay
<vtnerd:monero.social> So it's somewhat lower benefit. I realize other projects feel differently, as they've switched to noise, but the peerlist thing is kind of a killer
-
m-relay
<vtnerd:monero.social> Our ssl implementation isn't doing anything with ECH. Im not aware of any benefits, other than possibly hiding the custom ciphersuite which could make the connection more fingeprintable
-
m-relay
<vtnerd:monero.social> I suppose if you pushed me, the benefit to noise is that it forces a spy to actively make p2p connections to learn of all nodes. If this is advantage to you, I can revisit the implementation and switch to noise
-
jpk68
Thanks for the response, much appreciated. My mistake about ECH; I thought it was mentioned in the GitHub issue or something.
-
jpk68
At the moment I don't have a super strong opinion towards one or the other, just interested and looking through options
-
jpk68
-
m-relay
<boog900:monero.social> have you looked into bitcoins custom protocol?
-
m-relay
<boog900:monero.social> I haven't really thought about it too much, just wondering if you have any opinions on it.
-
m-relay
<jeffro256:monero.social> I personally don't think it's worth the change. There is no jurisdiction where running a node and downloading the peer list would be illegal, and technically there is nothing stopping someone from doing so. Trying to hide your participation in a p2p network whose transport layer is not anonymous is more or less pointless. We already use openssl as a dependency, so SSL makes sense <clipped message>
-
m-relay
<jeffro256:monero.social> to me. The main benefit of p2p encryption is hiding how messages (blocks, txs, etc) propagate through the network, which especially gives anonymity to transaction broadcasters against ISP-level spies. Both SSL and Noise achieve this just fine
-
m-relay
<boog900:monero.social>
bips.dev/324
-
m-relay
<vtnerd:monero.social> No I don't recall anything about it