Top-level Files of ec0e84eb75fc7bc1

Files in the top-level directory of check-in ec0e84eb75fc7bc1


Copyright (C) 1997-2000 Matt Newman <[email protected]>
TLS 1.4.1 Copyright (C) 2000 Ajuba Solutions

$Header: /home/rkeene/tmp/cvs2fossil/../tcltls/tls/tls/README.txt,v 1.5 2003/05/15 21:02:10 razzell Exp $

TLS (aka SSL) Channel - can be layered on any bi-directional Tcl_Channel.

Both client and server-side sockets are possible, and this code should work
on any platform as it uses a generic mechanism for layering on SSL and Tcl.

The TLS 1.4 release requires Tcl 8.2.0+, with 8.3.2+ preferred.  The
stacked channel implementation in Tcl was originally introduced in 8.2.0
(previously the Trf patch) and rewritten for 8.3.2+ due to inherent
limitations in the earlier implementation.  TLS 1.4 should compile with
any stubs-capable Tcl interpreter, but will require 8.2+ when loaded.
There are known limitations in the 8.2.0-8.3.1 stacked channel
implementation, so it is encouraged that people use TLS 1.4+ with an
8.3.2+ Tcl interpreter.  These modifications are by Jeff Hobbs
<[email protected]>.

Full filevent sematics should also be intact - see tests directory for
blocking and non-blocking examples.

This was built (almost) from scratch based upon observation of OpenSSL 0.9.2b.
For correct functioning, use OpenSSL 0.9.6g or later.  This release contains
important fixes to memory management, as well as incorporating the verify
callback correction which appeared in OpenSSL 0.9.6c.  For best security, use
the latest official release of OpenSSL.

Addition credit is due for Andreas Kupries ([email protected]), for
providing the Tcl_ReplaceChannel mechanism and working closely with me
to enhance it to support full fileevent semantics.

Also work done by the follow people provided the impetus to do this "right":-
tclSSL (Colin McCormack, Shared Technology)
SSLtcl (Peter Antman)

This code is licensed under the same terms as the Tcl Core.

I would also like to acknowledge the input of Marshall Rose, who convinced 
me that people need to be able to switch-to-encrypted mode part way
through a conversation.

Also I would like to acknowledge the kind support of Novadigm Inc, my
current employer, which made this possible.


Matt Newman