Executive Summary

Distributed architecture is one of main characteristics of many modern application. Remote communication between separate modules (clients and servers) is required in order to allow basic functionality of the product. In most cases, Information is being transferred through communication channels using Web Services technology based on TCP/IP and HTTP transport protocols which are not secure by definition. TCP/IP and HTTP do not have built in ability to protect data and authenticate communicating peers which may compromise confidentiality, integrity and authenticity of sensitive application data. Even though currently there is no requirement in PCI DSS/PA-DSS or other security standards to use secure protocols on non-public networks such as corporate LAN/WAN, it is highly recommended to protect network data traffic and enable authentication of communicating clients in order to improve security of the applications. When product is deployed in environments connected to public networks such as Internet or wireless, securing communication becomes a strong requirement. Implementing SSL (Secure Socket Layer) will enable secure communication and protect the system from security threats caused by nature vulnerabilities of TCP/IP and HTTP protocols.

Introduction

Vulnerabilities Due To Insecure Communication

Confidentiality of the data can be compromised as transmission of sensitive data - such as credit card numbers which are sent to payment processor during credit authorization session, or customer PII (Personally identifiable Information), or user credentials (login and password) - can be sniffed (eavesdropping attack) using protocol analyzer (network sniffer) installed on external computer connected to the local network or Trojan horse application installed on internal computer.Stolen credit card data can be used for fraudulent transactions, PII – for “identity theft”, and user credentials – for unauthorized access to the system and privilege escalation.Integrity of the data can be compromised as data traffic can be intercepted using “man-in-the middle” attack, so original data sent by client (such as transaction report) can be altered during transmission – for example, in order to enable manipulations with cash collected at the store registers by reporting wrong transaction types and amounts.

Authenticity of the data can be compromised as the server is unable to authenticate the client so malicious application installed on any computer connected to the local network can call server in the name of the legitimate client and update server database with forged information (for example, modified transaction data in order to enable manipulations described above) if it knows just basic information about the system: service interface and server address. The same threat is valid for communication in opposite direction: as client is unable to authenticate the server (i.e. determine whether the server is “real” ), the actual server can be replaced with fake application (using DNS poisoning attack, for example) so the application data can be manipulated by malicious software acting in the name of the actual server.In order to avoid threats listed above, application should use SSL.

Securing Data Transmission with SSL

The purpose of this article is providing instructions on how to implement, configure and deploy SSL-enabled product in order to ensure maximum security of client/server communication. Detailed description of SSL functionality and configuration options can be found in Microsoft documentation. Instructions were specifically created for Windows XP (client) / Windows 2003 (server) OS environment, however, can be also used for other systems supporting SSL with some corrections that might be required depending on specific implementations. 

Different Levels of Security Provided by SSL

SSL can be implemented in different modes providing different levels of protection – from basic configuration using self signed server certificate to mostly sophisticated implementation using both server and client certificates automatically issued by local Certificate Authority and custom certificate validation procedures at both client and server sides. Mode selection depends on several factors: deployment environment, network infrastructure, system configuration, performance and maintenance considerations. Final decision on specific SSL mode should be made by customer based on factors listed above. In order to simplify development, testing and deployment processes, all standard implementation modes should be developed and tested.  It is important that the system will be deployed “SSL enabled” by default using at least basic SSL configuration with certificates signed by test root certificate authority. Then, the level of protection can be raised by customer IT which may use certificates issued by local or public Certificate Authority. Implementation of default security level will provide consumers with basic protection against simple eaves dropping attacks, however, it will not defend against more sophisticated threats.

SSL Implementation Modes

As mentioned in previous section, SSL can be implemented in two different modes.

Server Certificate Only

In this model, only server certificate is used. Server certificate can be issued by test CA, customer’s local CA or public CA (such as VeriSign). No client certificate is used. Such mode can  be used for deployment with large number of usually anonymous clients (Internet application, for example), or when the customer for any reason does not want to enable client authentication SSL feature.    

