Обеспечение минимального шифрования для curl на FreeBSD и других ОС?

Я пытаюсь написать код, который устанавливает строгую защиту по умолчанию, а также относительно перспективен в отношении curl, то есть не требует обновления, если TLS 1.4, 1.5 и т. Д. Будут использоваться в будущем. Цель состоит в том, чтобы отправлять пакеты через HTTPS интернет-провайдеру пользователя, когда интернет-провайдер использует Plesk и включает только свой API XML. Так что это довольно чувствительно.

С помощью этого API учетные данные пользователя отправляются в незашифрованном виде как заголовки HTTP, что далеко от идеала, поэтому требуются довольно сильный минимальный TLS и какие-то аргументы проверки сертификата.

Проблема:

Согласно manстранице, нет никаких опций, которые устанавливают минимальное шифрование:

• --tls-max- устанавливает максимальный лимит. (Не похоже на подходящий аргумент для --tls-min)
• --tlsauthtype- поддерживает только SRP
• --tlsv1.[0-3]- говорит: «Заставляет curl использовать [ точно ] TLS версии 1. [0-3]», а не минимум TLS1. [0-3]. (Есть несколько ответов, в которых говорится, что это указывает минимум, но страница руководства FreeBSD говорит, что по крайней мере в этой системе установлено только точное совпадение).
• -1, --tlsv1- форсирует TLSv1, но не имеет значения, какая версия .

Я буду использовать --anyauthдля запроса самого сильного возможного, но это просто запросы лучше всего обсуждаемые, а не минимум . Я не хочу менять какие-либо другие системные параметры настроек шифрования, только те шифры, которые cURL будет использовать для этого вызова. Код может быть использован в самых разных операционных системах * nix.

Вопросы:

1. Есть ли способ обеспечить TLS "по крайней мере v1.2" или аналогичный, если я хочу установить широко работоспособный минимум по умолчанию для пользователя (который может быть во многих типах и возрастах системы)?
   
   Если нет, могу ли я отправлять какие-либо нулевые данные или минимальный заголовок только в качестве зонда, чтобы проверить шифр, который он будет использовать, и проверить, совпадает ли он, скажем tls(1\.[2-9]|[2-9]\.)или что-то, перед отправкой каких-либо «реальных» данных?

2. Также в качестве бонуса есть какие-либо опции, связанные с сертификатом, которые обычно используются или являются стандартными для проверки сертификата для стороннего URI, также является действительным, поэтому его нельзя перенаправить на поддельный IP, если кэш DNS пользователя отравлен или получен поддельный IP?