Re: Welcome to the ietf-apps-tls mailing list
Tim Hudson <[email protected]>
| Newsgroups | gmane.ietf.apps-tls |
|---|---|
| Message-ID | <[email protected]> |
According to John Gardiner Myers:
> > There are toolkits for it that some people like.
> Do any of these toolkits allow SSL to be started up on an
> already-existing connection?
SSLeay supports this and has done so for two years now. SSLtelnet and
SSLftp exist and support either direct non-negotiated SSL connections or
negotiation via extensions of the existing extensions for doing encryption.
There is a document draft-murray-auth-ftp-ssl-01.txt that details an expansion
of the system used in SSLftp to cater for a wider set of requirements than
what I had went I wrote the original code.
> I was under the impression that SSL toolkits would need a little
> upgrading in order to be able to support STARTTLS, at which point it
> is not unreasonable to also expect them to support at least SSL3.0.
SSL2 is widely deployed. SSL3 is also widely deployed for https only.
There are interesting quirks in the existing implementation that add a
number of challenges when trying to interoperate and do serious work with
client certificates.
SSLeay with support for SSL3 will be in general release as of July 1
at which point in time all the existing products (freeware, shareware and
commercial) built on top of it will rapidly be upgraded to supporting SSL3.
Building an infrastructure that doesn't allow for the widely deployed
toolkits available in source form is not sensible given that reference
implementations need to be generally available to get rapid deployment
and restricting things to in essence a USA only market would not be a smart
move in my opinion. A framework should support existing and future use.
Tim.
(naturally this is just my opinion ...)