On Tuesday, August 12, 2003 12:39 AM, Bill Barker [SMTP:[EMAIL PROTECTED] wrote: > > ----- Original Message ----- > From: "Mark Thomas" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] is the place to > write.
I'll drop them an e-mail with the suggestion. > > > > > 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. > Ah, hadn't picked up that the connection was just dropped. What about at the server end of the connection? Should an invalid cert cause a series (three) of exceptions? Wouldn't it be better for tomcat to handle an invalid cert (for whatever reason) in the same was it does for basic and form or is there something about the way SSL works that prevents this? > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > << File: disclaimer.txt >> << File: ATT00001.txt >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
