How to force clients to use HTTPS. Fortinet FortiWeb 5.1 Patch 3
Reklama
Reklama
See also
•
Supplementing a server certificate with its signing chain
•
How operation mode affects server policy behavior
How to force clients to use HTTPS
Most users are unaware of protocols and security. Even if your web sites offer secure services, users will still try to access web sites using HTTP.
As a result, for practical reasons, usually you must offer at least an HTTP service that redirects requests to HTTPS. Even then, if a man-in-the-middle attacker or CRL causes a certificate validation error, many users will incorrectly assume it is harmless, and click through the alert dialog to access the web site anyway — sometimes called “click-through insecurity.” The resulting unsecured connection exposes sensitive data and their login credentials.
Newer versions of major browsers such as Mozilla Firefox and Google Chrome have a built-in list of frequently attacked web sites such as gmail.com and twitter.com. The browser will only allow them to be accessed via HTTPS. This prevents users from ever accidentally exposing sensitive data via clear text HTTP. Additionally, the browser will not show click-through certificate validation error dialogs to the user, preventing them from ignoring and bypassing fatal security errors.
Similarly, you can also force clients to use only HTTPS when connecting to your web sites. To do this, when FortiWeb is performing SSL/TLS offloading, configure it include the RFC 6797 strict transport security header. All compliant clients will require access to that domain name to
To force clients to connect only via HTTPS
1. If you want to redirect clients that initially attempt to use HTTP, configure an HTTP-to-HTTPS
redirect. See “Example: HTTP-to-HTTPS redirect” on page 389
and
“Rewriting & redirecting” on page 382
.
2. When configuring the server policy, enable
See also
•
Indicating to back-end web servers that the client’s request was HTTPS
How to apply PKI client authentication (personal certificates)
If your clients will connect to your web sites using HTTPS, you can configure FortiWeb to require clients to present a personal certificate during the handshake in order to confirm their identities. This is sometimes called public key infrastructure (PKI) authentication ( RFC 5280 ).
Because FortiWeb presents its own server certificate to the client before requesting one from the client, all PKI authentication with FortiWeb is actually mutual (2-way) authentication.
In addition to FortiWeb verifying client certificates, you can configure FortiWeb to forward client certificates to the back-end server, whether for additional verification or identity-based
“Configuring a server policy” on page 512 .
Fortinet
PKI authentication is an alternative to traditional password-based authentication. The traditional method is based on “what you know” — a password used for authentication. PKI authentication is based on “what you have” — a private key related to the certificate bound to only one person.
307 FortiWeb 5.1 Patch 3 Administration Guide
PKI authentication may be preferable for devices where it is onerous for the person to type a password, such as an Android or iPhone smart phone.
A known weakness of traditional password based authentication is the vulnerability to password guessing or brute force attack. Despite your admonitions, many users will still choose weak passwords either because they do not understand what makes a password “strong,” because they do not understand the risks that it poses to the organization, or because they cannot remember a randomized password.
PKI authentication is far more resilient to brute force attacks, and does not require end-users to remember anything, so it is stronger than a password.
For even stronger authentication, you can combine PKI authentication with HTTP or form-based authentication. For more information, see
“Authentication styles” on page 228 .
Figure 43:Bilateral authentication
PKI authentication relies on these factors to strongly confirm identity:
•
Sole private key possession
— Like with all X.509 certificates, a client’s identity can only be irrefutably confirmed if no one else except that person has that certificate’s private key.
The private key is a randomized string of text that has a hard-to-guess relationship with its corresponding public key. As such, it features cryptographic protection that passwords lack:
Fortinet 308 FortiWeb 5.1 Patch 3 Administration Guide
passwords do not necessarily have a verifiable, computable relationship with anything.
However, like a password, a private key’s strength depends on it remaining a secret.
Provide the client’s private keys only to that specific client, and transmit and store any backups securely, just as you would for passwords. Failure to store them securely and restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your web sites. (i.e., It damages the property of non-repudiation.)
In the event of potential private key compromise, immediately revoke the corresponding personal certificate. See
“Revoking certificates” on page 333 .
•
Asymmetric encryption
— Public key encryption is a type of asymmetric encryption: it is based upon two keys that are different — but exactly paired — mathematical complements.
Fortinet
Only the private key can decrypt data that was encrypted by its public key. The inverse is also true: only the public key can decrypt data that was encrypted by its private key. This is true, for example, in the RSA cryptographic algorithm.
309 FortiWeb 5.1 Patch 3 Administration Guide
Figure 44:RSA algorithm
Fortinet
SSL 3.0 or TLS 1.0 is required. During an SSL or TLS handshake, the client and server (in this case, FortiWeb) negotiate which of their supported cryptographic algorithms to use, and exchange certificate(s). After the server receives the client’s certificate with its public key, the client will encrypt subsequent communications using its private key. As a result, if the server can decrypt messages using the public key, it knows that they originate from the originally connecting client who has the related private key, not an intercepting host (i.e. a man-in-the-middle attack).
Depending on factors such as a misconfigured client, an SSL/TLS connection may in some cases still be vulnerable to man-in-the-middle attacks. There are several steps that you can take to harden security, including using greater bit strengths, updating and properly configuring clients, revoking compromised certificates, and installing only trusted
certificates. See also “Hardening security” on page 643 and
“Configuring FortiWeb to validate client certificates” on page 331 .
Encrypted transmissions can contain a message authentication checksum (MAC) to verify that the message was not altered during transmission by an interceptor.
•
Digital signatures
— Public keys are also used as signatures. Similar to an encrypted message, as long as the private key is possessed by only one individual, any signature generated from it is also guaranteed to come only from that client. The client will sign a certificate with its matching public key.
Because certificate authorities (CA) sign applicants’ certificates, third parties who have that
CA’s certificate can also confirm that that CA certified the applicant’s identity, and the certificate was not forged.
•
Chain of trust
— What if a device does not know the CA that signed the connecting party’s certificate? Since there are many CAs, this is a common scenario.
The solution is to have a root CA in common between the two connecting parties, a “friend of a friend.”
If a root CA is trusted to be genuine and to sign only certificates where it has verified the applicant’s identity, then by induction, all sub-CA’s certificates that the root CA has verifiably signed will also be trusted as genuine. Hence, if a client or server’s certificate can prove that it is either indirectly (through an intermediary CA signed by the root CA) or directly signed by the trusted root CA, that client/server’s certificate will be trusted as genuine.
To configure client PKI authentication
1. Obtain a personal certificate for the client, and its private key, from a CA.
Steps vary by the CA. Personal certificates can be purchased or downloaded from either commercial CAs such as VeriSign, Thawte, or Comodo, or your organization’s own private
CA, such as a Linux server where you use OpenSSL or a Mac OS X server where you have
310 FortiWeb 5.1 Patch 3 Administration Guide
Fortinet set up a CA in Keychain Access. For information on certificate requirements such as extended attributes, see
“Configuring FortiWeb to validate client certificates” on page 331 .
2. Download the CA’s certificate, which contains its public key and therefore can verify any personal certificate that the CA has signed.
Steps vary by the CA.
For a private CA example, see “Example: Downloading the CA’s certificate from
Microsoft Windows 2003 Server” on page 321 .
If you purchased personal certificates from CAs such as VeriSign, Thawte, or Comodo, you should not need to download the certificate: simply export those CAs’ certificates from your
“Uploading trusted CAs’ certificates” on page 294
).
3. Install the personal certificate with its private key on the client.
Steps vary by the client’s operating system and web browser. If the client uses Microsoft
Windows 7, see
4. Upload the CA’s certificate to the FortiWeb’s trust store (see
“Uploading the CA’s certificate to FortiWeb’s trusted CA store” on page 330 ).
5. If you have a certificate revocation list or OCSP server, configure FortiWeb with it (see
“Revoking certificates” on page 333
).
6. Depending on the FortiWeb’s current operation mode, configure either a server policy or server farm to consider CA certificates and CRLs when verifying client certificates (see
“Configuring FortiWeb to validate client certificates” on page 331
).
7. Configure the server policy to accept HTTPS (see
).
Example: Generating & downloading a personal certificate from
Microsoft Windows 2003 Server
If you are running Microsoft Certificate Services on Microsoft Windows 2003 Server, you can use your server as a CA, to generate and sign personal certificates on behalf of your clients.
As part of signing the certificate, the CA will send the finished personal certificate to your web browser. As a result, when you are finished generating, you must export the certificates from your computer’s trust store in order to deploy the certificates to clients.
To generate a personal certificate in Microsoft Windows 2003 Server
1. On your management computer, start your web browser.
2. Go to: https://<ca-server_ipv4>/certsrv/ where
<ca-server_ipv4> is the IP address of your CA server.
311 FortiWeb 5.1 Patch 3 Administration Guide
3. Log in as
Administrator.
Other accounts may not have sufficient privileges. The Microsoft Certificate Services home page for your server’s CA should appear.
4. Click the Request a certificate link.
The Request a Certificate page appears.
5. Click the advanced certificate request link.
The Advanced Certificate Request page appears.
Fortinet 312 FortiWeb 5.1 Patch 3 Administration Guide
6. Click the Create and submit a request to this CA link.
The Certificate Request Template appears.
Fortinet
7. In the Certificate Template drop-down list, select the Client Authentication template (or a template that you have created for the purpose using Microsoft Management Console
(MMC)).
8. In the Name field, type the name the end-user on behalf of which the client certificate request is being made. This will be the
Subject: field in the certificate. Other fields are optional.
9. Click Submit.
The certificate signing request (CSR) is submitted to the CA.
313 FortiWeb 5.1 Patch 3 Administration Guide
10.If a message appears, warning you that the web site is requesting a new certificate on your behalf, click Yes to proceed.
Once the CA server generates the requested certificate, the Certificate Issued window appears.
11.Click the Install this certificate link.
Your browser downloads the certificate, including its private key, and installs it in its trust
store. The certificate’s name is the one you specified in step 8 .
Transmit and store any private key backups securely, just as you would for passwords. Failure to store them securely and restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your web sites. In the event of potential private key compromise, immediately revoke the corresponding personal certificate. See
“Revoking certificates” on page 333 .
12.If a message appears, warning you that the web site is adding one or more certificates to your computer, click Yes to proceed.
The Certificate Installed window appears.
13.Return to the Microsoft Certificate Services (MSCS) home page for your local CA and repeat steps 4 through
for each end-user that will use PKI authentication.
To export and transmit a personal certificate from the trust store on Microsoft Windows 7
1. Start Microsoft Internet Explorer 9.
Fortinet 314 FortiWeb 5.1 Patch 3 Administration Guide
2. Go to Tools [gear icon] > Internet options.
The Internet Options dialog window appears.
3. Click the Content tab.
Fortinet 315 FortiWeb 5.1 Patch 3 Administration Guide
4. Click the Certificates button.
The Certificates dialog window appears. By default, the Personal tab is front most.
5. Click to select a personal certificate in the list.
6. Click Export.
The Certificate Export Wizard dialog appears.
Fortinet 316 FortiWeb 5.1 Patch 3 Administration Guide
7. Click Next.
The Export Private Key step appears.
8. Select Yes, export the private key.
The end-user will require his or her private key in order to authenticate. Without that token (or if many people possess that token), identity cannot be confirmed.
Transmit and store any private key backups securely, just as you would for passwords. Failure to store them securely and restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your web sites. In the event of potential private key compromise, immediately revoke the corresponding personal certificate. See
“Revoking certificates” on page 333 .
Fortinet 317 FortiWeb 5.1 Patch 3 Administration Guide
9. Click Next.
The Export File Format step appears.
10.Select Personal Information Exchange - PKCS #12 (.PFX) as the file format.
11.If you need to absolutely guarantee identity (i.e. not even you, the administrator, will have the end-user’s private key installed — only the end-user will), mark the check box named Delete
the private key if the export is successful.
For improved performance, do not include all CA certificates from the personal certificate’s certification path (i.e. the chain of trust or signing chain). Including the signing chain increases the size of the certificate, which slightly increases the amount of time and traffic volume required to transmit the certificate each time to FortiWeb. Instead, upload those CAs’ certificates to the FortiWeb appliance (see
“Uploading trusted CAs’ certificates” on page 294
).
Fortinet 318 FortiWeb 5.1 Patch 3 Administration Guide
12.Click Next.
The Password step appears.
13.Enter and confirm the spelling of the password that will be used to password-protect and encrypt the exported certificate and its private key.
Fortinet 319 FortiWeb 5.1 Patch 3 Administration Guide
14.Click Next.
The File to Export step appears.
Fortinet
15.In File name, enter a unique file name for the certificate, then click Browse to specify the location where you want to save the exported certificate and private key.
Use a consistent naming convention. This will minimize the likelihood that you confuse one person’s private key with another’s, deliver it to the wrong person, and therefore need to revoke the corresponding certificate and generate a new one.
16.Click Finish to export the certificate and private key.
The certificate and private key are exported in a single file with a .pfx file extension to the
.
If the export is successful, a notice appears.
17.Click OK.
18.Securely transmit both the .pfx file and its password to the end-user, along with instructions on how to install the certificate in his or her web browser’s trust store.
Only provide the client’s private key to that specific client, and transmit and store any backups securely, just as you would for passwords. Failure to store it securely and restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your web sites. In the event of potential private key compromise, immediately
revoke the corresponding personal certificate. See “Revoking certificates” on page 333 .
For example, you could give him or her a USB key in person and instruct the end-user to double-click the file, or install the .pfx in a Microsoft Active Directory roaming profile. See also
“Example: Importing the personal certificate & private key to a client’s trust store on
Microsoft Windows 7” on page 322
.
320 FortiWeb 5.1 Patch 3 Administration Guide
Example: Downloading the CA’s certificate from Microsoft Windows 2003 Server
If you are generated and signed your end-users’ personal certificates using Microsoft Certificate
Services on Microsoft Windows 2003 or 2008 Server, you must download the CA’s certificate and provide it to the FortiWeb appliance so that it will be able to verify the CA signature on each personal certificate.
To download a CA certificate from Microsoft Windows 2003 Server
1. On your management computer, start your web browser.
2. Go to: https://<ca-server_ipv4>/certsrv/ where
<ca-server_ipv4> is the IP address of your CA server.
3. Log in as
Administrator.
Other accounts may not have sufficient privileges. The Microsoft Certificate Services home page for your server’s CA should appear.
4. Click the Download CA certificate, certificate chain, or CRL link.
The Download a CA Certificate, Certificate Chain, or CRL page appears.
Fortinet
5. From Encoding Method, select Base64.
6. Click Download CA certificate.
321 FortiWeb 5.1 Patch 3 Administration Guide
7. If your browser prompts you, select a location to save the CA’s certificate file.
Example: Importing the personal certificate & private key to a client’s trust store on
Microsoft Windows 7
If you need to import one or two certificates to a person’s computer on his or her behalf, you can manually import the .pfx file.
If you are importing a clients’ personal certificates to their computers on their behalf, for mass distribution, it may save you time to instead deploy certificates via a script or, if the computer is a member of a Microsoft Active Directory domain, a login script or roaming profile.
To harden security, you should also make sure that the browser’s settings are configured to check servers’ certificates (such as FortiWeb’s) with a CRL or OCSP server in case the servers’ certificates become compromised, and must be revoked.
Methods for importing a certificate to the trust store vary by the client’s browser and operating system. In this section are methods for some popular browsers. For other browsers and operating systems, consult the client’s browser documentation.
To import a client certificate into Microsoft Windows 7
1. Start Microsoft Internet Explorer 9.
Alternatively, if you have a .pfx file, double-click it to open the wizard, then skip to step
.
Fortinet 322 FortiWeb 5.1 Patch 3 Administration Guide
2. Go to Tools [gear icon] > Internet options.
The Internet Options dialog window appears.
3. Click the Content tab.
Fortinet 323 FortiWeb 5.1 Patch 3 Administration Guide
4. Click the Certificates button.
The Windows Certificates store dialog window appears. By default, the Personal tab is front most.
5. Click Import.
The Certificate Import Wizard appears.
Fortinet 324 FortiWeb 5.1 Patch 3 Administration Guide
6. Click Next.
The File to Import step appears.
7. If you double-clicked the certificate and private key file to start the wizard, the file is already specified in File name.
Otherwise, click Browse. Go to the location where you downloaded the personal certificate.
From Files of type, select Personal Information Exchange (*.pfx, *.p12), All Files (*.*), or whatever file format was used to export the certificate. Finally, select the certificate file, and click Open.
Fortinet 325 FortiWeb 5.1 Patch 3 Administration Guide
8. Click Next.
The Password step appears.
9. In Password, type the password that was used to secure the private key. (If the certificate was made on your behalf by an administrator, this is the password that the administrator used when exporting your .pfx file. He or she must provide this password to you.)
Fortinet 326 FortiWeb 5.1 Patch 3 Administration Guide
10.Click Next.
The Certificate Store step appears.
Fortinet
11.Select either:
• Automatically select the certificate store based on the type of certificate — Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.
• Place all certificates in the following store — Click the Browse button to manually indicate your personal certificate store.
12.Click Next.
13.Click Finish.
If the import is successful, a notification appears.
14.Click OK.
The certificate and private key are now imported to the store of certificates specified in step
, which should be the personal certificate store. The person’s browser should now be able to present his or her personal certificate whenever a server requires PKI authentication.
327 FortiWeb 5.1 Patch 3 Administration Guide
15.Click the Advanced tab.
Fortinet
16.In the Settings area, scroll down to the Security settings.
17.Enable Check for server certificate revocation.
18.Click OK to save your settings and close the Internet Options dialog window.
19.Close Internet Explorer.
The Check for server certificate revocation option will not take effect until you restart the browser.
To import a client certificate into Google Chrome on Microsoft Windows 7
1. Start Google Chrome.
2. Click the wrench icon in the top right (Customize and control Google Chrome), then select
Settings... from the drop-down menu that appears. (On Mac OS X, this option is named
Preferences instead.)
The dialog for configuring Google Chrome settings appears. On the left hand navigation menu, the Settings section is selected.
328 FortiWeb 5.1 Patch 3 Administration Guide
3. At the bottom of the page, click Show advanced settings to reveal additional settings, including, towards the bottom of the page, HTTP/SSL.
4. In the HTTPS/SSL area, enable Check for certificate revocation.
5. Click the Manage certificates button.
The Windows Certificates store dialog window appears. (In Mac OS X, this is the Keychain
Access application instead.) By default, the Personal tab is front most. Continue with step 5
in “To import a client certificate into Microsoft Windows 7” on page 322
.
Fortinet 329 FortiWeb 5.1 Patch 3 Administration Guide
Figure 45:Importing a personal certificate in Google Chrome — [Wrench icon] > Options >
Under the Hood, click Manage Certificates, then click Import
Fortinet
Uploading the CA’s certificate to FortiWeb’s trusted CA store
In order for FortiWeb to be able to verify the CA’s signature on client’s personal certificates when they connect, the CA’s certificate must exist in the FortiWeb’s trusted CA certificate store.
You must either:
• upload the certificates of the signing CA and all intermediary CAs to FortiWeb’s store of CA
certificates (see “Uploading trusted CAs’ certificates” on page 294
)
• in all personal certificates, include the full signing chain up to a CA that FortiWeb knows in order to prove that the clients’ certificates should be trusted
To harden security, configure FortiWeb with an OCSP server or regularly update its CRL file in order to immediately revoke a CA’s certificate if has been compromised. See
“Revoking certificates” on page 333
.
330 FortiWeb 5.1 Patch 3 Administration Guide
Configuring FortiWeb to validate client certificates
To be valid, a client certificate must:
• not be expired or not yet valid
• not be revoked by either certificate revocation list (CRL) or, if enabled, online certificate status protocol (OCSP)
• be signed by a certificate authority (CA) whose certificate you have imported into the
FortiWeb appliance (see
“Uploading trusted CAs’ certificates” on page 294
);
• contain a
CA field whose value matches a CA’s certificate
• contain an
Issuer field whose value matches the Subject field in a CA’s certificate
If the client presents an invalid certificate during PKI authentication for HTTPS, the FortiWeb appliance will not allow the connection.
Certificate validation rules (in the web UI, these are called certificate verification rules) tell
FortiWeb which set of CA certificates to use when validating personal certificates. They also specify a CRL and/or OCSP server, if any, if the client’s certificate must be checked for revocation.
To configure a certificate validation rule
1. Before you can configure a certificate validation rule, you must first configure a CA group
(see “Grouping trusted CAs’ certificates” on page 296
). You may also need to configure:
•
OCSP (see “Revoking certificates by OCSP query” on page 334 )
•
upload a CRL file (see “Revoking certificates” on page 333 )
if you need to explicitly revoke some invalid or compromised certificates.
2. Go to System > Certificates > Certificate Verify.
To access this part of the web UI, your administrator's account access profile must have
Read and Write permission to items in the Admin Users category. For details, see
3. Click Create New.
A dialog appears.
4. Configure these settings:
Fortinet
Setting name
Name
CA Group
Description
Type a name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.
Select the name of an existing CA group that you want to use to
authenticate client certificates. See “Grouping trusted CAs’ certificates” on page 296 .
331 FortiWeb 5.1 Patch 3 Administration Guide
Setting name
OCSP
CRL
Description
Select the name of an existing online certificate status protocol
(OCSP) certificate, if any, that you want to use to verify the revocation status of client certificates. See
“Revoking certificates by OCSP query” on page 334 .
Select the name of an existing certificate revocation list, if any, to use to verify the revocation status of client certificates. See
“Revoking certificates” on page 333 .
5. Click OK.
6. To apply a certificate verification rule, select it in
in a server policy or server farm that includes HTTPS service. For details, see
“Configuring a server policy” on page 512
or “Grouping your web servers into server farms” on page 265
.
When a client connects to the web site, after FortiWeb presents its own server certificate, it will request one from the client.The web browser should display a prompt, allowing the person to indicate which personal certificate he or she wants to present.
Figure 46:A personal certificate prompt in Microsoft Internet Explorer 9
Fortinet
If the connection fails when you have selected a certificate verifier, verify that the certificate meets the web browser’s requirements. Web browsers may have their own certificate validation requirements in addition to FortiWeb's requirements. For example, personal certificates for client authentication may be required to either:
• not be restricted in usage/purpose by the CA, or
• contain a
Key Usage field that contains a Digital Signature or have a
ExtendedKeyUsage or EnhancedKeyUsage field whose value contains
Client Authentication
If the certificate does not satisfy browser requirements, although it may be installed in the client’s store, when the FortiWeb appliance requests the client’s certificate, the browser may not present a certificate selection dialog to the user, or the dialog may not contain that certificate. In that case, verification will fail.
For browser requirements, see your web browser’s documentation.
332 FortiWeb 5.1 Patch 3 Administration Guide
Pobierz
Publiczny link zaktualizowany
Publiczny link do Twojego czatu został zaktualizowany. You may view and manage your chat links after registration here.
Publiczny link do dokumentu
Reklama