Support SSL mutual authentication

[Tom]

Hi,

I've read all the discussion re: client side certificates for SSL.
This involves placing a ClientCertificate.cer in the Fiddler
directory.

I have tried this with little success, as per an earlier posting.

I can't see how it will work with a .cer file that doesn't contain the
private key. This means the client (Fiddler) has no way of proving to
the server that it is the subject of the certificate.


I downloaded Charles proxy to see how it did it. It uses .p12/.pfx
files that contain both the client cert. and its private key. This
makes more sense.

Can you explain how Fiddler supports mutual authentication over SSL?

Thanks,

Tom

[EricLaw]

The article in question is here: http://www.fiddler2.com/fiddler/help/httpsclientcerts.asp

The local CER merely acts as a pointer to a certificate in your
Personal Certificates store-- that certificate, in the Certificates
store, has the private key associated with it and is thus available to
Fiddler.

[peter williams]

In windows land, the term certificate often incorporates handling of the
associated private key. Yes its improper, but for years IT folks struggled
to distinguish the private key from the cert, and then both of those from
the interchange file (p12) that carries both certs and keys.

A cert that is registered with a cert store (having been loaded from an
interchange file) is associated with its private key in a private key
container (if the interchange file provided it). As can any process, Fiddler
can use windows/dotNET APIs to dereference a stored cert given a file path,
and get to a usable private key in a key container. The two then drive the
schannel-based DH/DSA or RSA ciphersuites' client auth on the downstream
https channel.

If the private key is store in a container on the smartcard, smartcard APIs
also get invoked so the smartcard performs the DH/DSA crypto invoked by the
schannel provider.

The next gen crypto architecture in windows makes a lot of the above
somewhat legacy. But, its good, solid (and these days obvious) stuff.

Hi,

Thanks,

Tom

--
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.

[Tom]

Looks like I'm having an SChannel issue. I get the same problem using
a .NET client application. Java works fine.

I haven't had any joy trying to track down the SChannel error.

Here's what shows in Fiddler Response:

HTTP/1.1 502 Connection failed
Connection: close
Timestamp: 08:35:53.187

HTTPS connection failed.

System.Security.Authentication.AuthenticationException: A call to SSPI
failed, see inner exception. --->
System.ComponentModel.Win32Exception: The Local Security Authority
cannot be contacted
--- End of inner exception stack trace ---
at
System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken
message, AsyncProtocolRequest asyncRequest, Exception exception)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer,
Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer,
AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer,
Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer,
AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer,
Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer,
AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean
receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at
System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult
lazyResult)
at Fiddler.ServerPipe.WrapSocketInPipe(Socket oSocket, Boolean
bSecureTheSocket, Boolean bCreateConnectTunnel, String sCertCN, String
sClientCertificateFilename, String sPoolingKey, Int32&
iHTTPSHandshakeTime)
at Fiddler.Session._handleHTTPSConnect()

I get the following in the Windows System Event Log:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-
C8FF68F15C85}" />
<EventID>36888</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2010-11-18T21:35:53.173319400Z" />
<EventRecordID>6683</EventRecordID>
<Correlation />
<Execution ProcessID="716" ThreadID="5112" />
<Channel>System</Channel>
<Computer>MyComputer</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="AlertDesc">80</Data>
<Data Name="ErrorState">301</Data>
</EventData>
</Event>

[EricLaw]

Have you checked to see what cipher the server is using?

My guess is this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx

[Tom]

I did try using just SSL V3.0 rather than TLS 1.0, but no luck via
Fiddler CONFIG and KB article below

This KB: article talks about configuring SChannel to resolve
compatibility issues: http://support.microsoft.com/kb/980436

I'm having problems with my network sniffer

I can see for the Java client that works it is using the
SSL_RSA_WITH_RC4_128_SHA Cipher

I can also see with SChannel debugging that the correct private key is
being retrieved by SChannel

I may try and force SChannel to use the cipher that Java uses

[Tom]

I manged to get rid of the SChannel error in the event log by
disabling the PKCS KeyExchangeAlgorithm for SChannel and only allowing
Diffie-Hellman

I now get:

HTTP/1.1 502 Connection failed
Connection: close

Timestamp: 10:37:54.961

HTTPS connection failed.

System.IO.IOException: Received an unexpected EOF or 0 bytes from the
transport stream.
at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32
offset, Int32 count)
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.ForceAuthentication(Boolean
receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at
System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult
lazyResult)
at Fiddler.ServerPipe.WrapSocketInPipe(Socket oSocket, Boolean
bSecureTheSocket, Boolean bCreateConnectTunnel, String sCertCN, String
sClientCertificateFilename, String sPoolingKey, Int32&
iHTTPSHandshakeTime)
at Fiddler.Session._handleHTTPSConnect()

I'll need to find out what is going on at the server end

[Tom]

It turned out to be an issue with the certficate, and SChannel

The public key of the certficate was 1024 bits, however the high order
bit was zero. Many tools including OpenSSL interpreted it as a 1023
bit key. MS acknowledged that SChannel should have been able to handle
it.

We resolved it by obtaining another certifcate whose high order bit
was one.

To check your certifcate you can use the following openssl command
line:

openssl x509 -text -in MyCerticate.cer

and look for:

RSA Public Key: (1023 bit) This should be 1024 for a
'good' certificate