4 Answers, 1 is accepted
I'm not able to reproduce either problem.
The most likely explanation is that you've edited your CustomRules.js file and that is causing this unwanted behavior. If you don't care about any changes you've made to your FiddlerScript and want the latest default, simply close Fiddler and delete CustomRules.js from your %UserProfile%\Documents\Fiddler2\Scripts folder. The next time Fiddler starts, the default script will be restored.
Renaming the CustomRules.js causes the SSL protocols to be remembered correctly, which is great. I don't understand how or why that should affect the setting, because the only thing I changed in my CustomRules.js was to uncomment the OnPeekAtRequestHeaders method, in which I added filters to hide some URIs I don't ever want to see. I literally copy-pasted that method into Fiddler from my old CustomRules.js, saved it, and everything (including the SSL protocols) just worked. So... weird. The only other thing I can think of is that I'm using the BCCertMaker.BCCertMaker instead of Fiddler's built-in one.
However the CONNECT issue persists, as you can see from this screenshot: http://imgur.com/VSgMPCK This occurs with 220.127.116.11 regardless of whether I'm using my old/broken CustomRules.js, a clean one, or my new modified one.
Bug reports aside, I'd just like to express my gratitude for your creation, and continuing support, of Fiddler. It's one of those tools that you honestly can't imagine living without once you've used it, and I'm certain it's saved billions of hours and millions of dollars in time for developers around the world. - yet this wonderful application remains free for anyone to use. Thank you Eric, and thank you Telerik, for being awesome.
The "Protocols not remembered" symptom described is exactly what would happen if you had placed a line like this inside FiddlerScript's OnBoot or Main functions:
CONFIG.oAcceptedServerHTTPSProtocols = System.Security.Authentication.SslProtocols.Ssl3;
Some users have historically added that line to accommodate buggy servers that fail when TLS extensions are sent.
With regard to the screenshot you've sent-- do you see this for any other CONNECT requests, or just for the request to the version checking web service? For instance, if you open your browser and hit https://bayden.com, do you see a CONNECT tunnel? If so, can you email (help > send feedback) a SAZ file showing that?
Would I be correct in guessing that you have an upstream proxy server (look at the Gateway line inside the Help > About screen)?
Thanks a bunch!