Curl, SSL and Security

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

In general NEVER turn this check off.

Having the data transmitted in encrypted form does not make it secure, it will only be safe if you ensure that the recipient of the information is actually who you say you are. This is only possible if you set CURLOPT_PINNEDPUBLICKEY (available in PHP 7.0.7+) this is the most secure of the methods. Another more versatile option is to trust an authority (eg Comodo) and then use CURLOPT_CAINFO to determine which authorities are trusted for you and CURLOPT_SSL_VERIFYPEER to true to verify that the certificate was issued by someone who you trust.

If you do not use VERIFYPEER you are vulnerable to:

• DNS Poisoning
• Spoofing
• Proxy Attacks
• ARP Spoofing

etc ...

SSL without using VERIFYPEER as high as possible may be encrypted traffic, but it does not guarantee that the destination of your connection is real, which partially negates the purpose of SSL

in>.

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

What is the use of encrypted traffic? Nothing.

If you turn off CURLOPT_SSL_VERIFYHOST , the certificate can even be abc.com and is connecting to xyz.com and will be valid.

"Data interception" will not occur because you have stopped using SSL! It will occur because it is not necessarily connecting to the actual server because of non-verification of the certificate.

No need 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   it's not enough, you can not be sure   communicating with the correct end-point.

    

Putting "false" does not make anything unsafe because connection will still be SSL and encrypted. You just can not put false if you're doing this on a service or link that needs certificates with validation, because in that case, you would receive a lot of complaints about not being able to authenticate the certificate on the site. In this case, this security is necessary to avoid malicious code that assumes the identity of "microsoft.com" and that starts to create own hosts of Windows Update, that can threaten and compromise the integrity of the server, being able to send viruses or open ports through of keys that install themselves or malicious scripts. No matter what configuration you make of it, if you force an SSL connection, it will be secure and encrypted. In short, putting "true" is only necessary, if there is a certificate request, since it has data entry, there are dangers.

Here are more details , if you understand English.