Production profiling security considerations

time to read 3 min | 548 words

I am currently in the process of building support for the production profiling. The technical part (how to reduce the footprint of the profiler when not profiling) is pretty easy, and I spiked it out in a matter of a few hours. The non technical part has been driving me mad for days.

One of the major issues that I have to deal with with regards to production profiling is the issue of security. There are actually multiple levels to this issue. The most obvious one is that we want to secure who can start profiling. Initially I thought that providing a password and limiting IP range that can connect to the profiling endpoint would be enough, but I quickly realized that I am being overly naive.

The idea that someone can just hook into all the communication that goes on with the database is something that will give any security analyst heart palpitations. Not only do I need to secure access to the endpoint, I also need to ensure that no one can sniff this traffic, as it might very well include sensitive information. Beyond that, just to make sure that the aforementioned security analyst doesn’t show up at my door armed & pissed, it is important that only the system administrator (and not the developers) can turn that on.

That one isn’t so much to catch maliciousness, as much as to prevent people from deploying to production with their debug configuration enabled, but will also stop malicious acts of trying to open up holes in the application.

After some investigation, I decided that I probably want to use SSL (and the SslStream implementation in the BCL) to do that. This has several advantages, it means that the network traffic is encrypted and I can ignore that aspect. It also means that I can take advantage on mutual authentication to ensure that the client is really authorized to do connect to me. Finally, I can also require that the certificate will be installed on the server machine, thus meeting the requirement of the system administrator having to take an explicit step to allow it.

From design perspective, it looks nice, so the next question was to write some code to spike it. I should preface everything that follows with the admission that I have only rudimentary knowledge of the actual details of SSL and certificates. But basically, what I thought was to have the following:

  • Server certificate – self signed, server auth, bound to a particular hostname, not CA.
  • Client certificate – self signed, client auth, bound to a particular hostname, not CA.

The client certificate would need to be added as a trusted root on the server. That would allow mutual authentication between the two parties. The server will reject unknown certs or ones that do not bind to the same hostname as the server cert. I am not sure if I should require that the server cert would have to be installed on the client machine, but I am leaning on not requiring that.

Thoughts? Anything else that I might need to think about? Is this scheme really secure? Is it going to cause the ops people to go mad?