-----BEGIN PGP SIGNED MESSAGE----- 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 >> 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. 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)? > 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?) 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQuDVnAAoJEOs4Jb6SI2CwYV0IAL41jRuG5EYuGy9F4Yu4vrVu /0VwKsNPos2wYKtNavgmajXopuWjWxWDeWHwdzzHa4BL+UpT7Md6w2IR3uC7XLXm FC4boRLBNzvC/l7GzhIXQSK6WK0wYbOMAMbnO3WAvKUuekgkoTsIvJ30/HVvIIvj u++Q3kYcAj0m4jPmToJUebEC4XdjbsxdKz0IYFV8ODMQnbFvkc7Yf5qgFPsR0bbg OwUd+TaE9HQ4afgofZhhQjOaF8j6JiSViBBbdkQqLPtbdZkn+UzDgwAKt/VHXBkb KIRI55J2revZa1YgPIIAfN1zKKMIrsBQnix1tBQXpZ0RgERWcEeHLqZEfLYRmos= =wNA3 -----END PGP SIGNATURE----- _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
