if you did e.g.
curl --insecure 'https://22.214.171.124/users/login' -d ssrc=login -d email=Webster -d password=hunter1 --header 'Host: meta.stackexchange.com'
to log into stackexchange (simplified example), then the client (i.e. the
curl command where you used
--insecure) would happily connect (and send that request with username and password) to an attacker that MITM your connection to 126.96.36.199
Evidently, if you are not sending any sensitive data, and you are treating the response as untrusted data anyway, and you don't care about wrong/invalid info, and it's not an issue that the command hangs forever or gets sent infinite data, then it might not be an issue in your specific use case (still a bad practice, though).
The proper way would be:
- Use the server hostname for which the certificate is sent:
curl 'https://meta.stackexchange.com/users/login' -d ssrc=login -d email=Webster -d password=hunter1
If you wanted to force connecting to specific IP address 203.0.113.69 instead of whatever is resolved by the dns, you could use curl option
curl --connect-to meta.stackexchange.com:443:203.0.113.69:8080 'https://meta.stackexchange.com/users/login' -d ssrc=login -d email=Webster -d password=hunter1
or simply add it to
- If the problem is that the certificate is not trusted (e.g. it's using an unknown intermediate, an internal CA, or even a self-signed certificate), you can provide an explicitly with
--cacert which CA/certificate to trust.