19:58:51 <selsta> jeffro256[m]: https://github.com/monero-project/monero/pull/8344
20:00:11 <selsta> basically we would hardcode the fingerprint into the GUI source code, right? and then host a couple nodes with this specific cert?
20:02:36 <selsta> seems like a good idea
20:03:12 <selsta> instead of just hardcoding IPs / domains for the remote node list
20:39:58 <jeffro256[m]> 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 
20:42:02 <jeffro256[m]> 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"
20:42:48 <jeffro256[m]> Then it would remember it later so you don't have to reconfirm it. Think of the know_hosts file for SSH
20:43:15 <jeffro256[m]> But that PR is just an extra file that sits besides your certificate file, it doesn't do anything yet
20:49:06 <nikg83[m]> <selsta> "basically we would hardcode..." <- Why hardcode ? Can’t we do it like browsers which validate certificate 
20:59:34 <nikg83[m]> 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 ⚠️
21:19:36 <jeffro256[m]> > 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 ⚠️ 
21:19:36 <jeffro256[m]> @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 
21:22:38 <nikg83[m]> > <@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 ⚠️ 
21:22:38 <nikg83[m]> > @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 
21:22:38 <nikg83[m]> Checking ssl certificate will help all users, incase of simple mode the code can switch to other node incase invalid cert is found 
21:23:46 <nikg83[m]> * ssl certificate validity will help
21:37:45 <jeffro256[m]> 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
21:37:45 <jeffro256[m]> 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
21:37:45 <jeffro256[m]> mode wallet to connect to them. 
21:39:04 <jeffro256[m]> 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. 
21:41:40 <nikg83[m]> jeffro256[m]: Yes, self signed will show up as invalid and should be fine for ppl connecting to their own nodes 
21:43:57 <nikg83[m]> <jeffro256[m]> "However, introducing SSL..." <- Yah that would be helpful 
22:02:15 <selsta> "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
22:07:34 <nikg83[m]> 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?
22:08:33 <jeffro256[m]> > basically we would hardcode the fingerprint into the GUI source code, right? and then host a couple nodes with this specific cert?
22:08:33 <jeffro256[m]> 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 
22:10:26 <selsta> hmm, not sure about that yet, ideally I don't want any p2p dependency
22:10:34 <jeffro256[m]> Also the seed nodes should also have SSL verification 
22:12:28 <jeffro256[m]> Well yeah the wallet would have no p2p dependency, but would just use RPC to retreive the public node list 
22:12:53 <jeffro256[m]> Does wallet2 get the public node list from p2p protocol or from an RPC endpoint?
22:12:57 <jeffro256[m]> currently 
22:13:11 <selsta> it uses the daemon for that currently
22:13:22 <selsta> ./monerod --no-sync --bootstrap-daemon-address auto
22:14:29 <selsta> this was the easiest way to implement this but it's not ideal
22:14:35 <selsta> waiting for the daemon to start and stop is slow
22:14:39 <selsta> etc.
22:18:44 <jeffro256[m]> 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)
22:22:35 <selsta> what do you mean with 1) ? wallets don't connect to seed nodes
22:24:57 <jeffro256[m]> 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 
22:26:02 <jeffro256[m]> I need to make a diagram or something because I don't feel like I'm making much sense right now 
22:26:05 <selsta> but seed nodes don't have any wallet RPC endpoints
22:27:04 <jeffro256[m]> Yes sorry "seed nodes" is a bad term, they wouldn't necessarily overlap with THE seed nodes for p2p. 
22:27:15 <selsta> ok, different seed nodes
22:27:17 <selsta> that confused me
22:27:23 <jeffro256[m]> I would be some group of nodes which bootstrap trust for RPC wallet commands 
22:29:21 <jeffro256[m]> > ./monerod --no-sync --bootstrap-daemon-address auto
22:29:21 <jeffro256[m]> simplewallet doesn't do this, correct? Also would I find this logic in DaemonManager.cpp ?
22:29:56 <jeffro256[m]> > ok, different seed nodes
22:29:56 <jeffro256[m]> Yes, but they could overlap 
22:30:03 <jeffro256[m]> Not necessarily 
22:30:58 <jeffro256[m]> Practically they probably shouldn't overlap for load balancing reasons 
22:30:59 <selsta> so ideally I don't want any monerod dependency
22:31:27 <selsta> we don't want to increase the attack surface of p2p seed nodes, so no RPC
22:33:32 <selsta> no, simplewallet doesn't do this
22:38:37 <selsta> 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.
23:01:11 <nikg83[m]> <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 
23:03:52 <selsta> 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
23:21:52 <jeffro256[m]> nikg83 Also it's not hard to register a malicious HTTPS certificate 
23:22:39 <jeffro256[m]> 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 
23:23:08 <nikg83[m]> <selsta> "What I want is when we e.g..." <- Got it 👍 as it’s hardcoded 
23:24:12 <nikg83[m]> jeffro256[m]: If it’s my own domain and has a valid cert, why not 
23:25:05 <nikg83[m]> Simple mode will have hardcoded nodes
23:25:33 <jeffro256[m]> Right, but users using simple mode won't have their own domain and keep track of their SSL certificates 
23:25:53 <jeffro256[m]> Also in simple mode, you don't specify which node you connect to IIRC
23:26:00 <nikg83[m]> jeffro256[m]: Yep, for them the solution would be much different 
23:26:58 * jeffro256[m] uploaded an image: (2248KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/ciJDpdqwziTodDDpcshBzbqk/ima_3cf047d.png >
23:27:16 <jeffro256[m]> @selsta this is sort of the design I was thinking about 
23:29:08 <jeffro256[m]> 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