Remove bugs/ and crypto/threads/

If you use the function that does an fopen inside the DLL, it's malloc

will be used and when the function is then written inside, more

hassles

....

think about it.

So far...

ssl3.netscape.com:443 does not support client side dynamic

session-renegotiation.

ssl3.netscape.com:444 (asks for client cert) sends out all the CA RDN

in an invalid format (the outer sequence is removed).

Netscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte

challenge but then appears to only use 16 bytes when generating the

encryption keys.  Using 16 bytes is ok but it should be ok to use 32.

According to the SSLv3 spec, one should use 32 bytes for the challenge

when opperating in SSLv2/v3 compatablity mode, but as mentioned above,

this breaks this server so 16 bytes is the way to go.

www.microsoft.com - when talking SSLv2, if session-id reuse is

performed, the session-id passed back in the server-finished message

is different from the one decided upon.

ssl3.netscape.com:443, first a connection is established with RC4-MD5.

If it is then resumed, we end up using DES-CBC3-SHA.  It should be

RC4-MD5 according to 7.6.1.3, 'cipher_suite'.

Netscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug.

It only really shows up when connecting via SSLv2/v3 then reconnecting

via SSLv3. The cipher list changes....

NEW INFORMATION.  Try connecting with a cipher list of just

DES-CBC-SHA:RC4-MD5.  For some weird reason, each new connection uses

RC4-MD5, but a re-connect tries to use DES-CBC-SHA.  So netscape, when

doing a re-connect, always takes the first cipher in the cipher list.

If we accept a netscape connection, demand a client cert, have a

non-self-signed CA which does not have it's CA in netscape, and the

browser has a cert, it will crash/hang.  Works for 3.x and 4.xbeta

Netscape browsers do not really notice the server sending a

close notify message.  I was sending one, and then some invalid data.

netscape complained of an invalid mac. (a fork()ed child doing a

SSL_shutdown() and still sharing the socket with its parent).

Netscape, when using export ciphers, will accept a 1024 bit temporary

RSA key.  It is supposed to only accept 512.

If Netscape connects to a server which requests a client certificate

it will frequently hang after the user has selected one and never

complete the connection. Hitting "Stop" and reload fixes this and

all subsequent connections work fine. This appears to be because 

Netscape wont read any new records in when it is awaiting a server

done message at this point. The fix is to send the certificate request

and server done messages in one record.

/* bugs/alpha.c */

/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)

 * All rights reserved.

 *

 * This package is an SSL implementation written

 * by Eric Young (eay@cryptsoft.com).

 * The implementation was written so as to conform with Netscapes SSL.

 *

 * This library is free for commercial and non-commercial use as long as

 * the following conditions are aheared to.  The following conditions

 * apply to all code found in this distribution, be it the RC4, RSA,

 * lhash, DES, etc., code; not just the SSL code.  The SSL documentation

 * included with this distribution is covered by the same copyright terms

 * except that the holder is Tim Hudson (tjh@cryptsoft.com).

 *

 * Copyright remains Eric Young's, and as such any Copyright notices in

 * the code are not to be removed.

 * If this package is used in a product, Eric Young should be given attribution

 * as the author of the parts of the library used.

 * This can be in the form of a textual message at program startup or

 * in documentation (online or textual) provided with the package.

 *

 * Redistribution and use in source and binary forms, with or without

 * modification, are permitted provided that the following conditions

 * are met:

 * 1. Redistributions of source code must retain the copyright

 *    notice, this list of conditions and the following disclaimer.

 * 2. Redistributions in binary form must reproduce the above copyright

 *    notice, this list of conditions and the following disclaimer in the

 *    documentation and/or other materials provided with the distribution.

 * 3. All advertising materials mentioning features or use of this software

 *    must display the following acknowledgement:

 *    "This product includes cryptographic software written by

 *     Eric Young (eay@cryptsoft.com)"

 *    The word 'cryptographic' can be left out if the rouines from the library

 *    being used are not cryptographic related :-).

 * 4. If you include any Windows specific code (or a derivative thereof) from

 *    the apps directory (application code) you must include an acknowledgement:

 *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"

 *

 * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND

 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE

 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE

 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL

 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS

 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)

 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT

 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY

 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF

 * SUCH DAMAGE.

 *

 * The licence and distribution terms for any publically available version or

 * derivative of this code cannot be changed.  i.e. this code cannot simply be

 * copied and put under another distribution licence

 * [including the GNU Public Licence.]

 */

