gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Camouflage


From: LRN
Subject: Re: [GNUnet-developers] Camouflage
Date: Fri, 30 Nov 2012 08:26:15 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20.0 Thunderbird/20.0a1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30.11.2012 4:04, Christian Grothoff wrote:
> On 11/29/2012 10:04 PM, LRN wrote:
>> On 29.11.2012 22:53, Christian Grothoff wrote:
>>>> 2) Transport disguise. Modify the protocol to allow clients
>>>> to ignore initial data sent by the server, and require
>>>> clients to be the first ones to speak GNUnet protocol after
>>>> connecting (i'm not sure how the protocol works right now;
>>>> what a GNUnet node sends to the connected party immediately
>>>> after accepting an incoming connection? Does it send anything
>>>> at all?).
>>> No, clients always first send their peer identity.  Transport 
>>> plugins are supposed to hang up (or 404 for HTTP) if they are
>>> in F2F mode and the identity is not that of a friend.
>> If you send you identity first, you are exposing your identity
>> and the fact that you're using GNUnet to the other [unknown]
>> party (you have no way to verify that you are really connected to
>> your friend, and not to an adversary). Adversary won't be able to
>> fake your friend, since adversary does not have your friend's
>> private key, but your initial message will be enough to identify
>> you.
> With HTTP/HTTPS, you can choose to only load the 'server' side and
> then you never actively establish connections.  Naturally, that
> then puts the burden on your friends to send the first
> "identifying" information. Nevertheless, with HTTPS that is still
> encrypted (see below).
> 
> Now, in general, for your above statement to work, the adversary
> needs to be able to somehow give you a HELLO with your friend's
> public key and an adversary address, just to trick you into
> connecting to the adversary.  But to give you such a HELLO, the
> adversary must either run the hostlist or be another one of your
> friends --- and somehow suspect who else might be your friend.
> Possible, but the additional information lost by connecting to the
> adversary ID and sending your identity is clearly minimal at that
> point.
>> That is, unless i'm really missing something about the way HTTPS
>> works - - in general, and the way GNUnet HTTPS transport works -
>> in particular. My experience with TLS comes mostly from reading
>> GnuTLS documentation and performing handshakes (with PSKs) over
>> tcp socket connections.
>> 
>>> Naturally, a powerful adversary can still observe traffic and 
>>> replay (which will only fail once the server sends the
>>> challenge), but at least adversaries that cannot monitor your
>>> inbound traffic should not be able to simply probe to see if a
>>> host is running GNUnet
>> They don't need to monitor your inbound traffic, only outbound 
>> traffic. Once you connect somewhere (to your friend), and send
>> your identity, they know you're a GNUnet node, unless the
>> connection is first secured in a way that makes it impossible for
>> adversaries to monitor.
> With GNUnet over HTTPS, we first do a TLS handshake.  Now, the 
> certificates are not validated (and can be self-signed), so a
> really strong adversary might MitM the TLS handshake and still
> decrypt, but that's again a pretty strong network-level adversary.
That's not a lot of strength. All ISPs have that ability.

Is there any way to use validatable certificates? With only
HTTPS_(client|server) (no reverse-proxy)?

> Right, which is why I suggested above that you'd then configure
> your system as HTTPS-server-only. Your non-F2F-friend can then
> still easily enable both client and server on his system, and then
> he only connects to you, which could still be him surfing.
OK, this is one way to do that. But running a reverse-proxy (otherwise
your HTTPS_server transport won't have a valid certificate for your
friends to validate; by the way, is there a config option for
HTTPS_client to enable certificate checking?) is not something
everyone could do (for various reasons - doesn't know how to set up
Apache, has no external IP-address, etc). So i'd vote for implementing
validatable certificates for HTTPS transports.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQuDVnAAoJEOs4Jb6SI2CwYV0IAL41jRuG5EYuGy9F4Yu4vrVu
/0VwKsNPos2wYKtNavgmajXopuWjWxWDeWHwdzzHa4BL+UpT7Md6w2IR3uC7XLXm
FC4boRLBNzvC/l7GzhIXQSK6WK0wYbOMAMbnO3WAvKUuekgkoTsIvJ30/HVvIIvj
u++Q3kYcAj0m4jPmToJUebEC4XdjbsxdKz0IYFV8ODMQnbFvkc7Yf5qgFPsR0bbg
OwUd+TaE9HQ4afgofZhhQjOaF8j6JiSViBBbdkQqLPtbdZkn+UzDgwAKt/VHXBkb
KIRI55J2revZa1YgPIIAfN1zKKMIrsBQnix1tBQXpZ0RgERWcEeHLqZEfLYRmos=
=wNA3
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]