Message-ID: <[email protected]>
Oskar writes:
I have been skeptical of the idea of using SSL for future
encrypted Freenet connections, because I think there are other
highly favorable features, such as nodes that only accept
and make connections to nodes they know are trusted, or even
web-of-trust type systems within the network, which I guess
would require that we have our own key management (or even
dictate how it works) for node authentication even beyond
encrypting the streams. Of course I don`t know much about SSL,
so maybe this is all possible within it`s framework.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <51734.955575629.1 at cloud.rain.com>
Date: Wed, 12 Apr 2000 14:40:29 -0700
Message-ID: <51735.955575629 at cloud.rain.com>
From: Bill Trost <[email protected]>
I believe so, although some libraries may not support all of it. I know
SSL/TLS supports "only connect if you have a certificate you trust,"
and even "only allow connections if you have a certificate you trust."
Presumably you could even do things like restrict a node's behavior
based on (non-)receipt of a validatable certificate.
SSL doesn't restrict what constitutes a valid key authority, either, so
sites are free to dream up whatever web of trust they choose.
And what is the Freedom situation with SSL? It uses RSA which
will be free in a few months, but what about the symmetric
ciphers?
The RFC (http://www.ietf.org/rfc/rfc2246.txt) lists RC2, RC4, DES, 3DES,
and IDEA. DES and 3DES are fairly clearly Free. Software which is
functionally compatible with the encryption algorithm licensed under
the trademarked name "RC4" are legally and Freely available. IDEA
has patent issues in some countries. I know little about RC2, but I
assume that it is either a patented algorithm or is being held as a
trade secret and has an associated trademark, and thus of doubtful
suitability.
Also, note that there are SSL modes that do not require RSA.
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is a likely choice, or one could just
use TLS_DH_anon_WITH_3DES_EDE_CBC_SHA if authentication isn't an issue.
However, implementors seem to have an inordinate fondness for RSA, so
finding code that actually supports these modes could be challenging.
Of course we should be weary of a "do it ourselves" attitude to
security, since it is by far the most difficult field to get
right - but on the other hand I would rather it took us longer
to do things right then that we compromise the intentions of
system to cram it into existing standards (as per my rejection
of using HTTP).
Stay away with home-baked crypto at *any* level -- not just the
ciphers, but the protocols as well. Pick one, well-known, open-source
(for peer review) implementation of SSL and use it to create the
encrypted/authenticated link. Once the SSL exchanged has completed, the
link can be used by the underlying code just like a cleartext link.
On Wed, 12 Apr 2000, Ian Clarke wrote:
> The last time we discussed this, the main obstacle was that I
> really didn`t want to bundle an entire encryption package with
> Freenet, when we would only be using a small fraction of its
> functionality...
Sorry, I didn't make myself clear. Stunnel is a little SSL program
that can be used to tunnel other arbitrary TCP data streams. By
making a small addition to the Freenet code, people can hack up
encrypted/authenticated connections on their own, using whatever tunnel
software they please. This isn't meant as a long-term solution, just a
quick hack people can use to get encryption up in short order.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
