You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2008/02/17 18:10:34 UTC
[jira] Created: (HTTPCLIENT-750) manage connections with
upgradeable security
manage connections with upgradeable security
--------------------------------------------
Key: HTTPCLIENT-750
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-750
Project: HttpComponents HttpClient
Issue Type: New Feature
Components: HttpConn
Reporter: Roland Weber
Assignee: Roland Weber
Fix For: 4.0 Alpha 4
RFC 2817 (http://tools.ietf.org/html/rfc2817) specifies not only tunnelling of TLS/SSL via proxies, but also upgrading an existing HTTP connection to TLS/SSL. The latter is not commonly used for communication with traditional HTTP servers, but part of other protocols like IPP that are based on HTTP.
The current connection management code assumes that a route planner can determine in advance whether a connection will be secure or not. A connection manager will not reuse an existing unsecure connection if a secure connection is requested. It probably also doesn't consider a returned connection secure if it wasn't requested for a secure route.
One way to improve the situation is to give HttpRoute a trinary security flag, with values plain/secure for the current usage scenario and a new value upgradeable for the new scenario. The two scenarios won't mix, but that is probably not required.
We have to make sure that upgrade to security of an existing plain HTTP connection is correctly tracked and either respected or suitably ignored by the connection manager. If the security flag of the route is 'upgradeable', mixing of scenarios is not required, and the actual security level can be obtained from the connection itself, it is probably safe to let the connection manager ignore it.
cheers,
Roland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-750) manage connections with
upgradeable security
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569729#action_12569729 ]
Roland Weber commented on HTTPCLIENT-750:
-----------------------------------------
If the unsecure connection is through a proxy, upgrading it requires to tunnel the connection first. So not only the security flag but also the tunnelled flag in HttpRoute causes problems. I may have to reconsider the concept on a higher level.
cheers,
Roland
> manage connections with upgradeable security
> --------------------------------------------
>
> Key: HTTPCLIENT-750
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-750
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpConn
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0 Alpha 4
>
>
> RFC 2817 (http://tools.ietf.org/html/rfc2817) specifies not only tunnelling of TLS/SSL via proxies, but also upgrading an existing HTTP connection to TLS/SSL. The latter is not commonly used for communication with traditional HTTP servers, but part of other protocols like IPP that are based on HTTP.
> The current connection management code assumes that a route planner can determine in advance whether a connection will be secure or not. A connection manager will not reuse an existing unsecure connection if a secure connection is requested. It probably also doesn't consider a returned connection secure if it wasn't requested for a secure route.
> One way to improve the situation is to give HttpRoute a trinary security flag, with values plain/secure for the current usage scenario and a new value upgradeable for the new scenario. The two scenarios won't mix, but that is probably not required.
> We have to make sure that upgrade to security of an existing plain HTTP connection is correctly tracked and either respected or suitably ignored by the connection manager. If the security flag of the route is 'upgradeable', mixing of scenarios is not required, and the actual security level can be obtained from the connection itself, it is probably safe to let the connection manager ignore it.
> cheers,
> Roland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCLIENT-750) manage connections with
upgradeable security
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-750:
-----------------------------------------
Fix Version/s: (was: 4.0 Alpha 4)
Future
I added support for managing stateful connections as per HTTPCLIENT-652. However, support for connections with upgradeable security cannot be fully implemented until HTTPCORE-158 is resolved.
Oleg
> manage connections with upgradeable security
> --------------------------------------------
>
> Key: HTTPCLIENT-750
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-750
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpConn
> Reporter: Roland Weber
> Fix For: Future
>
>
> RFC 2817 (http://tools.ietf.org/html/rfc2817) specifies not only tunnelling of TLS/SSL via proxies, but also upgrading an existing HTTP connection to TLS/SSL. The latter is not commonly used for communication with traditional HTTP servers, but part of other protocols like IPP that are based on HTTP.
> The current connection management code assumes that a route planner can determine in advance whether a connection will be secure or not. A connection manager will not reuse an existing unsecure connection if a secure connection is requested. It probably also doesn't consider a returned connection secure if it wasn't requested for a secure route.
> One way to improve the situation is to give HttpRoute a trinary security flag, with values plain/secure for the current usage scenario and a new value upgradeable for the new scenario. The two scenarios won't mix, but that is probably not required.
> We have to make sure that upgrade to security of an existing plain HTTP connection is correctly tracked and either respected or suitably ignored by the connection manager. If the security flag of the route is 'upgradeable', mixing of scenarios is not required, and the actual security level can be obtained from the connection itself, it is probably safe to let the connection manager ignore it.
> cheers,
> Roland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-750) manage connections with
upgradeable security
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569984#action_12569984 ]
Roland Weber commented on HTTPCLIENT-750:
-----------------------------------------
The last comment was still shooting too low. Technically, upgrading the connection is layering. Layering may require tunnelling, and it can result in raised security. So all three flags currently in HttpRoute are affected by the operation. There is no point in adding an additional flag. The routes before and after the update are simply two different routes, and the current ThreadSafeClientConnManager is not capable of making the link between the two.
I'll collect my thoughts in the Wiki (http://wiki.apache.org/HttpComponents/ClientConnectionManagementDesign) and discuss the ideas on the dev list when it's time.
cheers,
Roland
> manage connections with upgradeable security
> --------------------------------------------
>
> Key: HTTPCLIENT-750
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-750
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpConn
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0 Alpha 4
>
>
> RFC 2817 (http://tools.ietf.org/html/rfc2817) specifies not only tunnelling of TLS/SSL via proxies, but also upgrading an existing HTTP connection to TLS/SSL. The latter is not commonly used for communication with traditional HTTP servers, but part of other protocols like IPP that are based on HTTP.
> The current connection management code assumes that a route planner can determine in advance whether a connection will be secure or not. A connection manager will not reuse an existing unsecure connection if a secure connection is requested. It probably also doesn't consider a returned connection secure if it wasn't requested for a secure route.
> One way to improve the situation is to give HttpRoute a trinary security flag, with values plain/secure for the current usage scenario and a new value upgradeable for the new scenario. The two scenarios won't mix, but that is probably not required.
> We have to make sure that upgrade to security of an existing plain HTTP connection is correctly tracked and either respected or suitably ignored by the connection manager. If the security flag of the route is 'upgradeable', mixing of scenarios is not required, and the actual security level can be obtained from the connection itself, it is probably safe to let the connection manager ignore it.
> cheers,
> Roland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org