17:06:48 <ma1> #startmeeting Applications Team Office Hours 2025-10-08
17:06:48 <MeetBot> Meeting started Wed Oct  8 17:06:48 2025 UTC.  The chair is ma1. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:48 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:06:59 <ma1> (just to log the silence)
17:07:17 <PieroV> And then we backport to 15.0 for the Feb 24 release
17:07:21 <dan_b> lol. but yeah i remember, so it was unlikely anyways but yeah.
17:07:26 <dan_b> haha omg
17:07:29 <PieroV> Go keeps cutting macOS support
17:07:40 <PieroV> 1.25 requires macOS 12
17:07:55 <PieroV> So, basically Google decided to support only what Apple officially supports with security updates
17:08:15 <PieroV> And Apple kills after not too long, considering they do yearly major releases
17:09:14 <PieroV> And it's awful, as it's like asking PT to stay on old Go versions, or to tell users to absolutely upgrade if they want to use bridges
17:09:24 <Jeremy_Rand_Lab19[mds]> hello!
17:10:08 <Jeremy_Rand_Lab19[mds]> So I've been pondering FPI things for onion TLS
17:10:33 <Jeremy_Rand_Lab19[mds]> (As well as Namecoin TLS, which is using the same code)
17:11:04 <Jeremy_Rand_Lab19[mds]> And I was hoping I could get a brief sanity check from you guys
17:11:10 <dan_b> pierov: from google's PoV not unreasonable, im questioning with OP stuff supporting stuff the manufacturer doesnt
17:11:26 <dan_b> but yes
17:11:27 <dan_b> it's terrible
17:11:32 <PieroV> Jeremy_Rand_Lab19[mds]: as far as I know FPI covers ephemeral keys too
17:11:41 <PieroV> (is it session keys perhaps in TLS lexicon?)
17:11:56 <dan_b> and as a team downstream of apple and google. esh. tough if we want to care more about users than they do, which is... not hard to do, harder then to implement
17:11:59 <PieroV> ((that tells how much unreliable I am for this kind of questions :)))
17:12:10 <morganava> o/
17:12:32 <Jeremy_Rand_Lab19[mds]> So the issue I'm dealing with is that PKCS#11 modules don't have any API for getting the first-party origin associated with a cert lookup
17:13:10 <Jeremy_Rand_Lab19[mds]> Meaning that if the cert lookup induces a PKCS#11 module to generate any network traffic or handle state, then you get a FPI leak
17:14:33 <Jeremy_Rand_Lab19[mds]> For onion services, a cert lookup will trigger a fetch of the onion descriptor, for Namecoin domains, a cert lookup will trigger an Electrum-NMC request to a remote server
17:15:09 <Jeremy_Rand_Lab19[mds]> In theory, you could patch NSS to have an FPI API added to PKCS#11
17:15:13 <Jeremy_Rand_Lab19[mds]> But this would be quite invasive
17:16:05 <Jeremy_Rand_Lab19[mds]> You could also potentially just never cache anything, and use a fresh Tor circuit for every cert lookup, but this would suck for performance
17:16:14 <PieroV> Not only for performance
17:16:51 <PieroV> Mike Perry advised us against creating new circuits for a similar case
17:16:53 <Jeremy_Rand_Lab19[mds]> So here is the workaround I have come up with
17:17:09 <Jeremy_Rand_Lab19[mds]> PieroV: ah interesting
17:17:11 <PieroV> I don't remember if it's bad for guard discovery, I would have to find the comment
17:17:21 <Jeremy_Rand_Lab19[mds]> Hmm
17:17:25 <Jeremy_Rand_Lab19[mds]> Anyway so
17:17:54 <Jeremy_Rand_Lab19[mds]> PKCS#11 modules don't have access to the first-party origin, but the control port does
17:18:20 <Jeremy_Rand_Lab19[mds]> And any time you open a connection to an onion service or a Namecoin domain, the control port sees a new stream
17:18:47 <Jeremy_Rand_Lab19[mds]> Indeed, we already use the control port to resolve Namecoin domains to the appropriate IP or onion service
17:18:58 <Jeremy_Rand_Lab19[mds]> So what I think we can do here is
17:20:07 <PieroV> (I'll let you finish - but control port knows about FPI only after the connection has already been opened, the proxy filters knows about FPI)
17:20:14 <Jeremy_Rand_Lab19[mds]> When we get a notification from the control port that a .onion or .bit domain is being requested, we (synchronously) fetch the data that's needed to validate TLS certs for that domain, using stream isolation per the origin that the control port tells us was used
17:21:03 <Jeremy_Rand_Lab19[mds]> We cache that data locally in a place where the PKCS#11 module can access it
17:21:34 <Jeremy_Rand_Lab19[mds]> Then, when the PKCS#11 module gets a cert lookup request, it doesn't do any new lookups, instead it only uses that cached data
17:22:29 <Jeremy_Rand_Lab19[mds]> That cached data cannot be directly queried by the website, the only behavioral inference the website can make about it is "did the TLS connection succeed or not"
17:23:00 <Jeremy_Rand_Lab19[mds]> Which, AFAICT, is safe from an FPI standpoint.
17:24:08 <Jeremy_Rand_Lab19[mds]> If the website sends a cert chain that's designed to induce a PKCS#11 lookup for a domain that isn't the domain being connected to, then the cert validation will fail due to a name constraint violation, but that doesn't give any way to fingerprint the user or bypass FPI
17:24:20 <Jeremy_Rand_Lab19[mds]> Since that cert chain would have been rejected anyway
17:25:20 <Jeremy_Rand_Lab19[mds]> A longer writeup is at https://github.com/namecoin/encaya/issues/70 but basically I'm hoping you guys can tell me if I'm failing to notice any FPI leak vectors here
17:26:21 <Jeremy_Rand_Lab19[mds]> PieroV: the control port does know about FPI in the sense that it can see the SOCKS5 user+pass of the stream before the stream is assigned to a circuit, which is sufficient for this purpose
17:26:34 <PieroV> Jeremy_Rand_Lab19[mds]: onion services usually have its own circuit anyway
17:27:09 <PieroV> So, you'll get a new circuit for other resources... But having it tied to the onion service would be still a good goal
17:27:36 <PieroV> Jeremy_Rand_Lab19[mds]: did you play already with this code?
17:28:05 <PieroV> Our proxy filter needs a browser/browsingContext for associating the credentials
17:28:25 <Jeremy_Rand_Lab19[mds]> PieroV: the code for getting the SOCKS5 user+pass over the control port?
17:28:34 <Jeremy_Rand_Lab19[mds]> That code has been in active use by Namecoin for years
17:28:46 <PieroV> Are the request you're interested in catching associated to this data
17:28:51 <PieroV> ?
17:29:24 <Jeremy_Rand_Lab19[mds]> PieroV: not sure I understand the question, can you elaborate?
17:29:40 <PieroV> Jeremy_Rand_Lab19[mds]: sure
17:30:19 <PieroV> Have you noticed that the streams you're interested in catching are correctly associated to the expected username and password?
17:30:25 <PieroV> This is what I meant by "play with" :)
17:31:21 <PieroV> (either on the control port side, or in the browser side - for the latter you can set `browser.tordomainisolator.loglevel` to `All`)
17:31:26 <Jeremy_Rand_Lab19[mds]> PieroV: I think so? I tried switching circuits in Tor Browser when loading Namecoin domains, and Electrum-NMC did correctly log that the stream isolation parameter was changing
17:31:47 <Jeremy_Rand_Lab19[mds]> Is there some reason this would be expected to not work in some situations?
17:32:11 <PieroV> Jeremy_Rand_Lab19[mds]: wait, is the request happening on the browser or on another program?
17:32:43 <PieroV> So far I thought it was going through the browser's network stack, but maybe I misunderstood
17:33:01 <Jeremy_Rand_Lab19[mds]> PieroV: Namecoin has a dedicated program that talks to the control port and resolves Namecoin domains to IP addresses and onion services
17:34:00 <Jeremy_Rand_Lab19[mds]> (the motivation for it being a separate program is that I want Namecoin support to work in arbitrary applications, not just Tor Browser -- same motivation applies for onion TLS, since PKCS#11 is a thing in lots of applications, e.g. wget)
17:37:15 <PieroV> And are you trying to isolate requests that are originated from this separate program?
17:40:55 <Jeremy_Rand_Lab19[mds]> PieroV: that program needs to (at the least) isolate any requests it makes from each other, based on the SOCKS5 user+pass that it sees associated with the STREAM events that it receives from the Tor control port. Which it does; that code has been written and tested for years.
17:40:56 <Jeremy_Rand_Lab19[mds]> The new thing I'm looking for peer review on is the idea of having that program also cache the data needed to validate TLS certs (which it retrieves anyway as a side effect of its existing requests), in a place where the PKCS#11 module can see it, so that the PKCS#11 module doesn't have to trigger any new network requests when a cert lookup happens
17:45:15 <Jeremy_Rand_Lab19[mds]> (I apologize if I'm explaining this in a way that assumes too much familiarity with how Namecoin TLS and Namecoin onion naming work under the hood)
17:45:42 <PieroV> And is your objective to re-use the same circuit as the other application? In case, I wonder if IsolateClientAddr could be a problem (maybe - I don't know if the address here is only the IP address or the (IP, port) tuple)
17:47:38 <Jeremy_Rand_Lab19[mds]> PieroV: reusing the same circuit between e.g. Tor Browser and the controller program would be nice I suppose but it's not my primary goal and I don't care too much if it doesn't happen. I just want to make sure that when Tor Browser queries my PKCS#11 module to do a cert lookup, this doesn't produce any FPI leaks that could track users in some way.
17:54:13 <PieroV> Okay, I think I got it, more or less. But I'm not sure you'll get all the info from the streams
17:54:35 <PieroV> I mean, a website could request any image, or stylesheet, or script, and so on
17:54:36 <Jeremy_Rand_Lab19[mds]> Put another way, I guess my question is: assuming that the actual fetching of data needed to validate the cert chain is stream isolated properly, is there any FPI leak vector from the fact that this data is cached in a place that can be read by PKCS#11 without any FPI?
17:54:37 <Jeremy_Rand_Lab19[mds]> My intuition is that this is not dangerous because the only way a website can infer what's in that local cache is by seeing "does a TLS connection fail or succeed", and this doesn't yield any new information for the website to fingerprint by, as long as we make sure that the TLS cert validation is done correctly (which I think we are doing)
17:54:52 <PieroV> And I think you'll see only the first pary from there. Do you need the specific site too?
17:56:01 <Jeremy_Rand_Lab19[mds]> PieroV: the control port should tell us both the destination domain and the first-party domain; that's been working fine for years
17:56:02 <PieroV> Also, what if two different sites request the same domain? Will you re-use the cache?
17:56:14 <PieroV> Oh, okay, then you should be golden :)
17:57:57 <Jeremy_Rand_Lab19[mds]> PieroV: so if two different first-party domains induce a connection to the same Namecoin or onion service, then the result is that we do two lookups (with stream isolation), but the results of those lookups get placed in the same cache that PKCS#11 can read. I believe this should not be a problem, because that just means you cache two TLS intermediate CA's that have the same name constraint and the same public key, so they
17:57:57 <Jeremy_Rand_Lab19[mds]> have the same behavior.
17:58:42 <Jeremy_Rand_Lab19[mds]> The two intermediate CA's will have different cert serial numbers and different expiration dates (but both are unexpired), but that's not detectable by a website
17:58:55 <Jeremy_Rand_Lab19[mds]> (which is why I was asking yesterday whether a website could tell what cert chain got built by the browser)
17:59:39 <PieroV> (BTW, we're close to the hour)
17:59:55 <Jeremy_Rand_Lab19[mds]> we can move to #tor-browser-dev if needed
18:00:30 <ma1> ok then
18:00:41 <ma1> #endmeeting