DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=44309>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44309 Summary: Possible overriding the security state of the connection Product: Tomcat 5 Version: 5.5.9 Platform: Sun OS/Version: Solaris Status: NEW Severity: enhancement Priority: P2 Component: Connector:HTTP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Overview Using the embedded version of TomCat 5.5.9 (in JBoss 4.03SP1 on Solaris 9) we had to integrate our own SSL layer into TomCat, so that the secure connections could be configured in a special/required way. Therefore we couldnt follow the official way of configuring the connectors for secure communication. As a solution the pure Java socket and server socket factories were overridden by our own factories where the factorized socket implementation managed all the SSL stuff. Problem description However the above solution worked fine with TomCat we encountered a special problem. TomCat offers the mechanism called port redirecting to fulfill the servlet specification chapter SRV.12.8.3: "The characteristics of the connection on which the request was received must satisfy at least one of the supported connection types defined by the constraints. If this rule is not satisfied, the container shall reject the request and redirect it to the HTTPS port." Therefore two connectors were defined: one for secure and an other for insecure communication, where the insecure was redirected to the secure using the connectors attribute redirectPort. An other servlet specification requirement regarding to programmatic security had to be fulfilled as well: SRV.4.7 SSL Attributes: "If a request has been transmitted over a secure protocol, such as HTTPS, this information must be exposed via the isSecure method of the ServletRequest interface." Based on the above section the methods isSecure() and scheme() always have to return the proper values. In our test case we didnt configure any certificates nor keys for the secure connector. We tried to access a test servlet which declared its content as confidential via the insecure connector. Because the port redirecting mechanism worked the request was forwarded to the secure connector and the isSecure() and scheme() functions returned with values defined for the secure connector in server.xml: isSecure() -> true scheme() -> https Based on this, the connection was declared as secure on TomCat level. Unfortunately the return values arent correct in this case. We had to find a solution to determine the security state of the connections based on the real security characteristic of our own underlying socket layer. Feature request/Suggestion It would be great if TomCat could offer an interface to influence the decision whether the connection is secured or not in case of isSecure() and scheme() methods. Therefore the actual decision based on the connector configuration could be redefined with our own implementation. Similar to protocol attribute of connectors the implementation class of this interface could be specified as an optional connector attribute. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
