Re: [GNUnet-developers] Camouflage

[LRN]

-----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.
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.

>> 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?).

>> 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?

> 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.

>> 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.
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).

> 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.

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).

> 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)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQt83jAAoJEOs4Jb6SI2CwhNQH/3Ed3eFx2k4DdOQliynMEI5A
yCNTnbXZSgrDxWhMEskHWRqpX8UAP/WSI6vM+Dlgo07n5YvxMQ8AvSNt8TWafYCX
pML0C123tur4qO11M0V1iJPsyoKRQjOdPciLkTfYFwy0LEQDuJyjfzsAawHaB+YP
1usv6yORJC3hPMmlpMNaf1h4dKYKElXv/h5LB54uk7cz92qHNGPwGtCngb8COzxS
OTPuzHF7RlWIonaMrAXmyzt8Oi6GpM9OpauI1b8ulVcGq+klkcFisJclWqps2TF6
IuVxrDygXPna5hC9eluUL89drsB/TGimXvrlDY67wmJEe5jWVuVF/PmYf7eLna0=
=H5rM
-----END PGP SIGNATURE-----