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