Curl, SSL and Security

Question

Hello

I have a little doubt about CURL and SSL.

I have seen that it is unsafe to put false in CURLOPT_SSL_VERIFYPEER, because it would make CURL not check SSL, enabling data interception.

But I didn’t understand how this could happen. For example, I have a script on a server that accesses another server via https. For someone to intercept this, it would need to be on the same physical server network where my script is hosted, right? If not, how could such insecurity be explained?

Thank you

Answer 1

Putting "false" does not make anything unsafe, as connection will still be SSL and encrypted. You just can’t put false if you’re doing this on a service or link that requires certificates with validation, in which case you would receive many complaints about not being able to do the authenticity of the certificate on the site. In this case, this security is required to prevent malicious code that assumes the identity of "microsoft.com" and that starts creating own Windows Update hosts, which can threaten and compromise the integrity of the server, can send viruses or open doors through keys that are installed or malicious scripts. Regardless of any configuration you make in this, if you force an SSL connection, it will be secure and encrypted. In short, putting "true" is only necessary, if there is a request for certificates, because then there is data entry, there are dangers.

Here are more details, understand English.

Answer 2

Assuming you are connecting with an HTTPS server and define the CURLOPT_SSL_VERIFYPEER for false you become vulnerable to attacks from MITM, even some libraries have had problems with this in the past, such as Google Adwords PHP Client, since the stream_context_get_default() in PHP 5.6 and below did not check the certificates were issued by a trusted authority (self-signed was valid), thus making it vulnerable to connections that are not real from Google.

In general NEVER turn off this check.

Having the data transmitted in an encrypted way does not make it safe, it will only be safe if you ensure that the receiver of the information is really who it says it is. This will only be possible if you set the CURLOPT_PINNEDPUBLICKEY (available in PHP 7.0.7+) this is the safest of methods. Another and more versatile option is to trust an authority (e.g. Comodo) and then use the CURLOPT_CAINFO to determine which authorities are reliable for you and the CURLOPT_SSL_VERIFYPEER for true to check if the certificate was issued by someone you trust.

---

If you do not use the VERIFYPEER you are vulnerable to:

• DNS Poisoning
• Spoofing
• Proxy Attacks
• ARP Spoofing

etc....

---

SSL without using the VERIFYPEER the most that can occur is the information be trafficked in an encrypted way, but it does not guarantee that the destination of your connection is real, which partially cancels the purpose of SSL.

Imagine want to connect with the https://google.com, then you need a DNS that finds the real host of google.com. The DNS is attacked and sends you to the 1.1.1.1. This 1.1.1.1 uses a certificate self-signed by the name of google.com, your CURL will connect to it normally. Then this false server will have how to get the information you would send to the google.com and for you not to suspect he makes a proxying to the real google.com, returning true results. Now the intermediary server (1.1.1.1) has the information you sent and the actual response from google.com.

What good did having encrypted traffic do? Nothing.

If you turn off the CURLOPT_SSL_VERIFYHOST the certificate may even be abc.com and is connecting in xyz.com and will be valid.

---

"Data interception" will not occur because you stopped using SSL! It will occur because it is not necessarily connecting to the actual server due to not checking the certificate.

---

You don’t have to trust me, CURL’s own words:

WARNING: Disabling Verification of the Certificate Allows bad guys to man-in-the-Middle the Communication without you Knowing it. Disabling Verification makes the Communication insecure. Just having Encryption on a transfer is not enough as you cannot be sure that you are communicating with the correct end-point.