Mindestverschlüsselung für curl unter FreeBSD und anderen Betriebssystemen sicherstellen?

373
Stilez

Ich versuche, Code zu schreiben, der die Strong-ish-Sicherheit standardmäßig einstellt und auch in Bezug auf curl relativ zukunftssicher ist. Das bedeutet, dass kein Update erforderlich ist, wenn TLS 1.4, 1.5 usw. in Zukunft verwendet werden. Der Zweck besteht darin, Pakete über HTTPS an den ISP des Benutzers zu senden, wenn der ISP Plesk verwendet und nur seine XML-API aktiviert. Es ist also ziemlich empfindlich.

Mit dieser API werden die Anmeldeinformationen des Benutzers unverschlüsselt als HTTP-Header gesendet, was alles andere als ideal ist. Daher sind ein relativ starkes minimales TLS und einige Art von Prüfüberprüfungsargumenten erforderlich.

Problem:

Der manSeite zufolge gibt es keine Optionen, die eine Mindestverschlüsselung festlegen:

  • --tls-max- setzt ein Maximallimit . (Scheint nicht ein passendes Argument zu sein --tls-min)
  • --tlsauthtype- unterstützt nur SRP
  • --tlsv1.[0-3]- sagt, es "zwingt curl [ genau ] TLS-Version 1. [0-3] zu verwenden", eher ein Minimum von TLS1. [0-3]. (Es gibt einige Antworten, die besagen, dass dies ein Minimum angibt, aber die FreeBSD-Manpage sagt zumindest auf diesem System aus, dass sie nur eine exakte Übereinstimmung festlegt).
  • -1, --tlsv1- erzwingt TLSv1, kümmert sich aber nicht um welche Version .

Ich werde es verwenden --anyauth, um die bestmögliche Nachfrage zu erreichen, aber dies ist nur die beste Verhandlungsbasis, nicht ein Minimum . Ich möchte keine anderen Systemaspekte der Verschlüsselungseinstellungen ändern, sondern nur die Verschlüsselungscodes, die cURL für diesen Aufruf verwendet. Der Code kann auf einer Vielzahl von aktuellen und anderen * nix-Betriebssystemen verwendet werden.

Fragen:

  1. Gibt es eine Möglichkeit, um sicherzustellen, dass TLS "mindestens v1.2" oder ähnliches ist, wenn ich standardmäßig ein weitgehend funktionsfähiges Minimum für den Benutzer festlegen möchte (der möglicherweise viele Systemtypen und -alter hat)?

    Wenn nicht, könnte ich eine Art Nulldaten oder einen minimalen Header nur als Probe senden, um die zu verwendende Chiffre zu testen und zu prüfen, ob das mit dem Ergebnis tls(1\.[2-9]|[2-9]\.)oder etwas übereinstimmt, bevor "echte" Daten gesendet werden?

  2. Ebenfalls als Bonus gibt es Optionen für das Zertifikat, die normalerweise verwendet werden oder standardmäßig verwendet werden, um zu prüfen, ob das Zertifikat für den Drittanbieter-URI ebenfalls gültig ist. Es kann also nicht zu einer gefälschten IP-Adresse umgeleitet werden, wenn der DNS-Cache des Benutzers verwendet wird wird vergiftet oder eine gefälschte IP empfangen?

0

0 Antworten auf die Frage