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

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

>
> Yes, you're welcome to setup an own certificate authority if you like ;)
> 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 ;)

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