/*

 * while not exactly a bug (ASN1 C leaves this undefined) it is something to

 * watch out for.  This was fine on linux/NT/Solaris but not Alpha

 */

/*-

 * it is basically an example of

 * func(*(a++),*(a++))

 * which parameter is evaluated first?  It is not defined in ASN1 C.

 */

#include <stdio.h>

#define TYPE    unsigned int

void func(a, b)

TYPE *a;

TYPE b;

{

    printf("%ld -1 == %ld\n", a[0], b);

}

main()

{

    TYPE data[5] = { 1L, 2L, 3L, 4L, 5L };

    TYPE *p;

    int i;

    p = data;

    for (i = 0; i < 4; i++) {

        func(p, *(p++));

    }

}

/* NOCW */

/* sgibug.c */

/* bug found by Eric Young (eay@mincom.oz.au) May 95 */

#include <stdio.h>

/*

 * This compiler bug it present on IRIX 5.3, 5.1 and 4.0.5 (these are the

 * only versions of IRIX I have access to. defining FIXBUG removes the bug.

 * (bug is still present in IRIX 6.3 according to Gage

 * <agage@forgetmenot.Mines.EDU>

 */

/*-

 * Compare the output from

 * cc sgiccbug.c; ./a.out

 * and

 * cc -O sgiccbug.c; ./a.out

 */

static unsigned long a[4] =

    { 0x01234567, 0x89ABCDEF, 0xFEDCBA98, 0x76543210 };

static unsigned long b[4] =

    { 0x89ABCDEF, 0xFEDCBA98, 0x76543210, 0x01234567 };

static unsigned long c[4] =

    { 0x77777778, 0x8ACF1357, 0x88888888, 0x7530ECA9 };

main()

{

    unsigned long r[4];

    sub(r, a, b);

    fprintf(stderr, "input a= %08X %08X %08X %08X\n", a[3], a[2], a[1], a[0]);

    fprintf(stderr, "input b= %08X %08X %08X %08X\n", b[3], b[2], b[1], b[0]);

    fprintf(stderr, "output = %08X %08X %08X %08X\n", r[3], r[2], r[1], r[0]);

    fprintf(stderr, "correct= %08X %08X %08X %08X\n", c[3], c[2], c[1], c[0]);

}

int sub(r, a, b)

unsigned long *r, *a, *b;

{

    register unsigned long t1, t2, *ap, *bp, *rp;

    int i, carry;

#ifdef FIXBUG

    unsigned long dummy;

#endif

    ap = a;

    bp = b;

    rp = r;

    carry = 0;

    for (i = 0; i < 4; i++) {

        t1 = *(ap++);

        t2 = *(bp++);

        t1 = (t1 - t2);

#ifdef FIXBUG

        dummy = t1;

#endif

        *(rp++) = t1 & 0xffffffff;

    }

}

The February 9th, 1995 version of the SSL document differs from

https://www.netscape.com in the following ways.

=====

The key material for generating a SSL_CK_DES_64_CBC_WITH_MD5 key is

KEY-MATERIAL-0 = MD5[MASTER-KEY,"0",CHALLENGE,CONNECTION-ID]

not

KEY-MATERIAL-0 = MD5[MASTER-KEY,CHALLENGE,CONNECTION-ID]

as specified in the documentation.

=====

From the section 2.6 Server Only Protocol Messages

If the SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE,

CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will be zero. 

This is not true for https://www.netscape.com.  The CERTIFICATE-TYPE

is returned as 1.

=====

I have not tested the following but it is reported by holtzman@mit.edu.

SSLref clients wait to receive a server-verify before they send a

client-finished.  Besides this not being evident from the examples in

2.2.1, it makes more sense to always send all packets you can before

reading.  SSLeay was waiting in the server to receive a client-finish

before sending the server-verify :-).  I have changed SSLeay to send a

server-verify before trying to read the client-finished.