You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jan Luehe <Ja...@Sun.COM> on 2003/06/05 21:05:28 UTC
Re: cvs
commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java
Http11Protocol.java
Remy/Bill,
> Ouch, that's one nasty hack.
> -1, please revert it.
>
> There are callbacks to the processor to evaluate the SSL related
> attributes. If something is broken, this should be fixed, but using that
> pattern. I believe get/setSocket are useless, and the calls should be
> entierely removed.
I noticed the ActionHook calls to get SSL related attributes, however,
CertificatesValve needs the SSLSocket in order to renegotiate an SSL
handshake if the requested resource is from a webapp with this
authentication constraint:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
If the request was received through an SSL-enabled connector that does
not enforce SSL client authentication, the handshake needs to be
reinitiated, with client authentication enforced. In order to do that,
CertificatesValve needs access to the SSLSocket, in order to call its
startHandshake() method.
If the only purpose of CertificatesValve is to support the deprecated
Http11Connector, which component is going to replace it and implement SSL
handshake renegotiation?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re:
cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy,
> > P.S.: I'm also +1 for removing the CertificatesValve, since it is
> > confusing to have several valves essentially doing the same thing.
>
> There's no need to hardcode the authenticator, you only need to add it
> in startup.Authenticators.properties, and it will be added in the
> pipeline as needed. It's already there, BTW, so I don't quite see what's
> going on (but it should be fixed there, no harcoding required).
yes, I understand. The confusing part was that in ContextConfig, we
were adding both the CertificatesValve (in certificatesConfig) and the
Authenticator configured in web-app/login-config/auth-method, where
CertificatesValve and SSLAuthenticator were essentially doing the
same, except that CertificatesValve was operating on the (SSL)Socket
and was always failing on a CoyoteRequest (whose getSocket() always returns
null).
Bill has cleared up this confusion by removing the certificatesConfig() method.
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Bill,
>
>
>>SSLAuthenticator makes a request for a special Request attribute
>>("org.apache.coyote.request.X509Certificate"), which fires off an Action
>>hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
>>
>>I changed TC 5 a little while back to do a lazy-evaluation of the SSL
>>attributes. If you are seeing problems, that might be where.
>
>
> Well, the reason I was still using the (supposedly deprecated)
> CertificatesValve was because it was still being added to the pipeline
> in ContextConfig. I'm going to change ContextConfig as follows:
>
> Index: ContextConfig.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
> retrieving revision 1.25
> diff -u -r1.25 ContextConfig.java
> --- ContextConfig.java 14 May 2003 17:42:55 -0000 1.25
> +++ ContextConfig.java 5 Jun 2003 23:08:13 -0000
> @@ -497,7 +497,7 @@
> Valve certificates = null;
> try {
> Class clazz =
> - Class.forName("org.apache.catalina.valves.CertificatesValve");
> + Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
> certificates = (Valve) clazz.newInstance();
> } catch (Throwable t) {
> return; // Probably JSSE classes not present
>
> Even with this fix in place, the SSLAuthenticator's authenticate() method
> was still not being invoked, because org.apache.catalina.authenticator.AuthenticatorBase
> currently does not consider the CLIENT-CERT authentication constraint at
> all.
>
> After fixing this, the SSL handshake does get renegotiated in the way you
> described, but for some reason the connection then times out. I'm still investigating.
>
> Thanks for putting me on the right track, Bill!
>
> Jan
>
> P.S.: I'm also +1 for removing the CertificatesValve, since it is
> confusing to have several valves essentially doing the same thing.
There's no need to hardcode the authenticator, you only need to add it
in startup.Authenticators.properties, and it will be added in the
pipeline as needed. It's already there, BTW, so I don't quite see what's
going on (but it should be fixed there, no harcoding required).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re:
cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Bill,
> SSLAuthenticator makes a request for a special Request attribute
> ("org.apache.coyote.request.X509Certificate"), which fires off an Action
> hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
>
> I changed TC 5 a little while back to do a lazy-evaluation of the SSL
> attributes. If you are seeing problems, that might be where.
Well, the reason I was still using the (supposedly deprecated)
CertificatesValve was because it was still being added to the pipeline
in ContextConfig. I'm going to change ContextConfig as follows:
Index: ContextConfig.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.25
diff -u -r1.25 ContextConfig.java
--- ContextConfig.java 14 May 2003 17:42:55 -0000 1.25
+++ ContextConfig.java 5 Jun 2003 23:08:13 -0000
@@ -497,7 +497,7 @@
Valve certificates = null;
try {
Class clazz =
- Class.forName("org.apache.catalina.valves.CertificatesValve");
+ Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
certificates = (Valve) clazz.newInstance();
} catch (Throwable t) {
return; // Probably JSSE classes not present
Even with this fix in place, the SSLAuthenticator's authenticate() method
was still not being invoked, because org.apache.catalina.authenticator.AuthenticatorBase
currently does not consider the CLIENT-CERT authentication constraint at
all.
After fixing this, the SSL handshake does get renegotiated in the way you
described, but for some reason the connection then times out. I'm still investigating.
Thanks for putting me on the right track, Bill!
Jan
P.S.: I'm also +1 for removing the CertificatesValve, since it is
confusing to have several valves essentially doing the same thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jan Luehe" <Ja...@Sun.COM>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 05, 2003 12:05 PM
Subject: Re: cvs
commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Htt
p11Processor.java Http11Protocol.java
> Remy/Bill,
>
> > Ouch, that's one nasty hack.
> > -1, please revert it.
> >
> > There are callbacks to the processor to evaluate the SSL related
> > attributes. If something is broken, this should be fixed, but using that
> > pattern. I believe get/setSocket are useless, and the calls should be
> > entierely removed.
>
> I noticed the ActionHook calls to get SSL related attributes, however,
> CertificatesValve needs the SSLSocket in order to renegotiate an SSL
> handshake if the requested resource is from a webapp with this
> authentication constraint:
>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> </login-config>
>
> If the request was received through an SSL-enabled connector that does
> not enforce SSL client authentication, the handshake needs to be
> reinitiated, with client authentication enforced. In order to do that,
> CertificatesValve needs access to the SSLSocket, in order to call its
> startHandshake() method.
>
> If the only purpose of CertificatesValve is to support the deprecated
> Http11Connector, which component is going to replace it and implement SSL
> handshake renegotiation?
>
SSLAuthenticator makes a request for a special Request attribute
("org.apache.coyote.request.X509Certificate"), which fires off an Action
hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
I changed TC 5 a little while back to do a lazy-evaluation of the SSL
attributes. If you are seeing problems, that might be where.
>
> Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java
Http11Protocol.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Remy/Bill,
>
>
>>Ouch, that's one nasty hack.
>>-1, please revert it.
>>
>>There are callbacks to the processor to evaluate the SSL related
>>attributes. If something is broken, this should be fixed, but using that
>>pattern. I believe get/setSocket are useless, and the calls should be
>>entierely removed.
>
>
> I noticed the ActionHook calls to get SSL related attributes, however,
> CertificatesValve needs the SSLSocket in order to renegotiate an SSL
> handshake if the requested resource is from a webapp with this
> authentication constraint:
>
> <login-config>
> <auth-method>CLIENT-CERT</auth-method>
> </login-config>
>
> If the request was received through an SSL-enabled connector that does
> not enforce SSL client authentication, the handshake needs to be
> reinitiated, with client authentication enforced. In order to do that,
> CertificatesValve needs access to the SSLSocket, in order to call its
> startHandshake() method.
>
> If the only purpose of CertificatesValve is to support the deprecated
> Http11Connector, which component is going to replace it and implement SSL
> handshake renegotiation?
Well, first of all, even if there's a bug or some missing feature, or
anything, it's not a valid reason for adding a nasty hack. So please
revert your patch.
It seems pretty clear to me that if you want to really implement that,
you could add an additional callback (aka action), like the other SSL
ones which are already there.
BTW, either there's client cert on the connector, or there isn't, right
? This seems best left to the lower level of the container, rather than
trying to be too smart (and since it will be hard to make it consistent
between JK and HTTP/1.1, I'm close to being -1 for trying to implement
it). And yes, if JK can't be implemented in a compliant way, then I
believe that part of the specification is broken and should be fixed.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org