Guzzle disabling certificate verification to false, how insecure is it?

Question

Recently I found myself working with Guzzle while making requests to another server to post and fetch some data, in some cases, tokens. But I was getting certificate invalid error and I even tried to get a new .pem certificate, but Guzzle was still not accepting and kept throwing that error. So finally, I did what the "Internet" said:

$guzzleClient = new Client([
    'verify' => false
]);

Now although this solution works, I am not sure how insecure it can get. Do I need to worry? If yes, in what scenarios?

Innards

Thank you very much , happy to be of assistance – Estell

Answer 1

well this is a big problem if you are for example

1. having login system on the request you are sending using guzzle
2. having payment/checkout on the request
3. basically any sensitive data being passed to the other server

because when you pass data without SSL certificate then your requests might get caught by malicious programs like

BurbSuite / WireShark , cain and abel / EtterCap 

as these programs are Sniffing programs and anyone can get a version from the internet as they are open sourced and every thing going without SSL can be intercepted by the hacker using the tools mentioned above and the hacker can look to the entire request in plaintext! so its highly recommended to use SSL connection when passing sensitive data

Worth Mentioning : now a days even SSL isn't very secure because hackers can remove it using SSLStrip tool but believe me SSL will make it much harder for them to get to your request because if they used it your website sometimes will make non-completed requests and it will notify the user that the network isn't secure this will make it very hard for the hacker to get the user's data,

Estell

if you ever feel that you need any more explanation or examples pls notify me and i will provide some for you but i think the idea is very clear – Estell

Okay, small side question, let us say that a request is secured by a SSL, it is hard for the sniffer to decrypt data, but what if the sniffer gets a hold on the .pem cert file, will be it very easy for them to decrypt the request and look at the data being passed in? – Innards

well if the attacker got a hold of the certificate then if he is an experienced hacker then he can attack and sniff data like if there wasn't SSL certificate but if the hacker is just for example sniffing data over network just for having fun and he didn't study cyper security then it properly will mean nothing to him and he wouldn't f go through the trouble of using it, to reference checkout here security.stackexchange.com/questions/16685/… – Estell

Okay, I have one more example, I am using curl and guzzle (which uses curl underneath anyway), and in many scenarios I keep getting a curl 60 error, SSL certificate not found/verified/expired. So many peeps on the internet point to this -> curl.haxx.se/docs/caextract.html and suggest using the cacert.pem file here. In some of the places I have seen people use it and keep it publicly as it is already a public file. My question is what is the benefit of encrypting data using a public pem file? Like everyone can see the certificate, so what benefit does this avail? – Innards

i think that the file they stored as if its public file contains only the public key of the certificate and even if the hacker got it , it would be worthless because he also needs the private key , what i commented before was if the hacker got the entire file (public key + private key) then he can do MITM attack , sniffing , etc but if he has only the public key then it would be with no value to him i would like to refer this question security.stackexchange.com/questions/160004/… – Estell

basically the public key is as the name suggests its public which means the client should have Read authority to it , so the mechanism is your server sends the public key , the client checks the public key and then the client sends its public key as well after checking that both keys are valid , both of them generate session keys and these keys will be removed at the end of the communication , these keys will be used to encrypt/decrypt everything in this session you may want to take a look here cloudflare.com/learning/ssl/how-does-ssl-work – Estell

The OP is talking about not verifying the certificate, not disabling SSL. So actually the requests are using SSL, just that it doesn't care if the certificate is signed by CA or not if verify is false. – Mireyamiriam

Answer 2

TLS/SSL in common configurations is meant to give you three things:

• confidentiality - no third party is able to read the messages sent and received,
• integrity - no third party is able to modify the messages sent and received,
• server authentication - you know who are you talking to.

What you do with setting verify to false is disabling the certificate verification. It immediately disables the server authentication feature and enables loosing confidentiality and integrity too when facing an active attacker that has access to your data stream.

How is that?

First of all TLS/SSL relieas on Public Key Infrastructure. Without going into too much details: you hold on your machine a set of certificates of so called Certification Authorities (CA) whom you trust. When you open a new communication to a service, you get the services certificates and in the process of verification you validate amongst other things if the certificate belongs to a CA you trust. If yes, then the communication may proceed. If no, then the communication channel is closed.

Attack patterns

Disabling certificate verification allows for Man-in-the-Middle (MitM) attacks than can easily be performed in your local network (e.g. via ARP poisoning attacks), in the local network of the service you are calling or in the network between. As we usually do not trust the network completely, we tend to verify.

Imagine me performing an attack on you. I have performed ARP poisoning, now I can see all your traffic. It's encrypted, isn't it? Well, not obviously. The TCP handshake and TLS handshake you believe you have performed with the target service - you have performed with me. I have presented you not the certificate of the target service, as I am unable to fake it, but my own. But you did not validate it to reject it. I have opened a connection between me and the target service on your behalf too so I can look into the decrypted traffic, modify if necessary and reply to you to make you believe everything is ok.

First of all - all your secrets are belong to me. Second of all - I am able to perform attacks on both you and the target service (which might have been secured by authentication mechanisms, but now is not).

How to fix this?

In XXI century there should be little reason to disable TLS verification anywhere. Configuring it to work properly might be a pain though, even more when you are doing it for the first time. From my experience the most common issues in the micro service world are:

1. the target certificate is self-signed,
2. you are missing a CA root certificate in your trust store,
3. the microservice does provide his certificate, but does not provide an intermediate CA certificate.

It's hard to guess what your issue is. We would need to dig deeper.

Herc

So this is my problem -> github.com/guzzle/guzzle/issues/1935 and this is probably the solution -> github.com/guzzle/guzzle/issues/1935#issuecomment-371756738 but my question here is that the cert file that is recommended is open to public. So when guzzle (curl underneath) is making requests from one of my services to another, even when using that cert, is it secure? Like that pem file is public, doesn't that defeat the whole purpose? – Innards

That's how asymmetric cryptography works. One key is private, one is public. When you define whom you trust, you define it based on the public part of the key. Private key is for proving, that the public key belongs to you. And - well - private is private. You don't share it. It's hopefully lying safe on the server. – Herc

Answer 3

While the other answers points out some really good point about how important SSL/TLS is, your connection is still encrypted and the remote endpoint you're using has https:// in it as well. So you're not entirely disabling SSL when you set verify to false if I'm not mistken. It's just less secure since that you're not verifying the certificate of the remote server if they are signed by a Certificate Authority (CA) using the CA bundle.

Do you need to worry?

If this is something on your production, ideally you'd want things to be secure and configured correctly, so yes. By not verifying the certificate, like Marek Puchalski mentioned, there's possibility of the server might not be the one you think it is and allows mitm (man in the middle) attack as well. More about mitm here, and peer verification here.

Why is it happening & how do you fix it?

• Most common issue is misconfigured server, especially PHP configuration. You can fix your PHP configuration following this guide, where you'll be using adding the CA root certificates bundle to your configuration. Alternatively you can add this to Guzzle.
• Another common issue is, the remote server is using a self-signed certificate. Even if you configured your CA bundle in your trustedstore, this certificate can't be trusted since it's not signed by a trusted CA. So the server needs to configure a SSL certificated signed by a CA. If that's not possible, you can manually trust this CA root, however this comes with some security concerns as well.

Hope this helped :)

Mireyamiriam