SSLeay 0.6.5 After quite some time (3 months), the new release. I have been very busy for the last few months and so this is mostly bug fixes and improvments. The main additions are - assember for x86 DES. For all those gcc based systems, this is a big improvement. From 117,000 DES operation a second on a pentium 100, I now get 191,000. I have also reworked the C version so it now gives 148,000 DESs per second. - As mentioned above, the inner DES macros now have some more variant that sometimes help, sometimes hinder performance. There are now 3 options DES_PTR (ptr vs array lookup), DES_UNROLL (full vs partial loop unrolling) and DES_RISC (a more register intensive version of the inner macro). The crypto/des/des_opts.c program, when compiled and run, will give an indication of the correct options to use. - The BIO stuff has been improved. Read doc/bio.doc. There are now modules for encryption and base64 encoding and a BIO_printf() function. - The CA program will accept simple one line X509v3 extensions in the ssleay.cnf file. Have a look at the example. Currently this just puts the text into the certificate as an OCTET_STRING so currently the more advanced X509v3 data types are not handled but this is enough for the netscape extensions. - There is the start of a nicer higher level interface to the X509 strucutre. - Quite a lot of bug fixes. - CRYPTO_malloc_init() (or CRYPTO_set_mem_functions()) can be used to define the malloc(), free() and realloc() routines to use (look in crypto/crypto.h). This is mostly needed for Windows NT/95 when using DLLs and mixing CRT libraries. In general, read the 'VERSION' file for changes and be aware that some of the new stuff may not have been tested quite enough yet, so don't just plonk in SSLeay 0.6.5 when 0.6.4 used to work and expect nothing to break. SSLeay 0.6.4 30/08/96 eay I've just finished some test builds on Windows NT, Windows 3.1, Solaris 2.3, Solaris 2.5, Linux, IRIX, HPUX 10 and everthing seems to work :-). The main changes in this release - Thread safe. have a read of doc/threads.doc and play in the mt directory. For anyone using 0.6.3 with threads, I found 2 major errors so consider moving to 0.6.4. I have a test program that builds under NT and solaris. - The get session-id callback has changed. Have a read of doc/callback.doc. - The X509_cert_verify callback (the SSL_verify callback) now has another argument. Have a read of doc/callback.doc - 'ca -preserve', sign without re-ordering the DN. Not tested much. - VMS support. - Compile time memory leak detection can now be built into SSLeay. Read doc/memory.doc - CONF routines now understand '\', '\n', '\r' etc. What this means is that the SPKAC object mentioned in doc/ns-ca.doc can be on multiple lines. - 'ssleay ciphers' added, lists the default cipher list for SSLeay. - RC2 key setup is now compatable with Netscape. - Modifed server side of SSL implementation, big performance difference when using session-id reuse. 0.6.3 Bug fixes and the addition of some nice stuff to the 'ca' program. Have a read of doc/ns-ca.doc for how hit has been modified so it can be driven from a CGI script. The CGI script is not provided, but that is just being left as an excersize for the reader :-). 0.6.2 This is most bug fixes and functionality improvements. Additions are - More thread debugging patches, the thread stuff is still being tested, but for those keep to play with stuff, have a look in crypto/cryptlib.c. The application needs to define 1 (or optionaly a second) callback that is used to implement locking. Compiling with LOCK_DEBUG spits out lots of locking crud :-). This is what I'm currently working on. - SSL_CTX_set_default_passwd_cb() can be used to define the callback function used in the SSL*_file() functions used to load keys. I was always of the opinion that people should call PEM_read_RSAPrivateKey() and pass the callback they want to use, but it appears they just want to use the SSL_*_file() function() :-(. - 'enc' now has a -kfile so a key can be read from a file. This is mostly used so that the passwd does not appear when using 'ps', which appears imposible to stop under solaris. - X509v3 certificates now work correctly. I even have more examples in my tests :-). There is now a X509_EXTENSION type that is used in X509v3 certificates and CRLv2. - Fixed that signature type error :-( - Fixed quite a few potential memory leaks and problems when reusing X509, CRL and REQ structures. - EVP_set_pw_prompt() now sets the library wide default password prompt. - The 'pkcs7' command will now, given the -print_certs flag, output in pem format, all certificates and CRL contained within. This is more of a pre-emtive thing for the new verisign distribution method. I should also note, that this also gives and example in code, of how to do this :-), or for that matter, what is involved in going the other way (list of certs and crl -> pkcs7). - Added RSA's DESX to the DES library. It is also available via the EVP_desx_cbc() method and via 'enc desx'. SSLeay 0.6.1 The main functional changes since 0.6.0 are as follows - Bad news, the Microsoft 060 DLL's are not compatable, but the good news is that from now on, I'll keep the .def numbers the same so they will be. - RSA private key operations are about 2 times faster that 0.6.0 - The SSL_CTX now has more fields so default values can be put against it. When an SSL structure is created, these default values are used but can be overwritten. There are defaults for cipher, certificate, private key, verify mode and callback. This means SSL session creation can now be ssl=SSL_new() SSL_set_fd(ssl,sock); SSL_accept(ssl) .... All the other uglyness with having to keep a global copy of the private key and certificate/verify mode in the server is now gone. - ssl/ssltest.c - one process talking SSL to its self for testing. - Storage of Session-id's can be controled via a session_cache_mode flag. There is also now an automatic default flushing of old session-id's. - The X509_cert_verify() function now has another parameter, this should not effect most people but it now means that the reason for the failure to verify is now available via SSL_get_verify_result(ssl). You don't have to use a global variable. - SSL_get_app_data() and SSL_set_app_data() can be used to keep some application data against the SSL structure. It is upto the application to free the data. I don't use it, but it is available. - SSL_CTX_set_cert_verify_callback() can be used to specify a verify callback function that completly replaces my certificate verification code. Xcert should be able to use this :-). The callback is of the form int app_verify_callback(arg,ssl,cert). This needs to be documented more. - I have started playing with shared library builds, have a look in the shlib directory. It is very simple. If you need a numbered list of functions, have a look at misc/crypto.num and misc/ssl.num. - There is some stuff to do locking to make the library thread safe. I have only started this stuff and have not finished. If anyone is keen to do so, please send me the patches when finished. So I have finally made most of the additions to the SSL interface that I thought were needed. There will probably be a pause before I make any non-bug/documentation related changes to SSLeay since I'm feeling like a bit of a break. eric - 12 Jul 1996 I saw recently a comment by some-one that we now seem to be entering the age of perpetual Beta software. Pioneered by packages like linux but refined to an art form by netscape. I too wish to join this trend with the anouncement of SSLeay 0.6.0 :-). There are quite a large number of sections that are 'works in progress' in this package. I will also list the major changes and what files you should read. BIO - this is the new IO structure being used everywhere in SSLeay. I started out developing this because of microsoft, I wanted a mechanism to callback to the application for all IO, so Windows 3.1 DLL perversion could be hidden from me and the 15 different ways to write to a file under NT would also not be dictated by me at library build time. What the 'package' is is an API for a data structure containing functions. IO interfaces can be written to conform to the specification. This in not intended to hide the underlying data type from the application, but to hide it from SSLeay :-). I have only really finished testing the FILE * and socket/fd modules. There are also 'filter' BIO's. Currently I have only implemented message digests, and it is in use in the dgst application. This functionality will allow base64/encrypto/buffering modules to be 'push' into a BIO without it affecting the semantics. I'm also working on an SSL BIO which will hide the SSL_accept()/SLL_connet() from an event loop which uses the interface. It is also possible to 'attach' callbacks to a BIO so they get called before and after each operation, alowing extensive debug output to be generated (try running dgst with -d). Unfortunaly in the conversion from 0.5.x to 0.6.0, quite a few functions that used to take FILE *, now take BIO *. The wrappers are easy to write function_fp(fp,x) FILE *fp; { BIO *b; int ret; if ((b=BIO_new(BIO_s_file())) == NULL) error..... BIO_set_fp(b,fp,BIO_NOCLOSE); ret=function_bio(b,x); BIO_free(b); return(ret); } Remember, there are no functions that take FILE * in SSLeay when compiled for Windows 3.1 DLL's. -- I have added a general EVP_PKEY type that can hold a public/private key. This is now what is used by the EVP_ functions and is passed around internally. I still have not done the PKCS#8 stuff, but X509_PKEY is defined and waiting :-) -- For a full function name listings, have a look at ms/crypt32.def and ms/ssl32.def. These are auto-generated but are complete. Things like ASN1_INTEGER_get() have been added and are in here if you look. I have renamed a few things, again, have a look through the function list and you will probably find what you are after. I intend to at least put a one line descrition for each one..... -- Microsoft - thats what this release is about, read the MICROSOFT file. -- Multi-threading support. I have started hunting through the code and flaging where things need to be done. In a state of work but high on the list. -- For random numbers, edit e_os.h and set DEVRANDOM (it's near the top) be be you random data device, otherwise 'RFILE' in e_os.h will be used, in your home directory. It will be updated periodically. The environment variable RANDFILE will override this choice and read/write to that file instead. DEVRANDOM is used in conjunction to the RFILE/RANDFILE. If you wish to 'seed' the random number generator, pick on one of these files. -- The list of things to read and do dgst -d s_client -state (this uses a callback placed in the SSL state loop and will be used else-where to help debug/monitor what is happening.) doc/why.doc doc/bio.doc <- hmmm, needs lots of work. doc/bss_file.doc <- one that is working :-) doc/session.doc <- it has changed doc/speed.doc also play with ssleay version -a. I have now added a SSLeay() function that returns a version number, eg 0600 for this release which is primarily to be used to check DLL version against the application. util/* Quite a few will not interest people, but some may, like mk1mf.pl, mkdef.pl, util/do_ms.sh try cc -Iinclude -Icrypto -c crypto/crypto.c cc -Iinclude -Issl -c ssl/ssl.c You have just built the SSLeay libraries as 2 object files :-) Have a general rummage around in the bin stall directory and look at what is in there, like CA.sh and c_rehash There are lots more things but it is 12:30am on a Friday night and I'm heading home :-). eric 22-Jun-1996 This version has quite a few major bug fixes and improvements. It DOES NOT do SSLv3 yet. The main things changed - A Few days ago I added the s_mult application to ssleay which is a demo of an SSL server running in an event loop type thing. It supports non-blocking IO, I have finally gotten it right, SSL_accept() can operate in non-blocking IO mode, look at the code to see how :-). Have a read of doc/s_mult as well. This program leaks memory and file descriptors everywhere but I have not cleaned it up yet. This is a demo of how to do non-blocking IO. - The SSL session management has been 'worked over' and there is now quite an expansive set of functions to manipulate them. Have a read of doc/session.doc for some-things I quickly whipped up about how it now works. This assume you know the SSLv2 protocol :-) - I can now read/write the netscape certificate format, use the -inform/-outform 'net' options to the x509 command. I have not put support for this type in the other demo programs, but it would be easy to add. - asn1parse and 'enc' have been modified so that when reading base64 encoded files (pem format), they do not require '-----BEGIN' header lines. The 'enc' program had a buffering bug fixed, it can be used as a general base64 -> binary -> base64 filter by doing 'enc -a -e' and 'enc -a -d' respecivly. Leaving out the '-a' flag in this case makes the 'enc' command into a form of 'cat'. - The 'x509' and 'req' programs have been fixed and modified a little so that they generate self-signed certificates correctly. The test script actually generates a 'CA' certificate and then 'signs' a 'user' certificate. Have a look at this shell script (test/sstest) to see how things work, it tests most possible combinations of what can be done. - The 'SSL_set_pref_cipher()' function has been 'fixed' and the prefered name of SSL_set_cipher_list() is now the correct API (stops confusion :-). If this function is used in the client, only the specified ciphers can be used, with preference given to the order the ciphers were listed. For the server, if this is used, only the specified ciphers will be used to accept connections. If this 'option' is not used, a default set of ciphers will be used. The SSL_CTX_set_cipher_list(SSL_CTX *ctx) sets this list for all ciphers started against the SSL_CTX. So the order is SSL cipher_list, if not present, SSL_CTX cipher list, if not present, then the library default. What this means is that normally ciphers like NULL-MD5 will never be used. The only way this cipher can be used for both ends to specify to use it. To enable or disable ciphers in the library at build time, modify the first field for the cipher in the ssl_ciphers array in ssl/ssl_lib.c. This file also contains the 'pref_cipher' list which is the default cipher preference order. - I'm not currently sure if the 'rsa -inform net' and the 'rsa -outform net' options work. They should, and they enable loading and writing the netscape rsa private key format. I will be re-working this section of SSLeay for the next version. What is currently in place is a quick and dirty hack. - I've re-written parts of the bignum library. This gives speedups for all platforms. I now provide assembler for use under Windows NT. I have not tested the Windows 3.1 assembler but it is quite simple code. This gives RSAprivate_key operation encryption times of 0.047s (512bit key) and 0.230s (1024bit key) on a pentium 100 which I consider reasonable. Basically the times available under linux/solaris x86 can be achieve under Windows NT. I still don't know how these times compare to RSA's BSAFE library but I have been emailing with people and with their help, I should be able to get my library's quite a bit faster still (more algorithm changes). The object file crypto/bn/asm/x86-32.obj should be used when linking under NT. - 'make makefile.one' in the top directory will generate a single makefile called 'makefile.one' This makefile contains no perl references and will build the SSLeay library into the 'tmp' and 'out' directories. util/mk1mf.pl >makefile.one is how this makefile is generated. The mk1mf.pl command take several option to generate the makefile for use with cc, gcc, Visual C++ and Borland C++. This is still under development. I have only build .lib's for NT and MSDOS I will be working on this more. I still need to play with the correct compiler setups for these compilers and add some more stuff but basically if you just want to compile the library on a 'non-unix' platform, this is a very very good file to start with :-). Have a look in the 'microsoft' directory for my current makefiles. I have not yet modified things to link with sockets under Windows NT. You guys should be able to do this since this is actually outside of the SSLeay scope :-). I will be doing it for myself soon. util/mk1mf.pl takes quite a few options including no-rc, rsaref and no-sock to build without RC2/RC4, to require RSAref for linking, and to build with no socket code. - Oh yes, the cipher that was reported to be compatible with RSA's RC2 cipher that was posted to sci.crypt has been added to the library and SSL. I take the view that if RC2 is going to be included in a standard, I'll include the cipher to make my package complete. There are NO_RC2, NO_RC4 and NO_IDEA macros to remove these ciphers at compile time. I have not tested this recently but it should all work and if you are in the USA and don't want RSA threatening to sue you, you could probably remove the RC4/RC2 code inside these sections. I may in the future include a perl script that does this code removal automatically for those in the USA :-). - I have removed all references to sed in the makefiles. So basically, the development environment requires perl and sh. The build environment does not (use the makefile.one makefile). The Configure script still requires perl, this will probably stay that way since I have perl for Windows NT :-). eric (03-May-1996) PS Have a look in the VERSION file for more details on the changes and bug fixes. I have fixed a few bugs, added alpha and x86 assembler and generally cleaned things up. This version will be quite stable, mostly because I'm on holidays until 10-March-1996. For any problems in the interum, send email to Tim Hudson . SSLeay 0.5.0 12-12-95 This is going out before it should really be released. I leave for 11 weeks holidays on the 22-12-95 and so I either sit on this for 11 weeks or get things out. It is still going to change a lot in the next week so if you do grab this version, please test and give me feed back ASAP, inculuding questions on how to do things with the library. This will prompt me to write documentation so I don't have to answer the same question again :-). This 'pre' release version is for people who are interested in the library. The applications will have to be changed to use the new version of the SSL interface. I intend to finish more documentation before I leave but until then, look at the programs in the apps directory. As far as code goes, it is much much nicer than the old version. The current library works, has no memory leaks (as far as I can tell) and is far more bug free that 0.4.5d. There are no global variable of consequence (I believe) and I will produce some documentation that tell where to look for those people that do want to do multi-threaded stuff. There should be more documentation. Have a look in the doc directory. I'll be adding more before I leave, it is a start by mostly documents the crypto library. Tim Hudson will update the web page ASAP. The spelling and grammar are crap but it is better than nothing :-) Reasons to start playing with version 0.5.0 - All the programs in the apps directory build into one ssleay binary. - There is a new version of the 'req' program that generates certificate requests, there is even documentation for this one :-) - There is a demo certification authorithy program. Currently it will look at the simple database and update it. It will generate CRL from the data base. You need to edit the database by hand to revoke a certificate, it is my aim to use perl5/Tk but I don't have time to do this right now. It will generate the certificates but the management scripts still need to be written. This is not a hard task. - Things have been cleaned up alot. - Have a look at the enc and dgst programs in the apps directory. - It supports v3 of x509 certiticates. Major things missing. - I have been working on (and thinging about) the distributed x509 hierachy problem. I have not had time to put my solution in place. It will have to wait until I come back. - I have not put in CRL checking in the certificate verification but it would not be hard to do. I was waiting until I could generate my own CRL (which has only been in the last week) and I don't have time to put it in correctly. - Montgomery multiplication need to be implemented. I know the algorithm, just ran out of time. - PKCS#7. I can load and write the DER version. I need to re-work things to support BER (if that means nothing, read the ASN1 spec :-). - Testing of the higher level digital envelope routines. I have not played with the *_seal() and *_open() type functions. They are written but need testing. The *_sign() and *_verify() functions are rock solid. - PEM. Doing this and PKCS#7 have been dependant on the distributed x509 heirachy problem. I started implementing my ideas, got distracted writing a CA program and then ran out of time. I provide the functionality of RSAref at least. - Re work the asm. code for the x86. I've changed by low level bignum interface again, so I really need to tweak the x86 stuff. gcc is good enough for the other boxes.