tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Bug 19867
Date Mon, 11 Aug 2003 23:39:24 GMT

----- Original Message -----
From: "Mark Thomas" <medthomas@ntlworld.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Monday, August 11, 2003 3:23 PM
Subject: RE: Bug 19867


> I have been looking into
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19867
>
> and have a couple of questions.
>
> The error seen in this report is a result of specifying CLIENT-CERT
> authentication without specifying a user-data-constraint. This causes a
NPE
> because the sslSupport attribute of the http11Processor object is null.
>
> I have looked at the servlet spec (2.3 and the draft of 2.4) and, based on
the
> 2.4 draft, the user-data-constraint is not mandatory (end of SRV.12.8) and
the
> use of CLIENT-CERT requires SSL (SRV.12.5.4). With this in mind, my first
> question is:
>
> 1. If a user wants to use CLIENT-CERT should they have to specify a
> user-data-constraint or should tomcat automatically apply SSL to the
resources
> in the web resource collection specified in the security constraint when
the
> auth constraint is CLIENT-CERT? Having read the spec, I can't figure out
what
> should happen.

Having CLIENT-CERT imply a transport-guarantee sounds like a nice idea.
However, it would violate section 12.8 of the current draft of the 2.4 spec.
If the spec changes, then we could add it as a feature.  If you feel
strongly about this, then servletapi-feedback@eng.sun.com is the place to
write.

>
> Regardless of the answer to the above, if CLIENT-CERT is specified,
> user-data-constraint is set to CONFIDENTIAL and there are no valid certs
on the
> client a number of exceptions get thrown by tomcat. This brings me to my
> remaining question:
>
> 2. Not having a matching certificate is equivalent to getting the password
> wrong. Therefore, shouldn't tomcat behave in a similar way (no exceptions,
> return a 403 to the client) rather than throwing the exceptions?

SSL doesn't work that way.  If the client's cert can't be validated, then
the connection is just dropped, so there is no way to send anything back to
the client.  If the certificate is valid, but not a known user, then Tomcat
treats it the same way that it would Basic or Form.

This isn't that big of an issue, for the simple reason that browsers
generally don't give you the option to re-select a cert once you've chosen
one.  You're stuck having to close the browser and start all over again.

>
> With some guidance on the above, assuming that some code changes will be
> required, I'll set about writing a patch.
>
> Note: Although the bug is reported against 4.1.24, the same behaviour is
seen
> with the latest 4.x.x and 5.x.x
>
> Regards,
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


Mime
View raw message