If you as a client trust the server and know the IP of the server, and intend to initiate a HTTPS request to that IP, what are the potential vulnerabilities in disabling server certificate verification, such as disabling this with curl via -k/--insecure?
Specifically, can an attacker replace the certificate in a man-in-the-middle-attack during the key exchange?
Yes. If your client does not verify the certificate that it sees for the server, then this opens the door for a man in the middle (MITM) attack.
See https://en.wikipedia.org/wiki/Man-in-the-middle_attack for some interesting reading on how MITM attacks work. As you can see, the basis for the attack is that the MITM attacker replaces the server's actual certificate with his own fake certificate. The attack is deadly - but the attack can only succeed if the MITM is able to dupe the client into trusting the MITM's fake certificate instead of the server's actual certificate.
If the client blindly trusts the certificate that it sees for the server without verifying it (which is what curl does when the --insecure option is used; or what wget does when the --no-check-certificate option is used) - then anyone in a position to intercept the traffic between the client and the server (such as your ISP, or the operator of the Wifi hotspot that you are using, etc.), could act as a MITM, and use a tool such as sslsniff with a fake certificate to MITM the SSL/TLS connection between the client and the server. This is why it is so important for the client to validate that the certificate that it sees for the server is actually the true and correct certificate for the server.
Typically, the client performs this validation by verifying that the certificate that it sees for the server is signed by a certificate authority (CA) that the client trusts. Command line tools such as curl and wget have the ability to do this.
If using a command line tool such as curl and wget to make an https request, and the tool fails due to a certificate validation error - the most likely cause is that the tool simply does not know where to find the root CA certificate that the site's certificate chains up to. Rather than addressing the symptom (by simply disabling certificate checking), it's much better to address the source of the problem, to avoid opening the door to a MITM attack.
The attacker does not need to replace certificate on the target server. Also the attacker will not wait until the client received the certificate from the server, because afterwards there will be no way to read the traffic.
The attacker will intercept any request from the client to the server. If request means initiating TLS connection, the attacker's device will behave as a server. In particular, when the client requests a certificate, the attacker will generate a certificate and send it back. Even though the certificate is self-signed or issued by some non-trusted CA of the attacker, your client will trust it and establish a TLS session.
Also the attacker will establish a TLS session to the server. The attacker will read request from your client, modify if needed, and send to the server. Then receive a server response, modify it if needed, and send to your client.
Yes.
if you did e.g.
curl --insecure 'https://151.101.1.69/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 151.101.1.69
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:
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 --connect-to
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 /etc/hosts
--cacert which CA/certificate to trust.