I agree with Costin on waiting for more comments. I've done a first look over, so I'm happy to do start doing the ci (say at the end of the week?). It looks like there may be some API changes to fully integrate with j-t-c (esp. JNI), but it shouldn't be a problem to port these to 3.3.x. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Friday, November 30, 2001 11:33 PM Subject: Re: Submission: Portable SSL Support
> Hi Eric, > > I looked at the patch - it seems ok. I think we should wait few more > days for more people to have a chance to look at the code. It's great > having an SSL expert around :-) > > > What remains to be done is getting jk to reuse the same abstractions > for ssl support - that would make the code cleaner. But it can wait a > while, there are bigger changes going on there. > > > Costin > > On Fri, 30 Nov 2001, Eric Rescorla wrote: > > > I've finished patching Tomcat to support both PureTLS and JSSE (and it > > would be trivial to add pretty much any other SSL implementation if > > there was a need). Essentially, what I did was take the current > > support for JSSE and generalize it so that it could support any > > implementation. This required adding a fair amount of abstraction. > > > > (1) Each implementation is encapsulated by a subclass of SSLImplementation. > > As before, PoolTCPConnector is responsible for detecting that SSL has > > been called for and loading up the right implementation but it > > does it by using SSLImplementation. > > > > (2) SSLImplementation.getInstance() automatically chooses whatever > > implementation is active. (There's a parameter to tell it to use a > > specific one). > > > > (3) In order to get a socket you first get the appropriate > > socketFactory from the SSLImplementation. You then use > > socketFactory.getSocket() as before. > > > > (4) All the special things you can do with an SSL socket are > > encapsulated in SSLSupport. SSLImplementation.getSSLSuport(Socket > > sock) lets you get the SSLSupport for a given socket. > > > > (5) Currently you can get the attributes: > > javax.servlet.request.cipher_suite > > javax.servlet.request.X509Certificate > > > > What's supposed to be at: > > javax.servlet.request.key_size > > is extremely vague. I'll implement it once I hear back from Sun about > > the value. > > > > (6) Changes to the doc to explain this stuff. > > > > The changes are of three types: > > (1) A patch file. > > (2) A mess of new source files which live in > > org/apache/tomcat/util/net. > > (3) The following file needs to be deleted from the repository: > > org/apache/tomcat/util/net/SSLSocketFactory.java > > > > Due to the size of the changes I've put the patch and new source files > > up at http://www.rtfm.com/tomcat-changes-20011130.tar.gz. If someone > > wants them mailed to the list I'm happy to do so. > > > > Note: These changes only work properly with the latest PureTLS snapshot: > > 20011130 (though they should work fine if you're compiling without > > PureTLS at all as well). > > > > -Ekr > > > > -- > > [Eric Rescorla [EMAIL PROTECTED]] > > Author of "SSL and TLS: Designing and Building Secure Systems" > > http://www.rtfm.com/ > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > *----* This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
