SSL

A while ago, I discussed the use of Apache to protect OWA from web-based attacks.  This configuration placed an Apache HTTP server in front of a server running Microsoft Exchange Server 2003 to protect it against web-based attacks, offload SSL encryption, and enable name-based virtual hosts (for the conservation of public DNS hostnames, especially important for smaller organizations).  While this is a useful configuration, it is not without its drawbacks.

First, let’s review some of the advantages of this type of configuration:

• You can use the open source mod_security module to protect OWA against virtually all forms of URL-based attacks.  Mod_security is an extremely powerful and useful module that can greatly increase the protection against web-based attacks.  See the mod_security web site for more information.
• Even without mod_security, deploying Apache in front of OWA can protect the OWA server against many IIS-specific attacks.
• This configuration can be used in addition to IIS-specific protection such as URLScan.
• You can terminate the SSL connection at the Apache server instead of on the OWA server, freeing up CPU resources on the OWA server for other tasks (this is especially useful in smaller Exchange deployments where the OWA server may also be a mailbox server).

Now, for some of the disadvantages of this type of configuration:

• Apache lacks the intelligence of an Exchange server configured as a true front-end, and therefore cannot direct requests to multiple back-end mailbox servers.  In this type of configuration, the Apache reverse proxy always directs requests to the same OWA server and cannot determine which mailbox server the user is homed on.
• Organizations with expertise in Microsoft products won’t necessarily see any real benefit from this due to the added overhead and learning curve of supporting Linux and Apache.  (Don’t snicker, this is a real concern for organizations.)

I’m sure there are other disadvantages as well.  Anyone care to comment and share their experiences?

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.

Funambol, formerly Sync4j, is claiming that its latest product, Funambol 3, could function as an open-source Blackberry workaround, allowing push e-mail to be delivered to a variety of mobile devices, including Blackberries.  This is particularly important in light of the threat of a Blackberry shutdown due to the RIM-NTP patent dispute.

Currently in beta, the v3 server software runs on Linux or Windows, and clients are available for Outlook, Windows Mobile, Blackberry, Palm, and (believe it or not) iPod.

More information can be found in this article.

Some people are also suggesting the use of open standards to ease the impact of a potential Blackberry shutdown as well.  While not as functionally rich as a typical Blackberry implementation, the use of POP3/IMAP4 and SMTP to handle mobile messaging needs is certainly very viable.  This is easily implemented via most commercial messaging systems and through a number of open source packages as well.  For example, I use Dovecot and Postfix to provide IMAP4/SMTP support for my Treo, all secured by SSL/TLS encryption.  Like the Funambol approach, this also offers a great deal of client-side variety as well, instead of locking users into a single client device.

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.

Outlook Web Access (OWA) is the web-based interface for accessing e-mail and other resources handled by Microsoft Exchange.  Unfortunately, OWA’s popularity also makes it the target of numerous worms and security exploits.  As a result, many organizations seek to deploy OWA behind a reverse proxy that can help shield OWA from web-based attacks and exploits.  In this posting, I’m going to share information to help build a reverse proxy using Apache 2.0.

Here’s a skeleton of an httpd.conf file to support Apache as a reverse proxy in front of OWA:

NameVirtualHost 1.2.3.4:80
NameVirtualHost 1.2.3.4:443
ProxyRequests Off

<VirtualHost 1.2.3.4:443>
ServerAdmin webmaster@domain.com
ServerName webmail.domain.com
DocumentRoot /var/www/webmail
RequestHeader set Front-End-Https “On”
ProxyRequests Off
ProxyPreserveHost On

SSLEngine On
SSLCertificateFile conf/webmail-ssl-cert.pem

<Location /exchange>
ProxyPass http://mail.domain.com/exchange
ProxyPassReverse http://mail.domain.com/exchange
SSLRequireSSL
</Location>

<Location /exchweb>
ProxyPass http://mail.domain.com/exchweb
ProxyPassReverse http://mail.domain.com/exchweb
SSLRequireSSL
</Location>

<Location /public>
ProxyPass http://mail.domain.com/public
ProxyPassReverse http://mail.domain.com/public
SSLRequireSSL
</Location>

</VirtualHost>

The key portions of this configuration are described below, along with some supporting information.

• NameVirtualHost:  The NameVirtualHost directive enables Apache to use name-based virtual hosts on the specified IP addresses and ports.  The parameter to the NameVirtualHost directive must match one of the VirtualHost definitions, as shown in the sample configuration, or else the content will be served from the default virtual host (the first virtual host listed in the configuration).  Note that if the Apache reverse proxy will not be using name-based virtual hosts (instead using IP address-based virtual hosts or running only a single server instance), then this directive is not required.
• RequestHeader:  This directive instructs Apache to add a header “Front-End-Https: On” to requests sent to the internal OWA server.  This header is proprietary to OWA and forces OWA to build URLs using “https://” references instead of ordinary “http://” references.  This directive is required in order to terminate the SSL tunnel at the reverse proxy and use clear-text HTTP between the reverse proxy and the internal OWA server.  This directive requires the mod_headers module.
• ProxyPreserveHost:  This directive configures Apache to pass the original host header, supplied by the client, to the server to which the request is being proxied.  (This is instead of the host name supplied in the ProxyPass directive.)  Again, this facilitates the construction of URLs with the correct hostname when accessing resources inside OWA.
• SSLCertificateFile:  Apache expects the web server’s SSL certificate to be in PEM format.  If the certificate’s key is encrypted, Apache will prompt upon startup for the passphrase to the key (this prevents any form of automated startup).  It is considered a security best practice to keep the key in a separate file (using the SSLCertificateKeyFile directive) in encrypted form and supply the password upon the startup of Apache.

With this configuration in place, the following benefits are realized:

1. Name-based virtual hosts are supported. This allows other URLs to also be proxied through this same reverse proxy server.
2. SSL encryption is offloaded from the Exchange server to the reverse proxy server. Traffic from the reverse proxy server itself to the Exchange server is standard, unencrypted HTTP.
3. When used in conjunction with mod_security (another Apache module), OWA is protected against a very significant majority of all web-based attacks.

Using Apache to serve as a reverse proxy for OWA is a cost-effective way to add another layer of security to an Exchange-based messaging infrastructure.

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).

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.

As part of my experimentation with OpenBSD 3.7, I’m going to try to setup a way of transparently tunneling RDP (Remote Desktop Protocol, used by Windows Remote Desktop/Terminal Services) inside SSL.  I’m thinking that I can use IP aliases and Stunnel to have “ordinary” RDP encapsulated in SSL by Stunnel and then passed off to another instance of Stunnel at the other end.  Then, from the RDP client, I just connect to one of the IP aliases and the rest is handled transparently.

When I get it working, I’ll post more details here as well as on the Mercurion Systems web site.