gnunet-developers
[Top][All Lists]
Advanced

[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 01:04:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 11/29/2012 10:04 PM, LRN wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. Only AFTER the TLS connection is up, the initiator (HTTPS-client) sends its identity to the GNUnet-HTTPS-server. And then eventually core-level encryption is added in addition to the TLS-level encryption. So really, unless someone can get into the TLS handshake, even if you initiate (as HTTPS-client), a network-level passive adversary would not see that it is a GNUnet connection without fingerprinting the encrypted channel. In summary: yes, the connection is first secured (TLS-encrypted) before the client sends its identity.

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 node. 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.
Both HTTP and HTTPS use HTTPS handshake? How exactly do they set up
encryption (certificates? issued and signed by whom? PSKs?).
No, sorry I was unclear, of course only HTTPS does TLS/SSL.
Again, the client sends its own identity in the HTTP header, so
the server can 404 for non-friends / invalid requests.
That does happen after HTTPS handshake, right?
Yes, over the encrypted channel.
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).
That would be unnecessary. At least for now :) AFAIU, any pattern you
can pry from encrypted connection's data is an educated guess at best,
and that guess can't be easily verified if your node is in F2F-only mode.
Well, I'd have to say "educated guess" might be underestimating the state of the art here. Unless of course you intend to imply that any statistical claim is an 'educated guess'. :-)
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 https://gnunet.org/https-reverse-proxy)?  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.
That's cool, and i was also thinking of something like that.
Though i doubt that many people will be ready to configure this, and
unless all your friends run Apache or nginx, the questions i asked
(above) still remain crucial for maintaining your disguise.
No, only YOU need to run Apache/nginx, and your friends only need to have libcurl installed. After all, HTTP/HTTPS work if one peer is a client and the other a server. While you CAN be both, you don't have to! So your friends could pretend to browse your HTTPS-website.

If _YOU_ are running a reverse-proxy, it gives you good protection
from casual scans, but someone who tries to identify you as a GNUnet
node might still be able to do that (again, see above).
If you _only_ use the "https_server" transport plugin, and that within an existing HTTPS-site via reverse proxy, and then _only_ give that HELLO to a few friends and run in F2F mode, only your friends and an adversary with strong passive traffic fingerprinting or active MitM on your HTTPS-server has a chance IMO (and with a reverse proxy, you might make the MitM even harder by getting a real certificate and ask your friends to enable checking against the X509 PKI, making even the MitM option hard; I don't say impossible here as I'm pretty sure most large states could still do it).
Did you know that https://gnunet.org/SpeedTest/ and
http://gnunet.org/SpeedTest/ are addresses for a GNUnet peer?
No, i did not.

Given that we can already do this, I don't quite see that we'd
need anything else.
As far as faking real servers goes, this should be enough, yes.

However, you have not addressed the indirect identification problem.
I.e. your fried runs in non-F2F-only mode, without reverse-proxy.
His HTTPS_server transport runs on port 8080, and it even performs
HTTPS handshake before you send your identity to it, so adversaries
don't know you're using GNUnet.
However, since he's not using F2F-only mode, adversaries can connect
to his 8080 port (after seeing you connecting to it, and seeing you
having a stable encrypted connection with data flowing both ways), and
then try to identify themselves as various network services.
Eventually an adversary will try to identify as GNUnet node, and your
friend will accept that. Now they know your friend runs GNUnet node
with a HTTPS_server transport on port 8080.
And by knowing that they also know, with great amount of certainty,
that you also run a GNUnet node, since you communicated with your
friend on the same port.
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.
Running F2F-only transports on alternative porta might reduce
adversaries' certainty, since your friend might have a machine with
different services on different ports, one of which is GNUnet on port
8080, and another is some HTTPS on port 973 that they can't
authenticate with, and thus know nothing about (only the fact that
you're using it; that is, unless they figure out the protocol from
timing and packet size patters of the encryption channel).
I think the secure version is still to simply not connect out to your friends if you need this level of secrecy.
Now, we might do a "TLS" plugin which runs GNUnet's TCP over TLS to
avoid the HTTP-overhead.
How will it do TLS handshake (same question as above)?
Eh, standard TLS? I'm not sure what you mean here by "how".
GNUnet would use gnutls to just get it done. Still, as mentioned before, this is theoretically possible but I don't see a huge advantage in doing this.


Happy hacking!

Christian



reply via email to

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