16:15:59 <meskio> #startmeeting tor anti-censorship meeting
16:15:59 <MeetBot> Meeting started Thu May  2 16:15:59 2024 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:15:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:16:04 <meskio> hello everyone!!
16:16:07 <meskio> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:16:09 <meskio> ask me in private to give you the link of the pad to be able to edit it if you don't have it
16:16:11 <meskio> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
16:16:26 <onyinyang> hello!
16:16:53 <shelikhoo> hi~
16:17:27 <theodorsm> hi
16:19:11 <meskio> I guess we can start
16:19:17 <meskio> the first point in the agenda is:
16:19:28 <meskio> Snowfalke API has insufficent support for passing additional settings in constructor
16:19:35 <meskio> shelikhoo: ???
16:20:20 <shelikhoo> yes
16:20:22 <meskio> BTW, I don't see dcf1 around, not sure if he is needed for this conversation
16:21:21 <shelikhoo> Anyway the main point of this is that with API stability promise we are having more and more overloads(different version of) constructors in Snowflake
16:22:01 <shelikhoo> this is unavoidable to add new to settings to constructor
16:23:15 <shelikhoo> so we should think of a way to avoid need to accumulate more constructors
16:23:27 <shelikhoo> To fix this
16:23:37 <shelikhoo> we could use builder pattern
16:23:47 <shelikhoo> or new with options pattern
16:24:04 <shelikhoo> or something else
16:24:40 <shelikhoo> like make more constructors private
16:25:00 <shelikhoo> over
16:25:11 * meskio tries to remember pattern names...
16:25:34 <shelikhoo> don't worry I think I might have making up some names
16:25:44 <meskio> I think I usually go for the options pattern, as in have an options struct and pass it to the constructor
16:25:48 <meskio> but I don't have strong opinions here
16:25:54 <shelikhoo> withXXXX pattern is used in grpc
16:26:24 <meskio> anyway, I guess that means we might want to have a snowflake version 3 API in some near future
16:26:25 <cohosh> the builder pattern is common in rust, like for example this http library: https://docs.rs/http/0.2.9/http/request/struct.Builder.html
16:26:34 <shelikhoo> https://pkg.go.dev/google.golang.org/grpc#WithAuthority
16:27:33 <meskio> I've seen the options pattern in few libraries in go, but not sure if what is more common, anyway, both are nice approaches
16:28:14 <shelikhoo> I think one of the difference it is theoretically options can be implemented by third party packages
16:28:15 <meskio> I guess it might make sense to write some short description of the changes we want to do and review them including other users of snowflake (like guardian project or ooni) to see if they like the changes
16:29:11 <shelikhoo> yes, that's right
16:29:34 <shelikhoo> or maybe since no one is directly using these apis
16:30:00 <shelikhoo> there is neutral feedback
16:30:27 <shelikhoo> I mean maybe neutral feedback if no one is directly using these apis
16:30:43 <meskio> are the client or proxy APIs affected?
16:30:52 <meskio> or is only broker?
16:31:21 <shelikhoo> client is affected
16:32:18 <shelikhoo> but these apis are low level apis, so I don't expect a typical client need to directly work on them
16:33:02 <meskio> I see, so maybe is not affecting anybody outside and then is easy
16:33:20 <shelikhoo> anyway, I will create a issue about this soon, and see what feedback we got
16:33:48 <shelikhoo> let's see if there is any users of these api comment on this matter
16:33:52 <shelikhoo> over
16:33:57 <meskio> AFAIK orbot is not using the API at all, just patching our client main function to become an API for them, and ooni usage is probably not affected as you say
16:34:03 <meskio> thank you
16:34:18 <meskio> anything else on this topic? should we move on?
16:34:58 <meskio> Snowflake broker Debian version EOL
16:35:01 <meskio> cohosh: ???
16:35:10 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40349
16:35:31 <cohosh> right, the last time i did a snowflake broker deployment i noticed it's still running a old version of debian
16:35:59 <cohosh> that will lose support in june i think?
16:36:47 <meskio> June 30th
16:36:53 <meskio> https://wiki.debian.org/LTS
16:37:04 <dcf1> ~.
16:37:39 <dcf1> (sorry SSH troubles)
16:37:43 <meskio> :)
16:37:55 <cohosh> heh i recognized those characters
16:38:24 <shelikhoo> In theory the ideal way would be setup a new server with everything(or almost everything... ACME don't like server without A record) working on on it
16:38:25 <cohosh> we could either upgrade in place or set up a new broker machine but dcf1 i'd like your input there
16:39:11 <shelikhoo> hi! dcf1~
16:39:13 <dcf1> It's probably a good idea to do a new installation since the current one is so old
16:39:46 <dcf1> I can provision a new equivalent bare host on Greenhost if you want
16:40:33 <cohosh> sure, that sounds good to me if you're still okay with handling the hosting
16:41:04 <dcf1> I don't think I can spare time to get it set up, but I can allocate the host on the same hosting, if that's convenient
16:42:11 <shelikhoo> I think I can handle the setup...
16:42:43 <cohosh> shelikhoo: if you take that on, do you want to try the reverse proxy setup at the same time?
16:43:18 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40329
16:43:24 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Broker-Installation-Guide
16:43:31 <dcf1> This is our existing installation guide
16:44:10 <dcf1> If you make different choices (e.g. a reverse proxy in front of the HTTPS port, I think that's fine, just update the guide)
16:44:18 <shelikhoo> cohosh: yes, I think I can setup nginx to reverse proxy the traffic
16:44:30 <dcf1> Smae if you want to use systemd units rather than runit
16:44:48 <shelikhoo> any specific about what reverse proxy we should choose?
16:45:28 <shelikhoo> or nginx is fine
16:45:35 <cohosh> i don't have a strong opinion. i'm more familiar with nginx personally
16:45:43 <meskio> same here
16:46:28 <meskio> good, it looks like we have a plan
16:46:48 <meskio> anything more on this topic?
16:47:06 <meskio> ed25519 keys in bridgelines
16:47:09 <meskio> https://gitlab.torproject.org/tpo/core/torspec/-/issues/257
16:47:32 <meskio> arma2: sent this issue some days ago to our irc channel, I just wanted to bring it to our attention
16:47:48 <meskio> there is a conversation on how to add ed25519 keys into bridgelines
16:47:59 <meskio> looks like arti already have support for them as an argument
16:48:32 <meskio> I'm not sure I have much opinion here, but I haven't given it much thought
16:49:37 <cohosh> what input is needed from us?
16:50:24 <cohosh> or helpful from us i guess
16:50:40 <meskio> I don't think we need to provide any input, I plan to watcht the process at least
16:50:45 <shelikhoo> I have commented that the thing I mostly concern is know where is this will break things
16:51:24 <shelikhoo> we need to know if it this will break things for users in general, and try to avoid that if possible
16:51:28 <meskio> I agree, I'm not sure how many things assume a bridgeline has a hexadecimal fingerprint
16:51:29 <shelikhoo> to make transition smoother
16:51:59 <meskio> I guess that is why arti is going on the direction of keeping the hexadecimal fingerprint and just adding another one
16:52:26 <meskio> but that could also break things like lox having a maximum size bridglines
16:53:02 <cohosh> the broker assumes that the fingerprint the client sends in its rendezvous message is a hex string
16:53:58 <cohosh> meskio: yeah that too, but that was the motivation for lox!147
16:54:11 <meskio> yep
16:54:11 <dcf1> the broker only uses it as an arbitrary identifier though, basically a code word. it correspond's to the bridge's actual fingerprint, but nothing really depends on that I think.
16:54:28 <shelikhoo> yes, we should be able to change it
16:54:33 <shelikhoo> or add a new mapper
16:54:38 <shelikhoo> without too much issue
16:55:16 <cohosh> yeah for the broker we're just using it as a simple validation and it's not necessary to the function
16:56:03 <dcf1> or even abbreviate it, since the broker only uses it to enforce a whitelist on bridge selection. it could even be `1`, `2`, `3`, just that doesn't have as transparent a mapping from code word to bridge.
16:56:47 <cohosh> oh right, i forgot about the mapping
16:57:06 <meskio> can also be abreviated with the first 4 chars in the fingerprint so is a visible mapping
16:57:51 <meskio> (who says 4 could say 2, I just wanted to make it really hard to produce collisions)
16:59:32 <dcf1> All I'm saying is even if the bridgeline starts with `Bridge ABCD1234:ed25519:XyZz+123`, we can keep using `fingerprint=ABCD1234` and things will keep working, there's no automatic correlation between the two fingerprint fields
17:00:56 <meskio> nice
17:00:59 <dcf1> The PT protocol never even has tor send the bridge fingerprint to the PT client, that's why we had to create a redundant parameter.
17:02:41 <shelikhoo> the PT protocol we have right now is already quite tor specific.. maybe it don't have to actually assume it is the tor running it
17:02:53 <shelikhoo> and have a corresponding bridge fingerprint
17:03:49 <meskio> do you mean changing it to get the fingerprint from the protocol?
17:03:54 <shelikhoo> no
17:04:05 <shelikhoo> I was just commenting on it
17:04:10 <shelikhoo> without suggesting anything
17:04:22 <shelikhoo> sorry for not making myself more clear
17:04:23 <meskio> :)
17:04:30 <meskio> I see
17:05:06 <meskio> as long as we depend on c-tor changes into the protocol seem to take some effort, but I hope this will change in the future with arti
17:05:37 <meskio> anyway, we don't need to provide any input there, I'll keep an eye to it and bring it back if something move on there
17:06:03 <shelikhoo> yes! thanks! EOF
17:06:11 <meskio> something more to discuss on this topic?
17:06:37 <meskio> moving to the intersting links:
17:06:40 <meskio> https://github.com/ooni/utls-light by arturo, an alternative approach to modifying TLS fingerprints that requires less invasive crypto/tls library changes. It works by parsing the serialized native crypto/tls handshake messages before they are sent, and re-serializing them according to a desired schema.
17:07:14 <dcf1> arturo tols me about this, it might be interesting to theodorsm
17:07:39 <meskio> is nice to have around some easier to integrate uTLS like library
17:07:49 <dcf1> a different way of doing something uTLS-like that is supposed to require less maintenance for standard library chnaged
17:07:52 <dcf1> changes
17:08:07 <dcf1> not easier to integrate, easier to maintain / smaller diff from upstream crypto/tls
17:08:24 <dcf1> It's not really an analogous situation though, as we have a cooperative upstream in pion/dtls
17:08:39 <meskio> ahh, I thought less invasibe was from the usability not from the maintenance, I understand now
17:08:48 <theodorsm> cool library! Very similar to what Im doing yes
17:09:41 <meskio> anything else for today?
17:10:42 <meskio> I guess I can close the meeting
17:10:47 <meskio> #endmeeting