Hi, the attached patch is a first approach to add SSL support to GTKG.
Configure with -Dccflags='-DUSE_SSL' and -Dldflags='-lcrypto -lssl'. Maybe you don't need -lcrypto. It's possible that you have to add the appropriate include and library paths. After that GTKG handles normal and SSL-tunneled incoming connections whereas only Anonymous Diffie-Hellman (ADH) is supported usually used together with a AES-256 cipher. For outgoing connections the property "ssl_enforce" must be set to true. Either from the remote shell or before starting GTKG in config_gnet. If this property is set, *all* outgoing connections will use SSL - so you'll hardly get any connection. ADH means that this doesn't protect against Man-In-The-Middle attacks but it should help against content-based firewall filtering. Adding support for certificates which can be protect against MITM attacks shouldn't be too complicated but I am neither a OpenSSL nor encryption expert. Last but not least, the real issue is the missing infrastructure resp. missing workable security concepts for Gnutella. For debugging purposes I've added a property "gnet_deflate_enabled" which is normal set and enables Gnutella traffic compression. However, to verify whether the traffic is really encrypted, compression should be disabled. I would have been finished much earlier if I hadn't bothered to check the traffic with tcpdump. ;) Anyway, there's no infrastructure for Gnutella over SSL so it's completely experimental and is only useful in a LAN or with known dedicated servents. Bugs/Problems: SSL_write() and SSL_read() are no drop-in replacements for read()/write(). This is because SSL_write() might require a read operation on the underlying socket and the vice-versa is true for SSL_read(). This means the I/O callbacks are sometimes called from the "other" poll event and the event mask has to be changed. I've currently used the hack to return (-2) if this happens. I assume it would be better to let the wrappers around SSL_write/read() directly access the event mask and just return (-1, errno == EAGAIN). Due to this problem, it can also happen that GTKG runs into a tight loop for a while. I've stumbled across a very weird bug which cost me a lot of time. The bug occurs when I establish a SSL connection from a leaf to an UP. The vice-versa case is OK. The problem is that the UP claims that the leaf sent a "Too large" message. The reason is that some bytes from the previous packet get injected. Looks like a off-by-one bug in the iovec structure handling. The problem seems to derive from mq_service() but I couldn't really figure out what's going on. This happened for this certain case and if you disable "ssl_enforce" there's no problem either. -- Christian
gtkg-ssl.udif.bz2
Description: Binary data
pgpkYJl9JIByW.pgp
Description: PGP signature
