Encryption

I’d gotten turned on to Cyberduck as my primary FTP/SFTP client after really getting into Growl, the global notification system for Mac OS X.  The application I was using at the time, Fugu, didn’t have Growl support.  Cyberduck did, so I switched, and I’ve been using Cyberduck ever since.

I like the Cyberduck interface; it seems to make sense to me and I’ve never really run into any major compatibility issues (seems like I ran into one minor problem after an upgrade of OpenSSH on one of my servers, but that problem was quickly resolved as I recall).  The Growl support is, of course, excellent, and Cyberduck also offers a veritable laundry list of features—integrated support for Spotlight, a Dashboard widget, Keychain support, multiple windows, etc.  It even comes as a Universal binary.  (The features are far too many to list here; refer to the Cyberduck web site for complete information.)

Sound like a great application?  It is—if you don’t need to transfer large files.  Since I started out just using Cyberduck to move some small web pages back and forth to my web server, these were mostly small files and I didn’t really notice any performance hit.  Sure, it seemed a bit slower than command-line SFTP or SCP and it seemed to be a bit of a memory hog, but I figured it was just GUI overhead and thought no more about it.  For what I was doing at the time, it worked fine.

Recently, though, I’ve been needing to transfer much larger files to and from some SFTP servers on my local LAN.  How large?  ISO images ranging from 300MB to 600MB, sometimes multiple ISO images at a time.  Generally, the file transfers will complete, but they are just plain slow.  Almost painfully slow.  So slow, in fact, that I’ve been driven to looking at alternatives.

I’m currently evaluating Interarchy.  While the interface is a bit quirky (although I suppose that is due to being predisposed to an interface like Cyberduck’s), the performance is astounding.  I can transfer multiple ISO images in minutes, not hours as with Cyberduck.  It’s almost unbelievable.

I have yet to decide whether I’ll just buy Interarchy or if I’ll evaluate two other potential candidates, Transmit and Fetch.  Both applications have gotten good reviews, but—being the UI stickler that I am—neither of them sports as modern a UI as Interarchy (I really like the unified toolbar look).

My primary complaint with Interarchy is the price.  Sixty bucks seems a bit high for this type of application; both Transmit and Fetch (other options to replace Cyberduck) charge about half that.  Of course, the other applications don’t offer the same set of functionality that Interarchy offers, either.  But will I actually use that functionality?  Amazon S3 support is great, but will I really use Amazon S3?  I don’t have a WebDAV server, so is it worth paying for WebDAV support?  Is it worth paying for network tools that duplicate functionality already in the base operating system?

What do you think?  If you are a Fetch, Transmit, Interarchy, Fugu, or even Cyberduck user, please post in the comments and tell me what you think.

The OpenSSL toolkit is a veritable Swiss Army knife of SSL functionality.  Among the many, many things that can be done using OpenSSL is converting SSL certificates between formats.  This is particularly helpful in a heterogeneous environment where different platforms may require SSL certificates to be in different formats.

A mixed Windows-Linux shop is one excellent example.  Windows typically requires certificates in PFX format; Linux, on the other hand, typically needs PEM format.  (See this X.509 article for more information on the PFX and PEM formats.)  Using the OpenSSL toolkit, we can pretty easily convert certificates from PFX to PEM.  Here’s how.

Before we begin, we’ll need to make sure we have the certificate in PFX format with the private key.  In organizations that use the Windows Certificate Services as a CA, we can use the Certificates MMC snap-in to export the certificate and the corresponding private key to a PFX file.  During this process, we’ll be prompted for a passphrase; make note of it, as we’ll need it later in the process.

With our PFX file in hand, we start the conversion process:

1. At a command-line prompt, type “openssl pkcs12 –in pfxfilename.pfx –out tempfile.pem”. This will convert the PFX file to a PEM file. The OpenSSL toolkit will prompt for the import passphrase; this will be the passphrase for the PFX file when the certificate and private key were exported (as mentioned above). OpenSSL will prompt for a new PEM passphrase; be sure to make note of this information as well.
2. Using a text editor, split the PEM file into two separate files, one containing the certificate and one containing the encrypted private key.  Remove all extra text from these files outside the lines with the dashes.
3. Because many Linux-based applications will need the private key decrypted (or they will prompt for the passphrase during service start), we’ll decrypt the private key.  To decrypt the private key, use the command “openssl rsa –in encryptedkey –out decryptedkey” (where encryptedkey is the file containing the RSA private key, as separated above, and decryptedkey is the file that will contain the decrypted RSA private key). The OpenSSL toolkit will prompt for the RSA key passphrase; this will be the PEM passphrase we specified when we first converted the certificate to PEM format above.
4. If the application can use the certificate and the key in separate files, then we’re finished.  If we need to put them back into the same file, then use the command “cat decryptedkey certificatefile > finalfile.pem” (on Mac OS X or Linux) or the command “copy /b decryptedkey+certificatefile finalfile.pem” (on Windows).  This will combine the certificate and the decrypted private key into a single file.  Using a text editor, add a blank line between the decrypted RSA private key and the certificate, and a blank line after the end of the certificate.

The final file is now ready for use with any number of Linux-based applications, such as Stunnel, Apache, Postfix, or others.

UPDATE:  It turns out this is a duplicate post, originally covered earlier here.  Sorry!

Quite a long time ago, I posted two short articles on transparent RDP tunneling (read more here and here).  To be honest, I had forgotten that I hadn’t posted more complete details on how exactly I went about making it work.  So, to rectify that problem, here are the full details.

First, some background.  I have a number of customers whose servers I manage remotely via Remote Desktop.  Remote Desktop (or Terminal Services, if running in Application Server mode), as you may be aware, uses Microsoft’s RDP as the protocol.  Not comfortable using RDP across the Internet, I always encrypted RDP using SSL (typically via Stunnel), but this proved unwieldy as the number of servers increased.  I needed a way that I could use any ordinary RDP client from within my office and transparently tunnel that RDP traffic inside SSL.

<aside>The reason this became unwieldy is due to the number of client-side definitions I had to create on my Mac OS X laptop using SSL Enabler.  After a while, it become difficult to remember which local port corresponded with each remote server.</aside>

So, using OpenBSD (then version 3.7, now version 3.8), I first added some additional IP addresses to the le1 interface by modifying the /etc/hostname.le1 file like so:

inet 192.168.100.1 255.255.0.0
alias 192.168.100.2
alias 192.168.100.3

Using ping, I verified that the new IP addresses were responding, then proceeded to configure Stunnel to accept unencrypted connections and forward them to another host as encrypted connections.  The Stunnel configuration looked something like this:

client = yes
[ms-wbt-server]
accept  = 192.168.100.2:3389
connect = 172.16.100.100:54321

I also had to add the “ms-wbt-server” to the /etc/services file with the appropriate port numbers (3389).

On the other end of the tunnel, Stunnel was set up in reverse—it was configured to receive an encrypted connection on port 54321 (for example) and forward that as an unencrypted connection to the standard RDP port (3389).  The Stunnel configuration looked something like this:

CApath = c:\winnt\system32\stunnel
cert = c:\winnt\system32\stunnel\stunnel.pem
client = no
service = SSLTunnel
[ms-wbt-server-s]
accept = 54321
connect = 3389

Again, the “ms-wbt-server-s” (for “secure”) had to be added to to the services file (on Windows boxes typically located in “C:\winnt\system32\drivers\etc”).  Then I registered Stunnel to run as a service (I believe the command-line was “stunnel -s <config file name>” or similar).  Upon starting the service, I verified that we now had a listening port using “netstat -an”.

When all looked good, I configured any firewalls to pass the appropriate traffic and tested the connection.  Done!  I was now able to connect to one of the internal IP addresses on the OpenBSD server using a standard, unencrypted RDP connection.  That connection was then encrypted in SSL and forwarded across the Internet to a waiting Stunnel instance, where it was decrypted and handed off to the RDP listener.

With a few modifications, this approach could easily be used to create application-specific VPNs between multiple locations within the same organization, or between different organizations.

One of my projects involved the configuration of GRE (Generic Routing Encapsulation) tunnels, encrypted by IPSec, between two locations.  I was having some problems getting the tunnels to work properly, but now I’ve managed to resolve that problem, and the configuration is working well.  Here’s some additional information on the problem and how it was finally corrected.

This was my first project using GRE tunnels.  I’d used IPSec tunnels many times, and on many different platforms, but this time around we needed an interface that could be tracked for HSRP (Hot Standby Router Protocol) purposes, and until recently Cisco didn’t offer IPSec tunnel interfaces.  (I just came across some documentation last night that indicated very recent releases of IOS offer this functionality.)  So, the idea was to use GRE tunnels, track the GRE tunnels using HSRP for failover with another router, and encrypt the traffic using IPSec in transport mode.

The GRE tunnel configuration (scrubbed for sensitive data) looked something like this originally:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1
 crypto map tunnel-ipsec-map

Of course, there was an appropriately configured interface at the other end of the tunnel as well.  The tunnels came up, and appeared to work just fine, until we added the keepalive statement.  (The keepalive statement is required for the tunnel to report an actual up/down status, necessary for HSRP interface tracking.)  Then they went down and stayed down.

A “debug tunnel” statement showed that the keepalives were being sent, but none were being received.  Thinking perhaps the IPSec configuration was incorrect, I removed the “crypto map” statement from the tunnel interface.  It still didn’t work.

After reviewing the configuration again, I began to suspect an MTU issue—the “show int tun0” output listed an MTU of 1514.  I consulted with a Cisco expert (recently obtained his CCIE), and he confirmed that it was most likely an MTU issue.  So I modified the configuration to look like this:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 ip mtu 1400
 keepalive
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1

At that point, the tunnel finally came up and I was able to pass traffic through the tunnel.  I re-added the “crypto map” statement to enforce encryption, and the tunnels promptly went back down again.

Once again, debug output saved the day.  The output from a “debug crypto” statement was constantly reporting “packet too small”.  A search of the Cisco web site turned up a result (I can’t find it now) that indicated a bug within IOS and suggested the addition of a “tunnel key” statement.  So, I modified the configuration again:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 ip mtu 1400
 keepalive
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1
 tunnel key 12345
 crypto map tunnel-ipsec-map

With this configuration, the IPSec/ISAKMP SAs were established and the tunnels came up, passing traffic as expected.  The debug output showed no crypto errors, and keepalives were being sent and received.  Success!

I coined the term “application specific VPNs” as I began exploring the many uses of tools such as SSH (the OpenSSH implementation, in particular) and Stunnel (the open source SSL wrapper).  An “application specific VPN” is a technique for employing encrypted communication with a particular remote application that does not affect the operation of other applications (local or remote) on the system.

In general, most VPNs employ technology such as PPTP or IPSec.  These protocols usually affect all traffic originating from that system (unless we use split tunneling).  With an application specific VPN, only particular types of traffic are affected, and these particular types of traffic are wrapped in an encrypted SSH or SSL tunnel using either OpenSSH or Stunnel, respectively.  Other types of traffic are unaffected.

While this may seem old hat to long-time Linux, Unix, or Mac OS X users, this is a relatively new concept to other platforms.  Being a (fairly) new convert to Mac OS X myself, I found myself enjoying the tremendous flexibility offered by application specific VPNs.  However, this functionality is certainly not limited to these platforms, and it is possible for Windows users to utilize this functionality as well.

Some Examples

Here’s a few examples of how you can use application specific VPNs:

• Citrix Presentation Server:  Users can wrap Citrix ICA traffic in SSL using Stunnel; this avoids the need to pay for commercial solutions (although, quite honestly, the commercial solutions are typically easier to deploy and manage).
• E-Mail:  Lots of people talk about securing e-mail, but not usually in the context of securing client-to-server traffic.  With Stunnel, you can add SSL support for IMAP, POP, and/or SMTP even if the server doesn’t support SSL natively.  In fact, you can add Stunnel to Microsoft Exchange to help bolster that product’s built-in support for SSL (such as using SMTPS instead of STARTTLS for encrypting SMTP traffic).
• Remote Desktop:  This is a great technique for sysadmins.  Need to use Remote Desktop to manage a Windows-based server remotely, but don’t want to run into security problems?  Use Stunnel or OpenSSH to encrypt the RDP traffic.  Stunnel, in my opinion, is particularly good here, since it’s incredibly easy to use the Windows port of Stunnel to establish an SSL listener on an arbitrary high port for this very purpose.

Using Stunnel for SSL-based Application Specific VPNs

