SSLeay - Whats the story...
Maybe I miss it, but when did this arrive? Is anyone testing it?
On Thu, 3 Aug 1995, Jason Weisberger wrote:
Maybe I miss it, but when did this arrive? Is anyone testing it?
I started writting the library back at the start or april. It has been available for ftp for a month or 2 now but I'm still working on it. I have only mentioned it on a few mailing lists and am holding off its anouncment on sci.crypt until we have the windows 3.1 DLL working fully (well, we have it working now but I'm still cleaning things up a bit :-). It even compiles under DOS :-) It is a free (for comercial and non-comercial use) complete implementation of netscapes SSL v 2. The SSL part of the library is quite small, most of the rest is support routines for the x509 environment. I have routines for DES (my libdes library), RC4, IDEA, RSA, MD2, MD5. I have support routines to generate RSA private keys and I have programs to generate, and certify x509 certificates. Tim Hudson has put SSL in ftp, telnet, Moasic, httpd etc. These patches are available from the same ftp site. For those in the USA, you can build to use RSAref and can build with RC4 and or IDEA removed. All code in this 'library' has been written by me from publicaly available material. Documentation of the non SSL part is quite small since I have mostly been coding and nearly all of this work has been done outside of my normal work hours. People have been using the library quite a bit, and we can interoperate with netscape secure servers and their clients (if we have a certificate signed by netscape). Have a play and please send me any comments :-) http://www.psy.uq.oz.au/~ftp/Crypto/ ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/ ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/ eric -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups that the message contents :-)
On Thu, 3 Aug 1995, Jason Weisberger wrote:
Maybe I miss it, but when did this arrive? Is anyone testing it?
You may take a look at http://www.psy.uq.oz.au/~ftp/Crypto/ My initial enthusiasm has somewhat vanished when I've realized that a free SSL implementation doesn't automatically allow to build a Netsite-compatible server: without a certificate issued by Verisign on behalf of Netscape Communications, Netscape Navigator won't talk to it. As SSL has some intrinsic points of weakness, I don't see the point of sticking to it to secure the TCP layer. For details, see also http://petrified.cic.net/~altitude/ssl/ssl.saga.html On the other hand, the CryptoTCP approach (see the file ctcp.0.9.tar.gz at ftp://utopia.hacktic.nl/pub/crypto) looks promising. Is anybody working on it? I'm interested in exchanging ideas, as I'm thinking of adding CryptoTCP client capabilities to a SOCKS 4.2 daemon. I see three major areas for improvement: 1. A better PRNG for the session key 2. Authentication of the D-H key exchange with digital signatures, a` la Photuris 3. Less "hard-wired" structure: at present, for example, the module size for D-H calculations is fixed at 1024 bits. 1. and 2. are relatively easy, but 3. would require a lot of work. Also, being able to negotiate different encryption algorithm in addition to triple-DES wouldn't be bad.
On Thu Aug 3 23:45:04 1995: you scribbled...
On Thu, 3 Aug 1995, Jason Weisberger wrote:
Maybe I miss it, but when did this arrive? Is anyone testing it?
You may take a look at http://www.psy.uq.oz.au/~ftp/Crypto/
My initial enthusiasm has somewhat vanished when I've realized that a free SSL implementation doesn't automatically allow to build a Netsite-compatible server: without a certificate issued by Verisign on behalf of Netscape Communications, Netscape Navigator won't talk to it. As SSL has some intrinsic points of weakness, I don't see the point of sticking to it to secure the TCP layer.
just wondering but...What are the intrinsic points of weakness? ...alex...
On Fri, 4 Aug 1995, Alex Tang wrote:
just wondering but...What are the intrinsic points of weakness?
Perry Metzger and Mark Chen have recently expressed some criticism, and Adam Shostack, around the end of May, posted a review that hilighted a number of potential problem areas. Personally, I especially dislike the use of RC4-40 (yes, other algorithms are supported, but not using the export version of Netscape Navigator); the excessively large portion of the handshaking data exchanged as cleartext; and the limitations in certificate management (no provisions for verifying the revocation status with a CA).
On Fri, 4 Aug 1995, Enzo Michelangeli wrote:
On Fri, 4 Aug 1995, Alex Tang wrote: Perry Metzger and Mark Chen have recently expressed some criticism, and Adam Shostack, around the end of May, posted a review that hilighted a number of potential problem areas.
Do you have a copy of this?
Personally, I especially dislike the use of RC4-40 (yes, other algorithms are supported, but not using the export version of Netscape Navigator); Totaly agree, hell, I going to give the option for users and server to specify at run time which ciphers never to use :-).
the excessively large portion of the handshaking data exchanged as cleartext; and the limitations in certificate management (no provisions for verifying the revocation status with a CA).
The clear text I don't like, I agree. But then when used for http, everything begins with a GET anyway. The CRL verification is again to me a matter of implementation. Currently my library does not support CRL (but I can load and manipulate them). It is simply a function of the infrastructure to go with the library. SSL v3 of the spec does alow for CRL to be passed along with the certificate heigherachy (a PKCS-7 object). I'm mostly concered with any objections raised with the protocol, not the particular implementation around right now. With my library I fully intend to make it possible to refuse to authenticate the server unless a current CRL is present. Anyway, I'm intersted in hearing people complains so I can attempt to make sure none of the fixable problems are in my library :-) eric -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups that the message contents :-)
On Fri, 4 Aug 1995, Eric Young wrote:
Do you have a copy of this?
Yes, I've forwarded it to you separately.
The clear text I don't like, I agree. But then when used for http, everything begins with a GET anyway.
Well, ssh and Photuris shows that a better way is possible: do a D-H key exchange, then handle anything else (including the authentication of the D-H transaction) on the newly established encrypted channel.
| > As SSL has some intrinsic points of weakness, I don't see the point | > of sticking to it to secure the TCP layer. | | just wondering but...What are the intrinsic points of weakness? As Bruce Schneier reminded people in his keynote at Defcon, its easier to steal the keys than to break the cryptosystem. Web servers tend to be far too big and bulky to be trusted with cryptographic keys. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
participants (5)
-
Adam Shostack -
Alex Tang -
Enzo Michelangeli -
Eric Young -
Jason Weisberger