WolfSSL тоже отстой, и что теперь? — Makefile.feld

В прошлом году статья от Haproxy было опубликовано сообщение о том, насколько ужасно медленным стал OpenSSL. Это повторилось несколько раз, и мне захотелось почесаться, поэтому я помог FreeBSD упаковать вариант Haproxy, созданный на базе WolfSSL. Это казалось простым способом более широко познакомить людей с WolfSSL, поскольку маловероятно, что мы увидим это в большинстве дистрибутивов Linux, поэтому на самом деле единственные люди, которые используют Haproxy с поддержкой WolfSSL, – это люди, которые знают, во что они ввязываются, и сами создали его по индивидуальному заказу. На самом деле я не проверял, сделали ли подобное Arch, Gentoo, Nix и т. д., но с ними было бы проще всего создать подобное. хапрокси-волфссл упаковка.

Итак, я сделал это и запустил WolfSSL в нескольких местах, а затем обнаружил ошибку. Я сообщил об ошибке, забыл о ней и пошел дальше. А потом я ударил еще раз и почувствовал мотивацию действительно разобраться в этом. Поэтому я снова открыл ошибка и пытался отладить проблему, пока не была определена основная причина.

TLS 1.3 определен в RFC 8446. Он работает несколько иначе, чем TLS 1.2, что вызвало у них множество проблем, например, они задокументировали: «Разработка TLS 1.3 была ограничена широко распространенными несовместимыми промежуточными блоками TLS».

Ах да, пресловутые мидлбоксы. Большой. Эти невидимые куски мусора, которые могут повлиять на ваш трафик, и вы, как правило, никогда не узнаете об их существовании, пока они не причинят вам горе. И они это сделают.

Ад — это определенно место, где были изобретены промежуточные ящики, и никакие исполнения желаний не ликвидируют их существование. Хотя, возможно, некоторые ведьмы с Etsy могли бы дать совет, поскольку им невероятно везет в решении проблем…

В любом случае, у нас есть все эти промежуточные блоки, и они отстой, и мы хотим, чтобы сеть имела лучшие гарантии безопасности, чем TLS 1.2, но блоки понимают только TLS 1.2, а TLS 1.3 не может существовать, если блоки их сломают, поэтому TLS 1.3 должен иметь возможность притворяться TLS 1.2. Вот где мы находимся с этим.

Поэтому авторы хмыкнули и пробормотали по этому поводу и нашли решение: Режим совместимости промежуточного ящика.

По сути, клиенты могут дополнительно установить непустой идентификатор сеанса в ClientHello, чтобы обмануть промежуточные блоки, а клиент и сервер обмениваются фиктивными записями Change_cipher_spec. Это бесполезно и лишь увеличивает задержку при установлении сеанса TLS, но это будет работать. Справедливый.

В RFC довольно четко указано, как все это должно происходить.

Этот «режим совместимости» частично согласован: клиент может выбрать предоставление идентификатора сеанса или нет, а сервер должен повторить его.

и

если клиент отправляет непустой идентификатор сеанса, сервер ДОЛЖЕН отправить Change_cipher_spec, как описано в этом приложении.

Но WolfSSL говорит: «Спасибо, но нет, спасибо». Вся функциональность совместимости с промежуточной коробкой скрывается за компиляцией библиотеки с помощью -DWOLFSSL_TLS13_MIDDLEBOX_COMPATчто заставляет его всегда находиться в этом режиме или нет.

Таким образом, в настоящее время нельзя доверять WolfSSL в корректной работе с клиентами TLS 1.3. Все зависит от того, насколько они прощают, а это не совсем залог уверенности. Комментарий к проблеме GitHub, оставленный в конце, заставляет меня поверить, что они на самом деле не заинтересованы в соблюдении RFC. Здесь нет промежуточного варианта или «другого способа» реализации совместимости с промежуточным блоком. Это либо соответствует RFC, либо нет. И это не так.

На данный момент я выявил только одну жертву этого решения, но их наверняка будет больше. Erlang/OTP имеет собственную реализацию библиотеки SSL, и вы можете по праву предположить, что они приняли к сведению совет Джо при добавлении поддержки TLS 1.3:

Заставьте это работать, затем сделайте это красиво, а затем, если вам действительно нужно, сделайте это быстро. – Джо Армстронг

Поэтому, чтобы прикрыть свои задницы, они решили включить middlebox_comp_mode по умолчанию. (Если вам нужно быстро и вы знаете, что это безопасно — выключите его)

И теперь каждый HTTP-клиент Elixir/Erlang/etc не может подключиться к HTTPS-серверу WolfSSL, если доступен TLS 1.3.

OpenBSD, вероятно, был прав. Нам просто нужно заставить людей сосредоточиться на LibreSSL и забыть об этих других библиотеках. Как отметил Haproxy, он не стал жертвой ошибок OpenSSL 3.0, поскольку они разветвлялись ранее, но ему не хватает некоторых оптимизаций. Я думаю, что это, вероятно, справедливый компромисс, и пробелы будут заполнены в свое время.

Так что не будьте как я. Я думаю, это было высокомерие. Конечно, я думал, что могу проявить смекалку и ускорить завершение TLS для своих веб-сайтов, но все это привело меня к тому, что я потратил много времени на изучение чего-то, что мне действительно не хотелось знать, а затем написал этот глупый пост в блоге. Вас предупредили.

#!/usr/bin/env elixir

url = "https://some-wolfssl-endpoint"

url = String.to_charlist(url)

{:ok, _} = Application.ensure_all_started(:inets)
{:ok, _} = Application.ensure_all_started(:ssl)

:logger.set_application_level(:ssl, :debug)

http_options =
  [
    ssl: [
      verify: :verify_peer,
      cacerts: :public_key.cacerts_get(),
      depth: 2,
      customize_hostname_check: [
        match_fun: :public_key.pkix_verify_hostname_match_fun(:https)
      ],
      versions: [:"tlsv1.2", :"tlsv1.3"],
      middlebox_comp_mode: true
    ]
  ]

options = [body_format: :binary]

:httpc.request(:get, {url, []}, http_options, options)

11:00:44.996 [warning] Description: ~c"Failed to assert middlebox server message"
     Reason: [missing: {:change_cipher_spec, 1}]

11:00:45.014 [notice] TLS :client: In state :hello_middlebox_assert at ssl_gen_statem.erl:821 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unexpected_msg,
 {:internal,
  {:encrypted_extensions,
   %{
     elliptic_curves: {:supported_groups,
      [:secp521r1, :secp384r1, :secp256r1, :x25519, :ffdhe2048]}
   }}}}