Server and Client Certificates

This model is more secure as it uses both Server and Client certificates so both sides authenticate each other. Certificates can be issued by either test CA, customer’s local CA or public CA (server only). Such mode can be used for deployments with predefined number of usually pr-allocated clients (in-store POS application, for example), or when the customer wants to increase security and enable client authentication SSL feature.

SSL Certificates

Certificate Issuing Methods

There are several ways to issue certificates.

Self-Signed

Self-signed certificate can be created using special tools such as Microsoft’s makecert utility or open source OpenSSL library. Normally, self-signed certificates are used during development process and replaced with “real” certificates when a system goes to production.

Issued Using Self-Signed Root Certificate (Certificate Authority)

Certificate can be issued using another self-signed root certificate in order to simplify maintainance of the test certificates. Local Certificate AuthorityLocal CA such as Microsoft CA service can be used to issue certificates. Microsoft CA allows automating the process of issuing client certificates by employing  “Autoenrollment” process. Local CA and Autoenrollment are normally used when clients and servers are located in single domain.Public Certificate AuthorityCertificates issued by public CA such as VeriSign are mostly used when server is located on public or cross-domain network environments such as Internet.

Creating Test Certificates

Server Certificate

There are two ways to create test server certificate. The simplest was is just creating standalone self-signed certificate as described below. It will work in mode without client certificates but will raise security warning at client as certificate is not trusted. If  you want to use client certificates, I would recommend to create test CA and derive all the certificates from its root certificate. It will make easier to setup both server and clients so server will recognize client certificates and vice versa.

Creating CA

In order to create test CA, you need to create  folder for your CA, for example - C:\CA. Then you need to create CA root certificate. All further certificates, both client and server, will be derived from this root certificate. Once root certificate is installed in the system, clients or server will be able to validate certificate issued by your test CA.

Creating Self-Signed CA Root Certificate

makecert -n "CN=Test Certificate Authority Root,OU=R&D,
  O=<Company Name>,L=<City>,S=<State>,C=<Country>" -cy authority 
  -sv "C:\CA\Test Certificate Authority Private  Key.pvk" -r -len 1024 
  "C:\CA\Test Certificate Authority.cer"

Note: 2014 bit keys are not supported by IIS 5.0 or IE 8. Use 1024 bit keys.

Installing the Root Certificate (both server and client)

1. Click Start, click Run, type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. In the Add Standalone Snap-ins dialog box, click Certificates, click Add, click Computer account, click Next, and then click Finish.
4. Click Close, and then click OK.
5. Expand Certificates (Local Computer), right-click Trusted Root Certification Authorities, click All Tasks, and then click Import.
6. In the Certificate Import Wizard dialog box, click Next, and then in the File name box, type the name of the certificate file, and then click Next two times.
7. Click Finish, and then click OK.

Creating Server Certificate for Specific Server Host Name

makecert –pe -n "CN=<server host name>,OU=R&D,O=<company name>,
  L=<City>,S=<State>,C=<Country> " -ic "C:\CA\Test Certificate Authority.cer" 
  -iv "C:\CA\Test Certificate Authority Private  Key.pvk " -eku 1.3.6.1.5.5.7.3.1 
  -pe -sr localmachine -ss my -sky exchange -sp "Microsoft RSA SChannel 
  Cryptographic Provider" -sy 12

Creating Server Certificate for localhost

makecert –pe -n "CN=localhost,OU=R&D,O=<company name>,L=<City>,
  S=<State>,C=<Country> " -ic "C:\CA\Test Certificate Authority.cer" 
  -iv "C:\CA\Test Certificate Authority Private  Key.pvk " -eku 1.3.6.1.5.5.7.3.1 
  -pe -sr localmachine -ss my -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Creating Standalone Self-Signed Server Certificate (without CA root)

makecert -r -pe -n "CN=ltdalslavatemp" -b 01/01/2010 -e 01/01/2020 
  -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp 
  "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Creating Client Test Certificate using Root CA Certificate

makecert –pe -cy end -n "CN=Test SSL Client,OU=R&D,O=<Company Name>,
  L=<City>,S=<State>,C=<Country> " -ic 
  "C:\CA\Test Certificate Authority.cer" -iv "C:\CA\Test Certificate 
  Authority Private  Key.pvk" -eku 1.3.6.1.5.5.7.3.2 -pe -sr currentuser 
  -ss my -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Going to Production

Production certificates can be obtained from local CA (such as Microsoft CA service)  or public CA (such as VeriSign). See specific CA documentation for instructions. Theoretically, you can continue using self-signed  certificates in production environment, but it is not recommended as it is difficult to keep self-signed certificates secured as well as deploy them.

Implementing SSL on Server

Web Server Configuration

See particular Web Server documentation for certificate installation and setup instructions. If you are using IIS, see Microsoft documentation for instructions.

Server Application Configuration

No special application configuration is required besides configuring Web Server using SSL.

Server Application Code Changes

No code changes required if using default client certificate validation. Extra code can be added in order to perform additional check on client certificates (not discussed in this article).

Implementing SSL on Client

Client Application Configuration

Make sure the server URL in your client application configuration is modified to include “s” in protocol prefix in order to indicate usage of HTTPS (HTTP over SSL) protocol instead of regular http. Example:<URL>https://localhost/WebService.asmx</URL>.

Client Application Code Changes

The following code should added to Web Service initialization.

Note: CertificateSubjectName should be configurable and point to Client certificate’s Subject field.

public static X509Certificate2 GetCert(string certificateSubjectName)
{         
    var storeMy = new    X509Store(StoreName.My,StoreLocation.CurrentUser);
    storeMy.Open(OpenFlags.ReadOnly);
    X509Certificate2Collection certColl = 
      storeMy.Certificates.Find(X509FindType.FindBySubjectName, 
      certificateSubjectName, true);   
    storeMy.Close();
    if (certColl.Count != 0)
    {
        return certColl[0];
    }         
    return null;
}

X509Certificate2 cert = GetCert(certificateSubjectName);
srv.ClientCertificates.Add(cert);

Additional Server Certificate Validations Performed by Client

Extra validations can be performed by the client application in order to determine whether server certificate is not fake and was issued by legitimate Certificate Authority. The following code checks whether server certificate was issued by legitimate CA.

Note: IssuerName should be configurable and set to Server Certificate’s Issuer Name field (‘O’).

ServicePointManager.ServerCertificateValidationCallback += ValidateServerCertificate;
public static bool ValidateServerCertificate( object sender, 
       X509Certificate certificate, X509Chain chain, 
       SslPolicyErrors sslPolicyErrors)
{
    if (certificate == null)
    {
        Console.WriteLine("No Server Certificate found");
        return false;
    }
    Console.WriteLine("Certificate hash: {0}",  certificate.GetCertHashString());
    if (!certificate.Issuer.Contains(IssuerName))
    {
        Console.WriteLine("Certificate issued by invalid authority: {0}", 
                          certificate.Issuer);
        Console.WriteLine(certificate.GetPublicKeyString());
        return false;
    }
    if (sslPolicyErrors == SslPolicyErrors.None)
        return true;
    Console.WriteLine("Certificate error: {0}", sslPolicyErrors); 
    // Do not allow this client to communicate with unauthenticated 
    // servers.
    return false;
}

Validating Protection Status

It is possible to validate that after implementing SSL the communication became secure. Use network protocol analyzer (packet sniffer) - for example, WireShark. In order to validate the communication security, you should install the sniffer and configure it to capture IP packets between Client and Server hosts. Without SSL implemented, you will see HTTP (TCP) request and response data in clear text. After enabling SSL, all data traffic between client and server will be encrypted and therefore unreadable.
You may also try to connect to the server with client without client certificate and make sure that the access is denied.

The same result (blocked communication) can be achieved with server having certificate issued by CA which is not defined in client configuration.