You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before #38 is merged, hnsd only connects to a curated list of 8 seed nodes. This is a centralization issue. However, all 8 of those connections are encrypted.
With #38 we can now discover peers by requesting addr messages from the network, but these messages only contain clearnet addresses (no public key for brontide encryption). In hsd, we disabled gossiping brontide addresses (see handshake-org/hsd#315 and handshake-org/hsd@a333a24) but we may potentially be able to add them back, or use connection upgrades in the future (handshake-org/hsd#487). Once that is figured out in hsd we can circle back here and add the upgrade protocol to hnsd, and try to keep everything encrypted. For now, #38 compromises privacy for decentrazliation.
Clearnet connections leak privacy because they rely on getproof messages from a light client to a full node server which contain the unencrypted nameHash of the TLD with which to query the root zone. Note that if the TLD is not in the HNS root zone, a proof of non-inclusion is returned and the light client attempts to resolve the query using legacy DNS. But even in this case, let's say we are requesting google.com, the TLD com is sent in the clear to the hsd full node -- well, it's hash.
So we've made the tradeoff in #38 that decentralization is more important than privacy. hnsd will connect to multiple peers instead of just the seed nodes, but many of these peer connections will not be encrypted, meaning that network snoops can see what domains you are looking up. Note that with encrypted connections, snoops won't know what you are looking up, but the node operator on the other end will. So, privacy for hnsd is not great already, same as Bitcoin SPV.
Before we figure out connection upgrades in hsd there are a few things we can add to hnsd:
allow configuring hnsd to only connect to encrypted peers, which at this point is just the centralized seed nodes
The text was updated successfully, but these errors were encountered:
pinheadmz
changed the title
Feature request: onlynet (clearnet / brontide)
Clearnet connections leak privacy: allow extra settings to limit hnsd to encrypted connections only
Aug 26, 2020
Before #38 is merged, hnsd only connects to a curated list of 8 seed nodes. This is a centralization issue. However, all 8 of those connections are encrypted.
With #38 we can now discover peers by requesting
addr
messages from the network, but these messages only contain clearnet addresses (no public key for brontide encryption). In hsd, we disabled gossiping brontide addresses (see handshake-org/hsd#315 and handshake-org/hsd@a333a24) but we may potentially be able to add them back, or use connection upgrades in the future (handshake-org/hsd#487). Once that is figured out in hsd we can circle back here and add the upgrade protocol to hnsd, and try to keep everything encrypted. For now, #38 compromises privacy for decentrazliation.Clearnet connections leak privacy because they rely on
getproof
messages from a light client to a full node server which contain the unencryptednameHash
of the TLD with which to query the root zone. Note that if the TLD is not in the HNS root zone, a proof of non-inclusion is returned and the light client attempts to resolve the query using legacy DNS. But even in this case, let's say we are requestinggoogle.com
, the TLDcom
is sent in the clear to the hsd full node -- well, it's hash.So we've made the tradeoff in #38 that decentralization is more important than privacy. hnsd will connect to multiple peers instead of just the seed nodes, but many of these peer connections will not be encrypted, meaning that network snoops can see what domains you are looking up. Note that with encrypted connections, snoops won't know what you are looking up, but the node operator on the other end will. So, privacy for hnsd is not great already, same as Bitcoin SPV.
Before we figure out connection upgrades in hsd there are a few things we can add to hnsd:
--seeds
(see Seeds provided in command line not preferred by addrmgr. #39)The text was updated successfully, but these errors were encountered: