At some points developers of applications with either need to include some library, or make use of a native API, to perform a network call over HTTPS. Often appropriate certificate validation is performed by there libraries or APIs. However there are occasions when developers could hit certificate validation related errors. Often they might perform a search for the error and come across several results as to how to remedy the issue. The problem though is often the answer given is extremely insecure, disable certificate validation.
Why Disabling Certificate Validation is a REALLY Bad Idea
When connecting to a system, you want to make sure that you are in fact talking with the system which you originally intended to communicate with. This is where certificates come into play. When a client connects to a server of TLS, a TLS handshake is performed. A part of this handshake is a step where the server presents its server certificate to the client. This certificate should be validated by the client to ensure that it can be trusted (signed by a Certificate Authority which the client trusts) and is intended for the server (hostname validation). I detailed certificates in a previous post, so I would recommend that you have a read of it if you are unfamiliar about certificates. If you do not perform sufficient certificate validation, you significantly increase the risk of Man in The Middle (MiTM) attacks. This is an attack where the attacker would insert themselves in the connection between the client and server, and they would be able to view or modify the data in the traffic. So as you can see, it's vital to validate the server certificate. In terms of validating it, you should do so in the following order of importance:
- Validate the certificate is signed by a Certificate Authority (CA) which you trust. If you don't perform this step the attacker could simply create any certificate which would pass the next 2 steps.
- Validate the certificate is for the certificate. This is done by validating that the hostname of the server (the hostname which the client uses to connect to) either matches a DNS entry in the Subject Alternative Name (SAN) field or the Common Name (CN) attribure in the subject field.
- Validate the dates on the certificate. Typically at the expiration date on the certificate has not passed. It is not very common to have a certificate issued before the begin date.
Coming back to forums and questions, some examples include (taken from posts on stackoverflow):
The problem is that even some of the answer may include a sentence explaining that the solution is not secure, often developers are looking for a quick answer and may not read the sentence. Also unless you know what you are doing and why it is insecure, it is unlikely you know what would make it secure. Remember there's likely a reason why they were looking at this forum or page in the first place.
Your best defense is to look to the source code to look for common code which will disable certificate validation. This is by far the most efficient means of checking if your system(s) have had certificate validation disabled. And hopefully you are using some form of source code control, such as Git, which would allow you to potentially identify who disabled certificate validation and help them understand why it is a really bad idea and how you can help them address it.
To help with this, I've started a living document on GitHub, which hopefully can be used to help form a lookup which can be used to search in your source code for code which is disabling certificate validation. Any additional feedback and input would be most welcomed.
