RE: Portable SSL Support

[GOMEZ Henri]

>Or even better, in SSLInterceptor. No need to change Request 
>or the core -
>if it can be done in a module, it's better to do it this way.

A la mod_ssl :)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[Bill Barker]

+1
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "EKR"
<[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 1:53 PM
Subject: Re: Portable SSL Support


> On 16 Nov 2001, Eric Rescorla wrote:
>
> > "William Barker" <[EMAIL PROTECTED]> writes:
> >
> > > I was thinking of moving it to Http10Interceptor.getInfo, but
otherwise that
> > > was more or less what I was thinking.
> > Actually, ISTM that eventually this belongs in Request.getInfo(), since
> > that allows the use of SSLSupport with Ajp as well. For the moment,
> > though, I agree that it belongs in Http10Interceptor.
>
> Or even better, in SSLInterceptor. No need to change Request or the core -
> if it can be done in a module, it's better to do it this way.
>
> Costin
>
>
>
>
>
> --
> 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]>

Re: Portable SSL Support

[Bill Barker]

In j-t-c I could see putting in RequestBase.  However, since connector
development (with the possible exception of Http10Interceptor, which isn't
in j-t-c) is frozen in 3.3, I can't really see modifying Request.
- Original Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 1:42 PM
Subject: Re: Portable SSL Support


> "William Barker" <[EMAIL PROTECTED]> writes:
>
> > I was thinking of moving it to Http10Interceptor.getInfo, but otherwise
that
> > was more or less what I was thinking.
> Actually, ISTM that eventually this belongs in Request.getInfo(), since
> that allows the use of SSLSupport with Ajp as well. For the moment,
> though, I agree that it belongs in Http10Interceptor.
>
>
> -Ekr
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
>
> --
> 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]>

Re: Portable SSL Support

[costinm]

On 16 Nov 2001, Eric Rescorla wrote:

> "William Barker" <[EMAIL PROTECTED]> writes:
>
> > I was thinking of moving it to Http10Interceptor.getInfo, but otherwise that
> > was more or less what I was thinking.
> Actually, ISTM that eventually this belongs in Request.getInfo(), since
> that allows the use of SSLSupport with Ajp as well. For the moment,
> though, I agree that it belongs in Http10Interceptor.

Or even better, in SSLInterceptor. No need to change Request or the core -
if it can be done in a module, it's better to do it this way.

Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[Eric Rescorla]

"William Barker" <[EMAIL PROTECTED]> writes:

> I was thinking of moving it to Http10Interceptor.getInfo, but otherwise that
> was more or less what I was thinking.
Actually, ISTM that eventually this belongs in Request.getInfo(), since
that allows the use of SSLSupport with Ajp as well. For the moment,
though, I agree that it belongs in Http10Interceptor.


-Ekr
-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[William Barker]

I was thinking of moving it to Http10Interceptor.getInfo, but otherwise that
was more or less what I was thinking.
- Original Message -
From: "jean-frederic clere" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 3:10 AM
Subject: Re: Portable SSL Support


> [EMAIL PROTECTED] wrote:
> >
> > On 14 Nov 2001, Eric Rescorla wrote:
> >
> > > Well, I suppose that since JDK 1.1.x didn't stop you from putting
> > > classes in java. I could do my own version of
> > > java.security.cert.X509Certificate. A little gross but perhaps
> > > the best plan. The alternative is to blatantly violate the spec
> > > in 1.1 and just deliver something else.
> >
> > I would say - don't worry about JDK1.1. Support for JDK1.1 is important
> > for embeded devices ( but even there, GCJ does have X509Certificate - it
> > already supports a large subset of JDK1.2, and that's included ).
> >
> > > > > > You have to use request.getAttribute() in the JSPs/servlets.
> > > > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > > > interface. Instead we could break out each individual property
> > > > > we cared about into it's own attribute.
> > > >
> > > > To be consistant with 2.3 containers, I'd go with individually named
> > > > attributes.
> >
> > > Fine with me. Anyone object to this?
> >
> > Individual attributes are good, but if possible with lazy evaluation.
> >
> > The getInfo() callback in BaseInterceptor is supposed to do exactly
that -
> > allow you to lazy-evaluate expensive request fields, so only servlets
that
> > ask for the information will pay for it.
>
> In TC3.3:
> We have the following in Http10Interceptor.java:
>
> +++
> public Object getAttribute(String name) {
> if (name.equals("javax.servlet.request.X509Certificate")) {
> return(certcompat.getX509Certificates(socket));
> }
> return(super.getAttribute(name));
> }
> +++
>
> A note stored via request.setNote("SSLSupport",SSLSupport) somewhere in
> retrieved by getNote.
> The code ends to be:
> +++
> public Object getAttribute(String name) {
> if (name.equals("javax.servlet.request.X509Certificate")) {
> SSLSupport sslsupport = getNote("SSLSupport");
> if (sslsupport==null)
>   return(null);
> return(sslsupport.getX509Certificates(socket));
> }
> return(super.getAttribute(name));
> }
> +++
> Ideas?
>
> >
> > Costin
> >
> > --
> > 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]>

Re: Portable SSL Support

[jean-frederic clere]

[EMAIL PROTECTED] wrote:
> 
> On 14 Nov 2001, Eric Rescorla wrote:
> 
> > Well, I suppose that since JDK 1.1.x didn't stop you from putting
> > classes in java. I could do my own version of
> > java.security.cert.X509Certificate. A little gross but perhaps
> > the best plan. The alternative is to blatantly violate the spec
> > in 1.1 and just deliver something else.
> 
> I would say - don't worry about JDK1.1. Support for JDK1.1 is important
> for embeded devices ( but even there, GCJ does have X509Certificate - it
> already supports a large subset of JDK1.2, and that's included ).
> 
> > > > > You have to use request.getAttribute() in the JSPs/servlets.
> > > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > > interface. Instead we could break out each individual property
> > > > we cared about into it's own attribute.
> > >
> > > To be consistant with 2.3 containers, I'd go with individually named
> > > attributes.
> 
> > Fine with me. Anyone object to this?
> 
> Individual attributes are good, but if possible with lazy evaluation.
> 
> The getInfo() callback in BaseInterceptor is supposed to do exactly that -
> allow you to lazy-evaluate expensive request fields, so only servlets that
> ask for the information will pay for it.

In TC3.3:
We have the following in Http10Interceptor.java:

+++
public Object getAttribute(String name) {
if (name.equals("javax.servlet.request.X509Certificate")) {
return(certcompat.getX509Certificates(socket));
}
return(super.getAttribute(name));
}
+++

A note stored via request.setNote("SSLSupport",SSLSupport) somewhere in
retrieved by getNote.
The code ends to be:
+++
public Object getAttribute(String name) {
if (name.equals("javax.servlet.request.X509Certificate")) {
SSLSupport sslsupport = getNote("SSLSupport");
if (sslsupport==null)
  return(null);
return(sslsupport.getX509Certificates(socket));
}
return(super.getAttribute(name));
}
+++
Ideas?

> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[costinm]

On 14 Nov 2001, Eric Rescorla wrote:

> Well, I suppose that since JDK 1.1.x didn't stop you from putting
> classes in java. I could do my own version of
> java.security.cert.X509Certificate. A little gross but perhaps
> the best plan. The alternative is to blatantly violate the spec
> in 1.1 and just deliver something else.

I would say - don't worry about JDK1.1. Support for JDK1.1 is important
for embeded devices ( but even there, GCJ does have X509Certificate - it
already supports a large subset of JDK1.2, and that's included ).


> > > > You have to use request.getAttribute() in the JSPs/servlets.
> > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > interface. Instead we could break out each individual property
> > > we cared about into it's own attribute.
> >
> > To be consistant with 2.3 containers, I'd go with individually named
> > attributes.

> Fine with me. Anyone object to this?

Individual attributes are good, but if possible with lazy evaluation.

The getInfo() callback in BaseInterceptor is supposed to do exactly that -
allow you to lazy-evaluate expensive request fields, so only servlets that
ask for the information will pay for it.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[costinm]

On Wed, 14 Nov 2001, Paul Speed wrote:

>
>
> Eric Rescorla wrote:
> >
> [snip]
> > >
> > > To be consistant with 2.3 containers, I'd go with individually named
> > > attributes.
> > Fine with me. Anyone object to this?
> >
> > -Ekr
>
> I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
> was the former, but all of the servlet 2.3 comments recently make
> me now think it's the latter.

My understanding is that it'll eventually be both. Even for 3.x, anything
we implement must take into consideration the clarifications in 2.3.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[costinm]

On Thu, 15 Nov 2001, jean-frederic clere wrote:

> > > Yes, but the question is what does it costs to setAttribute each time we process
> > > a request even if the servlet does not do a getAttribute.
>
> > Yes, this is a good point. This suggests that we ought to just
> > expose SSLSupport as a single attribute because it will be faster.
> > Is that what you're saying?
>
> Yes, but now I am thinking that it only makes sense in mod_webapp (WARP) /mod_jk
> (Ajp14)  where the SSL informations are requested in a separate dialog step
> between httpd and TC.

I think it makes sense for the other cases as well, since the evaluation (
construction of Cert, etc ) can be done only if needed ( i.e. lazy ).

For Ajp14 you'll get an extra benefit if you don't even send it unless
needed.

On the other side, I'm not sure exposing SSLSupport as a req. attribute
is very easy - we must thing about security. If SSLSupport will be recycled,
which it should, then untrusted servlets should not be able to get a
reference to it, otherwise they can hang on the reference and access
informations on other webapps. And I see no need to have it visible to
servlets.

It can be stored as a private attribute ( note in 3.3 ), and that will
also make the access faster.

BTW, regarding JDK1.1 compatibility - I assume most of it will be done as
a module ( you should have all the hooks you need ), and modules don't
have to be 1.1 compatible. The only requirement is that people should be
able to build and run a basic functional container using JDK1.1 - and we
already have this.


Costin






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[jean-frederic clere]

Eric Rescorla wrote:
> 
> > Eric Rescorla wrote:
> > > jean-frederic clere <[EMAIL PROTECTED]> writes:
> > > > Eric Rescorla wrote:
> > > > With JDK 1.1.x and AJP a null is returned.
> > > > With JDK 1.1.x should the CC be returned as a String? (I thought it was).
> > > It's certainly not in the JSSE code I was porting. That code
> > > didn't even compile without JDK 1.2.x.
> >
> > You are right but Ajp does not need JSSE (See Ajp13.java).
> Correct. Currently it tries to convert it to a certificate but
> uses a string if it can't find JSSE. We could easily arrange
> that it did something cleverer than this.
> 
> > > from build.xml:
> > >> >unless="jdk12.present"/>
> > >
> > > In any case, we can do something far more sophisticated than a String
> > > if we want to, even with JDK 1.1.x.
> >
> > It was a String in the past.
> Right, but that's not exactly the most convenient interface.
> 
> > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > interface. Instead we could break out each individual property
> > > we cared about into it's own attribute.
> >
> > Yes, but the question is what does it costs to setAttribute each time we process
> > a request even if the servlet does not do a getAttribute.
> Yes, this is a good point. This suggests that we ought to just
> expose SSLSupport as a single attribute because it will be faster.
> Is that what you're saying?

Yes, but now I am thinking that it only makes sense in mod_webapp (WARP) /mod_jk
(Ajp14)  where the SSL informations are requested in a separate dialog step
between httpd and TC. 

> 
> It's actually easier for me to just expose SSLSupport but I want
> to do whatever's most appropriate and that's why I sought people's
> comments. The reason I wonder if we should set attributes is that
> that's what Ajp currently does.
> 
> > Another question is what about "javax.servlet.request.ssl_session" in PureSSL?
> > Could we get it? (That is the  SSL_SESSION_ID of mod_ssl).
> I'll have to modify PureTLS to expose it but it's not inherently
> difficult. Again, we'd want to add this to SSLSupport, I imagine.

Yes 

> 
> -Ekr

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[jean-frederic clere]

Bill Barker wrote:
> 
> This is for TC 3.3.  As a result, we are only required to expose the
> certificates. However, there is nothing that prevents exposing other request
> attributes as a non-portable feature (and Ajp13 & JNI already do this).

For TC 3.3:
I would advice to follow 2.3 when JVM1.2.x/1.3.x/1.4.x and a String when
JVM1.1.x because there are a lot of old examples where the CC is delivered as a
String...

For TC 4.x:
We have to follow the 2.3 spec's.

> 
> However, it's also likely to be adopted in j-t-c which supports both 3.3 and
> 4.x.
> - Original Message -
> From: "Paul Speed" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, November 14, 2001 11:39 AM
> Subject: Re: Portable SSL Support
> 
> >
> >
> > Eric Rescorla wrote:
> > >
> > [snip]
> > > >
> > > > To be consistant with 2.3 containers, I'd go with individually named
> > > > attributes.
> > > Fine with me. Anyone object to this?
> > >
> > > -Ekr
> >
> > I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
> > was the former, but all of the servlet 2.3 comments recently make
> > me now think it's the latter.
> > -Paul
> >
> > --
> > 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]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Portable SSL Support

[Bill Barker]

This is for TC 3.3.  As a result, we are only required to expose the
certificates. However, there is nothing that prevents exposing other request
attributes as a non-portable feature (and Ajp13 & JNI already do this).

However, it's also likely to be adopted in j-t-c which supports both 3.3 and
4.x.
- Original Message -
From: "Paul Speed" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 11:39 AM
Subject: Re: Portable SSL Support


>
>
> Eric Rescorla wrote:
> >
> [snip]
> > >
> > > To be consistant with 2.3 containers, I'd go with individually named
> > > attributes.
> > Fine with me. Anyone object to this?
> >
> > -Ekr
>
> I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
> was the former, but all of the servlet 2.3 comments recently make
> me now think it's the latter.
> -Paul
>
> --
> 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]>

Re: Portable SSL Support

[Bill Barker]

Actually, the spec only mandates X509Certificate if Tomcat is running under
Java 2.  Otherwise:

For a servlet container that is not running in a Java2 Standard Edition 1.2
environment, vendors
may provide vendor specific request attributes to access SSL certificate
information.

- Original Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 11:23 AM
Subject: Re: Portable SSL Support


> "William Barker" <[EMAIL PROTECTED]> writes:
> > > jean-frederic clere <[EMAIL PROTECTED]> writes:
> > > > Eric Rescorla wrote:
> > > > > A few issues remain:
> > > > > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the
> > > > > existing JSSE code and my new code rely upon java.security.cert.*
> > > > > which was introduced in JDK 1.2. Both JSSE and PureTLS provide
more or
> > > > > less complete (less in the case of JSSE) certificate interfaces
but
> > > > > they're of course different and we need a common interface
presented
> > > > > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
> > > > > abstraction layer, which can't inherit from java.security.cert
because
> > > > > that didn't exist in 1.1. This isn't a problem (Simple Matter of
> > > > > Programming) but is only worth doing if necessary.
> > > >
> > > > With JDK 1.1.x and AJP a null is returned.
> > > > With JDK 1.1.x should the CC be returned as a String? (I thought it
> > was).
> > > It's certainly not in the JSSE code I was porting. That code
> > > didn't even compile without JDK 1.2.x.
> > >
> > > from build.xml:
> > >> >unless="jdk12.present"/>
> > >
> > > In any case, we can do something far more sophisticated than a String
> > > if we want to, even with JDK 1.1.x.
> >
> > If it wasn't mandated to be a java.security.cert.X509Certificate [] by
> > section 5.7 of the servlet spec :).
> Well, I suppose that since JDK 1.1.x didn't stop you from putting
> classes in java. I could do my own version of
> java.security.cert.X509Certificate. A little gross but perhaps
> the best plan. The alternative is to blatantly violate the spec
> in 1.1 and just deliver something else.
>
> > > > You have to use request.getAttribute() in the JSPs/servlets.
> > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > interface. Instead we could break out each individual property
> > > we cared about into it's own attribute.
> >
> > To be consistant with 2.3 containers, I'd go with individually named
> > attributes.
> Fine with me. Anyone object to this?
>
> -Ekr
>
> --
> 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]>

Re: Portable SSL Support

[Paul Speed]

Eric Rescorla wrote:
> 
[snip]
> >
> > To be consistant with 2.3 containers, I'd go with individually named
> > attributes.
> Fine with me. Anyone object to this?
> 
> -Ekr

I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
was the former, but all of the servlet 2.3 comments recently make
me now think it's the latter.
-Paul

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[Eric Rescorla]

"William Barker" <[EMAIL PROTECTED]> writes:
> > jean-frederic clere <[EMAIL PROTECTED]> writes:
> > > Eric Rescorla wrote:
> > > > A few issues remain:
> > > > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the
> > > > existing JSSE code and my new code rely upon java.security.cert.*
> > > > which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or
> > > > less complete (less in the case of JSSE) certificate interfaces but
> > > > they're of course different and we need a common interface presented
> > > > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
> > > > abstraction layer, which can't inherit from java.security.cert because
> > > > that didn't exist in 1.1. This isn't a problem (Simple Matter of
> > > > Programming) but is only worth doing if necessary.
> > >
> > > With JDK 1.1.x and AJP a null is returned.
> > > With JDK 1.1.x should the CC be returned as a String? (I thought it
> was).
> > It's certainly not in the JSSE code I was porting. That code
> > didn't even compile without JDK 1.2.x.
> >
> > from build.xml:
> >>unless="jdk12.present"/>
> >
> > In any case, we can do something far more sophisticated than a String
> > if we want to, even with JDK 1.1.x.
> 
> If it wasn't mandated to be a java.security.cert.X509Certificate [] by
> section 5.7 of the servlet spec :).
Well, I suppose that since JDK 1.1.x didn't stop you from putting
classes in java. I could do my own version of 
java.security.cert.X509Certificate. A little gross but perhaps
the best plan. The alternative is to blatantly violate the spec
in 1.1 and just deliver something else.

> > > You have to use request.getAttribute() in the JSPs/servlets.
> > Right, but that doesn't mean that we have to expose the SSLSupport
> > interface. Instead we could break out each individual property
> > we cared about into it's own attribute.
> 
> To be consistant with 2.3 containers, I'd go with individually named
> attributes.
Fine with me. Anyone object to this?

-Ekr

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[William Barker]

- Original Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 9:17 AM
Subject: Re: Portable SSL Support


> jean-frederic clere <[EMAIL PROTECTED]> writes:
> > Eric Rescorla wrote:
> > > A few issues remain:
> > > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the
> > > existing JSSE code and my new code rely upon java.security.cert.*
> > > which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or
> > > less complete (less in the case of JSSE) certificate interfaces but
> > > they're of course different and we need a common interface presented
> > > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
> > > abstraction layer, which can't inherit from java.security.cert because
> > > that didn't exist in 1.1. This isn't a problem (Simple Matter of
> > > Programming) but is only worth doing if necessary.
> >
> > With JDK 1.1.x and AJP a null is returned.
> > With JDK 1.1.x should the CC be returned as a String? (I thought it
was).
> It's certainly not in the JSSE code I was porting. That code
> didn't even compile without JDK 1.2.x.
>
> from build.xml:
>   unless="jdk12.present"/>
>
> In any case, we can do something far more sophisticated than a String
> if we want to, even with JDK 1.1.x.

If it wasn't mandated to be a java.security.cert.X509Certificate [] by
section 5.7 of the servlet spec :).

>
> > > (II) How to expose SSLSupport? Currently Request has access to
> > > SSLSupport but it's not obvious (at least to me) how best to
> > > expose this to the rest of Tomcat and to JSPs/servlets.
> >
> > You have to use request.getAttribute() in the JSPs/servlets.
> Right, but that doesn't mean that we have to expose the SSLSupport
> interface. Instead we could break out each individual property
> we cared about into it's own attribute.

To be consistant with 2.3 containers, I'd go with individually named
attributes.  That is what the application programmer will be expecting.  As
an example (from the 2.3 spec)

Table 3: Protocol Attributes
Attribute   Attribute Name
Java Type
cipher suite
javax.servlet.request.cipher_suite  String
bit size of the algo-rithmjavax.servlet.request.key_size
Integer

If there is an SSL certificate associated with the request, it must be
exposed by
the servlet container to the servlet programmer as an array of objects of
type
java.security.cert.X509Certificate and accessible via a ServletRequest
attribute of javax.servlet.request.X509Certificate.

> -Ekr
>
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
>
> --
> 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]>

Re: Portable SSL Support

[Eric Rescorla]

jean-frederic clere <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
> > A few issues remain:
> > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the
> > existing JSSE code and my new code rely upon java.security.cert.*
> > which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or
> > less complete (less in the case of JSSE) certificate interfaces but
> > they're of course different and we need a common interface presented
> > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
> > abstraction layer, which can't inherit from java.security.cert because
> > that didn't exist in 1.1. This isn't a problem (Simple Matter of
> > Programming) but is only worth doing if necessary.
> 
> With JDK 1.1.x and AJP a null is returned.
> With JDK 1.1.x should the CC be returned as a String? (I thought it was).
It's certainly not in the JSSE code I was porting. That code
didn't even compile without JDK 1.2.x.

from build.xml:
  

In any case, we can do something far more sophisticated than a String
if we want to, even with JDK 1.1.x.

> > (II) How to expose SSLSupport? Currently Request has access to
> > SSLSupport but it's not obvious (at least to me) how best to
> > expose this to the rest of Tomcat and to JSPs/servlets.
> 
> You have to use request.getAttribute() in the JSPs/servlets.
Right, but that doesn't mean that we have to expose the SSLSupport
interface. Instead we could break out each individual property
we cared about into it's own attribute.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[jean-frederic clere]

Eric Rescorla wrote:
> 
> "William Barker" <[EMAIL PROTECTED]> writes:
> > If you decide on 2a, like Costin, I'd prefer it as a property of the
> > SocketFactory (the base class can return null, since Ajp1x would use it's
> > own mechanism) rather than an interface.  However, it's your call.
> 
> I ended up doing more or less what I proposed in my previous
> message. The master specification class is an SSLImplementation which
> contains methods allowing you to acquire ServerSocketFactories and
> SSLSupport objects. SSLImplementation knows how to automatically
> select whatever implementation is present (from the compiled in
> list) or you can provide an SSLImplementation property in the
> config file. This works fine.
> 
> A few issues remain:
> (I) Is portability to JDK 1.1.x desirable/a requirement? Both the
> existing JSSE code and my new code rely upon java.security.cert.*
> which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or
> less complete (less in the case of JSSE) certificate interfaces but
> they're of course different and we need a common interface presented
> to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
> abstraction layer, which can't inherit from java.security.cert because
> that didn't exist in 1.1. This isn't a problem (Simple Matter of
> Programming) but is only worth doing if necessary.

With JDK 1.1.x and AJP a null is returned.
With JDK 1.1.x should the CC be returned as a String? (I thought it was).

> 
> (II) How to expose SSLSupport? Currently Request has access to
> SSLSupport but it's not obvious (at least to me) how best to
> expose this to the rest of Tomcat and to JSPs/servlets.

You have to use request.getAttribute() in the JSPs/servlets.

> 
> The obvious choices are:
> (1) Simply provide a way to access the SSLSupport object
> (presumably via an attribute).
> 
> (2) Break out what we believe the relevant information
> in SSLSupport is (i.e. ciphersuites, cert chain, etc)
> and store that as individual attributes.
> 
> >From a cursory scan of the code it's not clear to me what would
> be most consistent with traditional practice. Do people have
> opinions?
> 
> -Ekr
> 
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> Author of "SSL and TLS: Designing and Building Secure Systems"
>   http://www.rtfm.com/
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[Eric Rescorla]

"William Barker" <[EMAIL PROTECTED]> writes:
> If you decide on 2a, like Costin, I'd prefer it as a property of the
> SocketFactory (the base class can return null, since Ajp1x would use it's
> own mechanism) rather than an interface.  However, it's your call.

I ended up doing more or less what I proposed in my previous
message. The master specification class is an SSLImplementation which
contains methods allowing you to acquire ServerSocketFactories and
SSLSupport objects. SSLImplementation knows how to automatically
select whatever implementation is present (from the compiled in
list) or you can provide an SSLImplementation property in the
config file. This works fine.

A few issues remain:
(I) Is portability to JDK 1.1.x desirable/a requirement? Both the
existing JSSE code and my new code rely upon java.security.cert.*
which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or
less complete (less in the case of JSSE) certificate interfaces but
they're of course different and we need a common interface presented
to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
abstraction layer, which can't inherit from java.security.cert because
that didn't exist in 1.1. This isn't a problem (Simple Matter of 
Programming) but is only worth doing if necessary.

(II) How to expose SSLSupport? Currently Request has access to 
SSLSupport but it's not obvious (at least to me) how best to
expose this to the rest of Tomcat and to JSPs/servlets. 

The obvious choices are:
(1) Simply provide a way to access the SSLSupport object
(presumably via an attribute).

(2) Break out what we believe the relevant information
in SSLSupport is (i.e. ciphersuites, cert chain, etc)
and store that as individual attributes.

>From a cursory scan of the code it's not clear to me what would
be most consistent with traditional practice. Do people have 
opinions?

-Ekr

--
[Eric Rescorla   [EMAIL PROTECTED]]
Author of "SSL and TLS: Designing and Building Secure Systems"
  http://www.rtfm.com/
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[Eric Rescorla]

jean-frederic clere <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
> > <[EMAIL PROTECTED]> writes:
> > > One simple workaround could be to abstract acceptSocket() too ( i.e. make
> > > it a method in ServerSocketFactory or SSLSupport).
> > Yes, we could do that. It's a little ugly but it avoids having a wrapper
> > class around ServerSocket so I suppose it's worthwhile.
> 
> Does implAccept play something there?
I don't think so. The problem is that we're using the native
ServerSocket of the SSL implementation so we need to wrap that
call.

-Ekr



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[jean-frederic clere]

Eric Rescorla wrote:
> 
> <[EMAIL PROTECTED]> writes:
> > Setting the socketFactory can force one behavior or another, but for
> > 'regular' users it should be possible to just set secure and the code
> > to detect what is available and use it.
> I can do this.
> 
> > > IMHO it's a mistake to rely on that behavior since it's kind of a
> > > misfeature in JSSE and this is already a problem with PureTLS, which
> > > does throw exceptions when the handshake fails. In the future Either
> > > PoolTcpEndpoint will have to be more forgiving or we'll need to wrap
> > > the socket so that it throws SocketException (which acceptSocket
> > > handles more cleanly).
> >
> > One simple workaround could be to abstract acceptSocket() too ( i.e. make
> > it a method in ServerSocketFactory or SSLSupport).
> Yes, we could do that. It's a little ugly but it avoids having a wrapper
> class around ServerSocket so I suppose it's worthwhile.

Does implAccept play something there?

> 
> > A don't like this either ( and I didn't like too much the idea
> > of returning a socket that implements SSLSupport either ).
> >
> > What I would do is:
> >
> > SSLSupport {
> >String getFoo( Object socket, ... );
> >
> > }
> This makes me very nervous since the first thing you have to do is
> a downcast. I hate downcasts. (Except when I love them :)
> 
> > - PoolTcpConnector will just have a method 'setSSLSupport'
> > - SSLSupport will be an abstract class, and will contain code to do
> > reflection and create the exact implementation
> > - Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
> > setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
> > used), etc.
> > - SSLSupport should be independent of tomcat ( you may noticed that
> > tomcat.util is compiled without any other tomcat class in classpath,
> > i.e. it can't have any dependencies on any internal tomcat class ! )
> Hmm... This seems like a kind of confusing merging of internal and
> external interfaces. (The internal ones being the ones required to
> create the socket factories and the external ones being those required to
> manipulate the SSL data.)
> 
> I'm (more than) happy to replace SSLFactory at the external interface but
> I don't like merging SSLSupport into the external class. So, using
> another layer of abstraction.
> 
> interface SSLSupport {
>  public String getCipherSuite();
>  ...
> }
> 
> abstract class SSLImplementation {
> static getInstance(); // Automatically picks out whatever there is
> static getInstance(String classname); // gets a specific instance
> 
> SocketFactory getSocketFactory();
> SSLSupport getSSLSupport(Socket sock);
> }
> 
> class JSSEImplementation extends SSLImplementation {
>...
> }
> 
> class PureTLSImplementation extends SSLImplementation {
> ...
> }
> 
> In general I'd expect SSLSupport to be implemented as a wrapper class.
> E.g. a prototype PureTLSSSLSupport would be:
> 
> class PureTLSSSLSupport implements SSLSupport {
> SSLSocket ssl;
> 
> PureTLSSSLSupport(SSLSocket s){
>   ssl=s;
> }
> 
> public string getCipherSuite() {
>   int cipherSuite=ssl.getCipherSuite();
> 
>   return SSLPolicyInt.getCipherSuiteame(cipherSuite);
> }
> 
> ...
> }
> 
> Then the user can either do "secure" or "secure" and "SSLImplementation=blah".
> 
> > BTW, my personal preference is to avoid too many interfaces - in general I
> > prefer abstract classes if it is possible.
> I have some of the same taste as well, but I want to use an interface for
> SSLSupport to allow the possibility of not having wrapper classes
> in some situations.
> 
> That said, having lots of interfaces does seem to be the Java way, no?
> (Worse yet, I've been switching back and forth between Java and C++ so
> I suffer from idiom inertia.)
> 
> -Ekr
> 
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[William Barker]

I was originally leaning towards 2a, but Costin has convinced me of the
merits of 2b+1.  It is simplest and more generalizable to Ajp14/JNI in
j-t-c.  It also allows you to skip implementing the pooling/recycling stuff
(since it should be possible to reuse one instance per connector).

If you decide on 2a, like Costin, I'd prefer it as a property of the
SocketFactory (the base class can return null, since Ajp1x would use it's
own mechanism) rather than an interface.  However, it's your call.
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 8:52 AM
Subject: Re: Portable SSL Support
>
> > 3. Originally I'd intended to have ServerSockets return a class
> > that subclassed SSLSupport. E.g.
> >
> > class PureTLSSSLSocket extends SSLSocket implements SSLSupport {
> >...
> > }
> >
> > Unfortunately, as I should have seen immediately this isn't very
> > convenient. There's no way to make JSSE return a programmer-specified
> > subclass of SSLSocket instead of SSLSocket. I can of course make
> > PureTLS do so but that ties it inappropriately to Tomcat.
>
>
> > This leaves us with two alternatives:
> > (1) Create a wrapper class for SSLSocket:
> >
> > class SSLSocketWrapper extends Socket implements SSLSupport {
> >   Socket internal;
> >
> >   SSLSocketWrapper(Socket sock) {
> > internal=sock;
> >   }
> >
> >   // Forwarding for all the relevant socket methods
> > }
> >
> > In general I hate class forwarding so I'm strongly tempted not to
> > do this.
>
> A don't like this either ( and I didn't like too much the idea
> of returning a socket that implements SSLSupport either ).
>
> What I would do is:
>
> SSLSupport {
>String getFoo( Object socket, ... );
>
> }
>
> In other words, you pass the socket from which the SSLSupport object will
> extract the information. ( it doens't have to be a socket - it can also be
> an Ajp14Connection ). I think this is quite flexible and doesn't have too
> much overhead
>
> ( but it's your choice, of course - you are writing the code :-)
>
>
> > (2) Extend/generalize the socketFactory to include an SSLSupport
> > factory. This is actually pretty convenient since the relevant
> > section of code, Http10Interceptor already has access to
> > the socketFactory information via inheritance from
> > PoolTcpConnector. This could be done in several ways
> >
> > (a) Require that all SocketFactorys that produce SSL sockets implement
> >
> > interface SSLSupportFactory {
> > public SSLSupport createSSLSupport(Socket socket);
> > }
>
> That's fine too. For Ajp connectors we could have a different mechansim to
> create the SSLSupport.
>
>
> > (b) Have a second factory object in PoolTcpConnector and use reflection
> > to look it up. I don't much like this idea because it implies that
> > you can mix and match SocketFactories with SSLSupport classes
> > which of course you cannot.
>
> Well, I like this idea - combined with the first one ( reversed ) :-)
>
> I.e:
> - SSLSupport act as a factory for SSLSocketFactories
> - user will set only the SSLSupport class, which will create the socket
> factory
> - PoolTcpConnector will just have a method 'setSSLSupport'
> - SSLSupport will be an abstract class, and will contain code to do
> reflection and create the exact implementation
> - Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
> setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
> used), etc.
> - SSLSupport should be independent of tomcat ( you may noticed that
> tomcat.util is compiled without any other tomcat class in classpath,
> i.e. it can't have any dependencies on any internal tomcat class ! )
>
>
> BTW, my personal preference is to avoid too many interfaces - in general I
> prefer abstract classes if it is possible. At least until it becomes clear
> we need a certain abstraction, otherwise we end up with something too
> complex. For most people ( other than the author ) it is hard to
> 'navigate' around dozens of interfaces and base classes and hierarchies (
> at least it is for me )
>
> Costin
>
>
>
>
> --
> 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 informati

Re: Portable SSL Support

[Eric Rescorla]

<[EMAIL PROTECTED]> writes:
> Setting the socketFactory can force one behavior or another, but for
> 'regular' users it should be possible to just set secure and the code
> to detect what is available and use it.
I can do this.

> > IMHO it's a mistake to rely on that behavior since it's kind of a
> > misfeature in JSSE and this is already a problem with PureTLS, which
> > does throw exceptions when the handshake fails. In the future Either
> > PoolTcpEndpoint will have to be more forgiving or we'll need to wrap
> > the socket so that it throws SocketException (which acceptSocket
> > handles more cleanly).
> 
> One simple workaround could be to abstract acceptSocket() too ( i.e. make
> it a method in ServerSocketFactory or SSLSupport).
Yes, we could do that. It's a little ugly but it avoids having a wrapper
class around ServerSocket so I suppose it's worthwhile.

> A don't like this either ( and I didn't like too much the idea
> of returning a socket that implements SSLSupport either ).
> 
> What I would do is:
> 
> SSLSupport {
>String getFoo( Object socket, ... );
> 
> }
This makes me very nervous since the first thing you have to do is
a downcast. I hate downcasts. (Except when I love them :)

> - PoolTcpConnector will just have a method 'setSSLSupport'
> - SSLSupport will be an abstract class, and will contain code to do
> reflection and create the exact implementation
> - Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
> setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
> used), etc.
> - SSLSupport should be independent of tomcat ( you may noticed that
> tomcat.util is compiled without any other tomcat class in classpath,
> i.e. it can't have any dependencies on any internal tomcat class ! )
Hmm... This seems like a kind of confusing merging of internal and
external interfaces. (The internal ones being the ones required to
create the socket factories and the external ones being those required to
manipulate the SSL data.)

I'm (more than) happy to replace SSLFactory at the external interface but 
I don't like merging SSLSupport into the external class. So, using
another layer of abstraction.

interface SSLSupport {
 public String getCipherSuite();
 ... 
}

abstract class SSLImplementation {
static getInstance(); // Automatically picks out whatever there is
static getInstance(String classname); // gets a specific instance

SocketFactory getSocketFactory();
SSLSupport getSSLSupport(Socket sock);
}

class JSSEImplementation extends SSLImplementation {
   ...
}


class PureTLSImplementation extends SSLImplementation {
...
}

In general I'd expect SSLSupport to be implemented as a wrapper class.
E.g. a prototype PureTLSSSLSupport would be:

class PureTLSSSLSupport implements SSLSupport {
SSLSocket ssl;

PureTLSSSLSupport(SSLSocket s){
  ssl=s;
}

public string getCipherSuite() {
  int cipherSuite=ssl.getCipherSuite();
  
  return SSLPolicyInt.getCipherSuiteame(cipherSuite);
}

...
}

Then the user can either do "secure" or "secure" and "SSLImplementation=blah".

> BTW, my personal preference is to avoid too many interfaces - in general I
> prefer abstract classes if it is possible.
I have some of the same taste as well, but I want to use an interface for
SSLSupport to allow the possibility of not having wrapper classes
in some situations. 

That said, having lots of interfaces does seem to be the Java way, no?
(Worse yet, I've been switching back and forth between Java and C++ so
I suffer from idiom inertia.)

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[costinm]

On Mon, 12 Nov 2001, Eric Rescorla wrote:

> 1. I don't see how to make the switch-hit via a configuration file in
> 3.3.  If you set the "secure" variable for your virtual server,
> PoolTCPConnector tries to load the class named in socketFactoryName,
> or, if null, the class named in SSL_FACT (currently JSSE).  I've spent
> some time looking through the code and I don't see anything that
> would cause it to be set. Setting socketFactory in server.xml doesn't
> work. Have I missed something obvious or is this currently broken?

'secure' is a 'convenience' setting, so users don't have to type the full
name of the socket factory.

IMHO you should check if secure is true and do a class.forName() to find
if JSSE is present, same for pureTLS.

Setting the socketFactory can force one behavior or another, but for
'regular' users it should be possible to just set secure and the code
to detect what is available and use it.


> 2. Both JSSE and PureTLS derive almost all of their exceptions from
> IOException. If a server socket throws an IOException in accept() it
> will cause PoolTcpEndpoint.acceptSocket() to destroy the
> endpoint. This appears to be currently safe with JSSE because JSSE
> doesn't throw an exception when a handshake fails but instead returns
> a socket which throws an IOException when used.
>
> IMHO it's a mistake to rely on that behavior since it's kind of a
> misfeature in JSSE and this is already a problem with PureTLS, which
> does throw exceptions when the handshake fails. In the future Either
> PoolTcpEndpoint will have to be more forgiving or we'll need to wrap
> the socket so that it throws SocketException (which acceptSocket
> handles more cleanly).

One simple workaround could be to abstract acceptSocket() too ( i.e. make
it a method in ServerSocketFactory or SSLSupport).


> 3. Originally I'd intended to have ServerSockets return a class
> that subclassed SSLSupport. E.g.
>
>   class PureTLSSSLSocket extends SSLSocket implements SSLSupport {
>  ...
>   }
>
> Unfortunately, as I should have seen immediately this isn't very
> convenient. There's no way to make JSSE return a programmer-specified
> subclass of SSLSocket instead of SSLSocket. I can of course make
> PureTLS do so but that ties it inappropriately to Tomcat.


> This leaves us with two alternatives:
> (1) Create a wrapper class for SSLSocket:
>
>   class SSLSocketWrapper extends Socket implements SSLSupport {
> Socket internal;
>
> SSLSocketWrapper(Socket sock) {
>   internal=sock;
> }
>
> // Forwarding for all the relevant socket methods
>   }
>
> In general I hate class forwarding so I'm strongly tempted not to
> do this.

A don't like this either ( and I didn't like too much the idea
of returning a socket that implements SSLSupport either ).

What I would do is:

SSLSupport {
   String getFoo( Object socket, ... );

}

In other words, you pass the socket from which the SSLSupport object will
extract the information. ( it doens't have to be a socket - it can also be
an Ajp14Connection ). I think this is quite flexible and doesn't have too
much overhead

( but it's your choice, of course - you are writing the code :-)


> (2) Extend/generalize the socketFactory to include an SSLSupport
> factory. This is actually pretty convenient since the relevant
> section of code, Http10Interceptor already has access to
> the socketFactory information via inheritance from
> PoolTcpConnector. This could be done in several ways
>
> (a) Require that all SocketFactorys that produce SSL sockets implement
>
> interface SSLSupportFactory {
>   public SSLSupport createSSLSupport(Socket socket);
> }

That's fine too. For Ajp connectors we could have a different mechansim to
create the SSLSupport.


> (b) Have a second factory object in PoolTcpConnector and use reflection
> to look it up. I don't much like this idea because it implies that
> you can mix and match SocketFactories with SSLSupport classes
> which of course you cannot.

Well, I like this idea - combined with the first one ( reversed ) :-)

I.e:
- SSLSupport act as a factory for SSLSocketFactories
- user will set only the SSLSupport class, which will create the socket
factory
- PoolTcpConnector will just have a method 'setSSLSupport'
- SSLSupport will be an abstract class, and will contain code to do
reflection and create the exact implementation
- Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
used), etc.
- SSLSupport should be independent of tomcat ( you may noticed that
tomcat.util is compiled without any other tomcat class in classpath,
i.e. it can't have any dependencies on any internal tomcat class ! )


BTW, my personal preference is to avoid too many interfaces - in general I
prefer abstract classes if it is possible. At least until it becomes clear
we need a certain abstr

Re: Portable SSL Support

[Eric Rescorla]

jean-frederic clere <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> > 
> > As discussed on the list previously, I'm working on changing the SSL
> > interfaces in Tomcat to make them more portable to various SSL
> > toolkits, in particular PureTLS. In the process I've run into some
> > issues that I wanted to run by the list.
> > 
> > 1. I don't see how to make the switch-hit via a configuration file in
> > 3.3.  If you set the "secure" variable for your virtual server,
> > PoolTCPConnector tries to load the class named in socketFactoryName,
> > or, if null, the class named in SSL_FACT (currently JSSE).  I've spent
> > some time looking through the code and I don't see anything that
> > would cause it to be set. Setting socketFactory in server.xml doesn't
> > work. Have I missed something obvious or is this currently broken?
> 
> It works for me:
> +++
> secure="false"
>maxThreads="100"
>maxSpareThreads="50"
>minSpareThreads="10"
>SocketFactory="toto" />
> +++
> And I got java.lang.ClassNotFoundException: toto as excepted.
Doh! I used "socketFactory". SocketFactory works for me as well.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[jean-frederic clere]

Eric Rescorla wrote:
> 
> As discussed on the list previously, I'm working on changing the SSL
> interfaces in Tomcat to make them more portable to various SSL
> toolkits, in particular PureTLS. In the process I've run into some
> issues that I wanted to run by the list.
> 
> 1. I don't see how to make the switch-hit via a configuration file in
> 3.3.  If you set the "secure" variable for your virtual server,
> PoolTCPConnector tries to load the class named in socketFactoryName,
> or, if null, the class named in SSL_FACT (currently JSSE).  I've spent
> some time looking through the code and I don't see anything that
> would cause it to be set. Setting socketFactory in server.xml doesn't
> work. Have I missed something obvious or is this currently broken?

It works for me:
+++

+++
And I got java.lang.ClassNotFoundException: toto as excepted.


> 
> 2. Both JSSE and PureTLS derive almost all of their exceptions from
> IOException. If a server socket throws an IOException in accept() it
> will cause PoolTcpEndpoint.acceptSocket() to destroy the
> endpoint. This appears to be currently safe with JSSE because JSSE
> doesn't throw an exception when a handshake fails but instead returns
> a socket which throws an IOException when used.
> 
> IMHO it's a mistake to rely on that behavior since it's kind of a
> misfeature in JSSE and this is already a problem with PureTLS, which
> does throw exceptions when the handshake fails. In the future Either
> PoolTcpEndpoint will have to be more forgiving or we'll need to wrap
> the socket so that it throws SocketException (which acceptSocket
> handles more cleanly).
> 
> 3. Originally I'd intended to have ServerSockets return a class
> that subclassed SSLSupport. E.g.
> 
> class PureTLSSSLSocket extends SSLSocket implements SSLSupport {
>...
> }
> 
> Unfortunately, as I should have seen immediately this isn't very
> convenient. There's no way to make JSSE return a programmer-specified
> subclass of SSLSocket instead of SSLSocket. I can of course make
> PureTLS do so but that ties it inappropriately to Tomcat.
> 
> This leaves us with two alternatives:
> (1) Create a wrapper class for SSLSocket:
> 
> class SSLSocketWrapper extends Socket implements SSLSupport {
>   Socket internal;
> 
>   SSLSocketWrapper(Socket sock) {
> internal=sock;
>   }
> 
>   // Forwarding for all the relevant socket methods
> }
> 
> In general I hate class forwarding so I'm strongly tempted not to
> do this.
> 
> (2) Extend/generalize the socketFactory to include an SSLSupport
> factory. This is actually pretty convenient since the relevant
> section of code, Http10Interceptor already has access to
> the socketFactory information via inheritance from
> PoolTcpConnector. This could be done in several ways
> 
> (a) Require that all SocketFactorys that produce SSL sockets implement
> 
> interface SSLSupportFactory {
> public SSLSupport createSSLSupport(Socket socket);
> }
> 
> Then Http10Interceptor could do:
> if(secure) {
>SSLSupport sslSupport=((SSLSupportFactory)socketFactory)->
>  createSSLSupport(socket);
> 
>// Add the SSLSupport as a not
> }
> 
> (b) Have a second factory object in PoolTcpConnector and use reflection
> to look it up. I don't much like this idea because it implies that
> you can mix and match SocketFactories with SSLSupport classes
> which of course you cannot.
> 
> I'd like to hear comments about this stuff. :)
> 
> -Ekr
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: