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.
CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
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:
- 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
- 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
- Use TLS for all pages, not just sensitive ones
- 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
Enable TLS encryption
To provide a secure way for your users to communicate with your web application, you must enable TLS encryption. You can enable TLS encryption by configuring trusted certificates.