Can you please tell me the full URL you were requesting? It looks a bit as if you accessed the page via HTTP but on port 443 (which is used for HTTPS).
Does this happen for every site using HTTPS? Does this happen with every browser?
Indeed it is a http access to port 443.
The full URL is http://applications1.inform.es:443/general/LoginAplic/LoginAplic.do?id=wQ4ONjOiG SwBTsPHIoEmG0kxlg5c6TUiNAZuHGpZ7z7TZULhJxeMwTphi69De4/u4mM+PmBkbVaO3PEghGkDDPYMt 3z2lF3R
But the problem is that It requires a previous login process and we cannot provide you access credentials.
Once logged in (still against 8080), customer is trying to access to another section and here it is where the request is against 443.
I've attached a screenshot with this last step.
Thanks for your help.
are you able to provide us some more information about your deployment? Which version of MWG are you running? Is it an explicit proxy scenario or are you using one of the transparent modes?
We´re running 22.214.171.124.0 version and we´re using transparent router mode.
I´m going to try to explain you the situation we´re noticing since las t friday when we enabled the SSL scanner to block connections against Ultrasurf anonymous proxy.
Before activating SSL scanner, we could access the page without problems. Then we activated the SSL scanner to block ultrasurf with the following rulesets configuration:
At this point, ultrasuf connections were blocked but, when we try to access the page, the handshake failed error message is displayed too.
Hope you can help me.
Thanks very much.
El mensaje fue editado por: maitane on 23/11/11 3:45:33 CST
SSL scanner ruleset.jpg 164.5 K
In the transparent router mode together with SSL scanner MWG 7 will always assume, that connections on 443 are HTTPS.
What you can do is to bypass the SSL scanner for all requests to inform.es. Therefore you need to enter the IP (or maybe multiple IPs) (and not the hostname, because we are in a transparent router setup!) to the list in the rule "Tunneled Hosts". But that also means, that you cannot filter these requests anymore.
we resolved the problema using all the range.
Thanks for the clarification.