Decrypt HTTPS appears to cause SSL handshake error on 64 bit Windows 7 (same version working on XP)
8,688 views
Skip to first unread message
Karlanne99
Jan 19, 2012, 7:36:40 PM1/19/12
to Fiddler
Hi Eric\All,
Fiddler has been an invaluable tool for me over the last year viewing
SSL traffic from a Java application to an external commercial web
service (XML requests\responses). Recently I had a corporate upgrade
from a 32 bit XP machine to a 64 bit Windows 7 machine but can't get
Fiddler intercepting the SSL traffic on the new machine with the same
setup.
When "Decrypt HTTPS traffic" is off, the Java application works fine
(I see the "Tunnel to" connections in Fiddler), but when I turn on
that flag I'm getting "Remote host closed connection during handshake"
exceptions in the Java app's log.
I thought it might be something to do with different Fiddler versions,
so upgraded to the same version on my XP machine (2.3.8.3) and it
works great! (Same Fiddler version, same Fiddler settings, same Java
app, same config, same web service called etc). Just can't see what's
different in the setup that is causing the issue on Windows 7 machine!
I've turned on SSL handshake debugging in Java App (see below). I'm
not too familiar with the SSL protocol, so hoping someone understand
what's going wrong. Appreciate any help (besides stick to the XP
machine :)
One difference I have noticed, when that flag is off Fiddler shows "A
SSLv3-compatible ClientHello handshake was found", when that flag is
on Fiddler shows "A SSLv2-compatible ClientHello handshake was found",
does this make sense to you?
Cheers,
Karl.
Details below:
Fiddler Web Debugger (v2.3.8.3)
Built: 13 January 2012
Capture HTTPS CONNECTS: On
Decrypt HTTPS traffic (from all processes): On
Ignore server certificate errors: On
JDK: 1.6.0_29 (tried both 32 bit and 64 bit)
Fiddler Root Cert added to cacerts file as trusted CA
Java's SSL Handshake Debug Info (cut out the adding of all the other
certs from info below):
eyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Program Files (x86)\Java\jdk1.6.0_29\jre\lib\security
\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created by
http://www.fiddler2.com
Issuer: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created by
http://www.fiddler2.com
Algorithm: RSA; Serial number: 0x2b80c3d2da1e38924415940c7ee0a041
Valid from Thu Jan 12 00:00:00 GMT 2012 until Tue Jan 11 23:59:59
GMT 2022
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(120000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1326945876 bytes = { 121, 110, 139, 121, 50, 159,
225, 75, 213, 123, 46, 107, 8, 254, 47, 84, 146, 109, 2, 199, 199,
186, 221, 37, 14, 18, 22, 48 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote
host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(120000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1326945877 bytes = { 47, 73, 34, 138, 173, 3, 170,
59, 46, 120, 163, 141, 74, 154, 79, 124, 53, 61, 178, 70, 120, 212,
34, 152, 255, 178, 89, 172 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote
host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
Java App's log:
org.apache.axis2.AxisFault: Remote host closed connection during
handshake
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
83)
at
org.apache.axis2.transport.http.AxisRequestEntity.writeRequest(AxisRequestEntity.java:
84)
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:
499)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:
2114)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:
1096)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:
398)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:
171)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
397)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
346)
at
org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:
542)
at
org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:
189)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:
75)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:
371)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:
209)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:
401)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:
228)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:
163)
...etc etc
Caused by: com.ctc.wstx.exc.WstxIOException: Remote host closed
connection during handshake
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:313)
at
org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWriter.java:
146)
at
org.apache.axiom.om.impl.MTOMXMLStreamWriter.getOutputStream(MTOMXMLStreamWriter.java:
394)
at com.barra.cp.bdtbeans.BDTServiceStub
$37.serialize(BDTServiceStub.java:8083)
at
org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:
664)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:
918)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
947)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:
240)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:
228)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
947)
at
org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:
471)
at
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
79)
... 23 more
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed
connection during handshake
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:
849)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:
1170)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:
637)
at
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:
88)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at
org.apache.commons.httpclient.ChunkedOutputStream.flush(ChunkedOutputStream.java:
191)
at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:99)
at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:
214)
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311)
... 34 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:
333)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:
830)
... 43 more
When Decrpt HTTPS Traffic is off, this is what I see in Fiddler:
Request:
CONNECT <external_host_name_here>:443 HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.1
Host: external_host_name_here
Proxy-Connection: Keep-Alive
A SSLv2-compatible ClientHello handshake was found. Fiddler extracted
the parameters below.
Major Version: 3
Minor Version: 1
Random: 4F 18 AE 01 04 3E EC 41 E5 CA 42 2A E9 51 E3 2A 7E 3F 84 F9 D0
26 13 B2 5D 7D 4C 18 B9 47 CE DB
SessionID: empty
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[10080] SSL2_RC4_128_WITH_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[002F] TLS_RSA_AES_128_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[700C0] SSL2_DES_192_EDE3_WITH_MD5
[0016] SSL_DHE_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[60040] SSL2_DES_64_WITH_MD5
[0015] SSL_DHE_RSA_WITH_DES_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[20080] SSL2_RC4_128_EXPORT40_WITH_MD5
[0008] SSL_RSA_EXPORT_WITH_DES40_SHA
[0014] SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
[0011] SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Response:
HTTP/1.1 200 Connection established
EndTime: 23:58:02.207
ClientToServerBytes: 3237
ServerToBytes: 3145
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
To view the encrypted sessions inside this tunnel, enable the Tools >
Fiddler Options > HTTPS > Decrypt HTTPS traffic option.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted
the parameters below.
Major Version: 3
Minor Version: 1
SessionID: 7C 21 9E 09 2B 49 A1 5B 12 B2 C3 18 AE 2D 3E D9 7F FE B3 1C
F3 68 ED CE 78 E6 95 F3 8F F0 9F 06
Random: 87 85 3A 61 3A 94 BC BA C7 7F 5B 89 65 8C 2E C6 D8 F0 9B 83 B3
2D 54 8E A5 B6 DB E1 71 22 CB D1
Cipher: 0x04
When Decrypt HTTPS traffic is on, this is what I see
Request:
Host: <external_host_name_here>
Proxy-Connection: Keep-Alive
A SSLv2-compatible ClientHello handshake was found. Fiddler extracted
the parameters below.
Major Version: 3
Minor Version: 1
Random: 4F 18 B4 C1 74 6B 4A 89 E6 54 E7 4D 0A 26 0F D9 BA 55 66 79 D0
7A 92 59 53 95 46 12 79 44 82 F9
SessionID: empty
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[10080] SSL2_RC4_128_WITH_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[002F] TLS_RSA_AES_128_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[700C0] SSL2_DES_192_EDE3_WITH_MD5
[0016] SSL_DHE_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[60040] SSL2_DES_64_WITH_MD5
[0015] SSL_DHE_RSA_WITH_DES_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[20080] SSL2_RC4_128_EXPORT40_WITH_MD5
[0008] SSL_RSA_EXPORT_WITH_DES40_SHA
[0014] SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
[0011] SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Response:
HTTP/1.1 200 Connection established
Fiddler has been an invaluable tool for me over the last year viewing
SSL traffic from a Java application to an external commercial web
service (XML requests\responses). Recently I had a corporate upgrade
from a 32 bit XP machine to a 64 bit Windows 7 machine but can't get
Fiddler intercepting the SSL traffic on the new machine with the same
setup.
When "Decrypt HTTPS traffic" is off, the Java application works fine
(I see the "Tunnel to" connections in Fiddler), but when I turn on
that flag I'm getting "Remote host closed connection during handshake"
exceptions in the Java app's log.
I thought it might be something to do with different Fiddler versions,
so upgraded to the same version on my XP machine (2.3.8.3) and it
works great! (Same Fiddler version, same Fiddler settings, same Java
app, same config, same web service called etc). Just can't see what's
different in the setup that is causing the issue on Windows 7 machine!
I've turned on SSL handshake debugging in Java App (see below). I'm
not too familiar with the SSL protocol, so hoping someone understand
what's going wrong. Appreciate any help (besides stick to the XP
machine :)
One difference I have noticed, when that flag is off Fiddler shows "A
SSLv3-compatible ClientHello handshake was found", when that flag is
on Fiddler shows "A SSLv2-compatible ClientHello handshake was found",
does this make sense to you?
Cheers,
Karl.
Details below:
Fiddler Web Debugger (v2.3.8.3)
Built: 13 January 2012
Capture HTTPS CONNECTS: On
Decrypt HTTPS traffic (from all processes): On
Ignore server certificate errors: On
JDK: 1.6.0_29 (tried both 32 bit and 64 bit)
Fiddler Root Cert added to cacerts file as trusted CA
Java's SSL Handshake Debug Info (cut out the adding of all the other
certs from info below):
eyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Program Files (x86)\Java\jdk1.6.0_29\jre\lib\security
\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created by
http://www.fiddler2.com
Issuer: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created by
http://www.fiddler2.com
Algorithm: RSA; Serial number: 0x2b80c3d2da1e38924415940c7ee0a041
Valid from Thu Jan 12 00:00:00 GMT 2012 until Tue Jan 11 23:59:59
GMT 2022
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(120000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1326945876 bytes = { 121, 110, 139, 121, 50, 159,
225, 75, 213, 123, 46, 107, 8, 254, 47, 84, 146, 109, 2, 199, 199,
186, 221, 37, 14, 18, 22, 48 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote
host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(120000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1326945877 bytes = { 47, 73, 34, 138, 173, 3, 170,
59, 46, 120, 163, 141, 74, 154, 79, 124, 53, 61, 178, 70, 120, 212,
34, 152, 255, 178, 89, 172 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote
host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
Java App's log:
org.apache.axis2.AxisFault: Remote host closed connection during
handshake
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
83)
at
org.apache.axis2.transport.http.AxisRequestEntity.writeRequest(AxisRequestEntity.java:
84)
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:
499)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:
2114)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:
1096)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:
398)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:
171)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
397)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
346)
at
org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:
542)
at
org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:
189)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:
75)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:
371)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:
209)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:
401)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:
228)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:
163)
...etc etc
Caused by: com.ctc.wstx.exc.WstxIOException: Remote host closed
connection during handshake
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:313)
at
org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWriter.java:
146)
at
org.apache.axiom.om.impl.MTOMXMLStreamWriter.getOutputStream(MTOMXMLStreamWriter.java:
394)
at com.barra.cp.bdtbeans.BDTServiceStub
$37.serialize(BDTServiceStub.java:8083)
at
org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:
664)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:
918)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
947)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:
240)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:
228)
at
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
947)
at
org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:
471)
at
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
79)
... 23 more
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed
connection during handshake
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:
849)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:
1170)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:
637)
at
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:
88)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at
org.apache.commons.httpclient.ChunkedOutputStream.flush(ChunkedOutputStream.java:
191)
at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:99)
at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:
214)
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311)
... 34 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:
333)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:
830)
... 43 more
When Decrpt HTTPS Traffic is off, this is what I see in Fiddler:
Request:
CONNECT <external_host_name_here>:443 HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.1
Host: external_host_name_here
Proxy-Connection: Keep-Alive
A SSLv2-compatible ClientHello handshake was found. Fiddler extracted
the parameters below.
Major Version: 3
Minor Version: 1
Random: 4F 18 AE 01 04 3E EC 41 E5 CA 42 2A E9 51 E3 2A 7E 3F 84 F9 D0
26 13 B2 5D 7D 4C 18 B9 47 CE DB
SessionID: empty
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[10080] SSL2_RC4_128_WITH_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[002F] TLS_RSA_AES_128_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[700C0] SSL2_DES_192_EDE3_WITH_MD5
[0016] SSL_DHE_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[60040] SSL2_DES_64_WITH_MD5
[0015] SSL_DHE_RSA_WITH_DES_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[20080] SSL2_RC4_128_EXPORT40_WITH_MD5
[0008] SSL_RSA_EXPORT_WITH_DES40_SHA
[0014] SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
[0011] SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Response:
HTTP/1.1 200 Connection established
EndTime: 23:58:02.207
ClientToServerBytes: 3237
ServerToBytes: 3145
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
To view the encrypted sessions inside this tunnel, enable the Tools >
Fiddler Options > HTTPS > Decrypt HTTPS traffic option.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted
the parameters below.
Major Version: 3
Minor Version: 1
SessionID: 7C 21 9E 09 2B 49 A1 5B 12 B2 C3 18 AE 2D 3E D9 7F FE B3 1C
F3 68 ED CE 78 E6 95 F3 8F F0 9F 06
Random: 87 85 3A 61 3A 94 BC BA C7 7F 5B 89 65 8C 2E C6 D8 F0 9B 83 B3
2D 54 8E A5 B6 DB E1 71 22 CB D1
Cipher: 0x04
When Decrypt HTTPS traffic is on, this is what I see
Request:
Host: <external_host_name_here>
Proxy-Connection: Keep-Alive
A SSLv2-compatible ClientHello handshake was found. Fiddler extracted
the parameters below.
Major Version: 3
Minor Version: 1
Random: 4F 18 B4 C1 74 6B 4A 89 E6 54 E7 4D 0A 26 0F D9 BA 55 66 79 D0
7A 92 59 53 95 46 12 79 44 82 F9
SessionID: empty
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[10080] SSL2_RC4_128_WITH_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[002F] TLS_RSA_AES_128_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[700C0] SSL2_DES_192_EDE3_WITH_MD5
[0016] SSL_DHE_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[60040] SSL2_DES_64_WITH_MD5
[0015] SSL_DHE_RSA_WITH_DES_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[20080] SSL2_RC4_128_EXPORT40_WITH_MD5
[0008] SSL_RSA_EXPORT_WITH_DES40_SHA
[0014] SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
[0011] SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Response:
HTTP/1.1 200 Connection established
EricLaw
Jan 19, 2012, 9:54:42 PM1/19/12
to Fiddler
That's odd.
If you edit Rules > Customize Rules and add the following to the
Main() function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
...do you see any change?
> Subject: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created byhttp://www.fiddler2.com
> Issuer: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created byhttp://www.fiddler2.com
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
> 83)
> at
> org.apache.axis2.transport.http.AxisRequestEntity.writeRequest(AxisRequestEntity.java:
> 84)
> at
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:
> 499)
> at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:
> 398)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:
> 371)
> at
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:
> 401)
> at
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:
> 664)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:
> 918)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
> 947)
> at
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:
> 240)
> at
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:
> 228)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
> 947)
> at
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:
> 471)
> at
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
If you edit Rules > Customize Rules and add the following to the
Main() function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
...do you see any change?
> Issuer: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created byhttp://www.fiddler2.com
> 83)
> at
> org.apache.axis2.transport.http.AxisRequestEntity.writeRequest(AxisRequestEntity.java:
> 84)
> at
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:
> 499)
> at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:
> 2114)
> at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:
> 1096)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:
> at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:
> 1096)
> at
> 398)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:
> 171)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 397)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 346)
> at
> org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 397)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 346)
> at
> 542)
> at
> org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:
> 189)
> at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:
> 75)
> at
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:
> at
> org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:
> 189)
> at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:
> 75)
> at
> 371)
> at
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:
> 209)
> at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
> at
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:
> at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
> at
> 401)
> at
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:
> 228)
> at
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:
> 163)
> ...etc etc
> Caused by: com.ctc.wstx.exc.WstxIOException: Remote host closed
> connection during handshake
> at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:313)
> at
> org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWriter.java:
> 146)
> at
> org.apache.axiom.om.impl.MTOMXMLStreamWriter.getOutputStream(MTOMXMLStreamWriter.java:
> at
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:
> 163)
> ...etc etc
> Caused by: com.ctc.wstx.exc.WstxIOException: Remote host closed
> connection during handshake
> at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:313)
> at
> org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWriter.java:
> 146)
> at
> 394)
> at com.barra.cp.bdtbeans.BDTServiceStub
> $37.serialize(BDTServiceStub.java:8083)
> at
> org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:
> at com.barra.cp.bdtbeans.BDTServiceStub
> $37.serialize(BDTServiceStub.java:8083)
> at
> 664)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:
> 918)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
> 947)
> at
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:
> 240)
> at
> org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:
> 228)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:
> 947)
> at
> org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:
> 471)
> at
> org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:
> 79)
> ... 23 more
> Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed
> connection during handshake
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:
> 849)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:
> ... 23 more
> Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed
> connection during handshake
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:
> 849)
> at
> 1170)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:
> 637)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:
> 88)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
> 65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
> org.apache.commons.httpclient.ChunkedOutputStream.flush(ChunkedOutputStream.java:
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:
> 637)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:
> 88)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
> 65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
EricLaw
Jan 19, 2012, 10:20:50 PM1/19/12
to Fiddler
Actually, the line probably should be:
CONFIG.oAcceptedClientHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -
CONFIG.oAcceptedClientHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
>
> read more »- Hide quoted text -
>
> - Show quoted text -
EricLaw
Jan 19, 2012, 10:22:20 PM1/19/12
to Fiddler
Oh, also, can you send me the text of Fiddler's LOG tab for this
scenario? Thx!
scenario? Thx!
Karlanne99
Jan 20, 2012, 6:19:32 AM1/20/12
to Fiddler
Hi Eric,
Thanks for the quick response!
That Customize Rule didn't make any difference. Hadn't thought
about .Net framework but both machines appear to be at 4.0.30319
With the "Decrypt HTTPS" on I see the following in the LOG tab (don't
see any messages when that flag is off)
-= Fiddler Event Log =-
See http://www.fiddler2.com/redir/?id=FiddlerLog for details.
09:33:28:1937 Fiddler Running...
09:34:18:0097 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:18:3937 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:18:7968 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:19:1898 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:20:8150 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:21:2090 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:21:5990 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:21:9851 Secure client pipe failed: The credentials supplied to
the package were not recognized.
(The Java app attempts to make 8 calls).
I was wrong with regards my "SSLv2-compatible" comment, so that might
be a Red Herring. When "Decrypt HTTPS" is off, the first "Tunnel to"
connection shows "A SSLv2-compatible ClientHello handshake was found.
Fiddler extracted the parameters below" and all subsequent "Tunnel to"
conenctions show "A SSLv3-compatible ClientHello handshake was found.
Fiddler extracted the parameters below.". I see the same behaviour on
the XP box.
When "Decrypt HTTPS" is on, I see 8 "Tunnel to" connections and all
show "A SSLv2-compatible ClientHello handshake was found. Fiddler
extracted the parameters below". All 8 attempts lead to a
"javax.net.ssl.SSLHandshakeException" in the Java app logs, but
Fiddler shows only the following in the response (and 200 in the
Result column):
"HTTP/1.1 200 Connection established"
On the XP box, the same 8 "Tunnel to" connections show the following
in the response:
"HTTP/1.1 200 Connection established
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS
Decryption is enabled in Fiddler, so decrypted sessions running in
this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls
Cipher: Rc4 128bits
Hash Algorithm: Md5 128bitsKey Exchange: RsaSign 2048bits
== Server Certificate ==========
[Subject]
CN=<external_host_name_here>:, O=<external_org_name_here>, L=New
York, S=New York, C=US
[Issuer]
CN=Entrust Certification Authority - L1C, OU="(c) 2009 Entrust,
Inc.", OU=www.entrust.net/rpa is incorporated by reference,
O="Entrust, Inc.", C=US
[Serial Number]
4C1B6952
[Not Before]
20/10/2011 21:54:24
[Not After]
22/10/2014 01:50:25
[Thumbprint]
3939AE4A266096F9E893FEA3868CEC164948DACC"
Cheers,
Karl.
Thanks for the quick response!
That Customize Rule didn't make any difference. Hadn't thought
about .Net framework but both machines appear to be at 4.0.30319
With the "Decrypt HTTPS" on I see the following in the LOG tab (don't
see any messages when that flag is off)
-= Fiddler Event Log =-
See http://www.fiddler2.com/redir/?id=FiddlerLog for details.
09:33:28:1937 Fiddler Running...
09:34:18:0097 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:18:3937 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:18:7968 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:19:1898 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:20:8150 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:21:2090 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:21:5990 Secure client pipe failed: The credentials supplied to
the package were not recognized.
09:34:21:9851 Secure client pipe failed: The credentials supplied to
the package were not recognized.
(The Java app attempts to make 8 calls).
I was wrong with regards my "SSLv2-compatible" comment, so that might
be a Red Herring. When "Decrypt HTTPS" is off, the first "Tunnel to"
connection shows "A SSLv2-compatible ClientHello handshake was found.
Fiddler extracted the parameters below" and all subsequent "Tunnel to"
conenctions show "A SSLv3-compatible ClientHello handshake was found.
Fiddler extracted the parameters below.". I see the same behaviour on
the XP box.
When "Decrypt HTTPS" is on, I see 8 "Tunnel to" connections and all
show "A SSLv2-compatible ClientHello handshake was found. Fiddler
extracted the parameters below". All 8 attempts lead to a
"javax.net.ssl.SSLHandshakeException" in the Java app logs, but
Fiddler shows only the following in the response (and 200 in the
Result column):
"HTTP/1.1 200 Connection established"
On the XP box, the same 8 "Tunnel to" connections show the following
in the response:
"HTTP/1.1 200 Connection established
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS
Decryption is enabled in Fiddler, so decrypted sessions running in
this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls
Cipher: Rc4 128bits
Hash Algorithm: Md5 128bitsKey Exchange: RsaSign 2048bits
== Server Certificate ==========
[Subject]
CN=<external_host_name_here>:, O=<external_org_name_here>, L=New
York, S=New York, C=US
[Issuer]
CN=Entrust Certification Authority - L1C, OU="(c) 2009 Entrust,
Inc.", OU=www.entrust.net/rpa is incorporated by reference,
O="Entrust, Inc.", C=US
[Serial Number]
4C1B6952
[Not Before]
20/10/2011 21:54:24
[Not After]
22/10/2014 01:50:25
[Thumbprint]
3939AE4A266096F9E893FEA3868CEC164948DACC"
Cheers,
Karl.
Karlanne99
Jan 20, 2012, 10:56:11 AM1/20/12
to Fiddler
Hi Eric,
Further update....it's not an issue on the Java side of the house as I
can repeat this through the browsers IE8 (through WinINET) and Firefox
(setting proxy as localhost:8888).
With "Decrypt HTTPS" off I can navigate to "https://
<external_webservice_url>?wsdl" in both browsers.
With "Decrypt HTTPS" on IE reports "Internet Explorer cannot display
the webpage" and FF reports "The connection was interrupted". Again
the "Tunnel to" connection only shows "HTTP/1.1 200 Connection
established" in the response, and the LOG tab shows "Secure client
indicating?)
Over on my XP box, I can navigate to the URL whether "Decrypt HTTPS"
is off or on. When it's on I see the HTTPS connections and decrypted
traffic in the inspectors.
Any ideas on what configuration from the local OS might effect the
Fiddler "Decrypt HTTPS" functionality?
Are there links to older versions that I could test?
(I really need to get Fiddler working on this new machine as ops want
to take the XP machine back, they think I'm making this up :)
Cheers,
Karl.
Windows 7 Fiddler about screen:
"Fiddler Web Debugger (v2.3.8.3)
Built: 13 January 2012
64-bit AMD64, VM: 59.00mb, WS: 70.00mb
.NET 2.0.50727.5448 WinNT 6.1.7601 SP1
You've run Fiddler: 56 times.
Running on: <my_windows7_machine_name>:8888
Listening to: All Adapters
Gateway: Using Script
DHCP/DNS url: http://<internal_ip>/wpad.dat
Config script: http://<internal_host>/wpad.dat
Author: Eric Lawrence (e_law...@hotmail.com)
©2003-2012 Eric Lawrence. All rights reserved."
XP Fiddler about screen:
"Fiddler Web Debugger (v2.3.8.3)
Built: 13 January 2012
32-bit x86, VM: 29.00mb, WS: 36.00mb
.NET 2.0.50727.3625 WinNT 5.1.2600 SP3
You've run Fiddler: 93 times.
Running on: <my_xp_machine_name>:8888
Listening to: All Adapters
Gateway: Using Script
Config script: http://<internal_host>/wpad.dat
Author: Eric Lawrence (e_law...@hotmail.com)
©2003-2012 Eric Lawrence. All rights reserved."
On Jan 20, 11:19 am, Karlanne99 <karlann...@gmail.com> wrote:
> Hi Eric,
>
> Thanks for the quick response!
>
> That Customize Rule didn't make any difference. Hadn't thought
> about .Net framework but both machines appear to be at 4.0.30319
>
> With the "Decrypt HTTPS" on I see the following in the LOG tab (don't
> see any messages when that flag is off)
>
> -= Fiddler Event Log =-
> Seehttp://www.fiddler2.com/redir/?id=FiddlerLogfor details.
> Inc.", OU=www.entrust.net/rpais incorporated by reference,
Further update....it's not an issue on the Java side of the house as I
can repeat this through the browsers IE8 (through WinINET) and Firefox
(setting proxy as localhost:8888).
With "Decrypt HTTPS" off I can navigate to "https://
<external_webservice_url>?wsdl" in both browsers.
With "Decrypt HTTPS" on IE reports "Internet Explorer cannot display
the webpage" and FF reports "The connection was interrupted". Again
the "Tunnel to" connection only shows "HTTP/1.1 200 Connection
established" in the response, and the LOG tab shows "Secure client
pipe failed: The credentials supplied to
the package were not recognized" (do you know what that is
indicating?)
Over on my XP box, I can navigate to the URL whether "Decrypt HTTPS"
is off or on. When it's on I see the HTTPS connections and decrypted
traffic in the inspectors.
Any ideas on what configuration from the local OS might effect the
Fiddler "Decrypt HTTPS" functionality?
Are there links to older versions that I could test?
(I really need to get Fiddler working on this new machine as ops want
to take the XP machine back, they think I'm making this up :)
Cheers,
Karl.
Windows 7 Fiddler about screen:
"Fiddler Web Debugger (v2.3.8.3)
Built: 13 January 2012
.NET 2.0.50727.5448 WinNT 6.1.7601 SP1
You've run Fiddler: 56 times.
Running on: <my_windows7_machine_name>:8888
Listening to: All Adapters
Gateway: Using Script
DHCP/DNS url: http://<internal_ip>/wpad.dat
Config script: http://<internal_host>/wpad.dat
Author: Eric Lawrence (e_law...@hotmail.com)
©2003-2012 Eric Lawrence. All rights reserved."
XP Fiddler about screen:
"Fiddler Web Debugger (v2.3.8.3)
Built: 13 January 2012
.NET 2.0.50727.3625 WinNT 5.1.2600 SP3
You've run Fiddler: 93 times.
Running on: <my_xp_machine_name>:8888
Listening to: All Adapters
Gateway: Using Script
Config script: http://<internal_host>/wpad.dat
Author: Eric Lawrence (e_law...@hotmail.com)
©2003-2012 Eric Lawrence. All rights reserved."
On Jan 20, 11:19 am, Karlanne99 <karlann...@gmail.com> wrote:
> Hi Eric,
>
> Thanks for the quick response!
>
> That Customize Rule didn't make any difference. Hadn't thought
> about .Net framework but both machines appear to be at 4.0.30319
>
> With the "Decrypt HTTPS" on I see the following in the LOG tab (don't
> see any messages when that flag is off)
>
> -= Fiddler Event Log =-
EricLaw
Jan 20, 2012, 1:11:02 PM1/20/12
to Fiddler
This: "Secure client pipe failed: The credentials supplied to
to use the digital certificate created by Fiddler, it was unable to do
so because of a problem in the Windows Security libraries. This could
happen if your certificate store was corrupted, or if some similar
problem occurred.
Your first step should be to try the "Remove Interception
Certificates" button in Fiddler's Tools > Fiddler Options > HTTPS
screen. You can enable the button by disabling decryption, then push
the button, then re-enable decryption. This will regenerate the
Fiddler certificates and you *should* be prompted to trust them.
If this doesn't resolve the issue, then further debugging will be
required. Do you happen to know if there's anything unusual about this
machine? E.g. do you have an Admin that might have set the "Require
FIPS-compliant crypto" group policy?
When you run Fiddler, are you running it as yourself (e.g. not
elevating to Administrator)?
> Author: Eric Lawrence (e_lawre...@hotmail.com)
> > Inc.", OU=www.entrust.net/rpaisincorporated by reference,
the package were not recognized. "
... is the smoking gun. This means that when the .NET Framework tried
to use the digital certificate created by Fiddler, it was unable to do
so because of a problem in the Windows Security libraries. This could
happen if your certificate store was corrupted, or if some similar
problem occurred.
Your first step should be to try the "Remove Interception
Certificates" button in Fiddler's Tools > Fiddler Options > HTTPS
screen. You can enable the button by disabling decryption, then push
the button, then re-enable decryption. This will regenerate the
Fiddler certificates and you *should* be prompted to trust them.
If this doesn't resolve the issue, then further debugging will be
required. Do you happen to know if there's anything unusual about this
machine? E.g. do you have an Admin that might have set the "Require
FIPS-compliant crypto" group policy?
When you run Fiddler, are you running it as yourself (e.g. not
elevating to Administrator)?
> ©2003-2012 Eric Lawrence. All rights reserved."
>
> XP Fiddler about screen:
>
> "Fiddler Web Debugger (v2.3.8.3)
> Built: 13 January 2012
>
> 32-bit x86, VM: 29.00mb, WS: 36.00mb
> .NET 2.0.50727.3625 WinNT 5.1.2600 SP3
>
> You've run Fiddler: 93 times.
>
> Running on: <my_xp_machine_name>:8888
> Listening to: All Adapters
> Gateway: Using Script
> Config script: http://<internal_host>/wpad.dat
>
> Author: Eric Lawrence (e_lawre...@hotmail.com)
>
> XP Fiddler about screen:
>
> "Fiddler Web Debugger (v2.3.8.3)
> Built: 13 January 2012
>
> 32-bit x86, VM: 29.00mb, WS: 36.00mb
> .NET 2.0.50727.3625 WinNT 5.1.2600 SP3
>
> You've run Fiddler: 93 times.
>
> Running on: <my_xp_machine_name>:8888
> Listening to: All Adapters
> Gateway: Using Script
> Config script: http://<internal_host>/wpad.dat
>
Karlanne99
Jan 20, 2012, 4:39:29 PM1/20/12
to Fiddler
Hi Eric,
Yeah I tried all those different combinations already today with no
joy
- removed all the Fiddler generated certs in Personal cert store in IE
and the Fiddler Root cert and then re-installed the Root cert (the
certs generated look fine to me).
Just for clarity - when I agree to trust the Fiddler cert it puts the
"DO_NOT_TRUST_FiddlerRoot" cert into both my Personal and Trusted Root
Certification Authorities store, presume that is expected behaviour?
(I've also manually added it to Trusted Publishers to no avail).
I've tried running Fiddler as administrator (I'm part of admin group
on machine) on the machine to no avail also.
I have repeated the issue on a colleague's Windows 7 machine - he had
never enabled SSL decryption previously on his Fiddler, so no
corrupted certs etc (doubt both our machines have a corrupted cert
store), and he couldn't navigate to the same URL with "Decrypt HTTPS"
on. He had an XP machine he could remote to, installed same version of
Fiddler, trusted Fiddler cert, enabled "Decrypt HTTPS" and no problems
viewing SSL traffic!
Appears to have somethign to do with our Windows 7 build. I checked
the "System crytography: Use FIPS compliant algorithms for encryptio,
hashing, and signing" setting in my Local Policy, it is disabled. I'll
ask our Admin guys do they know if there are any special in our group
policy settings around security.
Presume the Windows\IE cert store is embedded, any way I could take my
XP one and replace my Windows 7 one with it? Anything else I can do to
debug this?
Cheers,
Karl.
> > > Inc.", OU=www.entrust.net/rpaisincorporatedby reference,
Yeah I tried all those different combinations already today with no
joy
- removed all the Fiddler generated certs in Personal cert store in IE
and the Fiddler Root cert and then re-installed the Root cert (the
certs generated look fine to me).
Just for clarity - when I agree to trust the Fiddler cert it puts the
"DO_NOT_TRUST_FiddlerRoot" cert into both my Personal and Trusted Root
Certification Authorities store, presume that is expected behaviour?
(I've also manually added it to Trusted Publishers to no avail).
I've tried running Fiddler as administrator (I'm part of admin group
on machine) on the machine to no avail also.
I have repeated the issue on a colleague's Windows 7 machine - he had
never enabled SSL decryption previously on his Fiddler, so no
corrupted certs etc (doubt both our machines have a corrupted cert
store), and he couldn't navigate to the same URL with "Decrypt HTTPS"
on. He had an XP machine he could remote to, installed same version of
Fiddler, trusted Fiddler cert, enabled "Decrypt HTTPS" and no problems
viewing SSL traffic!
Appears to have somethign to do with our Windows 7 build. I checked
the "System crytography: Use FIPS compliant algorithms for encryptio,
hashing, and signing" setting in my Local Policy, it is disabled. I'll
ask our Admin guys do they know if there are any special in our group
policy settings around security.
Presume the Windows\IE cert store is embedded, any way I could take my
XP one and replace my Windows 7 one with it? Anything else I can do to
debug this?
Cheers,
Karl.
Karlanne99
Jan 20, 2012, 7:01:27 PM1/20/12
to Fiddler
Hi Eric,
I finally got this working, phew! Nothing to do with Windows 7 or XP,
that was a red herring.
It's the certs being generated by version v2.3.8.3 (Built: 13 January
2012). Since you pointed out the smoking gun, I removed all the
Fiddler certs again from the Windows 7 machine. Exported the certs
from the XP machine (the Fiddler Root cert and the generated cert
+private key for the external host as a pfx file). I manually imported
them into my Windows 7 machine's cert stores (Personal and Trusted
Root Certification Authorities store), no problem decrypting SSL from
the browsers after that. Put the XP's Fiddler Root into my Java's
trusted cacert store and can decrypt SSL from Java app now also.
The XP's Fiddler Root cert and generated personal cert for the
external host were created using an older version of Fiddler
(v2.3.0.6). When I upgraded to v2.3.8.3 on the XP machine I never
regenerated those certs, hence why version v2.3.8.3 worked on my XP
machine.
Just to prove the theory, I removed all Fiddler certs from the XP
machine, and regerenated them using Fiddler v2.3.8.3, now the XP
machine shows the same SSL handshake issue.
It appears the certs generated by v2.3.8.3 are different somehow to
v2.3.0.6 (did you change some functionality here?)
I can email you the two different pairs of certs if interested.
Anyway, happy days, thanks for the pointers in the right direction!
Cheers,
Karl.
I finally got this working, phew! Nothing to do with Windows 7 or XP,
that was a red herring.
It's the certs being generated by version v2.3.8.3 (Built: 13 January
2012). Since you pointed out the smoking gun, I removed all the
Fiddler certs again from the Windows 7 machine. Exported the certs
from the XP machine (the Fiddler Root cert and the generated cert
+private key for the external host as a pfx file). I manually imported
them into my Windows 7 machine's cert stores (Personal and Trusted
Root Certification Authorities store), no problem decrypting SSL from
the browsers after that. Put the XP's Fiddler Root into my Java's
trusted cacert store and can decrypt SSL from Java app now also.
The XP's Fiddler Root cert and generated personal cert for the
external host were created using an older version of Fiddler
(v2.3.0.6). When I upgraded to v2.3.8.3 on the XP machine I never
regenerated those certs, hence why version v2.3.8.3 worked on my XP
machine.
Just to prove the theory, I removed all Fiddler certs from the XP
machine, and regerenated them using Fiddler v2.3.8.3, now the XP
machine shows the same SSL handshake issue.
It appears the certs generated by v2.3.8.3 are different somehow to
v2.3.0.6 (did you change some functionality here?)
I can email you the two different pairs of certs if interested.
Anyway, happy days, thanks for the pointers in the right direction!
Cheers,
Karl.
EricLaw
Jan 20, 2012, 8:26:05 PM1/20/12
to Fiddler
Very interesting. Yes, please ZIP up the old (and optionally the new)
certs and mail them to me using the Help link in Fiddler. There were
no changes in the flags Fiddler sets on certificates between 2.3.0 and
2.3.8, so there's no reasonable explanation for the behavior you're
reporting.
thanks,
Eric
certs and mail them to me using the Help link in Fiddler. There were
no changes in the flags Fiddler sets on certificates between 2.3.0 and
2.3.8, so there's no reasonable explanation for the behavior you're
reporting.
thanks,
Eric
Peter Williams
Jan 20, 2012, 11:12:41 PM1/20/12
to httpf...@googlegroups.com
the default CSP changed alot between XP and win7. Night and day. Dont look at the cert. Look at the modulus in the subjectPublicKey blog, etc. Java is fussy about RSA (overly rigorous German crypto engineering).
EricLaw
Jan 21, 2012, 12:03:14 PM1/21/12
to Fiddler
His issue is on the .NET side of things; it has nothing to do with
Java.
Java.
Peter Williams
Jan 21, 2012, 12:25:27 PM1/21/12
to httpf...@googlegroups.com
Not an important read. perhaps delete now.
------
it was interesting that you cued onto the client pipe, from the fiddler output . I saw that and made the assumption that the credentials FROM the java UA to the MITM agent were, on invoking said agent's client pipe, somehow not handling the client-originated credentials. I kept thinking about the CLIENT cert from the UAs (not that the text hinted at it being in the scenario), particularly given the earlier focus on the client hellos that are also pre-hints about credential matters, these days
you cued into that message, about the client pipe, as being one of the proxy being unable to construct the client pipe, in some sense. The proposal is that thisis because of a failure to load keys/certs when acting as the SSL server endpoint for that pipe. The argument ventured is that something in the handover (via .p12) of the keying means that the SSL server endpoints on the pipes for different versionss of windows behave differently.
The thought that perhaps the CSP (or other windows security libraries) are configured differently seemed sound. This is what I was trying to get at. Ive seen this class of thing before, once folks even slightly touch the defaults (like ciphersuite order for schannel, using group policy).
Ive played a lot with certs in schannel on windows... and have encountered lots of multi-vendor quirks, over the years. For example, a cert/key pair minted using openssl and exported/imported via .p12 into certain windows versions doesn't always work, when older cryptoAPI methods are called to instantiate the private key. Its the nature of the modulus that just doesnt fit something about how the underlying provider requires moduluses. I never fixed it or made a formal diagnosis, and always assumed it was something about precison, that offended the provider programmer's assumptions about suitable modulii. Some folks think bit centric and other octet centric and others byte centric, when handling modulus (depending on their degree of math background). (This is all a good cue into the mindset of the egineering, when then attacking code by understanding the traditions of the engineer)
Anyways, your on it. Its always worrying when one sees folks going into an area that seemed to be stressing the SSL upgrade/downgrade countermeasures. This is one the weakest points of the protocol design . Fortunately, the issues looks like something more about implementation than design, at this point.
Karlanne99
Jan 21, 2012, 6:36:23 PM1/21/12
to Fiddler
Hi Eric,
Yes it's also nothing to do with Fiddler 2.3.0 versus 2.3.8 (enough
red herrings to train a pack of hunting dogs on this one! :)
I still have both versions on my XP machine, I removed Fiddler Root
cert and all generated Fiddler personal certs, then I used the older
2.3.0.6 to regenerate Fiddler Root and the personal cert for the
external domain. Now the new ones also fail with SSL Handshake issue
(Secure client pipe failed: The credentials supplied to the package
were not recognized).
So the only certs that work (for this external domain anyway) are the
ones I generated initially back in 2010. These work on all machines I
try them on. All new generated certs on both my XP and Windows 7
machine won't work for the same domain. These are corporate machines
that constantly get patched so hard to work out what was different on
the XP machine back in 2010.
I have emailed you two sets of certs, the old ones that work and the
new ones that fail. If you ever get to the bottom of this would be
very interested in knowing what the issue was, thanks!
Cheers,
Karl.
Yes it's also nothing to do with Fiddler 2.3.0 versus 2.3.8 (enough
red herrings to train a pack of hunting dogs on this one! :)
I still have both versions on my XP machine, I removed Fiddler Root
cert and all generated Fiddler personal certs, then I used the older
2.3.0.6 to regenerate Fiddler Root and the personal cert for the
external domain. Now the new ones also fail with SSL Handshake issue
(Secure client pipe failed: The credentials supplied to the package
were not recognized).
So the only certs that work (for this external domain anyway) are the
ones I generated initially back in 2010. These work on all machines I
try them on. All new generated certs on both my XP and Windows 7
machine won't work for the same domain. These are corporate machines
that constantly get patched so hard to work out what was different on
the XP machine back in 2010.
I have emailed you two sets of certs, the old ones that work and the
new ones that fail. If you ever get to the bottom of this would be
very interested in knowing what the issue was, thanks!
Cheers,
Karl.
EricLaw
Jan 21, 2012, 8:16:30 PM1/21/12
to Fiddler
We've had a look at Karl's setup and it looks like this might be
related to a 3rd party CryptoAPI provider being installed on the
machine. When Fiddler calls MakeCert.exe, it currently does not
specify which provider to use.
> > Anyways, your on it. Its always worrying when one sees folks going into an area that seemed to be stressing the SSL upgrade/downgrade countermeasures. This is one the weakest points of the protocol design . Fortunately, the issues looks like something more about implementation than design, at this point.- Hide quoted text -
related to a 3rd party CryptoAPI provider being installed on the
machine. When Fiddler calls MakeCert.exe, it currently does not
specify which provider to use.
EricLaw
Jan 21, 2012, 9:39:56 PM1/21/12
to Fiddler
We confirmed that the problem was the lack of an -sp parameter when
calling MakeCert. This will be fixed in the next stable release.
Thanks, Karl!
> > - Show quoted text -- Hide quoted text -
calling MakeCert. This will be fixed in the next stable release.
Thanks, Karl!
Eric
Jan 31, 2012, 8:44:04 AM1/31/12
to Fiddler
Would you be able to post the Release version that asa the fix^
EricLaw
Jan 31, 2012, 9:23:11 AM1/31/12
to Fiddler
@Eric: Are you actually having this exact problem?
Eric Lacroix
Jan 31, 2012, 6:25:55 PM1/31/12
to EricLaw, Fiddler
Yes, I do with the latest version on Windows x64 with a 2048 SSL
certificate.
certificate.
-----Message d'origine-----
De : httpf...@googlegroups.com [mailto:httpf...@googlegroups.com] De
la part de EricLaw
Envoyé : 31 janvier 2012 09:23
À : Fiddler
Objet : [Fiddler] - 4798 Re: - 4777 Re: - 4775 Re: Decrypt HTTPS appears to
cause SSL handshake error on 64 bit Windows 7 (same version working on XP)
--
You received this message because you are subscribed to the Google Groups
"Fiddler" group.
To post to this group, send email to httpf...@googlegroups.com.
To unsubscribe from this group, send email to
httpfiddler...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/httpfiddler?hl=en.
EricLaw
Jan 31, 2012, 8:22:03 PM1/31/12
to Fiddler
Sorry, I don't know what that means. What is a 2048 SSL certificate,
and why do you suspect your default CryptoAPI provider has been
changed?
and why do you suspect your default CryptoAPI provider has been
changed?
phil
Feb 17, 2012, 2:17:35 PM2/17/12
to Fiddler
I was seeing this error as well on my x64 Windows 7 laptop. I noticed
in my Security event log Event ID 5061 - Failure Audits:
Cryptographic operation.
Subject:
Security ID: nycmpscal4-dev\paul.xxxxx
Account Name: paul.xxxx
Account Domain: nycmpscal4-dev
Logon ID: 0x5e8bf
Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: Not Available.
Key Name: 1c0d3fda-3c20-4ff5-b187-c69acaf6f0de
Key Type: User key.
Cryptographic Operation:
Operation: Open Key.
Return Code: 0x80090016
When I started to look around at the error code 0x80090016, I cam
across this:
http://support.microsoft.com/kb/939616
I opened my personal cert store and had hundreds of certs issued by
the Fiddler Root CA for various websites that I had traced in the
past. I exported all of the certs from my personal store to a PFX
file and deleted all of the Fiddler issued certs. I am now able to
decrypt content using Fiddler (I am running the 4.3.9 BETA) I see
new certs flowing into my personal cert store issued by the Fiddler
Root CA.
See if that helps you out.
Phil
On Jan 31, 8:22 pm, EricLaw <bay...@gmail.com> wrote:
> Sorry, I don't know what that means. What is a 2048SSLcertificate,
> and why do you suspect your default CryptoAPI provider has been
> changed?
>
> On Jan 31, 3:25 pm, Eric Lacroix <elacr...@devmesh.com> wrote:
>
>
>
>
>
>
>
> > Yes, I do with the latest version on Windows x64 with a 2048SSL
> > certificate.
>
> > -----Message d'origine-----
> > De : httpf...@googlegroups.com [mailto:httpf...@googlegroups.com] De
> > la part de EricLaw
> > Envoyé : 31 janvier 2012 09:23
> > À : Fiddler
> > Objet : [Fiddler] - 4798 Re: - 4777 Re: - 4775 Re: Decrypt HTTPS appears to
> > causeSSLhandshake error on 64 bit Windows 7 (same version working on XP)
> > as theSSLserver endpoint for that pipe. The argument ventured is that
in my Security event log Event ID 5061 - Failure Audits:
Cryptographic operation.
Subject:
Security ID: nycmpscal4-dev\paul.xxxxx
Account Name: paul.xxxx
Account Domain: nycmpscal4-dev
Logon ID: 0x5e8bf
Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: Not Available.
Key Name: 1c0d3fda-3c20-4ff5-b187-c69acaf6f0de
Key Type: User key.
Cryptographic Operation:
Operation: Open Key.
Return Code: 0x80090016
When I started to look around at the error code 0x80090016, I cam
across this:
http://support.microsoft.com/kb/939616
I opened my personal cert store and had hundreds of certs issued by
the Fiddler Root CA for various websites that I had traced in the
past. I exported all of the certs from my personal store to a PFX
file and deleted all of the Fiddler issued certs. I am now able to
decrypt content using Fiddler (I am running the 4.3.9 BETA) I see
new certs flowing into my personal cert store issued by the Fiddler
Root CA.
See if that helps you out.
Phil
On Jan 31, 8:22 pm, EricLaw <bay...@gmail.com> wrote:
> Sorry, I don't know what that means. What is a 2048SSLcertificate,
> and why do you suspect your default CryptoAPI provider has been
> changed?
>
> On Jan 31, 3:25 pm, Eric Lacroix <elacr...@devmesh.com> wrote:
>
>
>
>
>
>
>
> > Yes, I do with the latest version on Windows x64 with a 2048SSL
> > certificate.
>
> > -----Message d'origine-----
> > De : httpf...@googlegroups.com [mailto:httpf...@googlegroups.com] De
> > la part de EricLaw
> > Envoyé : 31 janvier 2012 09:23
> > À : Fiddler
> > Objet : [Fiddler] - 4798 Re: - 4777 Re: - 4775 Re: Decrypt HTTPS appears to
EricLaw
Feb 17, 2012, 2:58:52 PM2/17/12
to Fiddler
Clicking "Remove Interception Certificates" should do that form of
cleanup for you.
> > > For more options, visit this group athttp://groups.google.com/group/httpfiddler?hl=en.- Hide quoted text -
cleanup for you.
phil
Feb 17, 2012, 3:43:54 PM2/17/12
to Fiddler
thanks, it was grayed out till i realized to read and uncheck the
decrypt checkbox. Maybe it would be good if
Eric Lacroix could check that all of the certs are removed when
removing the interception certs.
> > > > For more options, visit this group athttp://groups.google.com/group/httpfiddler?hl=en.-Hide quoted text -
decrypt checkbox. Maybe it would be good if
Eric Lacroix could check that all of the certs are removed when
removing the interception certs.
Matt
Mar 5, 2012, 9:40:13 AM3/5/12
to Fiddler
On Jan 21, 9:39 pm, EricLaw <bay...@gmail.com> wrote:
> We confirmed that the problem was the lack of an -sp parameter when
> callingMakeCert. This will be fixed in the next stable release.
> We confirmed that the problem was the lack of an -sp parameter when
> Thanks, Karl!
>
Any update on when this might be available, even in an alpha form? I'm
working on a client site where they defintely have some 3rd part
crypto stuff installed and this is preventing us from being able to
use Fiddler to debug a pesky problem...
Matt
EricLaw
Mar 7, 2012, 1:16:26 PM3/7/12
to httpf...@googlegroups.com
This update was released weeks ago. You have to set a preference to configure the command line to add the SP parameter.
Andy Weedman
Apr 19, 2012, 2:22:27 PM4/19/12
to httpf...@googlegroups.com
Eric,
What preference do you need to set? I'm having this problem with the most stable build downloaded today from the fiddler website.
EricLaw
Feb 18, 2013, 3:43:18 PM2/18/13
to
You can set fiddler.certmaker.Root.extraparams to the literal string you'd like to have added to makecert's command line. E.g. you can set to -sy 24 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" to pass those flags into makecert.
MakeCert parameters are defined here. Legal values for SP and SY can be found here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider.
Reply all
Reply to author
Forward
0 new messages