Enable TLS encryption

There is no SSL/TLS encryption enabled on your server. As a result, all traffic to your web application is transported over unencrypted channels. This leaves your users vulnerable to man-in-the-middle attacks.

Security assessment

Security_Assessment_EnableTLSEncryption CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Vulnerability information

TLS is a cryptographic protocol that evolved from the now-deprecated Secure Socket Layer (SSL) protocol. The purpose of both protocols is to secure web sessions and data transfer over the internet, mainly on the application layer, though not exclusively.

When properly applied, TLS encryption offers several major security advantages:

Authentication: enables clients to verify the identity of the server, i.e., that they are connected to the real server
Confidentiality: prevents attackers from reading the contents of traffic
Integrity: prevents attackers from modifying traffic
Replay prevention: protects against attackers replaying requests against the server

TLS encryption vulnerability information

The lack of TLS encryption is a major vulnerability that leaves traffic exposed and easily accessible by malevolent parties.

But even with TLS encryption, there are a number of possible directions from which your application can be attacked and compromised. Some of the attacks that can be launched against systems using TLS encryption include:

Renegotiation attacks
Downgrade attacks
Cross-protocol attacks
Timing attacks on padding
BEAST, CRIME, BREACH, and POODLE attacks, and more.

How to prevent TLS vulnerabilities

The OWASP Cheat Sheet section on Transport Layer Protection offers a number of measures that can be taken to prevent TLS vulnerabilities. These include:

Server configuration

Only provide support to strong protocols such as TLS 1.2 and 1.3, and disable all other protocols
Only provide support to strong ciphers and, if possible, only Galois/Counter Mode (GCM) ciphers
If using an ephemeral Diffie-Hellman key exchange, only strong DH parameters should be used
Disable TLS compression to prevent CRIME
Keep cryptographic libraries up to date with the latest patches
Test the server configuration once it has been hardened

Certificates

Use a strong private key and protect it from unauthorized access using filesystem permissions and other controls
Use strong cryptographic hashing algorithms such as SHA-256
Ensure the domain name matches the fully qualified name of the server that presents the certificate
Reconsider the use of Wildcard Certificates due to the increased risk of a security compromise
Use a trusted and well-known certificate authority (CA)
Use Certification Authority Authorization (CAA) DNS records to define the CAs that can issue certificates
Always provide intermediate certificates along with the main certificate
Consider the use of extended validation (EV) certificates if they can provide additional security and value

Application

Use TLS for all pages, not just sensitive ones
Do not use non-TLS content (such as JavaScript or CSS) on pages that are available over TLS
Flag all cookies with the Secure attribute
Use HTTP headers to instruct browsers not to cache sensitive information
Utilize HTTP Strict Transport Security (HSTS) to ensure the browser always requests the site over HTTPS
Consider the use of Client-Side Certificates so that clients are also required to verify their identity
Use public key pinning to provide assurance that the server certificate is valid, trusted, and matches the certificate expected for the server