RE: Bug 19867

[Mark Thomas <me...@ntlworld.com>]

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.

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?

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

Re: Bug 19867

[Bill Barker <wb...@wilshire.com>]

----- Original Message -----
From: "Mark Thomas" <me...@ntlworld.com>
To: <to...@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
>