Abstract
In this article and the white paper that accompanies it, we describe how to use easy-rsa, the free and open source certification authority software based on OpenSSL, to generate digital certificates that can be used to mutually authenticate IPsec connections between standalone Windows systems. First we describe the problem to be solved, then we discuss different approaches to the generation distribution of certificates, and finally, in the white paper, we provide two illustrative examples in the form of step by step guides to generate, install and use those digital certificates, using two different methods: generating certificate signing requests (CSR) in the hosts and signing those requests with easy-rsa, and generating the full certificates directly with easy-rsa, including their private keys and CSRs.
We hope this contributes in helping people to protect at least some of the insecure traffic still flowing through their networks.
Insecure communication protocols
Some communication protocols, like HTTP or TELNET, are vulnerable to man-in-the-middle attacks, because they exchange data in the clear, and because they do not provide mutual authentication of both ends of the communication. A subset of those insecure protocols have secure counterparts that we can use to replace them, like HTTPS instead of HTTP, or SSH instead of TELNET, but some of them do not have a secure alternative.
A clear example of the latter is the SMB (Server Message Block) protocol, which is used to access shared files and folders in Windows (and other) environments. Its variants SMBv1 and SMBv2 provide authentication of the user attempting to access resources in the shared folders, but they do not provide an authentication mechanism for the server to prove its identity to the client, and they do not offer the possibility of encrypting the traffic while in transit over the network. Version 3 of the protocol, SMBv3, introduces traffic encryption as a new feature of the protocol, which is an improvement, although it still seems to fail to address the problem of the authentication of the server. However, since SMBv3 is only available in systems running Windows 8, Windows Server 2012, or later, the vast majority of SMB traffic in our networks today is still SMBv1 or SMB2 and therefore exchanged in the clear. That means that any attacker that can position himself between the client and the server can obtain a copy of all files transferred, as demonstrated by the SMB export plug-in that we implemented for Wireshark some time ago.
Nevertheless, SMB is just an example. In many, if not most, of the networks we have analyzed, both in the long distant past and in very recent times, we have found custom applications that use completely insecure communication protocols, with a total lack of mutual authentication and/or encryption.
When trying to protect the communications of these insecure protocols, IPsec may come in handy.
IPsec in Windows
IPsec (IP security) is a set of protocols that allow two IP entities to authenticate each other, negotiate cryptographic keys, and use those keys to authenticate and encrypt each IP packet they exchange, thus protecting any communication carried out between those two endpoints at any higher level in the TCP/IP stack.
When compared to other security protocols that operate at higher levels in the TCP/IP stack, like TLS or SSH, IPsec offers the advantage of being transparent to any applications communicating through it: applications do not need to be aware of the existence of IPsec, whereas for an application to be able to use higher level security protocols, like TLS for example, the application must be designed or modified to support those protocols.
In the case of insecure protocols that cannot be replaced with a secure alternative, and which cannot be modified (be it because the source code is not available or because the cost would be prohibitive), IPsec may be a good option, if not the only option, to protect their communications.
IPsec has been available in Windows, included in the operating system (no need to install extra software), since Windows 2000. While the early versions could be considered difficult to configure and manage, that is hardly the case in recent Windows systems like Windows 7 or Windows Server 2008, where the configuration of IPsec rules is integrated in the Windows Firewall with Advanced Security console.
Figure 1 – Windows Firewall with Advanced Security
Windows’ implementation of IPsec offers several authentication methods, including using digital certificates issued by trusted certification authorities (CA). Other methods of authentication include Kerberos (in a Windows domain environment) or NTLMv2, but these articles will concentrate on the use of digital certificates because it is the strongest authentication method available both to domain and standalone computers.
In a Windows domain environment, managing the generation and installation of the appropriate certificates in the appropriate systems is really easy. An Enterprise (online) Certificate Authority can be set up in any domain member server (the CA software is included in Windows Server), and all the appropriate computers can be configured to automatically request from it, and install, the appropriate certificates. Such configuration may (should) be carried out centrally, using Group Policy, and applied automatically to the appropriate organizational units. Furthermore, IPsec may (should) also be configured using Group Policy, making the management of the whole solution very convenient, even for hundreds of systems.
However, configuring two standalone Windows systems to communicate using IPsec is a little more tedious, because the certificates will have to be generated and installed manually, and IPsec will need to be configured manually on each system.
Easy-rsa: A free and open source CA based on OpenSSL
Easy-rsa is a lightweight, free and open source software application that allows the user to set up and manage a certification authority (CA). It constitutes a subproject of OpenVPN. Programmed in POSIX shell and based on OpenSSL, which it requires, easy-rsa is available for Linux and Windows among other platforms.
The installation of easy-rsa in the Linux platform is especially simple, because all the external utilities that it requires are usually already there or can easily be installed using the appropriate package manager.
Easy-rsa constitutes a great alternative to Microsoft Active Directory Certificate Services (MS ADCS, Microsoft’s CA) if you don’t need an online CA and you don’t want to dedicate a Windows Server to this function. On top of that, using easy-rsa you will also get more flexibility, because its behavior can be tailored in much more detail.
Digital certificates
A digital certificate is a file that contains the public key and other relevant data (but not the private key) of some entity, all of which is signed by a CA. Anyone in possession of the public key of the CA will be able to validate its signature and therefore be assured that the information contained in the certificate was validated by the CA.
In order to generate a digital certificate, first a certificate signing request (CSR) must be generated. An entity needs to generate a private-public key pair and then include the public key in a so-called certificate signing request (CSR), along with whatever information it wants to have included in the certificate (e.g. common name, intended uses of its keys, etc.).
Then, the CSR must be brought to a certification authority (CA), which, after validating the information contained in the CSR, will use its own private key to sign the contents of the CSR, producing the corresponding digital certificate.
The certificate needs then to be given back to the requesting entity, so that such entity can use it, in tandem with the corresponding private key, which never left the requesting entity.
Finally, the requesting entity may or may not want to export the private key together with the certificate so that it can be backed up or transported to a different system.
Certificate generation and distribution: different approaches
Given the general process of generating certificates described in the previous section, a system administrator who wants to use digital certificates for the authentication of IPsec communication among some systems that fall under his control, could use at least two different strategies to generate and install the certificates. One way to do it would be to generate each key pair and CSR on each system, have them signed by the CA and the resulting certificates installed back in their corresponding systems. An alternative method would be to generate a bunch of key pairs and their corresponding CSRs on a central system, have them signed by the CA, get the certificates back, and then export together each private key with its corresponding certificate, and install each whole set on each appropriate system.
The first method has the advantage of the private key never leaving the single system where it will be used, but has the disadvantage of the system administrator needing to visit each system twice, to generate the key pair an CSR first, and then to install the certificate signed by the CA. However, the fact that the private key never leaves the system may not be too relevant if all systems are managed by the same administrator.
The second method has the advantage of allowing the system administrator to generate all keys and certificates at once, having to visit each system only once, to install both the certificate and the private key at the same time.
Additionally, the administrator also has the option to deal with X.509 extensions in different ways. Extensions in a certificate are fields that, among other things, may declare the uses for which such certificate should be trusted. Examples are «Server authentication», «IP security end system» or «Code Signing». CSRs may contain a list of desired extensions, which the CA may then decide to include or not in the final certificates, and the CA may or may not include additional extensions (not specified in the CSRs) to the final certificates. Thus, for a given set of required extensions, the administrator may include those extensions in the CSRs and configure the CA to include those extensions in the certificates, or generate the CSRs without extensions, and configure the CA to add those extensions when generating the certificates, or any combination of the above.
Step by step guides
In the accompanying white paper, available from our lab, we include two step by step guides that illustrate two different ways to set up an IPsec connection between two standalone Windows systems, using digital certificates for authentication, issued using easy-rsa.
In the first guide, each key pair and certificate signing request (CSR) is generated on its corresponding Windows system, including the desired extensions in the CSR, and easy-rsa is be configured to sign those CSRs including the requested extensions to generate the certificates.
In the second guide, however, all CSRs are generated in the Linux host and they do not contain information about any desired extensions; then, the CSRs are signed using easy-rsa, configured to add the appropriate extensions to the corresponding certificates, and then the certificates, including their corresponding private keys, are distributed to the Windows systems.
If you want to experiment with the exact same files that were created and used when writing the white paper, you may download a zipped copy of all of them from our lab.
Please note that by no means are the two procedures presented in these two step by step guides the only possible methods that could be followed. Indeed, a combination of both techniques, and possibly many other variations, could also be successfully applied. These step by step guides should be regarded just as illustrative examples.
For more detailed information, please refer to the accompanying white paper.
