use private messaging functions on websites that will not get blocked to deliver bridges

censors will not block ebay or microsoft sites for example. so sites like these could be used as unblockable channels for providing bridges

Trac:
Username: elypter

added component::circumvention/bridgedb owner::isis priority::medium reporter::elypter resolution::duplicate status::closed type::enhancement labels

Trac:
Username: elypter
Type: defect to enhancement

This is already in place via the meek protocol. We currently have takedown-resistant bridges on the Amazon, Azure, and Google clouds.

this only works if the censor is not desperate enough to do man in the middle attacks

with domainless fronting he only has to do a man in the middle attack on connections without sni. (assuming this paper is correct https://www.bamsoftware.com/papers/fronting/ i didnt really understand why the domainless variant cant have a fake sni)

the effect off a man in the middle attack could be much smaller than one would expect if the censor uses https stripping. everyone who doesnt enter an url with https or clicks on a link on an unencrypted or controlled site wont see a certificate warning

if the actual service of a website is being used then it would be impossible to block it without blocking the service even if there is no https

Trac:
Username: elypter

No, this still works because public keys are distributed through back-channels, so MITM in this case isn't possible. I don't think the attack works as you describe. The attacker simply doesn't have the private keys and all clients verify the keys when setting up their Tor circuits.

Closing as a duplicate of #16650 (moved).

Trac:
Status: new to closed
Resolution: N/A to duplicate

i meant a mitm attack on the cdn itself, not the tor infrastructure so that all traffic is unencrypted and can be censored

Trac:
Username: elypter

closed

moved to tpo/anti-censorship/bridgedb#17025 (closed)