Regarding this problem and this PR which replaces the old bridge with meek-unredacted, what is the reason there is only a single built-in meek bridge in Tor Browser, when there are multiple options for the other built-in transports?
Also: — To be perfectly clear I like Unredacted a lot and have worked closely with them myself, but — my understanding was that default bridge operators shouldn’t be exit relay operators because Tor does not yet solve the problem where bridges and exits are operated by the same family, and I didn’t think it would at least until happy families were stable.
Am I wrong and this is no longer a problem? I don’t know if I fully understand proposal 354, maybe that means this scenario is perfectly acceptable now.
I am Shelikhoo, working with anti-censorship team, and is the author of the merge request you have mentioned.
Thanks for letting me know that unredacted is also a exit relay operator. I was not aware of this when making this merge request, and I agree with your concern.
I will have a chat with my teammate about this issue and reply to you soon.
what is the reason there is only a single built-in meek bridge in Tor Browser?
To be able to use conflux it would be nice to have multiple. But meek is a costly (because we have to pay a big cloud provider for traffic) and slow transport (because we put limits on how much we are willing to pay for it). We have being for a while looking into retiring meek for other faster transports like snowflake. But we keep meek around as for certain situations of strong censorship has proven users last resort.
Adding extra bridges will increase the expense and the work needed to maintain this transport.
Is there any difference between meek and webtunnel besides domain fronting? For example, I see www.phpmyadmin.net is used with meek-unredacted here, but if phpmyadmin themselves ran a WebTunnel on that domain would it be functionally identical from an anti-censorship perspective?
Is there any difference between meek and webtunnel besides domain fronting?
Both meek and WebTunnel supports domain fronting.
Yet, meek and WebTunnel has different requirement for the CDN networks for it to be used as domain fronting providers, and WebTunnel requires the CDN to support relaying WebSocket traffic, while meek works with any typically CDN providers. So there is a bigger pool of potential usable CDN networks that could be used for meek’s domain fronting.
There are difference that could be observed from packet capture(and censor’s) point of view as well. WebTunnel is imitating(or using) WebSocket traffic, NOT typical half duplex HTTP request and response(which was used by meek), plus WebSocket is typically only supported by HTTP1.1 protocol, not HTTP2 protocol. As a result, the signature and the shape of the traffic would be different than each other when examined by an expert with special knowledge and tools.
if phpmyadmin themselves ran a WebTunnel on that domain would it be functionally identical from an anti-censorship perspective
Due to the difference in traffic shape and http protocol versions, they will have minor difference, despite equally useful for users when they are working correctly.
Thanks, that makes perfect sense. I had forgotten WebTunnel uses WS.
I guess I was mainly wondering whether Tor Browser adding built-in WebTunnel bridges would be useful or could potentially replace built-in meek bridges, and it sounds like… maybe yes, but meek still has an important role and should stick around.
Relatedly, I was trying to see if I could get a WebTunnel bridge to use ECH, but it doesn’t look like that works yet.
I guess I was mainly wondering whether Tor Browser adding built-in WebTunnel bridges would be useful or could potentially replace built-in meek bridges, and it sounds like… maybe yes, but meek still has an important role and should stick around.
I agree with you that having a few default WebTunnel bridges will be nice, but due to SNI blocking it could be blocked as well. If we wants it to works just like a obfs4 built-in bridge to help user in restricted network environment without specialized anti-censorship sabotaging tool, but it won’t work in network environment with high level of censorship.
I was trying to see if I could get a WebTunnel bridge to use ECH, but it doesn’t look like that works yet.
Yes, actually in theory indeed possible. But since, to the best of my knowledge, most of websites enabled it via Cloudflare, its collateral damage protection is limited, thus supporting it has not been a high priority.
Well I was testing a WebTunnel that was behind a Cloudflare tunnel in this case, so that was exactly what I was hoping to achieve
However, I’ll just point out that Caddy added support for ECH in April, I believe the first generally available webserver software to do so, so maybe there will be wider adoption this year.
