Overview

MOVEit DMZ uses the SSL and SSH standards to securely transport data between itself and various clients. MOVEit DMZ acts as server during all these transfers, so MOVEit DMZ is required to have an SSL server certificate (a.k.a., "cert" or "X.509 certificate") and an SSH server key.

Client certificates and client keys are OPTIONAL pieces of information which can be used in place of, or in addition to, a password to authenticate a particular user. Client certificates may be used with the two SSL interfaces (HTTPS and FTPS) and client keys may be used with the SSH interface. In certain cases, client certificates will be stored on hardware tokens of some kind.

The sections in this topic describe the components and refer to other sections of the documentation that provide detailed setup information.

Also, the following procedures are also useful when getting started:

• Creating and processing a Certificate Signing Request (CSR) - Instructions for creating a CSR and processing the CSR in IIS. A CSR can be generated and processed on any server. The resulting certificate can then be exported to the MOVEit DMZ server as an SSL server cert.
• Importing, Exporting, and Removing an SSL certificate. - Instructions for importing and exporting SSL certificates using the Certificates Snap-in.
• Assigning an SSL Certificate to the MOVEit DMZ Web site and to the MOVEit DMZ FTP server - Instructions for assigning an SSL certificate to a IIS site and a FTP server.

SSL Server Certificates

SSL server certificates are usually obtained from Comodo, Thawte, Verisign or any other of the many commercial Certificate Authorities ("CAs") in the market. Self-generated certs may also be used, but the advantage of using a cert from a commercial CA is that many popular browsers, including IE and Firefox, will automatically trust your site (display the lock in the corner). Otherwise, your clients will need to explicitly opt to trust your certificate.

MOVEit DMZ server certs are configured in two places:

• HTTP/SSL (web) - A certificate must be assigned to your MOVEit DMZ web site via the Microsoft Internet Services Manager application. ([Site] Properties menu, Directory Security tab, Secure Communications section)
• FTP/SSL - The same certificate must also be assigned to your MOVEit DMZ FTP site via the MOVEit DMZ Config application. (FTP Certs tab)

SSL Client Certificates

Users may be required to present an SSL client certificate during the signon process when using either the HTTPS or FTP/SSL interfaces. Complete information may be found in Client Certs - Overview and FTP - Configuration (Require Client Certificates.

SSH Server Keys

SSH keys do not have any relationship to a signer, so the MOVEit DMZ SSH server simply generates its own key the first time it runs.

You may view the fingerprint of your SSH key at any time via the MOVEit DMZ Config application. (SSH tab)

See also SSH Keys - Server Keys - Overview.

SSH Client Keys

Any SSH user may be required to present an SSH client key during the signon process. Complete information may be found in SSH Keys - Client Keys - Overview.

Relative Security of Passwords, Keys and Certificates

Passwords are easy to remember and easy for users to figure out how to use. To misuse these credentials, an attacker must guess, steal or record a password, but simply knowing a particular user's password is often enough to act as that user. (To protect passwords, MOVEit DMZ already features several industry-standard password defenses such as password strength requirements, password aging, per-user IP restrictions, per-user session restrictions, automatic lockouts and the use of SSL and SSH encrypted channels to securely transmit passwords.)

Client certificates ("certs") and keys are typically tied to specific computers or hardware tokens. To misuse these credentials, an attacker must typically gain control of a desktop/laptop machine (for an installed key/cert) or possess a hardware token. All client certs and client keys rely on "public key / private key" cryptography. Under this model, gaining possession of a particular user's private key is often enough to act as that user, so operating system and hardware solutions have evolved to protect private keys from unauthorized use. (MOVEit DMZ does not work directly with the private key halves of client cert/keys, and thus steers clear of private key protection issues.)

Because both passwords and client cert/keys have their own weaknesses, it has become increasingly common to require users to authenticate with both a password and a client cert/key. To defeat this scheme, an attacker must possess a user's password and access to that user's private key (i.e. access to their desktop/laptop or possession of their hardware token). While still possible, this "two factor" level of compromise is still harder for an attacker to achieve than either password or cert/key compromise alone, and affords a higher degree of security.

Difference Between Keys and Certificates

The main difference between SSH keys and (X.509) SSL certs is the concept of "trust": SSH keys are standalone credentials, while SSL certs must be verified.

SSH servers (MOVEit DMZ included) associate specific SSH client keys to specific users. If a SSH client presents an SSH key and it matches the one stored on the user record, the SSH client key will be authenticated - period.

SSL servers (MOVEit DMZ included) also associate specific SSL client certs to specific users, but SSL servers perform an additional background check on incoming SSL client certs. SSL client certs are signed (a.k.a. issued) by Certificate Authorities (CA). SSL servers maintain a list of CAs that they trust (all others are assumed to be untrusted.) If an SSL server receives an otherwise valid SSL client cert, but the client cert's CA isn't trusted, the SSL server will reject the connection.

With the extra CA check in mind, it could be said that SSL authentication is more secure than SSH authentication. For the same reason, however, configuring SSL authentication is more complicated than configuring SSH authentication.

Required Credentials

MOVEit DMZ users may authenticate with passwords, client keys (SSH only) or client certificates (HTTPS and FTP/SSL). Options on each user profile can be used to enforce exactly which combinations are allowed. (Default settings are available at the organization level.) The possible settings are:

• Password Only (Any key/certificate is ignored)
• Key/Cert Only (Any password is ignored)
• Password OR Key/Cert (If either credential matches, the other is ignored)
• Password AND Key/Cert (See also "Two-Factor Authentication")

Two-Factor Authentication

Systems which require "two-factor authentication" actually require three items:

• Statement of Identity (Usually, this is a username.)
• Unique Credential #1 (Usually, this is a password)
• Unique Credential #2 (Usually, this is a client certificate or client key.)

MOVEit DMZ supports "two-factor authentication" on its HTTPS and FTP/SSL interfaces with client certificates and on its FTP over SSH interface with client keys. To force this requirement on a particular user, the following user-level options MUST be enabled on each interface.

• Require client key/certificate
• Require password if a key/certificate is presented

It is worth noting that many FTP/SSL clients will work fine with two-factor settings ("Password And Cert") in both interactive and batch modes. However, the most popular SSH client (OpenSSH) will only work in interactive mode when two-factor settings are applied (OpenSSH requires a one-factor Key Only or Password OR Key setting while in batch mode.)