jeffro256[m]: monero-project/monero #8344

basically we would hardcode the fingerprint into the GUI source code, right? and then host a couple nodes with this specific cert?

seems like a good idea

instead of just hardcoding IPs / domains for the remote node list

Are you talking about the PR? The PR is wallet and GUI agnostic, it just saves the SHA256 fingerprint of your node in a file right besides your certificate file for easy viewing

The aim would be later in a CLI or GUI wallets is that I would give a message / UX that says "Hey this node you're connecting to has X fingerprint! Go make sure that's actually your fingerprint by checking the file 'rpc_ssl.fingerprint', cause otherwise you're the victim of a MitM attack"

Then it would remember it later so you don't have to reconfirm it. Think of the know_hosts file for SSH

But that PR is just an extra file that sits besides your certificate file, it doesn't do anything yet

<selsta> "basically we would hardcode..." <- Why hardcode ? Can’t we do it like browsers which validate certificate

Warn if certificate is invalid and ask if to allow connection, so public remote nodes can keep valid certs and private remote nodes can be connectable with warning ⚠️

> Warn if certificate is invalid and ask if to allow connection, so public remote nodes can keep valid certs and private remote nodes can be connectable with warning ⚠️

@nikg83 The SSL system for trusted mode in going to be for simple mode GUI users mainly. I don't want them to worry about valid/invalid certificates, fingerprints, etc. For simple mode, we want it to just work from a UX perspective

> <@jeffro256:monero.social> > Warn if certificate is invalid and ask if to allow connection, so public remote nodes can keep valid certs and private remote nodes can be connectable with warning ⚠️

> @nikg83 The SSL system for trusted mode in going to be for simple mode GUI users mainly. I don't want them to worry about valid/invalid certificates, fingerprints, etc. For simple mode, we want it to just work from a UX perspective

Checking ssl certificate will help all users, incase of simple mode the code can switch to other node incase invalid cert is found

* ssl certificate validity will help

Well "validity" is sort of a vague description in this context because most SSL certs are self-signed, which would not be accepted by most browsers. They could consider them "invalid", but the user of a CLI def wants to use their own cert, even if no one else will. And the only way the wallet will be able to distinguish a "valid" self-signed cert from an "invalid" self-signed cert is whether the user supplies corresponding

fingerprints. Supplying fingerprints in simple mode is counterproductive because the whole point of simple mode is that the user is not tech-saavy and introducing the concept of SSL certificates and fingerprints may overwhelm them or confuse them into accepting bad certficiates. Hence the curated trusted node list, where certs would be validated by a set of hard-coded SSL root certificates, so that not just anyone can coerce a simple

mode wallet to connect to them.

However, introducing SSL fingerprints for a slightly tech-saavy user (for example someone using the CLI wallet or advanced GUI mode) would help improve security by forcing users to confront the integrity of their SSL connections.

jeffro256[m]: Yes, self signed will show up as invalid and should be fine for ppl connecting to their own nodes

<jeffro256[m]> "However, introducing SSL..." <- Yah that would be helpful

"Hence the curated trusted node list, where certs would be validated by a set of hard-coded SSL root certificates, so that not just anyone can coerce a simple" <-- yes, that's what I meant

Let’s say I try connect to a remote node a.xyz.com I know it’s trusted but not on gui hard coded cert, will the wallet verify its certificate?

> basically we would hardcode the fingerprint into the GUI source code, right? and then host a couple nodes with this specific cert?

Okay so I think we should hardcode a set of roots certs (like any HTTPS-like certificate authority) but also those certificates should be able to sign other certificates (chains), and we change the p2p rules regarding public node lists to only gossip about public nodes which have a certificate that can be verified by our set of root certificates

hmm, not sure about that yet, ideally I don't want any p2p dependency

Also the seed nodes should also have SSL verification

Well yeah the wallet would have no p2p dependency, but would just use RPC to retreive the public node list

Does wallet2 get the public node list from p2p protocol or from an RPC endpoint?

currently

it uses the daemon for that currently

./monerod --no-sync --bootstrap-daemon-address auto

this was the easiest way to implement this but it's not ideal

waiting for the daemon to start and stop is slow

etc.

Ah interesting. Are there any other p2p dependencies? Theoretically, the wallet could have no p2p dependencies if it has 1) secure connections to some seed node (or your own node in advanced mode) 2) a light-weight RPC endpoint to get the latest block header (already exists) 3) and an RPC endpoint to retreive public node list (doesn't exist yet)

what do you mean with 1) ? wallets don't connect to seed nodes

Well if they *did*, they could ask the seed nodes for (3), a list of trusted public nodes that they can directly connect to start scanning

I need to make a diagram or something because I don't feel like I'm making much sense right now

but seed nodes don't have any wallet RPC endpoints

Yes sorry "seed nodes" is a bad term, they wouldn't necessarily overlap with THE seed nodes for p2p.

ok, different seed nodes

that confused me

I would be some group of nodes which bootstrap trust for RPC wallet commands

> ./monerod --no-sync --bootstrap-daemon-address auto

simplewallet doesn't do this, correct? Also would I find this logic in DaemonManager.cpp ?

> ok, different seed nodes

Yes, but they could overlap

Not necessarily

Practically they probably shouldn't overlap for load balancing reasons

so ideally I don't want any monerod dependency

we don't want to increase the attack surface of p2p seed nodes, so no RPC

no, simplewallet doesn't do this

My current plan are just hardcode e.g. 10 nodes, and then let the GUI connect to a random one. Maybe it's also possible to set a preferred region for lower ping. All these 10 nodes would need a specific cert, but for that I would need your help.

<selsta> "My current plan are just..." <- Why specific cert ? Can’t the ssl certificate given by node be checked for validity ? Or you don’t want to trust root certificates or issuing authorities

What I want is when we e.g. hardcode node.xmr.pm:18081 and someone takes over that domain then the wallet stops connecting to that node

nikg83 Also it's not hard to register a malicious HTTPS certificate

I'm sure you can make a domain somewhere named "232098472098472094709237402984.iowbfhebgreoihgbeougbge.net" for a couple bucks, but should simple mode connect to that? Probably not

<selsta> "What I want is when we e.g..." <- Got it 👍 as it’s hardcoded

jeffro256[m]: If it’s my own domain and has a valid cert, why not

Simple mode will have hardcoded nodes

Right, but users using simple mode won't have their own domain and keep track of their SSL certificates

Also in simple mode, you don't specify which node you connect to IIRC

jeffro256[m]: Yep, for them the solution would be much different

@selsta this is sort of the design I was thinking about

no monerod dependency and you can connect to any arbitrary node in simple mode, as long as its chain is verified by a root certificate. There are a handful of "root nodes" which defer to other trusted IP addresses + SSL certs