Reduce Your Risks: SSL / TLS Certificate Weaknesses
SSL / TLS Certificate Security
Welcome to the first of our Reducing Your Risks blog series where we address a range of security vulnerabilities and share best practice to protect your organisation from threat actors.
Here, our senior cyber security pro Abdul Ikbal looks at common SSL / TLS certificate weaknesses, the risks, and what you can do about them.
SSL (Secure Sockets Layer)
If you’re still using SSL v3 or below, I feel bad for you son, you may have 99 problems but SSL shouldn’t be one of them. You should be using TLS v1.2 or 1.1 at minimum.
SSL was the standard security protocol for disguising data in transit. It enabled sensitive information, e.g. credit card numbers, to be sent in encrypted form rather than plain text, which could be intercepted by an attacker.
That said, following SSL’s long existence (much like some of the consultants I work with), widespread use and aggressive security research targeting it, significant risks were recently identified.
In 2015, v3 of the protocol was deprecated due to the discovery of a critical flaw which allowed malicious attackers to extract secret information from encrypted communications.
TLS (Transport Layer Security)
We recommend using TLS, the successor to SSL. If used correctly and until otherwise stated, i.e. a vulnerability is released, v1.2 or at minimum v1.1 of the protocol should be used.
A Quick Bit On Cryptography and Encryption
People often use the terms cryptography and encryption interchangeably, but they are different.
The word cryptography derives from the Greek word kryptos, meaning hidden. It’s the science, practice or study – call it what you will, for disguising plain /clear text information to make it secret.
Encryption does the job of disguising the information itself using a mathematical formula (algorithm) known as a cipher.
The process involves a public and a private key; a key pair. The public key, as the name suggests, may be accessed by anyone and is used to encrypt data. The private key is the confidential property of the owner and is used for decrypting the information.
To establish a secure connection between a browser and a web server, you must apply for a TLS Certificate. Certificates have a key pair, a public and private key as mentioned above. Together, the keys establish an encrypted connection.
If deployed in line with industry standard security practices, the certificate can significantly increase the security of a secure service. The certificate commonly includes:
- Issuer – the entity that verified the information and issued the certificate (Certificate Authority)
- Valid to – the expiration date, after which the certificate in no longer valid
- Signature algorithm: The algorithm used to create the signature (keys) and prove its integrity
There are many certificate authorities that provide certificates for a price or for free. Our favourite free certificate authority is Let’s Encrypt.
Below, we discuss some of the basic and common SSL/TLS based issues we encounter.
Untrusted Certificate Attacks
Expired or untrusted certificates are an issue as they are taken advantage of by attackers. For example, if users are accustomed to seeing an expired certificate and usually ignore them, they’ll do exactly this when viewing your site. Elements of social engineering are required, however, in our opinion such attacks are trivial to perform these days.
The Solution: All certificates should be signed by a trusted Certificate Authority. This can be a reputable third party Certificate Authority or using Public Key Infrastructure that exists within the organisation. The latter would require the Certificate Authority root certificate to be installed on all connecting clients, which can be done through the modification of Windows Group Policy:
- Open the relevant Group Policy Object (GPO)
- In the console tree, click Trusted Root Certification Authorities: Policy Object Name/Computer Configuration/Windows Settings/Security Settings/Public Key Policies/Trusted Root Certification Authorities
- On the Action menu, point to All Tasks, then click Import to add the root certificate
Expired Certificates Attacks
Similar to untrusted certificates, a user connecting to an SSL service with an expired certificate is presented with an error message notifying that the certificate’s validity period has lapsed. Commonly this means that the Certificate Authority is no longer reporting on the integrity of the certificate.
In the case of internal-use SSL services, errors such as this are likely to be disregarded by regular users, which can again lead to the increased likelihood of successful DNS spoofing or Man-in-the-middle attacks against affected services.
The Solution: Maintain a record of certificate validity periods and ensure the renewal process is started thirty days before certificate expiry.
Weak Hashing Algorithm Attacks
A hashing algorithm is used to provide a certificate with a digital signature to ensure that its contents have not been altered. Hashing algorithms come in various types, some of which have been cryptographically broken and are subject to hash collisions; an attack which would facilitate the generation of fraudulent certificates.
If such attacks succeed, a malicious group or individual could masquerade as a trusted service and be privy to all the data passed between a user and that service. Not good…
The Solution: We recommend that all certificates signed using weak hashing algorithms such as SHA-1 and MD5 are reissued and mandated to use the SHA-2 family of hashing algorithms (SHA-224, SHA-256, SHA-384, and SHA-512).
Weak RSA Key Length Attacks
SSL certificates signed using RSA keys less than 2048 bits are considered weak, as given advances in computing power they are increasingly vulnerable to being broken in a reasonable time-frame. A successful attack of this nature would provide an attacker with clear text access to encrypted data as it’s in transit between client and server.
Quick geeky fun – YouTube: Rivest, Shamir, Adleman – The RSA Algorithm Explained
The Solution: Affected certificates in the chain with the RSA key less than 2048 bits in length are replaced with a longer key and any certificates signed by the old certificate are re-issued.
Improperly Signed SSL Certificates (Failure to Adhere to Basic Constraints / Key Usage Extensions)
Improperly signed X.509 certificates contain one or more violations of the restrictions imposed on it by RFC 5280. This means that either a root or intermediate Certificate Authority signed a certificate incorrectly. Certificates that fail to adhere to the restrictions in their extensions may be rejected by certain software.
The existence of such certificates indicates either an oversight in the signing process or malicious intent.
The Solution: The offending certificates’ extensions are altered and the certificates re-signed or re-issued.
If you need support with any aspect of your information security, you are welcome to contact us for friendly advice.