On Windows, there is no graphical user interface (GUI) for configuring Stunnel; all configuration must be done with the stunnel.conf configuration file.  A sample stunnel.conf file is found below; this file listens on TCP port 1494 and forwards traffic to TCP port 3389 on the same system. (Note that this would be a sample stunnel.conf file for a server-side configuration.)

CApath = c:\windows\system32\stunnel
cert = c:\windows\system32\stunnel\stunnel.pem
client = no
service = SSLTunnel
[rdp]
accept = 1494
connect = 3389

Once Stunnel has been configured, running “stunnel –install” will install it as a system service; this service can then be stopped and started through the Services MMC console just like any other background service.

Of course, this is only half the work; you’ll also need an equivalent Stunnel configuration on the client side, since the Microsoft RDP client (the Windows version or the Mac OS X version) does not support SSL.  Also, note that the SSL certificate used by Stunnel needs to be in PEM format (which is a nice lead-in to my article discussing the conversion of certificates).

On Mac OS X, there is a graphical utility for managing Stunnel called SSL Enabler.  (Note that I was not able to find a home page for this utility; downloads can be found at various sites.)

On Linux, the configuration again involves editing the stunnel.conf file and launching stunnel (either in the foreground or as a daemon).  I’m not aware of any GUI utilities for configuring Stunnel on Linux, but that certainly doesn’t mean they don’t exist.

Using SSH for Application Specific VPNs

As with Stunnel, it’s also possible to use SSH to create application specific VPNs.  Mac OS X comes with OpenSSH, as do most distributions of Linux and various flavors of BSD.  Windows users can also find various ports of OpenSSH and utilities such as PuTTY that make it possible to use SSH for application specific VPNs as well.

On Mac OS X, the following command in Terminal will create an application specific VPN to encrypt IMAP traffic to a remote server:

ssh -L 1143:imapserver.domain.com:143 -N -f \ user@sshserver.domain.com

This same technique could be used to encrypt WebDAV traffic to a remote web server, other types of mail traffic (POP3 or SMTP, for example), RDP (for Remote Desktop), etc.  Note that it doesn’t work well with HTTP traffic that requires the use of host headers.

There are a few graphical utilities on Mac OS X for managing SSH tunnels; these include SSH Tunnel Manager and AlmostVPN.

Not being a regular day-to-day Linux user (not on the desktop, at least), I don’t know of any SSH tunnel management applications, but I would be very surprised if they didn’t exist.

Creating Site-to-Site Application Specific VPNs

Most of the examples so far have been using SSH and/or Stunnel to connect endpoints (i.e., a single laptop or desktop computer) to a remote resource via an application specific VPN.  However, it’s also easily possible to create application specific site-to-site VPNs, whose purpose is to secure only a particular type of traffic between two locations.

Consider this two example.  CompanyA wants to send e-mail to CompanyB, but wants that e-mail to be secure.  If both mail servers support TLS, then the organizations could use TLS to secure the SMTP traffic.  If not, then the companies can use Stunnel to establish an SSL connection between two systems.  HostA at CompanyA can use Stunnel as a client side application to listen for unencrypted connections and pass them as encrypted connections to HostB at CompanyB.  HostB at CompanyB is using Stunnel to listen for encrypted connections and passes them unencrypted to the mail server at CompanyB.  With a simple configuration, the mail servers at both companies can be configured to pass mail connections for other company through the Stunnel connection.  With no additional cost and very little configuration, all e-mail traffic between the two organizations has now been secured.  All this without the complexity of a typical B-to-B VPN and the associated access controls.

For more information, documents on application specific VPNs with SSH and application specific VPNs with Stunnel are available.

A short while back, I posted an article on Cisco PIX VPN and Active Directory integration.  Now, I’d like to follow that article up with a version looking at integration between Active Directory and WatchGuard Firebox VPNs.

As with the PIX-AD integration document, this article assumes that you have some basic knowledge of how to work with the WatchGuard Firebox series of firewalls.  This article was written using version 6.2 of the WatchGuard Firebox System software and Windows Server 2003; other versions of either the firewall software or Windows should be similar.

Configuring the Firebox

First, we’ll need to setup the Firebox.  Use the Firebox software (Policy Manager, specifically) to perform the following configuration tasks:

• Add the server that is running IAS (or will be running IAS; see below) as a RADIUS server in the Authentication Servers dialog box (found on the Setup menu).  Here, you’ll need to specify the server’s IP address, port number (the default of 1645 will be fine), and the shared secret.
• Instruct the firewall to use RADIUS by going to Setup > Firewall Authentication and selecting “RADIUS” as the authentication type.
• Configure the firewall’s Remote User VPN (on the Network menu) to use RADIUS by checking the “Use RADIUS to authenticate remote users” check box.

Once this is done, proceed with configuring PPTP-based remote user VPNs as usual.  Be sure to add a rule allowing traffic to/from the pptp_users group; otherwise, VPN users will be subject to the same traffic restrictions as Internet users.

Configuring Internet Authentication Service

Before doing anything else, create a new global security group in Active Directory.  Call it “pptp_users”, just like the name of the group on the Firebox.  This is an important part of the glue that will bind the Firebox together with Active Directory.

If IAS is not already installed, install IAS using the Add/Remove Programs icon in Control Panel.

Once it has been installed, launch it from the Administrative Tools folder on the Start Menu and we’ll proceed with configuring it for authenticating VPN connections to the Firebox.

First, we need to grant IAS permission to read dial-in properties from user accounts in Active Directory.  To do this, right-click on the “Internet Authentication Service (Local)” and select “Register Server in Active Directory”.  Select Yes (or OK) if prompted to confirm.  Note that if IAS was already installed, it may have already been registered with Active Directory as well.

With that done, we can now configure the Firebox as a RADIUS client.  Right-click on RADIUS Clients and select New RADIUS Client.  In the wizard, specify the IP address (or DNS name) of the Firebox’s trusted interface and the shared secret.  Note that this shared secret is the same secret key specified when configuring the RADIUS server in the Firebox previously.  RADIUS clients use this to authenticate to RADIUS servers, so make it a reasonably strong password.

Now create a new remote access policy.  Right-click on Remote Access Policies and select New Remote Access Policy.  In the wizard, specify a name, select to create a custom policy, and then add the following conditions to the policy:

• NAS-IP-Address:  This will be the IP address of the Firebox’s trusted interface.  This helps to ensure that this policy only applies to VPN requests from this firewall and not from any other RADIUS client.
• Windows-Groups:  This should be the “pptp_users” security group created earlier.  Any user that should be allowed to authenticate on a VPN connection will need to be a member of this group.

Of course, this policy should grant access.  On the next screen, select “Edit Profile” to edit the remote access profile.  This is important because we’ll need to verify that the RADIUS server is passing the correct information to the Firebox.

On the Advanced tab, remove all the attributes listed there (Service-Type and Framed-Protocol are there by default) and then add the Filter-Id attribute.  To this attribute, add the string value “pptp_users”.  Click OK to save these changes to the profile and then finish creating the policy.

Make this policy the first policy (using the Move Up/Move Down commands in the IAS console), add a user to the group created earlier, and then test your connection.  Remote systems attempting to connect via PPTP should now be able to authenticate the VPN connection using their Active Directory usernames and passwords.

UPDATE:  I’ve updated this entry to correct some errors pointed out in the comments.  Thanks for the feedback!

In my various adventures with replacing Windows-based servers with Linux servers, I have had need on several occasions to take an SSL certificate (generated using Microsoft Certificate Services) and make it available to a Linux-based server.  In some cases, it was to be used by the SSL wrapper Stunnel; in others, it was for Apache.

In either case, the certificate needed to be in the PEM (originally Privacy Enhanced Mail, now a standard for encoding certificates) format.  Windows, on the other hand, typically uses the PFX (PKCS #12) format for storing certificates.  To prepare certificates for use on Linux, the certificates must be converted to PEM format.

In the hopes that this information might be useful to others, here’s a process for converting from PFX to PEM using OpenSSL.  With the exception of only a few items, the process is identical on Linux, Mac OS X, and Windows 2000/2003.  These steps were confirmed using OpenSSL 0.9.7a on Red Hat Linux 9.0, using OpenSSL 0.9.6i on Mac OS X 10.2.8, and OpenSSL 0.9.7c on Windows Server 2003.

1. If the certificate is not already available in PFX format, use the Certificates MMC snap-in to export the certificate and the corresponding private key to a PFX file.  Be sure to note the passphrase used to protect the PFX file; it will be needed later.  If the certificate (and its corresponding private key) is already available in PFX format and the passphrase for the PFX file is known, proceed to step 2.
2. At a terminal prompt, type “openssl pkcs12 –in pfxfilename.pfx –out tempfile.pem”. This will convert the PFX file to a PEM file.  The OpenSSL toolkit will prompt for the import passphrase; this will be the passphrase specified in step 1.  A PEM passphrase will also be needed; make note of the passphrase used here (it will be needed later).
3. Using a text editor (such as vi on a Linux system, or Notepad on a Windows system), split the encrypted RSA private key and the certificate into two separate files.  Remove all extra text, leaving only the text between the lines with the dashes.  Make note of the filenames; they will be needed later.
4. The RSA key is currently encrypted; this will an automated launch for the application using the certificate.  It will be necessary to decrypt the RSA private key.  To decrypt the RSA private key, use the command “openssl rsa –in encryptedkey –out decryptedkey” (where encryptedkey is the file containing the RSA private key, as separated in step 3, and decryptedkey is the file that will contain the decrypted RSA private key).  The OpenSSL toolkit will prompt for the RSA key passphrase; this will be the passphrase specified in step 2.
5. On Linux or Mac OS X:  To concatenate the decrypted RSA private key and the certificate into a single file, use the command “cat decryptedkey certificatefile > finalfile.pem” (where decryptedkey is the decrypted RSA key produced in step 4 and certificatefile is the file containing only the certificate, as produced in step 3).
6. On Windows:  To combine the decrypted RSA private key and the certificate into a single file, use the command “copy /b decryptedkey+certificatefile finalfile.pem” (where decryptedkey is the decrypted RSA key produced in step 4 and certificatefile is the file containing only the certificate, as produced in step 3).
7. Edit the concatenated file (finalfile.pem from step 5) with a text editor to add a blank line between the decrypted RSA private key and the certificate, and a blank line after the end of the certificate.

At this point, the certificate is ready for use.  Be sure to guard the unencrypted private key with extreme caution; loss of this file can result in the compromise of your system.  Note also that most applications require that the certificates be owned by root and readable only by root (“chown root:root” to make them owned by root and “chmod 600” to make them readable only by root).

This is something that only a computer junkie could enjoy.  In conjunction with the FUSE project (now an official part of the Linux kernel as of version 2.6.14), an SSH-wrapped remote filesystems—called sshfs—has been created.

This recent article describes sshfs in a bit more detail and provides some additional information.

So what does this mean?  It means that for any remote system you can reach via SSH, you can mount that remote system’s filesystem inside an SSH tunnel.  I can think of numerous possibilities, not the least of which involves easily updating a web site hosted on a remote web server without having to FTP (or SFTP) the files back and forth.

Now, if only there was a Mac OS X version of sshfs…it’s currently only available for Linux and FreeBSD.

I blogged earlier about my frustration with the Mac OS X Mail.app mail client and its apparent lack of STARTTLS support with IMAP4.  Well, on a whim today I decided to take this issue back up again.

Since Microsoft Exchange does not support STARTTLS, I had to use Perdition as an IMAP proxy in front of Exchange.  Earlier attempts to get Mail.app to do STARTTLS had failed (not sure why), but today I decided to try changing the IMAP port from 993 (the default when you check the “Use SSL” box) to 143 (the standard IMAP4 port).  Oddly enough, it seemed to work!

Curious to find out for sure, I trotted out tcpdump on the mail gateway running Perdition to capture traffic to/from Mail.app and to/from the back end mail server.  The traffic to/from the back end mail server was transmitted in the clear (I used plain text messages so that I could see the content), but the traffic to/from Mail.app was not readable.  I also saw Mail.app issue a CAPABILITY command, then issue a STARTTLS command.  Bingo!

So, it appears that Mail.app does indeed support STARTTLS for IMAP, but only if you set the port number back to 143 after checking the “Use SSL” checkbox.

After some fiddling around with Stunnel on OpenBSD, I got the transparent RDP tunneling inside SSL working.  I still need to run some network captures with Ethereal or similar to make sure that the traffic is encrypted, but I don’t see any reason why it won’t be.  Overall, the process was a bit easier than I expected.  Once I get it better documented, I’ll find an appropriate format in which to distribute the information for others to use in their own networks.