glassfish
  1. glassfish
  2. GLASSFISH-16209

when accessing simple secure webapp on 3.1 cluster with iWS and LBplugin frontend, it get redirect and expose the GF https instances url.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1_b43
    • Fix Version/s: 3.1.1_b03
    • Component/s: security
    • Labels:
      None
    • Environment:

      On OEL with iws 7.0.9 with LB b05

      Description

      When you deploy a simple secure webapp on a v3.1 cluster with iPlanet WebServer with LB plugin frontend, and access the webapp using HTTPS, it redirected to GF instance HTTPS port. In this setup, neither HTTPS Routing not authPassThrough is enabled. With this its exposing the GF instance to the client.

      For ex: When I access https://webserver_host/WebApplliaction/index.jsp it redirects to https:gf_instancehost_port/WebApplciation/index.jsp.

      Because of the SSL offloading, the HTTPS request from client is forwarded by the LB to the HTTP port of the GF instance. Its reasonable that GF instance sees this request as received on unsecure port and redirects to secure port. But it should have redirected to the WebServer HTTPs port using the Host header in the incoming request.

      As per analysis done by Kshitiz, GF instance seems to use the host name from Host header, However ssl port for instance is appended to it which is incorrect.

        Activity

        Hide
        Shing Wai Chan added a comment -

        Assign to load balancer team for evaluation.

        Show
        Shing Wai Chan added a comment - Assign to load balancer team for evaluation.
        Hide
        ramapulavarthi added a comment - - edited

        Apart from fixing the issue to use the correct port (https port) of the web server, I think the fix has to go little farther to provide insight into the problem to the user. As neither HTTPS Routing not authPassThrough is enabled, redirecting to webserver https port in this case would keep the client in loop as the new redirect location is the same as the original url client used.

        Client ---> https://webserver/App ---->http:gf_instance/App

        <--- https://webserver/App <---HTTP 302

        ---->
        If possible, the implementation can try to be little smart in detecting this scenario and suggest the user with an error page that suggests enabling HTTPS Routing on LB or authPassThrough on cluster.

        Show
        ramapulavarthi added a comment - - edited Apart from fixing the issue to use the correct port (https port) of the web server, I think the fix has to go little farther to provide insight into the problem to the user. As neither HTTPS Routing not authPassThrough is enabled, redirecting to webserver https port in this case would keep the client in loop as the new redirect location is the same as the original url client used. Client ---> https://webserver/App ---->http:gf_instance/App <--- https://webserver/App <---HTTP 302 ----> If possible, the implementation can try to be little smart in detecting this scenario and suggest the user with an error page that suggests enabling HTTPS Routing on LB or authPassThrough on cluster.
        Hide
        kshitiz_saxena added a comment -

        Load-balancer code should not kick in when redirection is from SSL to non-SSL OR non-SSL to SSL. User must set "rewrite-location" to "false" in load-balancer xml for such scenarios.

        The web-container must handle this scenario of redirection. As mentioned in description, it uses "Host" header correctly when creating redirect url. However it appends SSL listener port to it, resulting in this issue. The web-container code should detect whether "Host" header in request was pointing to its non-SSL listener.
        =>If yes, then redirect should to be to its SSL listener.
        =>If no, then it should use the url from "Host" header, and only update the protocol,i.e., from http to https in this case.

        Reassigning it back to web-container team.

        Show
        kshitiz_saxena added a comment - Load-balancer code should not kick in when redirection is from SSL to non-SSL OR non-SSL to SSL. User must set "rewrite-location" to "false" in load-balancer xml for such scenarios. The web-container must handle this scenario of redirection. As mentioned in description, it uses "Host" header correctly when creating redirect url. However it appends SSL listener port to it, resulting in this issue. The web-container code should detect whether "Host" header in request was pointing to its non-SSL listener. =>If yes, then redirect should to be to its SSL listener. =>If no, then it should use the url from "Host" header, and only update the protocol,i.e., from http to https in this case. Reassigning it back to web-container team.
        Hide
        Shing Wai Chan added a comment -

        The redirection logic is in security module. Reassign to security team.

        Show
        Shing Wai Chan added a comment - The redirection logic is in security module. Reassign to security team.
        Hide
        Nithya Ramakrishnan added a comment -

        Why fix this issue in 3.1.1?
        This fix impacts product security and must be fixed.

        Which is the targeted build of 3.1.1 for this fix?
        3.1.1_01

        Do regression tests exist for this issue?
        SQE security test - appserver-sqe/pe/security/ssl/redirectport

        Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
        QA(Jothir and Varun) are writing up tests for the specific issue.

        Show
        Nithya Ramakrishnan added a comment - Why fix this issue in 3.1.1? This fix impacts product security and must be fixed. Which is the targeted build of 3.1.1 for this fix? 3.1.1_01 Do regression tests exist for this issue? SQE security test - appserver-sqe/pe/security/ssl/redirectport Which tests should QA (re)run to verify the fix did not destabilize GlassFish? QA(Jothir and Varun) are writing up tests for the specific issue.
        Hide
        scatari added a comment -

        Does it apply only to 3.1.1?

        Since you haven't fixed it yet(correct me if I am wrong),the build # should be 3.1.1_02. Please refer here for build schedule. http://wikis.sun.com/display/GlassFish/3.1.1BuildSchedule

        Show
        scatari added a comment - Does it apply only to 3.1.1? Since you haven't fixed it yet(correct me if I am wrong),the build # should be 3.1.1_02. Please refer here for build schedule. http://wikis.sun.com/display/GlassFish/3.1.1BuildSchedule
        Hide
        Nithya Ramakrishnan added a comment -

        Changing the target build

        Show
        Nithya Ramakrishnan added a comment - Changing the target build
        Hide
        Nithya Ramakrishnan added a comment -

        This applies to 3.2 as well. The fix has already been checked in into the trunk. (after the 3.1.1 branching).
        This request is to checkin into the 3.1.1 branch.

        Yes, the target build should be the next one - changed it to 3.1.1_03

        Show
        Nithya Ramakrishnan added a comment - This applies to 3.2 as well. The fix has already been checked in into the trunk. (after the 3.1.1 branching). This request is to checkin into the 3.1.1 branch. Yes, the target build should be the next one - changed it to 3.1.1_03
        Hide
        Nithya Ramakrishnan added a comment -

        Fixed in the 3.1.1 branch and trunk

        Show
        Nithya Ramakrishnan added a comment - Fixed in the 3.1.1 branch and trunk

          People

          • Assignee:
            kumarjayanti
            Reporter:
            Homer Yau
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: