tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44309] New: - Possible overriding the security state of the connection
Date Mon, 28 Jan 2008 14:32:22 GMT
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: tomcat-dev@jakarta.apache.org
        ReportedBy: robert.kovacs@siemens.com
                CC: robert.kovacs@siemens.com


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 couldn’t 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
connector’s 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 didn’t 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 aren’t 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message