Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connecting to FQDN peers with SNI is broken #17923

Open
felixbrucker opened this issue Apr 28, 2024 · 13 comments
Open

Connecting to FQDN peers with SNI is broken #17923

felixbrucker opened this issue Apr 28, 2024 · 13 comments
Assignees

Comments

@felixbrucker
Copy link
Contributor

Currently when a FQDN is used to connect to a peer which requires SNI to correctly route the request to the host, no connection can be established. This is due to chia itself resolving the host and using the resulting ip to connect to it, breaking SNI.

@wjblanke
Copy link
Contributor

wjblanke commented May 1, 2024

3.9 aiohttp supports SNI so maybe it can be added

aio-libs/aiohttp#7543

What feature are you trying to implement exactly felix?

@felixbrucker
Copy link
Contributor Author

felixbrucker commented May 1, 2024

I wanted to connect to a full node behind cloudflare, but it would be the same for users trying to connect to one behind nginx, given that they host multiple servers on the same port, for example 443. This however is currently broken and does not work, as the correct endpoint to connect to can not be mapped as that info is missing (bc it connects to the resolved ip instead of connecting to the hostname in the config, and letting the library handle resolving and properly connecting to it).

@felixbrucker
Copy link
Contributor Author

I did some testing, i think there are two approaches to solve this:

  • the normal way: pass in the host to ws_connect, for example: ws_connect("wss://some-fqdn.com/ws") instead of ws_connect("wss://1.2.3.4/ws"). In this case aiohttp already handles everything correctly and a connection can be established.
  • the ugly way: continue to pass in the resolved ip as url, but also pass through the server_name argument and Host header set to the fqdn, for example:
ws_connect(
  "wss://1.2.3.4/ws",
  server_hostname=unresolved_peer_info.host,
  headers={
    "Host": unresolved_peer_info.host,
  },
)

Currently aiohttp can not set the server_hostname for ws_connect, see aio-libs/aiohttp#7942 (has been on main for 6 months)

@wjblanke
Copy link
Contributor

wjblanke commented May 8, 2024

Is this just farmers trying to connect to a node or do you want node-node traffic working like this?

@felixbrucker
Copy link
Contributor Author

I'd love to see it work for both, but primary is farmer to node

@wjblanke
Copy link
Contributor

wjblanke commented May 8, 2024

Looks like we need a new release of main aiohttp as well

@wjblanke
Copy link
Contributor

wjblanke commented May 8, 2024

we can probably get farmer to node working

@felixbrucker
Copy link
Contributor Author

for the ugly way, yes

i'd much prefer the correct way

@wjblanke
Copy link
Contributor

wjblanke commented May 8, 2024

node - node gossip may be an issue. i think it only supports ip. the bigger issue is the current strategy for nodes is to resolve as early as possible, so this is opposite of that.

@felixbrucker
Copy link
Contributor Author

felixbrucker commented May 8, 2024

Yeah resolving happens in chia-blockchain before connecting and it makes sense for network based configs, like determining if a peer is trusted/whitelisted etc, but i'm not sure for which other reasons this might happen, or is needed even.

@wjblanke
Copy link
Contributor

wjblanke commented Jul 3, 2024

In the interim would running a proxy work to map the IP connections to a domain name? Its kludgy but should work

@felixbrucker
Copy link
Contributor Author

Nope, because if you map ip to domain in a proxy you could just host on the ip itself in the first place, which is not desired and possible in my case.

@jack60612
Copy link
Contributor

it is in our backlog as i mentioned in discord, not sure if this is an especially priority issue however.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants