16:02:29 <cohosh> #startmeeting anti-censorship team meeting
16:02:29 <MeetBot> Meeting started Thu Jun 11 16:02:29 2026 UTC.  The chair is cohosh. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:02:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:02:31 <cohosh> hello
16:02:42 <Shelikhoo[mds]> hi~\
16:02:59 <cohosh> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:03:00 <M4i_un[mds]> hello~
16:03:20 <cohosh> please feel free to add to the agenda
16:03:26 <onyinyang[mds]> hello!
16:03:59 <cohosh> we've got at least one item of discussion and a reading group today
16:04:27 <dcf1> The discussion point is from last week "TLS fingerprint camouflage in rust"
16:04:44 <cohosh> the discussion item is from Shelikhoo[mds] on TLS fingerprint camouflage in rust
16:04:51 <Shelikhoo[mds]> yes!
16:04:52 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/194#note_3418590
16:05:00 <cohosh> https://gitlab.torproject.org/-/snippets/243
16:05:46 <Shelikhoo[mds]> So last week, I mentioned that the research on 2 routes we can choose when it comes to tls fingerprint imitation/diversification
16:06:21 <Shelikhoo[mds]> as shown in the report we can either imitate all the extension of the connection like how utls works
16:06:46 <Shelikhoo[mds]> or delegate the handshake to a wasm binary and then take over the connection, like how ktls works
16:07:18 <Shelikhoo[mds]> and we would like to discuss how we wants to proceed with this.
16:08:02 <cohosh> is there a timeline for when the decision is needed?
16:08:33 <Shelikhoo[mds]> I think we wants to make this decision soon, we are suppose to implement this now according to the timeline
16:09:18 <Shelikhoo[mds]> but I don't know a specific timeline
16:09:43 <cohosh> in reading your report, i remembered this implementation idea that arturo was excited about a few years ago: https://github.com/ooni/utls-light
16:10:06 <cohosh> i think it falls into the imitation path, but it's a different way to approach the implementation
16:12:27 <Shelikhoo[mds]> Yeah, I think there are different approach when it comes to imitation
16:13:52 <Shelikhoo[mds]> that being said, the key limitation, like constant work to keep up with both upstream still apply
16:15:00 <Shelikhoo[mds]> so we will be expecting some amount of constant maintenance work
16:15:18 <cohosh> yeah
16:15:34 <Shelikhoo[mds]> although this would make the library easier to use for sure
16:16:56 <Shelikhoo[mds]> So this is more or less a tradeoff
16:17:13 <cohosh> it wasn't clear to me how the estimated work compared, the takeover route is more complex in terms of piecing together components, but would it take less time to get something minimally working?
16:17:47 <cohosh> it reminds me a little of the original headless browser technique used by meek
16:19:51 <Shelikhoo[mds]> cohosh: It is possible to create a MVP for takeover route, but it would be maybe at least 50% of effort compare to its full shape
16:19:59 <cohosh> the discussion about randomizing existing extensions to create a lot of fingerprints was also interesting: https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/194#note_3409535
16:20:23 <Shelikhoo[mds]> as for the imitation route, since there is already a craftls, it take less effort to get started
16:21:36 <Shelikhoo[mds]> yes, randomizing existing extensions would work in the way that it create a lot of different fingerprints, but to be fair most of them can be blocked with a regular expression
16:21:58 <Shelikhoo[mds]> so it will work temporarily
16:22:01 <cohosh> oh i see in the craftls README there are some browser fingerprints already supported: https://github.com/3andne/craftls
16:22:52 <cohosh> ah but it's not being maintained
16:22:52 <Shelikhoo[mds]> yes, we just need to rebase it to the most recent restls, and fix a identification surface to get it to work
16:23:03 <cohosh> ok, makes sense
16:23:54 <Shelikhoo[mds]> I think most users update their browsers once in a while, so a old browser is not really a good imitation target
16:24:42 <Shelikhoo[mds]> in the takeover route, I also estimated the work to leverage IOT/embedded TLS stake
16:24:49 <Shelikhoo[mds]> in the takeover route, I also estimated the work to leverage IOT/embedded TLS stack
16:25:38 <Shelikhoo[mds]> where these TLS fingerprint will be seen from IOT devices, where, as you would imagined, hardly get an automated update
16:26:24 <Shelikhoo[mds]> so they are less likely to be blocked because of their staleness
16:27:14 <Shelikhoo[mds]> that being said, I think in the most case, the update for these tls library in these delegated handshaker can be done in an automated way
16:27:35 <Shelikhoo[mds]> by just update the source code of these libraries's source code
16:28:03 <cohosh> ok
16:28:45 <cohosh> and there's some maintenance risk i guess in major version updates of these libraries that will require us to change how we call that code?
16:29:40 <Shelikhoo[mds]> yes, it is true. But I assume that is not very frequent, although I have not examined that closely
16:30:58 <Shelikhoo[mds]> there are maybe 8 library we examined for delegate integration. I assume that such major version upgrade won't happen to all of them at the same time
16:31:27 <Shelikhoo[mds]> so we shouldn't end up in an emergency to update the library to pass some censorship
16:31:54 <Shelikhoo[mds]> although the need for such maintenance task is expected
16:31:57 <cohosh> and we'd only integrate one of these, right?
16:32:04 <cohosh> or a small number?
16:32:43 <Shelikhoo[mds]> yes, we won't need to integrate all of them, but we have these 8 options
16:32:50 <cohosh> cool
16:32:52 <Shelikhoo[mds]> 309613 May 14 22:02 tlsdelegate-bearssl-handshaker.wasm... (full message at <https://matrix.debian.social/ircbridge/media/v1/media/download/AXG47v1e8E_R6sFnelICOcsJtiZxvygY5e9T5CgS0b3lL4RqKk7lzzHRsbFU1BlmaMtsnRQfo6Y7baXfueUXgO5Cee25QIFAAG1hdHJpeC5kZWJpYW4uc29jaWFsL2ZCZnVJWFFqYnliUE1Vb1diZ3RKR21jSQ>)
16:33:19 <cohosh> i don't have a strong opinion one way or the other, they both require work and maintenance
16:33:50 <cohosh> i guess the imitation route we also have the option of starting with a small number of supported fingerprints and slowly expanding it
16:34:13 <cohosh> dcf1: do you have any insights in the switch from using a headless browser to using utls in meek?
16:34:34 <cohosh> the switch happened soon after i started at tor iirc
16:35:08 <Shelikhoo[mds]> yes, we could always just start with a small number of fingerprints even with imitation route
16:35:49 <cohosh> even though utls is maintained outside our team, it has still required some maintenance cost with us, especially with toolchain requirements for tor browser builds
16:35:50 <Shelikhoo[mds]> or we should say it already have a few fingerprint, we just need to sync it with upstream to use it
16:36:30 <cohosh> i am a little worried about how the takeover method would work with reproducible builds
16:36:34 <cohosh> and binary size
16:36:42 <Shelikhoo[mds]> yes, and utls is not, to the best of my knowledge, in perfect sync with chrome/firefox browser's updates
16:37:43 <Shelikhoo[mds]> I have not checked reproducible builds, but as for binary size, most handshaker would be 2-3 MB in size
16:38:15 <cohosh> we had a problem with using chrome's webrtc library in snowflake builds
16:38:32 <cohosh> it's ultimately what caused us to switch to using the pion go webrtc implementation
16:38:55 <Shelikhoo[mds]> yes... at least these handshakers won't run directly on client machine
16:39:11 <Shelikhoo[mds]> they are inside a restrictive runtime
16:39:34 <dcf1> cohosh: this is the issue of changing meek from headless firefox to utls https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/work_items/29077
16:39:54 <Shelikhoo[mds]> I should say at this point, that building these handshaker requires wasm's C toolchain
16:40:15 <Shelikhoo[mds]> which also need to be build from source for our reproducible build
16:40:19 <cohosh> Shelikhoo[mds]: the client requires the wasm C toolchain right?
16:40:24 <cohosh> ok yep
16:40:52 <Shelikhoo[mds]> cohosh: the client do not need it, only building them require them
16:40:58 <dcf1> the headless firefox worked well enough, but the linking together of different processes etc. was fairly intricate, and it took a lot of maintenance effort with each new release of tor browser to adjust settings to keep the fingerprint indistinguishable
16:41:14 <Shelikhoo[mds]> the client do not need it, only building the handshaker wasm binary require them
16:42:14 <cohosh> Shelikhoo[mds]: sorry maybe i am misunderstanding how the delegation works
16:42:35 <dcf1> tpo/anti-censorship/pluggable-transports/meek#11183
16:42:59 <Shelikhoo[mds]> So the delegation is running a binary wasm handshaker at client, which handle the TLS handshake
16:43:14 <Shelikhoo[mds]> which only requires a WASM interpreter/runtime
16:43:21 <Shelikhoo[mds]> and not a full compile toolchain
16:43:21 <cohosh> ok right
16:43:24 <cohosh> ah i see
16:43:48 <Shelikhoo[mds]> the WASM binary itself is requires a full C/C++, Rust toolchain
16:44:30 <dcf1> tpo/anti-censorship/pluggable-transports/meek#13442 tpo/anti-censorship/pluggable-transports/meek#15512 tpo/anti-censorship/pluggable-transports/meek#18927 tpo/anti-censorship/pluggable-transports/meek#22515 tpo/anti-censorship/pluggable-transports/meek#26241
16:44:31 <cohosh> that does match my understanding, and you're saying that we wouldn't need to generate these wasm blobs in the reproducible builds, just something that lets the client interpret them
16:45:29 <Shelikhoo[mds]> cohosh: In theory yes
16:45:54 <cohosh> dcf1: thanks for linking these
16:45:54 <dcf1> Not necessarily as much of a concern with BYOB, since it won't have the Tor Browser defaults that the meek-http-helper had to work do undo in some cases
16:46:17 <cohosh> yeah it sounds like the problems you faced are different than what might come up here
16:46:57 <Shelikhoo[mds]> but if our policy requires all binary be generated by rbm, then, yes, it would require a complex wasm toolchain setup
16:47:38 <Shelikhoo[mds]> as the wasm toolchain would require bootstrap
16:47:50 <cohosh> we are using a wasm blob with the lox tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/work_items/43096
16:47:59 <Shelikhoo[mds]> https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-33
16:48:45 <cohosh> but the difficulty there is also different from this
16:49:21 <Shelikhoo[mds]> yes, at least for the handshaker, the wasm binary would not need to be run by tor browser
16:49:55 <Shelikhoo[mds]> or at least it can be correctly sandboxed
16:50:44 <cohosh> ok nothing else is really coming to mind to discuss, it doesn't seem clear to me which route is better, they both seem reasonable and effortful
16:51:08 <cohosh> are you leaning one way Shelikhoo[mds], having spent the most time researching this?
16:52:05 <Shelikhoo[mds]> personally I think delegation would work better as it would allow us to defect MITM attack directly
16:52:43 <Shelikhoo[mds]> if we just go with the imitation route, then there is a risk that censor MITM the connection and choose an option that is not actually supported by cilent
16:53:16 <Shelikhoo[mds]> and the attacker would see client react in a distinct way, before the MITM attack is spotted(before server need to proof its identity)
16:54:18 <cohosh> i guess it's part of the parrot is dead argument of imitation
16:54:28 <Shelikhoo[mds]> and with delegation route, even if an option that is not supported by take over host is selected, the server would need to finish the handshake stage to see the client act in a different way
16:54:31 <cohosh> it's hard to satisfy all these edge cases
16:55:00 <Shelikhoo[mds]> so the attacker without server certificate secret will not work
16:55:35 <Shelikhoo[mds]> yes, I think it is really hard to defend against an active attacker with tls imitation
16:56:32 <Shelikhoo[mds]> for that reason I think delegation works on an known interface(ktls)
16:56:35 <cohosh> ok that seems good to me, i think a good first step is to verify that tor browser builds would still work, although i think it should
16:57:07 <Shelikhoo[mds]> yes, I will open a ticket and describe to the tor browser team what we intent to do
16:57:13 <cohosh> ok thanks
16:57:28 <Shelikhoo[mds]> like explain how the delegation/take over would work
16:57:39 <Shelikhoo[mds]> and see if have any reason to object to it
16:57:41 <cohosh> sorry for taking so much time in the discussion, we still have another point from M4i_un[mds] and reading group today
16:57:45 <cohosh> Shelikhoo[mds]: awesome
16:57:57 <Shelikhoo[mds]> thanks~
16:58:03 <Shelikhoo[mds]> sorry for the long discussion as well...
16:58:05 <Shelikhoo[mds]> hahah
16:58:18 <cohosh> M4i_un[mds]: the floor is yours :)
16:58:41 <M4i_un[mds]> If I'm not mistaken, I believe we were supposed to have a paper discussion session next, but does everyone still have time?
16:58:49 <M4i_un[mds]> okey
16:59:16 <M4i_un[mds]> I think I mentioned this briefly last week, but I was actually planning to apply for UAT funding through the NLnet NGI0 Commons Fund. However, since the application period for the 2026 fiscal year closed on June 1, I found the following project instead.
16:59:16 <M4i_un[mds]> https://apply.opentech.fund/
16:59:52 <M4i_un[mds]> I am currently considering applying for UAT funding for this project. While there are various reasons why I need the grant, the main one is to secure the time I need to develop UAT.
17:00:13 <M4i_un[mds]> Before I submit this, I’d like to hear your initial thoughts. And I plan to submit it based on the following plan—what do you think?
17:00:31 <cohosh> wow nice
17:00:38 <M4i_un[mds]> 1. Similar to WebTunnel, enable UAT to display the actual website on the same port.
17:00:38 <M4i_un[mds]> 2. In preparation for future integration, I will set up as many processes as possible—such as CI testing—at this stage
17:00:38 <M4i_un[mds]> 3. I will update the README to include deployment instructions and create a UAT website.
17:00:38 <M4i_un[mds]> 4. I will produce a report in some form regarding the performance comparison with WebTunnel, which I am currently researching.
17:01:05 <M4i_un[mds]> I plan to carry out these projects over a period of about six months to a year.
17:01:50 <cohosh> this sounds like a good plan, i hope you get the funding
17:02:09 <Shelikhoo[mds]> sounds great!
17:02:51 <cohosh> a usual problem that comes up with funding proposals like this is over-promising on tasks that could get blocked on someone from our team or tor to perform
17:03:04 <cohosh> but none of these tasks are things that would be blocked by us
17:03:34 <M4i_un[mds]> By the way, since this is my first time submitting an application like this, I’m honestly not sure exactly how much I should request.
17:03:50 <cohosh> my main advice is to discuss with us if otf gets back to you about wanting some direct interaction with our tools for deployment
17:03:52 <M4i_un[mds]> cohosh: I see. Thanks!
17:05:17 <cohosh> M4i_un[mds]: heh, i'm not good at this myself. i know someone who applied for otf funding recently. i can ask her and get back to you on that after the meeting
17:05:33 <cohosh> (about how much to ask for)
17:06:00 <M4i_un[mds]> That's a big help!
17:06:05 <Shelikhoo[mds]> nice!
17:06:24 <cohosh> for CI stuff and performance tests i'm curious what route you end up choosing
17:06:48 <cohosh> if you want to use shadow, i'm happy to point you towards resources and provide feedback
17:07:07 <cohosh> it's not good for everything but i've really liked it for integration testing PTs
17:08:05 <cohosh> and good luck! let us know how it goes
17:08:26 <cohosh> ok we're running pretty late, can i get a vibe check on whether people want to stay late and discuss the paper or push it to next week?
17:08:33 <Shelikhoo[mds]> yes! good luck!
17:08:49 <Shelikhoo[mds]> I am happy to discuss the paper
17:08:51 <M4i_un[mds]> To be honest, I am still in the early stages of considering CI-related matters, but as for performance testing, we’re using a specific paper as a reference to set up WebTunnel, UAT, and Chutney locally to measure performance.
17:09:53 <cohosh> M4i_un[mds]: okay nice :)
17:10:30 <M4i_un[mds]> sorry,thx!
17:10:52 <M4i_un[mds]> I am happy to discuss the paper too
17:11:02 <cohosh> ok, does anyone have a summary ready?
17:12:11 <dcf1> Some past papers have suggested the idea of routing the beginning of a QUIC connection over a different channel
17:12:37 <dcf1> and then doing the remainder of the connection direct, and relying on QUIC connection migration to glue together the two parts
17:12:57 <dcf1> This paper's focus is on an implementation and robust evaluation of the concept
17:13:42 <dcf1> The implementation uses WireGuard for the covert tunnel for the handshake, and iptables to choose which outgoing network interface to use for each packet (wireguard or direct)
17:14:11 <dcf1> They do a bunch of measurements to quantify how prevalent support for QUIC connection migration is in practice, which is actually not very
17:14:31 <dcf1> EOF
17:14:43 <cohosh> awesome, thanks for the summary
17:14:53 <dcf1> https://github.com/inspire-group/QUICstep
17:14:58 <dcf1> "3 years ago" gosh
17:15:14 <M4i_un[mds]> thanks for the summary!
17:16:22 <Shelikhoo[mds]> thanks for the summary
17:16:22 <dcf1> something like this faces a lot of barriers to practical use, it looks like
17:16:47 <dcf1> first of all, it only works when the domain name (SNI) is blocked but the IP address is not blocked
17:17:02 <dcf1> If the IP is blocked, it's like Geneva, you cannot help it
17:17:53 <dcf1> and then you need a web server that supports QUIC connection migration, which actually is not very common
17:18:00 <dcf1> see table 1 on page 6
17:18:48 <dcf1> connection migration is basically not supported at all on Cloudflare. the rate is higher on some other providers, but even then there are caveats, like only supporting a change of ports but not of client IP address
17:19:42 <dcf1> this is complicated by the fact that the local "end" of end-to-end QUIC is often compiled directly into an application, and would be hard to instrument or change without recompiling
17:19:53 <cohosh> i read a previous paper on this topic a while ago and i'd misremembered how the connection migration worked
17:19:56 <cohosh> https://petsymposium.org/popets/2022/popets-2022-0083.pdf
17:20:08 <dcf1> Yeah that's CoMPs which this paper cites
17:20:24 <cohosh> for some reason, i thought the connection migration occurred mid handshake to thwart middle boxes
17:20:37 <cohosh> without the use of an additional encrypted tunnel
17:20:44 <dcf1> The iptables rules in 3.2.3 have to work around the fact that, even on the local host of the client, you cannot see inside the encrypted QUIC packets in order to distinguish different types of packets
17:20:50 <cohosh> but i think i was melding some of the geneva techniques with this idea
17:21:03 <dcf1> but they found a sufficient workaround having to do with the fact that handshake packets use a different format
17:21:24 <Shelikhoo[mds]> I sense a probable use case, that is use this as some kind of new domain fronting to be used by anti-censorship tools
17:21:56 <Shelikhoo[mds]> like if some CDN supports quic connection migration
17:22:17 <dcf1> quic connection migration is kind of like snowflake session continuity. QUIC connections have a "connection ID" which is like the turbo tunnel "session ID". The connection ID is independent of the IP/port of the endpoints. That means when some part of the 4-tuple changes, the server can tell it's still the same connection, because of the connection ID.
17:22:30 <Shelikhoo[mds]> then an payload connection can be bootstrapped from a slow signaling channel
17:23:05 <Shelikhoo[mds]> in order to reduce consumption of signaling channel
17:23:21 <dcf1> There's an additional PATH_CHALLENGE/PATH_RESPONSE step in QUIC, but otherwise it's just a lot like how we use turbo tunnel. The server starts to reply to whatever client IP/port most recently communicated with it using a given connection ID.
17:23:51 <dcf1> I wondered if it would be possible to do this with a local SOCKS proxy or MASQUE proxy, and I'm not sure.
17:24:27 <Shelikhoo[mds]> dcf1: most of application does not support UDP over socks5
17:24:33 <dcf1> I'm not sure to what extent the QUIC stack needs to be made aware of the change in address in order to start its PATH_CHALLENGE procedure, an application-layer proxy might make that opaque, as opposed to the network-layer wireguard they were doing
17:24:50 <dcf1> Shelikhoo[mds]: not the point I'm trying to make
17:25:11 <dcf1> think just MASQUE if it helps, a QUIC or HTTP/3 proxy
17:25:53 <dcf1> yes, that's an interesting aspect of this, which is that the covert channel might be able to be served by what we usually think of as rendezvous channels
17:26:09 <dcf1> like QUICstep is not exeactly rendezvous, but there are similarities
17:27:06 <dcf1> There is a paper somewhat similar in spirit to QUICstep that I only became aware of recently, working on the fountain codes paper.
17:27:19 <cohosh> i see, but with this you couldn't easily plug in an application-level signalling channel for the handshake step?
17:27:20 <dcf1> "DNS-Morph: UDP-Based Bootstrapping Protocol for Tor" https://github.com/net4people/bbs/issues/619 https://arxiv.org/abs/1904.01240
17:27:50 <dcf1> cohosh: that's what I'm not sure about, whether the interface with the quic library makes it possible for the library to know its IP address has changed
17:28:05 <cohosh> got it
17:28:43 <dcf1> DNS-Morph implemented the idea for scramblesuit, which has a two-part initial handshake of one upload followed by one download. (They specialized the implementation to this communication pattern, it would not immediately work for other protocols.)
17:29:27 <dcf1> In order to implement it, they had to hack the source of pyobfsproxy, in order to know where the handshake boundaries were, which is similar to the challenge QUICstep faced.
17:29:48 <cohosh> cool
17:30:05 <dcf1> DNS-Morph used a DNS tunnel for the handshake tunnel. And there's no connection migration to speak of, both endpoints needed altered source code and to be DNS-Morph-aware.
17:30:55 <dcf1> DNS-Morph didn't make sense to me in one big way, namely that it targeted FEP protocols like ScrambleSuit. Because, by definition, the middle of a FEP protocol looks like the beginning (up to traffic analysis)
17:31:28 <dcf1> so sending the prefix of a FEP over a different channel just gets you a new "prefix" which is qualitatively similar when you do eventually make the direct TCP connection for the rest of the connection
17:32:05 <dcf1> In other words, if a censor was going to block ScrambleSuit as it is, it probably will also block DNS-Morph followed by ScrambleSuit.
17:32:34 <dcf1> QUICstep is different of course, because the prefix (handshake) of a connection *is* different from the rest, notably in that it includes classification features like the SNI
17:33:11 <dcf1> DNS-Morph might have made more sense if used with a TCP-TLS tunnel, then it would be analogous do what QUICstep is doing (still without the connection migration part).
17:33:28 <Shelikhoo[mds]> nice, I wonder if QUIC server that don't support connection migration can allow sni block bypass via nat rebinding support and forged src ip address
17:34:09 <Shelikhoo[mds]> https://quic-go.net/docs/quic/connection-migration/#nat-rebindings
17:34:50 <Shelikhoo[mds]> If QUIC server allow this nat rebind to happen immediately before client "receive" its packet
17:35:09 <dcf1> One non-obvious and interesting thing was section 4.4.7. since the DNS lookup goes through the wireguard tunnel as well, the server IP address you get is the one you would get from the point of view of the wireguard peer. which may not be optimal (might be geographically distant) from the IP address you would get from your own location, which is what gets used for most of the connection.
17:35:16 <Shelikhoo[mds]> then a server can send a sequence of handshake packet from client's ip address
17:35:42 <Shelikhoo[mds]> and then, let the client take over that connection, without sending SNI again
17:36:33 <dcf1> I don't understand Shelikhoo[mds].
17:37:04 <dcf1> The server sends a sequence of spoofed handshake packets? So this would still require support from the server; i.e., wouldn't work with a random server that doesn't support connection migration?
17:37:44 <Shelikhoo[mds]> the server is the "proxy signaling server" that support sending spoof ip packet and not quic server
17:38:11 <cohosh> isn't it pretty rare to find an AS that supports ip spoofing?
17:38:38 <cohosh> i think most providers do ingress and egress filtering on ip packets
17:38:39 <dcf1> Oh, maybe I understand. But if you have an unblocked proxy signaling server that can mitigate lack of support for connection migration, why not just use it as a MASQUE proxy?
17:38:55 <dcf1> Then there's no connection migration and no source address spoofing.
17:39:23 <Shelikhoo[mds]> let's say this unblocked proxy signaling server is publicly shared, so its own ip address is blocked
17:39:38 <Shelikhoo[mds]> it cannot receive direct packets from client
17:39:53 <Shelikhoo[mds]> and wants to help client connect to third party quic servers
17:41:46 <dcf1> soemthing like Triangle Boy? I still don't get it, I think.
17:42:29 <Shelikhoo[mds]> let's say user wants to access a cloudflare website to download a large file
17:43:05 <Shelikhoo[mds]> it first send quic handshake packets with this proxy signaling server to complete handshake with this cloudflare site
17:43:17 <Shelikhoo[mds]> then download from this site over cloudflare directly
17:43:36 <Shelikhoo[mds]> so that these large amount of traffic is between cloudflare and client
17:43:51 <Shelikhoo[mds]> without the need for a proxy signaling server to forward it
17:44:43 <dcf1> okay, that sounds like Triangle Boy if I recall, isolated to the handshake part
17:44:53 <dcf1> yeah that might work
17:45:01 <Shelikhoo[mds]> yes
17:45:06 <Shelikhoo[mds]> that is everything from me
17:45:06 <dcf1> I don't think NAT rebinding has anything to do with it, though, that's what confused me
17:45:13 <dcf1> That's all from me too
17:45:17 <Shelikhoo[mds]> (sorry for holding the meeting open)
17:45:53 <Shelikhoo[mds]> dcf1: because the spoof proxy signaling server does not know the source port of the client's udp connection
17:45:59 <cohosh> okay let's end the meeting here, thanks for the discussion!
17:46:04 <Shelikhoo[mds]> thanks~
17:46:12 <onyinyang[mds]> thanks!
17:46:20 <cohosh> #endmeeting