You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2008/01/28 15:32:22 UTC
DO NOT REPLY [Bug 44309] New: - Possible overriding the security state of the connection
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
DO NOT REPLY [Bug 44309] - Possible overriding the security state of the connection
Posted by bu...@apache.org.
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
------- Additional Comments From robert.kovacs@siemens.com 2008-01-28 06:42 -------
Detailed feature request:
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.
The interface could contain a method with an input parameter with type
java.net.Socket which belongs to the actual connection and it could return
boolean value indicating that the underlying layer is secured or not based on
the socket parameter.
For example:
package org.apache.coyote;
public interface SecurityExtension {
public boolean isSecure( java.net.Socket socket )
throws Exception;
}
Similar to protocol attribute of connectors the implementation class of this
interface could be specified as an optional connector attribute.
The interface method could be invoked in prepareRequest() method of
org.apache.coyote.http11.Http11Processor.java where the request scheme attribute
can be overridden.
--
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