Re: China Tor bridge blocking details

--===============1177597748==
Content-Type: multipart/signed;
  boundary="nextPart2086605.Cu1G2dzE9g";
  protocol="application/pgp-signature";
  micalg=pgp-sha256
Content-Transfer-Encoding: 7bit

--nextPart2086605.Cu1G2dzE9g
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On Wednesday 04 Apr 2012 20:34:02 Ian Clarke wrote:
> This is the motivation behind "silent bob", something we were talking abo=
ut
> way back in 2002-2003.

Right. This was carried through into 0.7: 0.7 doesn't respond AT ALL unless=
 you have the noderef so can use the outer (symmetric) encryption layer. (S=
trictly this is obfuscation). And also, our traffic is not identifiable by =
any fixed bytes. (But there may be other ways to identify it, and the below=
 suggests that the chinese will deploy such as soon as they see us as a thr=
eat again).
>=20
> Ian.
>=20
> On Wed, Apr 4, 2012 at 2:19 PM, Matthew Toseland
> <toad-EI5O+8PHWbJeeLb3ft/[email protected]>wrote:
>=20
> >
> > http://www.v3.co.uk/v3-uk/news/2165733/swedish-researchers-uncover-key-=
chinas-tor-blocking
> >
> > Looks like they look for a header that looks like a connection to a
> > bridge, then try to do a handshake. This is surprisingly sophisticated =
=2D I
> > had expected they just created thousands of gmail accounts and harvested
> > all the bridges by email.
> >
> > Also, they appear to be able to create unidentifiable IP addresses on
> > demand, meaning that the opennet protection schemes based on IP scarcity
> > are not going to work.
> >
> > This won't work as-is with Freenet because Freenet doesn't do handshakes
> > unless you have the keys. However there may be (more complicated) ways =
to
> > identify the traffic, and the above implies they may be sophisticated
> > enough to implement them. It does mean that obfuscation (stego) is
> > increasingly important.

--nextPart2086605.Cu1G2dzE9g
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABEIAAYFAk980fYACgkQYUNbc3WUHYi5WwCcD72eof9ZQyU1AO5wu5tgjlur
EroAn3kercKp0JEOfpNgwfooAIfiDbRB
=+EfO
-----END PGP SIGNATURE-----

--nextPart2086605.Cu1G2dzE9g--

--===============1177597748==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tech mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
--===============1177597748==--