Fiddler fixes HTTPS Post: how to emulate Fiddler proxy

[g]

I have a HTTPS Post that is failing with either:
  - The underlying connection was closed: An unexpected error occurred on a send, or
  - The request was aborted: Could not create SSL/TLS secure channel

When  capturing traffic with fiddler the problem goes away.  I've read the advice from Eric here:
  - http://blogs.telerik.com/fiddler/posts/13-02-28/help!-running-fiddler-fixes-my-app-
  - http://stackoverflow.com/questions/21481682/httpwebrequest-the-underlying-connection-was-closed-the-connection-was-closed

The server I'm connecting to (Chase bank ofx server) isn't intermittently letting me connect, so retrying isn't an option.

I'm wondering if there is a way to build/emulate the fiddler proxy in C# to keep the client connection open and get around the .Net 4 "bug" Eric mentions in the Stack Overflow post?  Or is there anything I can do in my firewall to keep the connection open?

I'd be grateful for any assistance getting started.

[Eric Lawrence]

Providing the URL you're trying to connect to would allow us to debug using something other than magic.

The "connection was closed" issue is only relevant if you've made at least one successful request. If you haven't, it's not related.

What HTTPS version is the client configured to use? What HTTPS version does the server select? What is the client OS in use?

Regards,
Eric Lawrence
Telerik

 

 

[g]

Thanks for taking a look.  The URL is https://ofx.chase.com.  I've had this communication working for over a year, but the error started last week and has been consistent.

I'm not sure how to answer HTTPS version.  I'm setting:
  the request object's ProtocolVersion = HttpVersion.Version10, and
  the ServicePointManager's SecurityProtocol = SecurityProtocolType.Ssl3

I'm not sure what version the server is selecting.

There are a number of other banks that support OFX for pulling bank statement data (e.g. Wells Fargo), and I'm not having the problem with those -- just Chase.  The problem is the same on both Windows Server 2008 and my Win 8.1 dev box.

I turned on some logging, and the raw error I get is:

System.Net Information: 0 : [8996] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 5efefc8:5f67768, targetName = ofx.chase.com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)

System.Net Information: 0 : [8996] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=IllegalMessage).

I could provide the .Net logging with and without Fiddler running if that would be helpful.

[Alan]

I'm not a .NET programmer but ... has Chase perhaps disabled use of SSL, because of the POODLE vulnerability?

I notice that you set ServicePointManager's SecurityProtocol = SecurityProtocolType.Ssl3 and the rejection is because "Could not create SSL/TLS secure channel".

Can you set the SecurityProtocol to TLS instead?

... An interested bystander ...

[g]

Wow, yes, I can try TLS, and Chase responded successfully.  I never would have thought of that.  Thanks for the input Alan and Eric!

[Eric Lawrence]

Thanks for weighing in, Alan-- yes, this is because Chase recently disabled SSL3 due to Poodle. Fiddler in the middle lets this work because Fiddler uses the default HTTPS versions when talking to the upstream server regardless of what the client used.

@g: Rather than manually specifying the TLS version for your ServicePointManager, it's best to just leave this out and allow .NET to use its default settings. Historically, there were some sites that required that you specify only SSL3 (e.g. http://blogs.msdn.com/b/fiddler/archive/2012/03/29/https-request-hangs-.net-application-connection-on-tls-server-name-indicator-warning.aspx ) but such servers are rare and you generally should not specify SSL3 unless you know you're talking to such a server.


Regards,
Eric Lawrence
Telerik

 

 

[Tuan]

Hi Alan,

you just solved an issue that i was stuck for a month now.

Thanks a loads. Love you. :)