I'm trying to write code that sets strong-ish security by default and is also relatively future-proof so far as curl is concerned, meaning it doesn't need an update if TLS 1.4, 1.5 etc come into use in future. The purpose is to send packets over HTTPS to the user's ISP, when the ISP uses Plesk and only enables its XML API. So it's pretty sensitive.
With this API, the user's credentials are sent unencrypted as HTTP headers, which is far from ideal, so a fairly strong minimal TLS and some kind of cert check arguments are needed.
According to the
man page, there aren't any options that set a minimum encryption:
--tls-max- sets a maximum limit. (Doesn't seem to be a matching arg for
--tlsauthtype- only supports SRP
--tlsv1.[0-3]- says it "Forces curl to use [exactly] TLS version 1.[0-3]", rather a minimum of TLS1.[0-3]. (There are some answers saying this specifies a minimum, but the FreeBSD man page says on that system at least, it sets an exact match only).
-1, --tlsv1- forces TLSv1 but doesn't care which version.
I will be using
--anyauth to request the strongest possible, but that just requests best negotiable, not a minimum. I don't want to change any other system aspects of encryption settings, just the ciphers that cURL will use for this call. The code could be used on a wide range of current and other *nix OSes.
Is there a way to ensure TLS "at least v1.2" or similar, if I want to set a broadly workable minimum by default for the user (who may be on many types and ages of system)?
If not, could I send some kind of null data or minimal header only as a probe, to test the cipher it would use, and check if that matches say
tls(1\.[2-9]|[2-9]\.)or something, before sending any "real" data?
Also as a bonus, are there any certificate related options that would normally be used, or are standard, to check the cert for the 3rd party URI is also valid, so it can't be redirected to a spoof IP if the user's DNS cache gets poisoned or a spoof IP is received?