Zdenek Stangl wrote:
With all due respect, Im still not sure what good is the encrypted
connection for DC. I was out for longer time. Are there any troubles
with anti-pirate organizations?
Well, yes. As well as new EU laws (which my country is pushing for,
which is embarassing). But the most important is the privacy for users.
I think it's fair to implement encryption as a basic privacy model for
people no matter protocol. Big brother is getting paranoid.
Jacek Sieka wrote:
Well, this has crossed my mind a few times, I actually downloaded a
few ssl libs the other day to have a look around...
In any case, while being a good (verbose) initiative, there are some
technical flaws, like:
1) Reinventing a secure handshake - dangerous, it took the ssl folks 3
versions, and hopefully they knew more than us about this stuff...
Well yes, and they depend on third-party organizations like Verisign. If
you site is verisign:ed then you are to be trusted... Maybe we should
beg users to pay tenths of dollars for a signed certificate ;)
But I agree, handshaking is critical.
2) No perfect forward secrecy - lose the key to someone and any
recorded data can be decrypted (authorities spring to mind)
Lose how? The symmetric keys are temporary for each session/connection,
and never stored. How the assymetric keys are locally stored, can be
made safe quite easily. However, this problem occurs to any program
implementing asymmetric ciphers. In Unix you depend on filesystem rights
for the private keys etc.
3) No algorithm negotiation - locked to one algorithm pair, and
algorithms tend to lose credibility over the years
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.
4) No separation between adc and encryption (what's that cid etc doing
in the initial negotiation?)
The CID is there because we poor P2P users have a tendancy of switching
IP numbers very frequently, and CID is used for storing public keys,
just like SSH does. It's not at all necessary, but efficient and
slightly increases security. So they say ;)
5) Still identifyable as ADC with all the packetfilter problems that
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.
6) Server speaks first - in general the server shouldn't waste
resources sending data until the client has made an effort
This was inteded so that hubs send their public key. Therefor one should
at least trust a hub's key. Also this makes the client responsible for
generating the symmetric keys. Not that this is much of a burden, but
Surely clients could go off first, by requesting the key, maybe by
sending a TTH of the stored key (if they have one), and only if it
differs hubs send their new key.
7) On a more philosofical note - who is this encryption targeted
against? ISP listening in? hub listening in? neighbour on the same
subnet listening in? As I read it there's one encrpytion layer between
hub and client and then another one in that between clients when
speaking through the hub...those are two completely separate use-cases
and should thus imho be covered in separate extensions - if encrypted
c-c messages through the hubs should be supported at all...
This is very interesting. Developing a fully waterproof solution is not
feasible. Personally i think ISP's and authorities in general are the
target of the reason for privacy.
About encrypted c-c, well, isn't this the reason for the FourCC? Hubs
shouldn't care what clients send to each other, it should only broadcast
B's, broadcast to actives by A's etc...? Then clients should have the
possibility of sending what lookes like junk to each other, but that is
encrypted traffic. This is probably only a client issue anyway.
8) No authentication - vulnerable to the good ole' man in the middle
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*
9) I can probably thing of more - these were just the first things
that sprung to mind...
Well, I'm satisified that you looked into it.
Instead I was just about to do something a lot more simple with dc++
and adchpp; SSL tunneling for both c-c and c-h connections, solves all
those issues above. there are a few details to be considered though,
mainly regarding key distribution, i e should the hub sign keys of its
users (probably not) or should all keys that can be verified by
querying the user for their hash with a d message be seen as valid?
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)...
Only support encrypted connections is by far the easiest way. Tunneling
ssl, by that you mean to for example implement the openssl's ssl part,
and not only its ciphers? To actually let the library handle the
connections? Well, it's a possibility. I personally just dislike the so
called 'certificates' that are being generated. I'm not sure they fit a
p2p system. They depend on dns names and so on iirc...