Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Future
    • Component/s: HttpConn
    • Labels:
      None

      Description

      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

        Issue Links

          Activity

          Hide
          Oleg Kalnichevski added a comment -

          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

          Show
          Oleg Kalnichevski added a comment - 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
          Hide
          Roland Weber added a comment -

          Let's take care of the connection based authentication state in HTTPCLIENT-652 first. Once we have the logic to be choosy about the connections in a route-specific pool, we can extend that to handle security upgrades as well. What that means for the route representation will be up for discussion.

          cheers,
          Roland

          Show
          Roland Weber added a comment - Let's take care of the connection based authentication state in HTTPCLIENT-652 first. Once we have the logic to be choosy about the connections in a route-specific pool, we can extend that to handle security upgrades as well. What that means for the route representation will be up for discussion. cheers, Roland
          Hide
          Roland Weber added a comment -

          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

          Show
          Roland Weber added a comment - 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
          Hide
          Roland Weber added a comment -

          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

          Show
          Roland Weber added a comment - 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

            People

            • Assignee:
              Unassigned
              Reporter:
              Roland Weber
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development