[Top][All Lists]

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

Re: [GNUnet-developers] Camouflage

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Camouflage
Date: Fri, 30 Nov 2012 07:54:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 11/30/2012 05:26 AM, LRN wrote:
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
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
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)?
I believe this part is trivial (just needs documentation on HOW to do it), the part that actually requires work is somehow telling the HTTPS-clients that they should try to validate the SSL certificate. After all, many users will not have a valid certificate and thus will use non-validating self-signed certs. So we'd need an extra bit in the HELLO to tell clients to enable certificate validation; the problem then is that an adversary might be able to set that bit to 0. This could then be solved by having the client send a *signed* 'welcome' message where he tells the server that he did validate the SSL certificate, and the server would only begin the full GNUnet-exchange after a friend signed that he validated the SSL cert. Now that's a somewhat more extensive change.
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?)
Enabling it globally would be easy to implement, but as I said above, enabling it for particular peers only, based on that peer wanting it enabled is going to be work.

  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.
One alternative --- that could likely be done without even modifying the HELLO --- is to just have the client tell the server in a new *signed* welcome message if the SSL cert did validate. So the client would always check --- but never fail, even if the cert failed to validate --- but then tell the server about it. That should actually suffice. (Note that we need it signed, as if the SSL cert did not validate, a MitM might be present...)

Happy hacking!


reply via email to

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