erlang_quic — это чистая реализация Erlang QUIC. До версии 1.4.4 клиент QUIC не аутентифицировал сервер во время установления связи TLS 1.3. Подпись CertificateVerify не проверялась, цепочка сертификатов не проверялась, а имя хоста не сравнивалось с сертификатом, поэтому проверка фактически не выполнялась на клиенте.
Посредник на сетевом пути может предъявить любой сертификат и выдать себя за любой сервер, нарушая конфиденциальность и целостность соединения. HTTP/3 использует тот же клиент и пострадал в равной степени. Рукопожатия, аутентифицированные с помощью PSK (возобновление сеанса), не затрагиваются, поскольку одноранговый узел аутентифицируется связующим устройством PSK и сертификат не отправляется.
Это исправлено в версии 1.4.4. Теперь клиент проверяет подпись CertificateVerify, проверяет цепочку сертификатов на соответствие хранилищу доверенных сертификатов (опция cacerts, хранилище операционной системы по умолчанию) и проверяет имя хоста. Клиентская проверка теперь включена по умолчанию; установите `verify => false`, чтобы принять любой сертификат (например, самозаверяющий тестовый сервер).
Никаких известных обходных путей до версии 1.4.4 не существует. `verify => true` не дало никакого эффекта, и проверка сертификата после подключения не помогает, потому что без проверки подписи никогда не доказывается, что партнер владеет сертификатом, который он представляет.
Показать оригинальное описание (EN)
erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.
Характеристики атаки
Последствия
Строка CVSS v3.1