Verified vulnerabilities,,,,,,,,
CVSS,Verified,Asset,Name,Areas,Reference,Details,Summary,Solution
7,true,1.2.3.4,TLSv1 Support Offered,sysadmin,There are no references to show,"offered (deprecated)","The affected host offers TLS 1.0 as a supported protocol, which is known to be vulnerable to man in the middle attacks, downgrade attacks, and a number of cipher related issues. TLS 1.0 should be disabled in favour of higher versions of TLS such as 1.2 and/or 1.3. Furthermore, any organisation seeking Payment Card Industry (PCI) compliance must disable TLS 1.0 to meet compliance standards. (Note: It's not common but disabling TLSv1.0 can result in older clients no longer being able connect to your website.)","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
7,true,1.2.3.4,TLSv1 Support Offered,sysadmin,There are no references to show,"offered (deprecated)","The affected host offers TLS 1.0 as a supported protocol, which is known to be vulnerable to man in the middle attacks, downgrade attacks, and a number of cipher related issues. TLS 1.0 should be disabled in favour of higher versions of TLS such as 1.2 and/or 1.3. Furthermore, any organisation seeking Payment Card Industry (PCI) compliance must disable TLS 1.0 to meet compliance standards. (Note: It's not common but disabling TLSv1.0 can result in older clients no longer being able connect to your website.)","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
5,true,1.2.3.4,Potentially Vulnerable To BEAST - CVE-2011-3389,sysadmin,https://www.cvedetails.com/cve/CVE-2011-3389/,"VULNERABLE -- but also supports higher protocols  TLSv1.1 TLSv1.2 (likely mitigated)","A number of Cipher Block Chaining (CBC) mode ciphers offered by SSLv3/v2 and TLS 1.0 are vulnerable to the Browser Exploit Against SSL/TLS. (BEAST) attack, which can enable an attacker to extract plaintext from an encrypted session. As the attack is inherent to certain ciphers used by SSLv3/v2 and TLS 1.0, these protocols should be disabled and replaced with TLS 1.2 and/or TLS 1.3","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
5,true,1.2.3.4,TLS_FALLBACK_SCSV Support,sysadmin,There are no references to show,"NOT supported","TLS_FALLBACK_SCSV is a Signalling Cipher Suite Value (the SCSV part) that allows a browser to indicate to a server when the current connection attempt is a fallback attempt. When present in the client hello, the server knows that the connecting client can use a better protocol than it is currently connecting with and will reject the connection. TLS_FALLBACK_SCSV gained a lot of popularity after POODLE as it would prevent clients that supported TLS from being forced back to SSLv3 to be attacked. It's a great feature to support on your server as it will prevent a client being forced back from TLSv1.2 to TLSv1.1 for example. We don't really want to be in a situation where an attacker can dictate the protocol we use to communicate so TLS_FALLBACK_SCSV is highly advised","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
5,true,1.2.3.4,Potentially Vulnerable To SWEET32 - CVE-2016-2183, CVE-2016-6329,sysadmin,https://www.cvedetails.com/cve/CVE-2016-2183/,"uses 64 bit block ciphers","The affected service’s SSL/TLS configurations allow for Triple DES ciphers and/or Blowfish ciphers in Cipher Block Chaining (CBC) mode to be used. These ciphers offer block sizes of 64 bits, which when used in CBC mode are vulnerable to a collision attack known as Sweet32 which can enable an attacker to decrypt cipher text after it has been captured in transit. Triple DES support and/or Blowfish support should be disabled to mitigate this.","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
4.3,true,1.2.3.4,RC4 Ciphers offered - CVE-2013-2566, CVE-2015-2808,sysadmin,There are no references to show,"VULNERABLE, Detected ciphers: RC4-SHA RC4-MD5","The affected systems offer RC4 stream ciphers when forming a secure connection which are known to be vulnerable to a number of issues including the Bar-Mitzvah and NOMORE attacks, effectively making it a broken cipher. Furthermore, the Internet Engineering Task Force (IETF) has called for the use of RC4 to be prohibited across the internet (See: https://tools.ietf.org/html/rfc7465). RC4 ciphers are considered extremely insecure and should be disabled","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
3,true,demo.com,No SPF Record,sysadmin,There are no references to show,no details available,"There is no SPF DNS record for the domain.","Create a SPF record using a tool like https://www.spfwizard.net/"
3,true,1.2.3.4,TLSv1.1 Support Offered,sysadmin,There are no references to show,"offered (deprecated)","The affected host offers TLS 1.1 as a supported protocol, which is known to be vulnerable to man in the middle attacks, downgrade attacks, and a number of cipher related issues. TLS 1.1 should be disabled in favour of higher versions of TLS such as 1.2 and/or 1.3. (Note: It's not common but disabling TLSv1.1 can result in older clients no longer being able connect to your website.)","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
3,true,1.2.3.4,TLSv1.1 Support Offered,sysadmin,There are no references to show,"offered (deprecated)","The affected host offers TLS 1.1 as a supported protocol, which is known to be vulnerable to man in the middle attacks, downgrade attacks, and a number of cipher related issues. TLS 1.1 should be disabled in favour of higher versions of TLS such as 1.2 and/or 1.3. (Note: It's not common but disabling TLSv1.1 can result in older clients no longer being able connect to your website.)","In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
,
,
,
Unverified vulnerabilities,,,,,,,,
CVSS,Verified,Asset,Name,Areas,Reference,Details,Summary,Solution
2,true,1.2.3.4,Incorrect use of Certificate,sysadmin,There are no references to show,"Certificate incorrectly used for digital signatures: 'Key Encipherment, Data Encipherment'","The certificate wasn't meant for the use it's been given.","Generate a new and correct certificate"
2,true,1.2.3.4,Lack of OCSP Stapling and CRL URIs,sysadmin,There are no references to show,"Neither CRL nor OCSP URI provided","Neither CRL nor OCSP URI provided. The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ('stapling') a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance. A certificate revocation list (CRL) provides a list of certificates that have been revoked. Publish the CRL at a publicly accessible location third-parties can fetch the CRL from this location to check whether any certificates they rely on have been revoked.","Configure a OSCP record and a certificate revocation list URL In short, the following summarises SSL/TLS hardening options that should be considered: Use 2048-bit RSA private keys and 256bit ECDSA private keys. Renew certificates on an annual basis. Use strong certificate signature algorithms (sha512). Disable SSLv2, SSLv3, TLSv1.0, and TLSv1.1 - support TLS 1.2 and 1.3. Disable insecure cipher suites (ADH, Null, Export, RC4 and 3DES). Support Forward Secrecy (ECDHE). Use strong key exchange algorithms (ECDHE and DHE > 2048-bit). Ensure the underlying software is patched and up to date. Encrypt everything and eliminate mixed HTTP/HTTPS content. Implement HTTP Strict Transport Security (HSTS) to ensure secure connections cannot be downgraded to an insecure connection. Support TLS_FALLBACK_SCSV to prevent protocol downgrade attacks. Disable SSL/TLS Compression. Configure a OSCP Stapling record and a certificate revocation list URL. Support Secure Renegotiation but don't allow Client Initiated Renegotiation. Create certifiates with a life time of 365 days. If using DH, use a 2048-bit Diffie-Hellman group. Configure a DNS CAA record in the DNS server.  Note: Implementing a strong SSL/TLS configuration can result in user agents no longer being able to connect to your site due to lack of compatible cipher suites. Recommended Reading: https://wiki.mozilla.org/Security/Server_Side_TLS https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/"
2,true,1.2.3.4,Lack of DNS CAA Record,sysadmin,There are no references to show,"--","CAA records allow domain owners to declare which certificate authorities are allowed to issue a certificate for a domain. They also provide a means of indicating notification rules in case someone requests a certificate from an unauthorized certificate authority. If no CAA record is present, any CA is allowed to issue a certificate for the domain. If a CAA record is present, only the CAs listed in the record(s) are allowed to issue certificates for that hostname.","Configure a DNS CAA record in the DNS server"
2,true,1.2.3.4,Lack of DNS CAA Record,sysadmin,There are no references to show,"--","CAA records allow domain owners to declare which certificate authorities are allowed to issue a certificate for a domain. They also provide a means of indicating notification rules in case someone requests a certificate from an unauthorized certificate authority. If no CAA record is present, any CA is allowed to issue a certificate for the domain. If a CAA record is present, only the CAs listed in the record(s) are allowed to issue certificates for that hostname.","Configure a DNS CAA record in the DNS server"
1,true,demo.com,No DMARC record,sysadmin,There are no references to show,no details available,"There is no DMARC DNS record associated for the domain.","Create a DMARC DNS record using a tool like https://dmarcian.com/dmarc-record-wizard/"