Has anyone found a way to resolve/get around the handshake could not be performed error while using SSL scanning in a way that they don't bypass the SSL scanner all together? We want to inspect SSL traffic, so we do not want to resolve the handshake could not be performed error by just bypassing SSL scanning.
Here's the error:
|The SSL handshake could not be performed.|
Reason: error:1408F10BSL routinesSL3_GET_RECORD:wrong version number
Any help would be appreciated.
What version of MWG?
In 7.2, which uses openssl 0.9.8e, my experience with that specific error has been that the server isn't speaking SSL. Another possibility is that the server is running a version of openssl that the proxy doesn't support, but that's far less likely.
7.3 uses openssl 1.0.1c. Based on the source RPM for 7.3's distro, you could be running up against an openssl bug that's mentioned @ http://cvs.openssl.org/chngview?cn=22565
can you state the exact URL which causes the error? I tried to go to smdservers.net, but that works fine for me. It is possible that the server is offering SSL/TLS versions which are not supported in 7.2.x or malformed information.
If you can let me know how to replicate the problem I can have a look.
No problem. The URL for the test above is: https://www.tjoselfstorage.com/self-storage/fort-worth-tx-116833/payonline. We had other URLs this happened to, but this was the one I was specifically using to troubleshoot our SSL setup.
I had a look at the URL you provided but on all my Lab MWGs running 7.2 or 7.3 the page shows up fine with SSL Scanner enabled. Unfortunately I do not have an appliance running in FIPS mode, probably this is related. I do not know many details about what the FIPS setting does, so I can't tell.
Do you mind creating a service request at tech support? They should be able to help you with the troubleshooting. If someone else is running in FIPS mode (or has one appliance in FIPS and another one in non-FIPS mode) it would be interesting if you can go to the URL and post whether you can access it or receive a similar issue.
Not sure if its due to FIPS mode or not, but wouldn't bet against it. I will put in a ticket in a bit. I do have a whitelist option setup in case we hit the handshake error again, but hopefully tech support can resolve it.
I have the same issue at WebGateway Version 220.127.116.11. Are there any ideas to solve the problem without SSL whitelisting? Is it possible that is caused by the POODLE attack and the Server-Provider has dissabled SSLV3?
But when SSL V3 is dissabled the client should handle a lower version SSL V1 or 2?
Please help me. I do not understand the Problem Any hints are welcome.
thanks for the fast answer.
I have followed the instructions from the Link. After prepering the rulebase settings connecting to the url was possible.
Thanks for your support!