Man-In-The-Middle Attacks

Defenses

To protect against man-in-the-middle attacks against Uniface applications, you must use the TLS connector and ensure that it is correctly and effectively configured.

The TLS connector has two authentication modes (Pre-Shared Key Authentication and Certificate Authentication), each with its own options and techniques for preventing MITM attacks. The following guidelines are common to both modes:

• Limit the cipher list on both your TLS clients and TLS servers to one cipher that offers a high level of encryption. This prevents a hacker from negotiating a low level of encryption by proposing a different cipher.
• Use the Pathscrambler utility to encrypt any key or password specified in the assignment files of the TLS server and TLS clients. For more information, see pathscrambler.exe .

Pre-Shared Key Authentication

Pre-shared key authentication uses a pre-shared key to authenticate the communicating peers, and a negotiated cipher and secret shared key for encrypting and decrypting the data. For more information, see Pre-Shared Key Authentication.

The pre-shared key is specified in the assignment files of both peers, so an attacker cannot get the key by intercepting messages, nor by negotiating some other key. However, the pre-shared key could still be obtained and used for a man-in-the middle impersonation if the assignment file is leaked, or if the pre-shared key can be easily guessed or obtained by a dictionary attack. To prevent this:

• Use the Pathscrambler utility to encrypt the pre-shared key in the assignment files of the TLS server and TLS clients.
• Ensure that the pre-shared key is of sufficient length and complexity

This makes it difficult for attackers who intercept messages to decrypt them, or construct fake messages, even if they have the encrypted pre-shared key or assignment file.

Certificate Authentication

Certificate-based authentication uses a negotiated master key for encrypting and decrypting the data, and a signed certificate (including a key file) to guarantee the identity of communicating peers. For more information, see Certificate-Based Authentication and Digital Certificates.

The key to be used for the encryption is not known beforehand, so the communicating peers exchange a public key or cryptographic numbers to set up the encryption. This exchange of keys or numbers is vulnerable to MITM attacks because the exchange can be intercepted, with the attacker substituting its own key or cryptographic numbers, which are then used by the peers to encrypt and decrypt their messages. An attacker can intercept and read all communication between them and each peer would think it is communicating with the other, but instead they would be communicating with an imposter.

Therefore, signed certificates are used to provide some level of confidence that communicating peers are who they say they are. Each certificate consists of a certificate file and a key file that are signed by a Certificate Authority (CA). The certificate’s signature is always checked for validity by checking that the signing Certificate Authority (CA) is a CA that the client trusts. Other items in the signature could also be checked, such as DNS names, IP addresses, URIs, or the purpose of the certificate.

The peer whose certificate is successfully verified is authenticated, so the verifying peer can be confident that the machine it is communicating with is the one intended. Thus, for an MITM attack to succeed, not only must an attacker's machine be able to intercept and decrypt messages, it must also present a certificate to its peer that it will accept.

When correctly configured, certificate mode provides much better security than pre-shared keys. However, it is still possible for a man-in-the-middle attack to occur:

• If the key of a certificate gets into the hands of an attacker, it can be used to impersonate machine B to machine A by presenting machine B’s certificate.
• If certificate verification only checks that the signing Certificate Authority (CA) is one that the client trusts, another certificate and key signed by the same CA as the real one could be used by an attacker for a MITM attack. Without additional checks, such a certificate would be accepted and the connection to the attacker’s machine established.

Preventing MITM Attacks with Certificate Mode

To ensure that you can protect your application against man-in-the-middle attacks:

• Protect your certificate key file to prevent it being leaked. Make sure that only users that actually need it have read access to it. See Protecting the Certificate Key File.
• Verify the peer’s identity against what is recorded in the certificate. This is known as peer name verification. See Peer Name Verification.
• Become a certificate authority so that you can sign your own certificates. See Becoming a Certificate Authority.
• Compare the certificate with other certificates that you know can be trusted. This is known as certificate pinning. See Certificate Pinning.

Protecting the Certificate Key File

For server verification, only the TLS server (the Uniface Router) needs access to the key file of your server certificate, but TLS clients (client applications and shared servers) do not. However, if exclusive servers are used, and they use the same certificate, they also need access to the key. All user accounts for client applications that connect to the exclusive server must also have Read access to the key file. More people with access to the key file increases the risk of the key being leaked.

To prevent this consider doing the following:

• Use shared Uniface Servers, not exclusive servers, so that only the Uniface Router needs Read access to the key file.
• Do not use the same, or any certificate, for the connections between the Uniface Router and exclusive servers so that only the Uniface Router needs read access to the key file. Since the Uniface Router is normally run as root or LocalSys, read access to the key can thus be restricted to these accounts.
• For the connections between the Uniface Router and exclusive servers you can use TCP/IP, or you can use TLS with a pre-shared key. Both shared and exclusive servers usually run on the same machine as the Uniface Router, and this machine is normally behind a firewall. Security is usually much less of a concern for these connections than for connections with client applications, so certificates or TLS may not be necessary.

Peer Name Verification

Peer name verification is a mechanism whereby a certificate is only considered valid if it contains a specified name. Names are contained in the certificate in the Subject Alternative Names or in the Common Name fields. Names can be of different types, for example a DNS name or an IP name can be used to identify a machine and is useful for server verification. Peer name types of EMAIL to identify a person or URI to identify a resource are useful in client verification. For more information see Peer Name Verification by the TLS Connector.

This is an extra level of protection against MITM attacks that prevents the use of another certificate signed by the same CA. However, attackers can still circumvent this check. For example, an attacker could hack into the DNS cache of your machine and modify the DNS entry of the machine you want to connect to so that it points to the attacker’s machine instead. A reverse lookup of the attacker's IP address will then find the DNS name that is in the certificate.

Note:  The TLS connector performs peer verification using DNS names by default. You can also use other techniques, such as self-signed certificates , to prevent MITM attacks.

For more information, see Certificate Verification.

Becoming a Certificate Authority

When host verification is not possible, you cannot rely on an external CA that signs certificates for you, because it also signs certificates for others, and such certificates could be used to authenticate an invalid peer to access your application.

Instead you can become your own CA and create your own CA root certificate and private key, which you can use to create an intermediate CA certificate and key and sign certificates. For more information, see Acting as a Certificate Authority.

Important: The root and intermediate certificate private keys and their passwords must never leak out to anyone that is not in charge of signing intermediate CA certificates. All those private keys and their passwords must therefore be kept securely, under lock and key.

Certificate Pinning

With certificate pinning, the peer’s certificate is checked for a valid signature from a trusted CA, but it is also compared with one or more certificates that are known to be good. If the certificate is not one of this set of known good certificates the verification fails, even though it was signed by a trusted CA.

The TLS connector does not have explicit support for certificate pinning. However, when you use a self-signed certificate you are effectively doing certificate pinning because the CA certificate that can validate a self-signed certificate is the self-signed certificate itself.

By using different self-signed certificates for your TLS servers and putting them into a client trust store that contains no other CA certificates, you have effectively pinned those certificates.

When you create and sign your own certificates:

• Select a strong cipher for both the certificate signature algorithm and the key exchange algorithm.
• Make a self-signed certificate for the TLS server, and keep the private key safely and its password from the potential hacker.
• On the client side, use a CA file with only a copy of this self-signed certificate (without its private key!).