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.