1 of 1 people found this helpful
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.
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.