{"id":33,"date":"2006-07-26T10:46:32","date_gmt":"2006-07-26T15:46:32","guid":{"rendered":"http:\/\/www.nynaeve.net\/?p=33"},"modified":"2019-12-13T17:41:41","modified_gmt":"2019-12-13T22:41:41","slug":"securing-server-and-remote-remote-debugging-sessions","status":"publish","type":"post","link":"http:\/\/www.nynaeve.net\/?p=33","title":{"rendered":"Securing -server and -remote remote debugging sessions"},"content":{"rendered":"

Previously, I’ve discussed the basics of -server and -remote<\/a>, and how to do reverse debugging connections<\/a>.\u00c2\u00a0 This covers most of the interesting functionality for this remote debugging mechanism, with one big exception: securing your remote debugger connection when you are operating over an untrusted network (such as the Internet).<\/p>\n

Used as-is, none of the remote debugging techniques\u00c2\u00a0I have discussed so far provide any real security, other than the inherent difficulty of hijacking a TCP connection.\u00c2\u00a0 Data is sent in plaintext and there is no authentication of potentially sensitive commands that could direct a debugger to do dangerous operations and even potentially take control of the target’s computer if a privileged process is being remotely debugged.<\/p>\n

If you are using the NTSD over KD<\/a> remoting technique, this is usually less of a concern, since you are usually operating over a serial or 1394 cable physically connecting the two computers.\u00c2\u00a0 For plain -server and -remote debugging, or remote.exe debugging<\/a>, however, this problem is more serious as these methods are typically used over networks.<\/p>\n

For remote.exe, there is not all that much that you can do to secure connections.\u00c2\u00a0 The -server and -remote mechanism has a happier tale to tell, however.\u00c2\u00a0 This remoting mechanism does in fact have built-in support for secure connections using both SSL over the TCP transport or SSL over the named pipe transport.\u00c2\u00a0 I’ll primarily cover SSL over TCP, but the general concepts apply to the SSL over named pipe (“SPIPE”) transport as well.\u00c2\u00a0 There is additional support for simple password authentication, for all transports, which I’ll discuss as well.\u00c2\u00a0 However, this only adds a very basic form of protection and usually buys you only minimally more security\u00c2\u00a0than an unpassworded connection.<\/p>\n

To use password authenticated connections, simply append the “password=password<\/em>” parameter to the connection string for both the client and the server.\u00c2\u00a0 For instance, “tcp:port=1234,server=127.0.0.1” becomes “tcp:port=1234,server=127.0.0.1,password=secret”.\u00c2\u00a0 That’s all there is to this mechanism; after using it, both ends must specify the same password or the connection will fail.\u00c2\u00a0 I should emphasize that this again does not really provide strong protection, and the SSL alternatives should usually be used instead.<\/p>\n

The SSL options are slightly more complicated.\u00c2\u00a0 These require a certificate that supports server authentication and is known to both ends of the remote connection.\u00c2\u00a0 The certificate that you use needs to have the “server authentication” role enabled for it.\u00c2\u00a0 Additionally, note that the same<\/em> certificate is needed by both parties; that is, both parties must have the private key for the certificate.\u00c2\u00a0 This makes using the SSL option unfortunately more cumbersome than it could be.\u00c2\u00a0 To get this to work, you will typicallly have to request a server authentication certificate from your domain CA, and then install it (with the private key) on both computers.\u00c2\u00a0 Then, you can use it with SSL or SPIPE remote debugging.<\/p>\n

The general format of an SSL transport connection string is very similar to the TCP transport, with some additional options added.\u00c2\u00a0 For the client, it is in the format of “ssl:port=port<\/em>,proto=ssl-protocol<\/em>,server=server-ip<\/em>,[certuser|machuser]=cert-name-or-thumbprint<\/em>“.\u00c2\u00a0 For a server, use “ssl:port=port<\/em>,proto=ssl-protocol<\/em>,[certuser|machuser]=cert-name-or-thumbprint<\/em>“.\u00c2\u00a0 Remember that the certificate must match for both parties.<\/p>\n

The “proto” parameter specifies which dialect of SSL to use, and can be one of tls1<\/em>, pct1<\/em>, ssl2<\/em>, or ssl3<\/em>.\u00c2\u00a0 The protocol must be the same for both the client and the server.<\/p>\n

The “certuser” parameter specifies either the name (e.g. “Subjectname”) or thumbprint (e.g. “12345689abcdef…”) of a certifcate in the user certificate store.\u00c2\u00a0 Alternative, you can use “machuser” instead of “certuser” to specify that the certificate is contained within the machine store (using “machuser” typically requires that the debugger be run with administrator or localsystem privileges).\u00c2\u00a0 To determine the subject name or thumbprint of a certificate, run mmc.exe, add the “Certificates” snapin for either your user or the computer user (if you are an administrator and want to use “machuser”), locate the certificate you want to use (typically under “Personal\\Certificates”), open the certificate property sheet, and view the “Details” tab.\u00c2\u00a0 The common name (“CN = “) under “Subject” is the subject name you will use, and the hex string under “Thumbprint” is the thumbprint you will use (you only need one).\u00c2\u00a0 If you are using the thumbprint, then remove all spaces between the hex digits when providing the parameter to “certuser” or “machuser”.<\/p>\n

Putting all of these together, once you get the certificate in place on both computers, activating an SSL remote debugging session is basically the same as with a TCP remote debugging session.\u00c2\u00a0 To start an SSL debugging server, you might do this:<\/p>\n

debugger -server ssl:port=1234,proto=tls1,\r\nmachcert=1111111111111111111111111111111111111111<\/pre>\n
Likewise, to start the client, you would use something like this:<\/p>\n
debugger -remote ssl:port=1234,server=127.0.0.1,proto=tls1,\r\nmachcert=1111111111111111111111111111111111111111<\/pre>\n
Afterwards, the debugging connection should operate as any other -server\/-remote session would.\u00c2\u00a0 All of the usual other considerations for -server\/-remote apply to SSL as well; for instance, you can use reverse debugging and you can use “.server” instead of “-server”.<\/p>\n
Because of the difficulty in setting up the certificate for SSL debugging, I usually recommend using something else to secure the remote debugging session other than the built-in SSL support, such as a VPN.<\/p>\n
Next time: Debugger process servers and smart clients.<\/p>\n","protected":false},"excerpt":{"rendered":"
Previously, I’ve discussed the basics of -server and -remote, and how to do reverse debugging connections.\u00c2\u00a0 This covers most of the interesting functionality for this remote debugging mechanism, with one big exception: securing your remote debugger connection when you are operating over an untrusted network (such as the Internet). Used as-is, none of the remote […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/33"}],"collection":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=33"}],"version-history":[{"count":1,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/33\/revisions"}],"predecessor-version":[{"id":666,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/33\/revisions\/666"}],"wp:attachment":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=33"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=33"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=33"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}