Ämne:Re: [dcdev] Encrypting ADC - a second approach
Från:Jan Vidar Krey
Till:Direct Connect developers
Hi all, See my responses below ;) On Friday 11 March 2005 11:22, Gustaf Räntilä wrote: (....)
Today you can "choose" from a set of symmetric keys (in SSL). But AES is by far the best one afaik. I don't know of inheriting the entire ssl set of ciphers are good, would anyone ever want to use DES/3DES? It's both much slower and more insecure than AES. The same with all fishes (blowfish, twofish etc). Surely one would like Some sort of negotation though, I fully agree on that.
Actually both Blowfish and Twofish are quite fast. Speaking about the former, also quite secure. I use Blowfish all the time for scp/sftp operations because it doesn't slow down transfers on fast networks, compared to 3DES. For a general crypto benchmark see this page: http://botan.randombit.net/bmarks.html
5) Still identifyable as ADC with all the packetfilter problems that followWhat packetfilter problems? Sure it's identifyable unless one uses a common cipher-handshake such as ssl/tls gives you. I don't have an opinion on whether this is an issue or not... Unless 'they' can read the traffic, do we care if they know what it's for? Maybe.
Traffic shaping. All medium-large ISPs use this these days. A standard SSL/TLS connection is harder to classify as P2P oposed to other SSL connections (like company VPNs over SSL, etc).
6) Server speaks first - in general the server shouldn't waste resources sending data until the client has made an effort
(...) Which again makes it easier for classification. The ISP can merely connect to the port see what's on there and disconnect.
8) No authentication - vulnerable to the good ole' man in the middle attack;) This is actually possible. Having like the hublist-servers to be authentication servers is a possibility. It would look like a one way kerberos sollution, by depending on a third part. It makes sense, but *trying to express myself as if I were a hub developer* it adds complexity ;)Yes, you're welcome to setup an own certificate authority if you like
Well how much complexity does it add to the hub? The hub will merely have to register it's key to the hublist, while it still have to register its existance to the hublist. The complexity is added to the client that will have to check the authenticity of the hub by quering the CA (hublist)... (if the user is paranoid enough). The hub will deal with passwords to authenticate users.
One potential issue is that we can't up-negotiate the protocol to encrypted mode if we want to make it http-lookalike - which means that the server must either have a unique port open or use some ugly heurestics (or perhaps best - support only encrypted connections)...
Sure you can, as on HTTP, try connection using plain HTTP on a HTTPS-port such as http://sourceforge.net:443/. You can easily delay the SSL initialization so that after the SUP-command is sent the server may send a special command requesting SSL. However, this adds complexity... :/ Dj_Offset, out.-- Jan Vidar Krey E-mail: [email protected] Mobile: +47 98607328 WWW : http://www.extatic.org/-- DC Developers mailinglist http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev