2 Replies Latest reply on Oct 21, 2016 12:00 PM by gunnars

    TLS sessions with multiple ports, including some that are not handled by MWG


      using MWG 7.5 in a Transparent Router mode, in this scenario:

      2016 10 20 092849.jpg

      application on the user's end might detect the fact that some of the session is being signed by a different cert and might choose to react by breaking the session all together.


      as a MWG admin, is my only choice therefore to detect such sessions before the custom port is used (perhaps by destination domain or URL) and then bypass the SSL scanning cycle all together?


      or is there some other creative approach I haven't thought of yet?


      thank you

        • 1. Re: TLS sessions with multiple ports, including some that are not handled by MWG
          Jon Scholten

          Hi Gunnars,


          Sounds like you're deep into this issue, I'm gonna take a step back for a second


          Anything is possible, but I would find it a bit strange that an application might establish two connections (443 then 2983) and check the certificate authorities presented in order to decide if the 443 connection is compromised. In most enterprise environments I would expect 2983 to be blocked at the firewall but thats besides the point.


          Typically applications will look into a certificate store which has a list of trusted certificate authorities. If that CA is in the list, the application allows the connection.


          OR, an application will be hardcoded to trust only a certain CA. In which case SSL inspection is not possible (unless we are that trusted CA...).


          I would guess the application might just have a hardcoded CA. In which case, MWG will log a handshake failure, with 500 as the HTTP status code.


          Best Regards,


          1 of 1 people found this helpful
          • 2. Re: TLS sessions with multiple ports, including some that are not handled by MWG

            nah, completely unrelated to any previous posts/comments, just a thought excercise to make sure I'm understanding the flows here.

            All based on various small observations over the past months, some involving plain browser sessions, some java applets, some flash.


            port 2983 selected at random just to represent _some_ other port that the MWG is not configured to handle. And yes, let's pretend the FW is allowing it


            I also have MCP in the mix here. MCP policy handles those with the Agent on the endpoint, those without are caught and handled by the transparent router.


            MCP port list matches the portlist on MWG, but MCP is configured to allow the rest of the ports to continue to original destination.


            time to pick a specific browser session, no java, no flash, fire up a vanilla windows vm on an open network, and watch the traffic with wireshark and OWASP Zed


            thank you for that http 500 mention, I'll watch for those when testing from behind MWG.