[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Bridge scanning resistance
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Bridge scanning resistance
- From: Gregory Maxwell <gmaxwell@xxxxxxxxx>
- Date: Thu, 19 Mar 2009 05:28:13 -0400
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Thu, 19 Mar 2009 05:28:16 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Dczcp0GBjligM/z4bMl28zc0JxlYCayuXyUIED4bhyg=; b=PKlpGgbJmjpNC4MkG3fnbER2W5Z4FhtrYFQGB75C7qHfnTQSphjXrlG3bvMubBuW+Y qP/GJ56kN7DcuC0xwECau4xhOf0uRe5IbnaKMVj456GXSniHgyb0gCpNorX3G4LkkYER 1DApa3CYVUTuEOw9wb5xfVEXpKxD9JYTCneWA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=E28cgZWPQmIWqRD/CNARyPNENRNj9mPgKBK6tGJOPSaBxGJ1RY94j1415n3KbsQ29P eo1vd0ebKQjQw6ygJQ5WlSLpW5UqweGks4ywLX1u1UzcJTbMXavFxZHNvXDDJbrMAAWk ORqOkgo0V4zTqa+4m611CQbJSdeAWjy77Qi+0=
- In-reply-to: <20090319010038.GA17087@xxxxxxxxxxx>
- References: <20090319010038.GA17087@xxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
People are unlikely to spend $$ to give their fake https sites real ca
signed certs. Its easy to test for, impossible to fake, and given how
the browser vendors handle self signed certs someone could claim they
are trying to defeat security risks by blocking self signed
webservers.
So I would guess that would put an upper limit on the level of disguse
the common node would get. The ability to multiplex with a real ca
signed https server might allow a few nodes to achieve better cover.
On 3/18/09, Christopher Davis <chrisd@xxxxxxxxxxx> wrote:
> Hello,
>
> I'm thinking of sending in a GSoC proposal for consideration by Tor/EFF
> this year. I see in item #4 on your volunteer project list work involving
> improvement of bridge scanning resistance, and it looks like it could be
> an interesting project.
>
> It seems the trick in the bridge-as-webserver design is making it appear
> as normal and boring as possible, while still accommodating bridge
> clients. Clients would have to upload an authentication string to the
> server in order to use it, but the server would have to take care in
> reporting authentication failure, etc, to avoid alerting a scanner to its
> true purpose. Also, there could be some application to having OR servers
> respond to HTTP requests with an informational message, etc.
>
> Certain aspects of the TLS handshake could also clue in a scanner. Are
> there any things about Tor's current implementation that could be
> improved to make it seem more like a web server? If required, answering
> this question could be one point of research in comparing Tor to
> Apache's mod_ssl or other HTTPS servers.
>
> Another part of the project is to address the specifics of bridge
> authentication. The bridge user has to get a password from us, then they
> would send it when they connect to the bridge. The web application to
> advertise bridges would need to be updated.
>
> Are there any other things to think about?
>
> Thanks,
> --
> Christopher Davis
> Mangrin Remailer Admin
> PGP: 0x0F8DA163
>