Implementing HTTPS to protect sensitive data in transmission

An e-commerce website wants to ensure that all user interactions, from browsing products to completing transactions, are conducted over a secure HTTPS connection instead of HTTP. This is crucial to protect sensitive information such as personal details, login credentials, and payment information from potential eavesdropping and tampering.

Solutions by FortiWeb

FortiWeb supports HTTPS traffic and can act as an SSL proxy to process the SSL/TLS encryption and decryption on behalf of your back-end servers. SSL certificates can be uploaded to FortiWeb for it to authenticate itself to clients and decrypt/encrypt requests.

The traffic flow is as below:

1. Client connects to FortiWeb to initiate an SSL connection.
2. FortiWeb presents its server certificate to the client.
3. Symmetric session keys are created, and an SSL connection gets established. The client and FortiWeb exchange information in a secure connection.

To facilitate HTTPS connections with the client, you need to perform the following:

• Uploading SSL certificates to FortiWeb

  FortiWeb presents this certificate to the client's browser to prove the authority of your website and then establish a secure connection with the browser.

• Enforcing HTTPS connections

  Redirect HTTP traffic to HTTPS, and insert an HSTS header to force the client's browser to use HTTPS service when accessing your website.

Uploading SSL certificates to FortiWeb

Self-signed certificate and CA-issued certificate

To enable HTTPS connections, an SSL (Secure Sockets Layer) certificate is required. It is a digital certificate that authenticates a website's identity. When a user visits a website with an SSL certificate, their browser and the web server establish an SSL connection through a process called the SSL handshake:

• The server sends a copy of its SSL certificate to the user's browser.

• The browser checks the certificate against a list of trusted Certificate Authorities (CAs). If the certificate is trusted, the browser generates a symmetric session key and encrypts it with the server's public key before sending it back to the server.

• The server decrypts the session key with its private key.

• Both the browser and the server now have the same session key, which is used to encrypt all further communications.

The SSL certificate is uploaded to the web server and is presented to client's browser upon SSL handshake. With FortiWeb deployed in your network, FortiWeb can act as an SSL proxy to process the SSL/TLS encryption and decryption on behalf of your back-end servers. To serve this purpose, you need to upload SSL certificates to FortiWeb for it to authenticate itself to clients and decrypt/encrypt requests.

The SSL certificate can be either self-signed or issued by a trusted Certificate Authority (CA).

The self-signed certificate is signed by the same entity that it certifies. It's usually used for internal testing, development environments, and private networks where all parties can be configured to trust the certificate. However, because it is not issued by a trusted Certificate Authority (CA), usually the external clients or browsers by default don't trust the self-signed certificate. It must be manually trusted by adding it to the client’s trusted certificate store. Otherwise, users will see a warning message when they visit your application through an HTTPS connection.

Thus, for the connections between the client and FortiWeb, it is common to use a certificate issued by a trusted Certificate Authority—an entity recognized and trusted by major browsers and operating systems. Users won't see warning messages when visiting your application if a CA-issued certificate is used for the HTTPS connections.

You can upload both the self-signed and CA-issued certificates to FortiWeb in Server Objects > Certificates > Local, then reference it in Server Policy.

SSL certificates with different cryptographic algorithms

FortiWeb supports RSA, DSA, and ECDSA certificates, which are different types of algorithms used in digital certificates for encrypting data and ensuring secure communications. Each has its own characteristics and use cases.

• RSA: It is one of the most widely used public key cryptographic algorithms. RSA's security relies on the length of the keys; longer keys provide more security. Common key sizes include 2048, 3072, and 4096 bits.

• DSA: It is a Federal Information Processing Standard for digital signatures. It's based on the difficulty of computing discrete logarithmsCommon key sizes include1024, 2048, or 3072 bits. DSA is generally faster at generating signatures compared to RSA, but slower at verifying them.

• ECDSA: It is based on elliptic curve cryptography (ECC) and provides similar security to RSA but with smaller key sizes. It relies on the difficulty of the elliptic curve discrete logarithm problem. It commonly uses key sizes like 256, 384, or 521 bits. ECDSA offers better performance and security at shorter key lengths compared to RSA and DSA, making it efficient for systems with limited resources. It's widely used in blockchain technologies like Bitcoin.

The cryptographic algorithm used to encrypt HTTPS connections is negotiated between the client and FortiWeb during the SSL handshake process. The connection will fail if the cryptographic algorithms supported by the client are not compatible with those supported by the SSL certificates presented by FortiWeb. To provide broader compatibility across different clients and devices, you can configure RSA, DSA, and ECDSA certificates into one "Multi-certificate" and reference it in the Server Policy.

Let's Encrypt certificate

If you don't have a physical CA-issued certificate to upload to FortiWeb, you can use the Let's Encrypt certificate as an alternative. Let's Encrypt is a non-profit certificate authority run by the Internet Security Research Group (ISRG), providing X.509 certificates for Transport Layer Security (TLS) encryption at no charge. A Let's Encrypt certificate functions the same as a CA-issued certificate, with simpler configuration. Simply enter your domain name, and FortiWeb will obtain a certificate from Let's Encrypt on your behalf.

Let's Encrypt certificate is configured through Sever Objects > Certificates > Let's Encrypt, then is referenced in Server Policy.

Enforcing HTTPS connections

Redirecting HTTP Traffic to HTTPS

It's common for web applications to initially support both HTTP and HTTPS services. However, it is much safer to configure the application to automatically redirect all HTTP traffic to HTTPS, for instance, access to "http://www.example.com" is automatically redirected to "https://www.example.com". This ensures that all data transmissions are encrypted and secure, protecting users from various security threats.

Enabling HTTPS redirection in FortiWeb is just one click. In Server Policy, if you have selected both HTTP and HTTP services, the "Redirect HTTP to HTTPS" option will appear.

Using HSTS Header to force clients to use HTTPS

The HTTP Strict Transport Security (HSTS) header is a security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. By implementing HSTS, you ensure that browsers only interact with your site using HTTPS, even if the user attempts to use HTTP. This is especially important for preventing man-in-the-middle attacks and ensuring the confidentiality and integrity of the data transmitted.

How HSTS Works

• Initial HTTPS Connection: When a user first connects to your application via HTTPS, FortiWeb sends an HSTS header to the browser.

• Enforcement: The browser stores this policy and automatically converts all subsequent HTTP requests to HTTPS for the specified duration.

• Future Requests: Any future attempts to access the site using HTTP are automatically redirected to HTTPS by the browser.

The HSTS header settings are available in Server Policy as shown below.

By implementing HTTPS the sensitive customer data is protected during transmission, reducing the risk of data breaches and enhancing overall security.