changing the recording's SSL Cipher setting
I am using vuGen 11.52. The web application under test was recently updated and vuGen can no longer record at Socket Level (it can record at the WinInet level, but when can't it?) in IE 9 (the customer's current system wide browser).
I suspect the problem is recent changes to the SSL protocol and cipher settings given the SSL hack found last Fall. Unfortunately the app developers I can get to (this is a large distributed app) have not be able to help me understand why I can no longer record at the Socket Level (I am getting a collective "must be your tool" response). At any rate I used OPENSSL to glean the protocol and cipher level using the "KM177385: How to find the SSL Version and Cipher type used by a secure website" HP support document and find:
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Protocol : TLSv1
Cipher : RC4-SHA
And as per the KM I should be using SSL 3.x with the explicit RC4-SHA cipher based on the OPENSSL information. So now I attempt to set these values in the Recording Options.
The Recording Option --> Port Mapping --> Options brings up the Advanced Port Mapping Settings dialog and I can select and save any SSL Version: setting (I have tried both SSL 3.x and TLS 1x given what OPENSSL returned above). But no matter what SSL Version: setting I select I can not get vuGen to save any explicit SSL Ciphers: setting--after selecting an explicit SSL Ciphers: setting of RC4-SHA I press the Update button to close the Advanced Port Mapping Settings dialog (this leaves the pending Recording Options dialog still open...):
At this point I can re-open the Advanced Port Mapping Settings and the RC4-SHA setting is still present. But after I click the OK button to close the Recording Options dialog, and then immediately re-open Recording Options and then the Advanced Port Mapping Settings dialog the SSL Ciphers: setting always reverts back to (Default OpenSsl Ciphers), as in:
I have tried a variety of combinations: SSL Version: TLS 1.x and SSL 3.x; SSL Ciphers: several expicit choices; with and without the Enable auto SSL detection checkbox selected--all with the same results.
Does anyone know how I can resolve this issue?
-Thanks, Terry Horwath
Last edited by Terry Horwath; 03-23-2015 at 06:03 AM.
Uncharted territory for me. Rather than diagnose things like this I simply throw to a level which will record (Proxy, ...), get the recording and move on. Perhaps a bit pragmatic in approach. I can't say I have ever had to adjust the cipher model.
I'm curious to see where this is headed and what (if anything) HP comes back with.
WinINet level recording has gotten us thru the last two builds and the customer does not want to spent time/money to pursue. So I have been working this as a side issue when I have some spare free time. But using only WinInet has the potential, according to HP online KMs, to cause missing requests and if/when that occurs then the time will be spent to dig in. I too have not seen this before (7-8 years using LR) and would like to understand how the web app could have changed to cause this odd problem.
And man, there is a ton of configuration paths with the SSL protocol/cipher settings, and the documentation on how to do it is quite murky.
Also I should have mentioned, when this first occurred I was still using vuGen 11.04. We then upgraded to 11.52 and had hoped that might resolve the problem, but did not. For a short period of time I was able to access an old build and confirm I could record at the sockets level. Anyway, this is quite a mystery.
Terry have you tried recording in anything else?
both Fiddler and wincap can be imported (into mobile protocol, but it's near as dammit regular web for the scripts)
at the very least this would enable you to verify the wininet recordings, if there are issues
(I haven't had any ssl cipher issues either, in 14 years!!!)
Jim, I CAN record in WinINet but NOT the more preferred/default sockets.
I was thinking about verifying the inet recordings (you mentioned HP claim it can miss some requests) to reduce your 'digging in time'