Why does Fiddler2 appear to block WCF Test Client?
gerry lowry +1 705 250-0112 alliston ontario canada
-- start WCF Test Client (WcfTestClient.exe)
-- in WCF Test Client: File, Add Service...
https://tbe.taleo.net/wsdl/DispatcherAPI.wsdl
Click OK for the above endpoint address
-- double click getURL()
-- set the request value for Name orgCode
to TALEOSK
-- click Invoke
-- if you get a security warning dialog, click OK
and wait for the security warning dialog to close
-- look at the XML after "Service invocation completed"
appears in the WCF Test Client status bar.
-- this is what you should see:
Request:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none" />
</s:Header>
<s:Body s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<q1:getURL xmlns:q1="urn:TBEDispatcherAPI">
<orgCode xsi:type="xsd:string">TALEOsk</orgCode>
</q1:getURL>
</s:Body>
</s:Envelope>
Response:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<s:Header xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" />
<SOAP-ENV:Body>
<ns1:getURLResponse xmlns:ns1="urn:TBEDispatcherAPI" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">https://tbe.taleo.net/NA12/ats/services/rpcrouter</return>
</ns1:getURLResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
-- next, start Fiddler2 (I'm running v2.3.1.0, Win 7 Home Premium; 64-bit)
-- navigate back to the WCF Test Client
-- Click the WCF Test Client Invoke control
Failure:
Failed to invoke the service. Possible causes:
The service is offline or inaccessible; the client-side configuration does not match the proxy; the existing proxy is invalid.
Refer to the stack trace for more detail.
You can try to recover by starting a new proxy, restoring to default configuration, or refreshing the service.
Error Details:
Could not establish trust relationship for the SSL/TLS secure channel with authority 'tbe.taleo.net'.
Server stack trace:
at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest
request, HttpAbortReason abortReason)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins,
Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at DispatcherAPI.getURL(String orgCode)
at DispatcherAPIClient.getURL(String orgCode)
Inner Exception:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
Inner Exception:
The remote certificate is invalid according to the validation procedure.
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception
exception)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytasyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.TlsStream.CallProcessAuthentication(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean
ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
MORE INFORMATION
Checking "Start a new proxy" before clicking Invoke
does not cure this.
Stopping Fiddler2 from capturing (F12) can cure this;
turning capture on breaks it.
Turning of (Tools, Fiddler Options) Decrypt HTTPS Traffic fixes this.
But then the decryption is lost.
MORE INFORMATION
Fiddlers Text view implies Decrypt HTTPS Traffic should work:
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
To view the encrypted sessions inside this tunnel,
ensure that the Tools > Fiddler Options > HTTPS > Decrypt HTTPS traffic option is checked. <====
^^^^^^^^^^
The data sent represents an SSLv3-compatible ServerHello handshake. For your convenience, the data is extracted below.
Major Version: 3
Minor Version: 1
SessionID: AD A2 D5 D2 FA 2C A6 10 D2 C2 B6 ED 9B 5D 7B 3E 44 CF 85 81 E4 69 52 73 CE CB 13 89 E5 F3 54 7E
Random: 4D 2E 69 B4 72 7D 28 94 63 70 E5 A1 60 CA F9 C7 EC 5C A5 9A C4 76 8C 2A D0 CA FA 58 36 14 59 84
Cipher: 0x2F
Regards/g.
P.S.: a better subject for this post might have been
Why can I not Decrypt HTTPS traffic?
EricLaw
certificate. http://www.fiddler2.com/fiddler/help/httpsdecryption.asp
You can fix this by launching certmgr.msc and dragging the Fiddler
root certificate from the Personal folder to the Trusted folder.
-Eric
On Jan 12, 7:01 pm, "gerry lowry +1 705 250-0112 alliston ontario
> request, HttpAbortReason abortReason)
> at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
> at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
> at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins,
> Object[] outs, TimeSpan timeout)
>
> Exception rethrown at [0]:
> at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
> at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
> at DispatcherAPI.getURL(String orgCode)
> at DispatcherAPIClient.getURL(String orgCode)
>
> Inner Exception:
> The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
> at System.Net.HttpWebRequest.GetResponse()
gerry lowry +1 705 250-0112 alliston ontario canada
-------------------------------------------------------------
update + follow-up questions:
UPDATE
Yes, Eric ... it appears that not trusting a certificate named "DO_NOT_TRUST_FiddlerRoot" was the problem.
FOLLOW-UP QUESTIONS:
(A)
Why the crash? i.e.; why am I not simply prompted each time when I choose not to trust the
"DO_NOT_TRUST_FiddlerRoot" certificate?
(B) is/are there any real risk(s) from saying yes specifically to your "DO_NOT_TRUST_FiddlerRoot" certificate?
MORE INFORMATION
it appears the I misinterpreted the documentation at http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp;
I assumed that if I said no, I would simple be prompted each time.
Regards,
Gerry
-Eric
EricLaw
Other applications, including those written in .NET, tend not to do
so.
On Jan 26, 10:34 am, "gerry lowry +1 705 250-0112 alliston ontario
> Thank you, Eric
> -------------------------------------------------------------
> update + follow-up questions:
>
> UPDATE
>
> Yes, Eric ... it appears that not trusting a certificate named "DO_NOT_TRUST_FiddlerRoot" was the problem.
>
> FOLLOW-UP QUESTIONS:
>
> (A)
> Why the crash? i.e.; why am I not simply prompted each time when I choose not to trust the
> "DO_NOT_TRUST_FiddlerRoot" certificate?
>
> (B) is/are there any real risk(s) from saying yes specifically to your "DO_NOT_TRUST_FiddlerRoot" certificate?
>
> MORE INFORMATION
>
> I assumed that if I said no, I would simple be prompted each time.
>
> Regards,
> Gerry
>
>
>
> -----Original Message-----
> From: httpf...@googlegroups.com [mailto:httpf...@googlegroups.com] On Behalf Of EricLaw
> Sent: 2011 January 12 Wednesday 22:12
> To: Fiddler
> Subject: [Fiddler] - 3155 Re: Why does Fiddler2 appear to block WCF Test Client?
>
>
> - Show quoted text -