[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: Thu, 29 Nov 2012 19:53:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10

On 11/29/2012 07:26 PM, Bart Polot wrote:
These are my thoughts on the matter, especially point 1:
- The spreading of false info is leads to quite some inefficiency for
the network in general.
- Even if you spread X false adresses for you, "they" can always issue
X+1 search orders/legal procedures and catch you.
- If you are worried about not getting recognized as a GNUnet user, I
think the best way to do this is to run in F2F mode and have your
friends not spread your HELLO at all. If anybody wants anything from
you, he can connect you on mesh level (tunnel through your friends). If
you trust your friends enough to allow them connect to you, you should
trust them not to spread your hello, right? Otherwise, acquire new
friends, repeat ;)

Also, our current spreading of HELLOs of peers that are in 'pure' F2F mode is inefficient anyway. So adding a way to flag a HELLO as "F2F-only" which means that other peers must not pass it on (or at least not with network addresses in it, I guess the public key itself is harmless), would make sense. We can probably easily do this by, for example, adding another message type (F2F_HELLO), have F2F-only peers generate that HELLO and have our processing of F2F_HELLOs make sure that we do not pass them to other peers.

On 24 November 2012 13:56, LRN <address@hidden
<mailto:address@hidden>> wrote:

    Hash: SHA1

    This is the idea that i've been thinking on.
    It should be possible for GNUnet node operator to hide the fact that
    his machine runs a GNUnet node.

    Ways to achieve this:

    1) Fake HELLO messages.
    AFAIU, right now anyone can collect HELLO messages (by running a node,
    or by querying a hostlist server), and then claim (with certain degree
    of sureness) that GNUnet nodes run on all addresses listed in these
    messages. Companies that track torrent users do this for BitTorrent.
    They may then proceed to actually connect to listed addresses to
    verify them, but that is quite another story.
    The solution is to spread fake HELLOs with fake public keys and fake
    A node should use its private key (key K) as a seed to generate a set
    fake of addresses (set A). Then use K and A themselves to generate
    fake public key (key F) for each A, thus getting a complete HELLO
    message. The use of K as a seed ensures that the node will keep lying
    about the same set of addresses (how large that set should be is an
    open question) with the same keys, making the fakes more believable
    (observer might think that these are real nodes, maintaining their
    real HELLOs over time; failure to validate any of them might be blamed
    on firewalls, etc).
    Address sets will intersect (A1 and A2 generated from K1 and K2 may
    share some elements), obviously, although that might not be true for
    IPv6 addresses...
    I expect that address generator will apply some rules to generate
    believable addresses (i.e. don't generate invalid IP addresses, like
    As an extra, a node could validate generated addresses and do
    non-agressive portscanning (or something similar - we're not speaking
    only of tcp) on them, to be able to add ports (or other parts of the
    address) that look believable to observers.

    AFAIU, right now nodes won't gossip about fake HELLOs (i.e. a node
    will never tell another node about a HELLO it got, unless it validated
    that HELLO). That might need to be changed to allow nodes to choose a
    random subset of invalid HELLOs and gossip about them as well.
    Otherwise only the node that generated them will be able to spread them.
    Not sure about hostlists.

    Extra yummy feature - add user-configurable fake templates, which
    could have addresses only, or addresses and private keys. GNUnet node
    will use templates from time to time (configurable) instead of
    generated addresses, and will generate missing template elements.
    It would be neat to be able to tell the world that [1]
    runs a GNUnet http_server transport on port 80...

This is also too complex, I prefer Bart's idea.

    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. 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 (if in F2F mode -- otherwise sending any identity would of course trigger a full handshake). Again, this is the theory, bugs may exist (in individual plugins) --- there is no easy way to test this.

    A node should send fake data that looks like, say, FTP greeting,
    faking a real-life FTP server.
    This will prevent casual observers from identifying the node as GNUnet
    Non-casual observer should not follow the fake protocol, but proceed
    to send a normal GNUnet handshake.
    If the node doesn't get a GNUnet handshake as a reply to its fake
    greeting, it might either drop the connection, or use some kind of
    bogus access control error as an excuse to drop it (i.e. ask for ftp
    login/password combo, and then reject all such combos and drop
    "clients" that failed to "authenticate" this way).

Well, this point seems to go a bit further --- you want to fully fake a protocol. The closest we have to that are the HTTP and HTTPS plugins. Here, both side run a real HTTP(S) session, with the full, standard HTTPS-handshake first. Again, the client sends its own identity in the HTTP header, so the server can 404 for non-friends / invalid requests.

This *still* may not prevent a sophisticated attacker from detecting GNUnet on the host --- we have people here across the hallway that can identify protocols (IMAP, HTTP, etc.) as they are tunneled over SSL, just by observing message sizes and timing. So even if your traffic is encrypted, traffic profiling can tell you a lot about the underlying protocol. I do not believe in even attempting to defeat this kind of traffic-profiling attack, as faking another protocol 'perfectly' is incompatible with reasonable performance in my mind (it gets too close to stego).

    Or a node should simply remain silent until it gets incoming handshake

They all do. In all of our protocols, the client must talk first.

    3) Handshake-first protocol
    Besides (2), which may or may not be implemented, don't identify
    yourself as GNUnet node until incoming peer sends a handshake, then
    drop it, if it doesn't match one of your friends, if you're running in
    F2F-only mode. You will be able to hide the fact that you're a GNUnet
    node, since only friends will get _anything_ out of you. Other
    non-friend (normal or malicious) GNUnet clients will have their
    connections dropped after their handshake message.

That's how it works already (modulo unknown bugs).

    To make it work both ways, GNUnet should establish a generic session
    with TLS encryption first. Again, it's not uncommon for services to
    have ports on which clients are expected to connect with an SSL/TLS
    session (instead of connecting normally and then issuing StartTLS).
    The point here is to use common TLS certificates and TLS connections
    for initial authentication (friend nodes will know TLS certificates of
    each other in advance). Otherwise your node will not be able to
    connect to any of your friends without revealing that it's a GNUnet
    node (friend won't identify itself as a GNUnet node initially, until
    you send a handshake, thus preventing you from verifying that you've
    connected to your friend, not to some man in the middle; and if you
    send a GNUnet handshake, you will reveal yourself as GNUnet node to
    the other end of the connection, not knowing who might be there). TLS
    allows authentication without revealing that nodes are using GNUnet.
    And using TLS itself is, thankfully, not illegal yet (and, hopefully,
    will never be).

    This will have to be a separate transport, since

    A) that is somewhat incompatible with existing tcp transport, which
    does not rely in TLS at all, AFAIK.
    B) Your friend might not be running in F2F-mode only, in which case
    you will reveal that you run GNUnet by connecting to your friend on
    the same port that other nodes connect to. If there's a separate port,
    which only accepts TLSed sessions, and only accepts known friends on
    them (at TLS level), it will be much more difficult for non-friends to
    identify you. If you make a TLS connection on port A to a machine that
    _also_ runs GNUnet on port B, that will not immediately prove that you
    are running GNUnet in F2F-only mode.

    We already discussed (3) in the past, AFAIR, just making sure that
    this discussion sticks somewhere.

Have you tried to configure GNUnet's HTTPS transport via reverse proxy?
(see This one goes as far as running 'real' HTTP inside of the TLS connection, so even simplistic traffic profiling might not succeed at telling it apart from normal HTTPS.

Did you know that and are addresses for a GNUnet peer?

Given that we can already do this, I don't quite see that we'd need anything else. Now, we might do a "TLS" plugin which runs GNUnet's TCP over TLS to avoid the HTTP-overhead.

However, in combination with a reverse proxy which essentially allows us to run a "hidden" GNUnet peer on a normal HTTPS-server (that serves a normal website as well) the existing HTTPS plugin is the best practical form of camouflage that I can think of...

Happy hacking!


    [1] That's what <> resolves to,
    for me.
    Version: GnuPG v1.4.11 (MingW32)
    Comment: Using GnuPG with undefined -

    -----END PGP SIGNATURE-----

    GNUnet-developers mailing list
    address@hidden <mailto:address@hidden>

reply via email to

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