fiddlercore and client certs (upstream to browser)
peter williams
Using fiddlercore, and the .net 4. Sample I setup the application as:
Fiddler.CONFIG.IgnoreServerCertErrors = true;
Fiddler.CONFIG.bDebugCertificateGeneration = true;
// ... but you can allow a specific (even invalid) certificate by implementing and assigning a callback...
FiddlerApplication.OverrideServerCertificateValidation += new OverrideCertificatePolicyHandler(FiddlerApplication_OverrideServerCertificateValidation);
FiddlerApplication.Prefs.SetBoolPref("fiddler.network.streaming.abortifclientaborts", true);
FiddlerApplication.Prefs.SetBoolPref("fiddler.network.https.requestclientcertificate", true);
So, in essence, fiddlercore process is in SSL MITM mode, minting resource server ssl certs on the fly, responding to a resource server client cert authn request (using the profile’s cert file pointer), and, due to the PREF (…requestclientcertificate), is now requesting client authn of the browser. The cert the browser releases to my FiddleCOre process is not being used, however…
Any way to register an event listener for the reception/validation of the _browser’s_ client certificate (enabling me to perform app-layer validation, much like the OverrideCertificatePolicyHandler does for server certs from resource servers?
Any harm in my setting and unsetting
FiddlerApplication.Prefs.SetBoolPref("fiddler.network.https.requestclientcertificate", true);
under program control, per server cert detected in OverrideCertificatePolicyHandler say?
peter williams
X509Certificate2 c = ((Fiddler.BasePipe)(oS.oRequest.pipeClient))._httpsStream.RemoteCertificate
The cert from the browser is available, as above, in a SSL MITM flow. However, _httpsStream is protected member.
Could RemoteCertificate be exposed as property on pipeClient, or could one just expose the entire httpsStream in pipeClient (and pipeServer) with a #ifdef FIDDLERCORE ?
I think its reasonable for users of the core lib to have access to the httpsStream.
--
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
changes.
It would be super helpful to have some idea what you're planning to
build that needs these capabilities. :-)
thanks,
Eric
On Apr 10, 2:19 pm, peter williams <home...@msn.com> wrote:
> X509Certificate2 c =
> ((Fiddler.BasePipe)(oS.oRequest.pipeClient))._httpsStream.RemoteCertificate
>
> The cert from the browser is available, as above, in a SSL MITM flow.
> However, _httpsStream is protected member.
>
> Could RemoteCertificate be exposed as property on pipeClient, or could one
> just expose the entire httpsStream in pipeClient (and pipeServer) with a
> #ifdef FIDDLERCORE ?
>
> I think its reasonable for users of the core lib to have access to the
> httpsStream.
>
> From: httpf...@googlegroups.com [mailto:httpf...@googlegroups.com] On
> Behalf Of peter williams
> Sent: Sunday, April 10, 2011 1:16 PM
> To: 'Fiddler'
> Subject: [Fiddler] - 3474 fiddlercore and client certs (upstream to browser)
>
> Using fiddlercore, and the .net 4. Sample I setup the application as:
>
> Fiddler.CONFIG.IgnoreServerCertErrors = true;
>
> Fiddler.CONFIG.bDebugCertificateGeneration = true;
>
> // ... but you can allow a specific (even invalid)
> certificate by implementing and assigning a callback...
>
> FiddlerApplication.OverrideServerCertificateValidation += new
> eValidation);
>
> FiddlerApplication.Prefs.SetBoolPref("fiddler.network.streaming.abortifclien
> taborts", true);
>
> FiddlerApplication.Prefs.SetBoolPref("fiddler.network.https.requestclientcer
>
> So, in essence, fiddlercore process is in SSL MITM mode, minting resource
> server ssl certs on the fly, responding to a resource server client cert
> authn request (using the profile's cert file pointer), and, due to the PREF
> Any way to register an event listener for the reception/validation of the
> _browser's_ client certificate (enabling me to perform app-layer validation,
> much like the OverrideCertificatePolicyHandler does for server certs from
> resource servers?
>
> Any harm in my setting and unsetting
>
peter williams
Ok last memo for the day!
http://msdn.microsoft.com/en-us/library/system.net.security.localcertificateselectioncallback.aspx
ideally, the _httpsStream object would be made available on the pipeClient, perhaps via a GetHttpsStream method (similar to GetSocket).
Then a FiddlerCore API user can see the remoteCertificate property (i.e. the browser’s client cert), *and* one can set the
string[] acceptableIssuers.
(In the W3C work on https/”WebID”, I need to set acceptableIssuers to empty string, which will hopefully induce FiddlerCore proc, acting as SSL responder for the CONNECT, to no longer list the self-signed certs in the machine root store as those CAs indicating the cert issuers proper for client authn – as is done by default).
From: peter williams [mailto:hom...@msn.com]
Sent: Sunday, April 10, 2011 2:19 PM
To: 'Fiddler'
Subject: RE: [Fiddler] - 3474 fiddlercore and client certs (upstream to browser)
X509Certificate2 c = ((Fiddler.BasePipe)(oS.oRequest.pipeClient))._httpsStream.RemoteCertificate
The cert from the browser is available, as above, in a SSL MITM flow. However, _httpsStream is protected member.
Could RemoteCertificate be exposed as property on pipeClient, or could one just expose the entire httpsStream in pipeClient (and pipeServer) with a #ifdef FIDDLERCORE ?
I think its reasonable for users of the core lib to have access to the httpsStream.
From: httpf...@googlegroups.com [mailto:httpf...@googlegroups.com] On Behalf Of peter williams
Sent: Sunday, April 10, 2011 1:16 PM
To: 'Fiddler'
Subject: [Fiddler] - 3474 fiddlercore and client certs (upstream to browser)
Using fiddlercore, and the .net 4. Sample I setup the application as:
--
peter williams
certs for the web, rather than just using client certs within the intranet
(talking to an STS like ADFS, say).
The last time I did this, I was the chief architect of VeriSIgn (circa 1995)
where we gave a million client certs to folks, testing out S/MIME and https
with client certs. It went nowhere, except in high-end operational theatres
like DoD. It's time to take another look, for strategic reasons (that now
have little to do with crypto, this time around, but to do with exploiting
https URIs in huge data graphs)
The goal is now to harmonize digital id certs (client auth) with the
semantic web, in which validation of the user's client cert is based on
certain semantics of that data web (vs ldap, say). The NT server no longer
just does an AD ldap lookup (and account mapping); it makes a second https
call to the web instead, and does a lookup using an RDF query that uses
logical constraints to prove this and that. (This is just like ldap... but
different!).
As part of that , once the user/cert is authenticated/validated, we have the
usual (classical?) problem of delegation/impersonation - in which one wishes
to enable the SSL server to access resources on behalf of the user, now
identified/authenticated. This is a variant of the SAML impersonation flow,
whicih was a refinement of the Kerberos delegation flow.... and so goes on
the world.
What Ive been doing is using fiddler (and its SSL MITM capability,
repurposed) as a framework for composing these several SSL channels - and
being able to SHOWCASE these interactions. I want to show (and so far have
been VERY successful) that windows as distributed has everything needed -
bar a bit of glue.
Another part of the project reacts of the reality of https, since I was last
involved. https web proxies were supposed to be non-invasive to the crypto
channel. Of course, at corporate firewalls they are actually invasive these
days - which is fine UNTIL one does client authn as we designed it. SSL
MITM at the wbe proxy breaks client authn, beyond the intranet/firewall.
Since there is no point bleating about that, at this point, a javascript
implemented ssl client, running in a browser frame, will now exchange SSL
messages on the first proxy hop over layer 7 messaging, talking to a layer
7/layer 4 bridge that acts as a more conventional web proxy - and allows
END-END signaling of (valid) client authn signatures. Updating https for all
the reality of the world is part of the scope.
If nothing else, expose the RemoteCert of the underlying SSL stream as a
property of the ClientPipe. That cannot hurt. Ideally, let me register a
validation callback property that that same SSL stream, much as you allowed
to verify the server certs of the true resource server. The simplest/fastest
technique is to expose the stream (so I do the work, as API user).
Alternatively, let me register the delegate and access the remotecert
property, scoped to the ClientPIpe (so it hides _httpsStream)
Thanks!
peter williams
would want, in Fiddler, to keep the application at bay from older endpoint
security frameworks. I can see how the SSL stream could be replaced on day
with an alternative, in which perhaps "ws-secureconversationStream" is being
used between browser and the endpoint, rather than SSL - and yet proxy and
resource server are still bridged via SSL.
But we have a strange setup right now (never mind the future). I get the
ability to turn on client auth between browser and MITM client-facing
endpoint (by design), but I cannot see the cert, configure its trust policy,
or validate it in script/code. I don't know, for example, is it subject to
chain trust or peer trust ? If I put some OCSP AIA fields in the cert,
should I expect to see fiddler showing from the CryptoAPI UA some requests
to sites, as the cert or its parents are evaluated by the revocation
policies of the cert trust provider. This would be normal in chain trust.
What I REALLY want to do is quite simple. First, I want the choice of cert
from browser to let me choose in script which cert file is bound the SSL
stream used by fiddle on the proxy->resource server hop. Second, Im
imagining then using a dynamic makecert using that client cert as a
template, replicating the client cert from browser for use by the resource
server much as we replicate the resource server cert for use by the browser!
It's simply symmetric SSL MITM.
-----Original Message-----
From: peter williams [mailto:hom...@msn.com]
Sent: Sunday, April 10, 2011 6:08 PM
To: 'EricLaw'; 'Fiddler'
Subject: RE: [Fiddler] - 3476 Re: - 3474 fiddlercore and client certs
(upstream to browser)
Im working for a W3C project that's taking another look a https and client
certs for the web, rather than just using client certs within the intranet
(talking to an STS like ADFS, say).
peter williams
NOT an ssl client authn event eveny occurred, between browser and fiddler in
SSL MITM mode?
Though I've set the preference to ask for that client authn, I don't know
whether this sets policy on the endpoint to REQUIRE client authn.
Two further alternative suggestions (that don't really change any of today's
system concept):
1. have 2 preferences: clientauthn (optional), clientauthn (required).
2. allow API user to *test* a bool (object.IsAuthenticated()) indicating
whether SSL client authn was done
2 has the property that fiddler doesn't reveal the actual cert asserted by
the user. It simply confirms to the API that some or other cert was asserted
and validated (somehow or other, by fiddlerCore (or not...)).
----
Could you imagine also letting the FiddlerCore API code assign its own
instance of SSLStream to the socket/clientpipe?
-----Original Message-----
From: peter williams [mailto:hom...@msn.com]
Sent: Thursday, April 14, 2011 5:04 AM
To: 'EricLaw'; 'Fiddler'