Good day!
I develop personal ads blocker on Fiddler.Core. My solution requires two times longer than classic Fiddler or clean browser to complete load page. After profiling problem founded at Fiddler.DefaultCertificateProvider.CreateCert what take 50% resources of solution. Fiddler.DefaultCertificateProvider.CreateCert called by Fiddler.DefaultCertificateProvider.LoadOrCreateCertificate. My certificate installation code is:
#region Certificate preparation
/// <summary>
/// Save and restore root cert and appropriate settings
/// </summary>
private void PrepareCert()
{
// check root cert
if (CertMaker.rootCertExists()) return;
// generate root cert
if (!CertMaker.createRootCert())
throw new InvalidOperationException("Cant create root certificate");
// install root cert
if (!CertMaker.trustRootCert())
throw new InvalidOperationException("Cant trust root certificate");
}
#endregion
This code called on application startup only.
My Fiddler.Core from NuGet.
How to fix this problem?
7 Answers, 1 is accepted
It would be very helpful if you could be much more specific about how many milliseconds you're seeing.
Creating a certificate takes time, potentially a few seconds, depending on the length of the RSA key. Fiddler and FiddlerCore offer three different root certificate generators:
MakeCert (provided by MakeCert.exe)
CertEnroll (used if MakeCert.exe isn't present, on Win7+ only)
BouncyCastle (provided by CertMaker.dll/BCMakeCert.dll)
Each of these takes a different amount of time, and those times are pretty much the same whether you're using Fiddler or FiddlerCore.
The issue that you're encountering is almost certainly the fact that Fiddler creates a root certificate *once*-- when you first enable decryption of HTTPS traffic, then reuses that root on subsequent runs. In contrast your FiddlerCore-based application might end up doing this every time it runs.
When your app runs, what is the information output to the FiddlerApplication.OnNotification event handler with regard to certificate generation?
If you're using BouncyCastle/CertMaker.dll, are you caching the root certificate and private key via a preference? See http://weblog.west-wind.com/posts/2014/Jul/29/Using-FiddlerCore-to-capture-HTTP-Requests-with-NET look for the text :
fiddler.certmaker.bc.cert
Regards,Eric Lawrence
Telerik
Good day, Eric!
Thanks for the quick response. In essence, your questions can report the following.
1) When profiling i use default VS sampling not milliseconds. I refresh same page in browser (certificates must not regenerate) and 45% of 50% take CreateCert from LoadOrCreateCert. I think it mean cert recreation. For cleaning situation i upload my skeleton project with profile report: http://effetto.ru/up/propaganda.zip. It created with VS 2015. You can see report or reprofile by yourself.
2) I know about different root cert generators. But i think problem at root cert generation. My investigation show endpoint cert recreation with same root cert.
3) Even if the root certificate is recreated with each running application, with repeated refresh of the same page in a single session, the application certificate is not exactly recreated.
4) I tested up OnNotification and it says nothing. Event handler was not called.
5) BouncyCastle was not used because it need additional routine.
6) Today i will investigate separate thread for initialization code, may be i will find something.
cert generation. My investigation show endpoint cert recreation with
same root cert.
Ah, i figure out what was wrong and Eric was right but not completely. Deploying MakeCert.exe as part of solution fixes certificate recreation. Rick Strahl wrote a good article about this situation and i googled it today: http://weblog.west-wind.com/posts/2014/Jul/29/Using-FiddlerCore-to-capture-HTTP-Requests-with-NET.
Thanks to Rick and Eric.
Fiddler.FiddlerApplication.OnNotification += delegate(object sender, NotificationEventArgs oNEA) { Console.WriteLine("** NotifyUser: " + oNEA.NotifyString); };
Fiddler.FiddlerApplication.Log.OnLogString += delegate(object sender, LogEventArgs oLEA) { Console.WriteLine("** LogString: " + oLEA.LogString); };
Certificates generated with MakeCert.exe have a number of problems, including the fact that they aren't accepted by some clients (e.g. Android and iOS in particular) and they default to using 1024 bit RSA keys (which may not be accepted by all software for much longer). However, this shorter default key length (vs. 2048 bit keys) does mean that each individual key is faster to generate than 2048 bit keys.
Using BouncyCastle or the CertEnroll mode of the default certificate generator provides the benefit that you can reuse the same key across all of the certificates, instead of generating a new key for every single certificate that is created.
Regards,
Eric Lawrence
Telerik
Good day, Eric!
About logging. Yes, I did on the first line of your sample.
About cert. All nuances that you have noted are not important for my project. My software is desktop private ads blocker for windows only platform. And small key is good for me because of speed.
About BouncyCastle. Did you mean what using this component may speedup endpoint cert generation?
Regards,
Eric Lawrence
Telerik