http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660in that case look like you need to roll your own or hook into an existing authentication system. Since you want it to be simple and also cross platform it's probably easier to roll a simple role base authorization system with a simple GUI that the admin can add and remove users at ease. With role base not only you can make sure that only authorize users are monitoring but also know who is doing it. It's a little bit of work up front but I think the admin is also going to be happier :) http://ayende.com/4350/production-profiling-security-considerations#comment35http://ayende.com/4350/production-profiling-security-considerations#comment35Wed, 06 Jan 2010 23:49:08 GMTKevin, You CAN'T trust someone else to do the right thing when dealing with security http://ayende.com/4350/production-profiling-security-considerations#comment34http://ayende.com/4350/production-profiling-security-considerations#comment34Tue, 05 Jan 2010 19:10:38 GMTObviously there's no way to deduce the sensitive columns automatically. I was assuming a configurable policy to identify the sensitive ones. http://ayende.com/4350/production-profiling-security-considerations#comment33http://ayende.com/4350/production-profiling-security-considerations#comment33Tue, 05 Jan 2010 18:49:27 GMTKevin, Sure, give me a general way to detect sensitive columns in arbitrary SQL. In one of my systems the following gave you the credit card information: select [2A871673-FBF4-4540-8F1D-89185A600119] from [2E113364-8E5D-40E5-8AE4-C7788C038488] In some systems, email is considered sensitive, and there is a host of other stuff like that. Trusting the developers to tell me about sensitive columns doesn't work either. http://ayende.com/4350/production-profiling-security-considerations#comment32http://ayende.com/4350/production-profiling-security-considerations#comment32Tue, 05 Jan 2010 18:43:24 GMTOutside of network security, have you considered the ability to "redact" sensitive data from the trace stream? E.g. Flag sensitive columns like SSN so they don't show up in the trace output. http://ayende.com/4350/production-profiling-security-considerations#comment31http://ayende.com/4350/production-profiling-security-considerations#comment31Tue, 05 Jan 2010 17:53:47 GMTFirefly, you can also distribute one client certificate to multiple users if that is what you want. http://ayende.com/4350/production-profiling-security-considerations#comment30http://ayende.com/4350/production-profiling-security-considerations#comment30Tue, 05 Jan 2010 15:27:50 GMTFirefly, Yes, and since the handshake is only a very small percentage of the time we will use the connection, the cost of asymmetric encryption isn't really meaningful. And where would you store that password? How do you make sure that only admin can manage that? http://ayende.com/4350/production-profiling-security-considerations#comment29http://ayende.com/4350/production-profiling-security-considerations#comment29Tue, 05 Jan 2010 11:19:03 GMT@Ayende, SSL does both actually, it use asymmetric encryption to do the handshake then it use symmetric to transfer data but I think you know that already. So handing out the password is the same the server doing the handshake but not very convenience to support a large group of disconnected user (i.e. the internet) but for a small group like inside a company I think it work quite well. Maybe I got the wrong perspective on the situation but I figure if it need to be that secure and the data are that sensitive then the number of client is probably small. After all it make no sense to set up all the security only to expose it to the whole company. So I look at it from an administrator perspective. I would rather control a single password and hand them out as necessary than to set up a certificate server. Then again that's just me :) Your clients requirement might be different. http://ayende.com/4350/production-profiling-security-considerations#comment28http://ayende.com/4350/production-profiling-security-considerations#comment28Tue, 05 Jan 2010 10:50:46 GMTDon't forget the overhead SSL produces. We recently had some problems after moving our web service to SSL. We received a '413 Request Entity too large' error. More info here: [blogs.msdn.com/.../...-large-files-using-iis6.aspx](http://blogs.msdn.com/jiruss/archive/2007/04/13/http-413-request-entity-too-large-can-t-upload-large-files-using-iis6.aspx)http://ayende.com/4350/production-profiling-security-considerations#comment27http://ayende.com/4350/production-profiling-security-considerations#comment27Tue, 05 Jan 2010 09:58:22 GMTIn addition to that, you need to consider the issue of acceptance, you want to enable trust for that, otherwise it wouldn't get there in the first place. http://ayende.com/4350/production-profiling-security-considerations#comment26http://ayende.com/4350/production-profiling-security-considerations#comment26Tue, 05 Jan 2010 07:57:19 GMTrumburak, There are many things that may require you to peek with the profiler, not all of them are full crisis mode, which is the only case where you have full & free access. I want to enable no just that case. http://ayende.com/4350/production-profiling-security-considerations#comment25http://ayende.com/4350/production-profiling-security-considerations#comment25Tue, 05 Jan 2010 07:53:58 GMTEven assuming SSL is an easy thing to do in .Net, I wonder if the whole scenario is realistic. If there are perfrormance problems on a production system at customer site you will not limit yourself to watching NHibernate performance with NHProf but you will want to look at various system performance metrics, view application log files, check server configuration and do thousand other thingies. Shortly, you will want almost free access to the production machine and it doesn't matter if NHProf runs on SSL or not since you will be using secure communication channel (VPN?) anyway. I can't imagine a maintenance contract without access to the production machine. http://ayende.com/4350/production-profiling-security-considerations#comment24http://ayende.com/4350/production-profiling-security-considerations#comment24Tue, 05 Jan 2010 07:46:25 GMTCertificates seem to be beyond KISS to me. I'd go for a plain password or even some temporary invitation ticket. http://ayende.com/4350/production-profiling-security-considerations#comment23http://ayende.com/4350/production-profiling-security-considerations#comment23Tue, 05 Jan 2010 07:45:27 GMTFirefly, SSL doesn't do asymmetric encryption, it generates a symmetric key on the fly. And this doesn't take care for the issues related to authentication and making sure that enabling that on production requires an explicit admin step http://ayende.com/4350/production-profiling-security-considerations#comment22http://ayende.com/4350/production-profiling-security-considerations#comment22Tue, 05 Jan 2010 07:31:21 GMTI personally would use Symmetric encryption with a hash from a password... The profiler server is started without a password, any client want to listen need to have the same password. I don't think asymmetric encryption is necessary in this case. Symmetric encryption is much faster and much simpler. http://ayende.com/4350/production-profiling-security-considerations#comment21http://ayende.com/4350/production-profiling-security-considerations#comment21Tue, 05 Jan 2010 07:06:31 GMTBruno, VS remote debugger is generally not installed on production machines, and it is expected that it will be VERY invasive, I do want to run this in production, and I want it to have as little effect as possible http://ayende.com/4350/production-profiling-security-considerations#comment20http://ayende.com/4350/production-profiling-security-considerations#comment20Tue, 05 Jan 2010 05:40:07 GMTJoel, I can assume neither a windows machine nor a domain existing there http://ayende.com/4350/production-profiling-security-considerations#comment19http://ayende.com/4350/production-profiling-security-considerations#comment19Tue, 05 Jan 2010 05:38:58 GMTJames, Do not assume that I am running only on Windows, or that there is even a domain there to allow windows auth. http://ayende.com/4350/production-profiling-security-considerations#comment18http://ayende.com/4350/production-profiling-security-considerations#comment18Tue, 05 Jan 2010 05:37:54 GMTDon't bother building in more security than Visual Studio remote debugger. http://ayende.com/4350/production-profiling-security-considerations#comment17http://ayende.com/4350/production-profiling-security-considerations#comment17Tue, 05 Jan 2010 00:37:13 GMTI must admit I haven't really followed NProf too closely, but since you are using the SslStream class to build the communications channel, I assume that client's will be using the .NET Framework. In this case, why not use NegotiateStream instead and base your authentication mechanism on Kerberos (or NTLM)? This would provide for encryption and signing as well. Furthermore, doing so would allow you to use the client's WindowsIdentity/*Principal to perform role-based access or impersonation. You could then rely on either AD or local accounts for authentication and alleviate the need to manage self-signed certificates. http://ayende.com/4350/production-profiling-security-considerations#comment16http://ayende.com/4350/production-profiling-security-considerations#comment16Mon, 04 Jan 2010 23:04:02 GMTI also don't like the idea of adding the client cert as a trusted root on the server side. With this, the client (or anyone that obtains its private key) will be able to issue certificates with any name that are accepted by the server. You want to "trust" the client as a peer and not as an certification authority. There is a store for this purpose on windows, called "Trusted People" (on an EN install). WCF has a special validation mode that uses this store, however I didn't found a similar functionality for SslStream. Another solution would be to use the RemoteCertificateValidationCallback (passed in the SslStream ctor) and a custom client certificate registry method. http://ayende.com/4350/production-profiling-security-considerations#comment15http://ayende.com/4350/production-profiling-security-considerations#comment15Mon, 04 Jan 2010 23:01:34 GMTSSL using a server cert makes sense to secure the channel, but client certs are going to cause confusion. They're not used very commonly. Why not use Windows auth to assert that the user is in some particular group? You could even make that group configurable so the admin can choose to allow devs on an app-by-app basis or globally for all apps. The admin could use domain groups or local groups. Lots of options and well-understood by admins and devs alike. http://ayende.com/4350/production-profiling-security-considerations#comment14http://ayende.com/4350/production-profiling-security-considerations#comment14Mon, 04 Jan 2010 22:46:41 GMTIt isn't your English, it IS confusing. http://ayende.com/4350/production-profiling-security-considerations#comment13http://ayende.com/4350/production-profiling-security-considerations#comment13Mon, 04 Jan 2010 21:56:07 GMTAyende, I'm sorry for my English :) http://ayende.com/4350/production-profiling-security-considerations#comment12http://ayende.com/4350/production-profiling-security-considerations#comment12Mon, 04 Jan 2010 21:54:18 GMTMaksym, Oh, I am not talking about a Certificate Server, I am talking about a certificate that the server uses. Different things, similar names http://ayende.com/4350/production-profiling-security-considerations#comment11http://ayende.com/4350/production-profiling-security-considerations#comment11Mon, 04 Jan 2010 21:52:50 GMTAyende, I meant that in case Profiler uses client certificates there is need to have Certificate Server installed otherwise customer should buy certificates from SSL Certificate Providers which not appropriate case for many companies. Server certificate could be purchased from third party. As well as I know SSL connection could be established with server certificate only. http://ayende.com/4350/production-profiling-security-considerations#comment10http://ayende.com/4350/production-profiling-security-considerations#comment10Mon, 04 Jan 2010 21:50:45 GMTrumburak, Tunneling in .NET is a piece of cake, you only need SslStream A lot of the time went into figuring out how to work with the certs, which is what would have happened anyway. http://ayende.com/4350/production-profiling-security-considerations#comment9http://ayende.com/4350/production-profiling-security-considerations#comment9Mon, 04 Jan 2010 21:36:01 GMTJustice, The question is how complex it is going to be to maintain that for the average admin. And what will the dev with the parttime admin hat going to do? http://ayende.com/4350/production-profiling-security-considerations#comment8http://ayende.com/4350/production-profiling-security-considerations#comment8Mon, 04 Jan 2010 21:35:08 GMTMaksym, SSL requires a certificate, and in order to allow the _client_ to authenticate, it must be registered. I am not sure you can do SSL without server cert, anyway http://ayende.com/4350/production-profiling-security-considerations#comment7http://ayende.com/4350/production-profiling-security-considerations#comment7Mon, 04 Jan 2010 21:33:47 GMTYou could use stunnel ( [http://stunnel.org](http://stunnel.org)) to tunnel a plain TCP connection through SSL. It supports mutual client-server authentication with certificates and some other options also. This would save you lots of time & effort, I suppose. http://ayende.com/4350/production-profiling-security-considerations#comment6http://ayende.com/4350/production-profiling-security-considerations#comment6Mon, 04 Jan 2010 21:28:54 GMT