Eu estou tentando escrever código que defina segurança de alta segurança por padrão e também é relativamente à prova de futuro no que diz respeito a curl, o que significa que ele não precisa de uma atualização se o TLS 1.4, 1.5 etc. entrar em uso futuro. O objetivo é enviar pacotes via HTTPS para o ISP do usuário, quando o ISP usa o Plesk e apenas habilita sua API XML. Então é bem sensível.
Com esta API, as credenciais do usuário são enviadas sem criptografia como cabeçalhos HTTP, o que está longe de ser ideal, portanto, é necessário um TLS mínimo razoavelmente strong e algum tipo de argumento de verificação de certificado.
De acordo com a página man , não há opções que definam uma criptografia mínima:
--tls-max - define um limite máximo . (Não parece ser um argumento correspondente para --tls-min ) --tlsauthtype - suporta apenas SRP
--tlsv1.[0-3] - diz "Forçar o curl a usar [ exatamente ] o TLS versão 1. [0-3]", em vez de um mínimo de TLS1. [0-3] . (Há algumas respostas dizendo que isso especifica um mínimo, mas a página de manual do FreeBSD diz que pelo menos esse sistema define uma correspondência exata). -1, --tlsv1 - força o TLSv1 mas não se importa com qual versão . Eu usarei --anyauth para solicitar o mais strong possível, mas isso só exige melhor negociável , não um mínimo . Não quero alterar nenhum outro aspecto do sistema de configurações de criptografia, apenas as cifras que o cURL usará para essa chamada. O código pode ser usado em uma ampla gama de sistemas operacionais atuais e outros * nix.
Existe uma maneira de garantir o TLS "pelo menos v1.2" ou similar, se eu quiser definir um mínimo amplamente funcional por padrão para o usuário (que pode estar em muitos tipos e idades de sistema)?
Se não, eu poderia enviar algum tipo de dados nulos ou cabeçalho mínimo apenas como uma sonda, para testar a cifra que usaria, e verificar se isso corresponde a tls(1\.[2-9]|[2-9]\.) ou algo assim, antes de enviar qualquer "real" "dados?
Além disso, como bônus, existem opções relacionadas a certificados que normalmente seriam usadas, ou são padrão, para verificar se o certificado do URI de terceiros também é válido, por isso não pode ser redirecionado para uma falsificação IP se o cache DNS do usuário for envenenado ou um IP falsificado for recebido?