Suicide
11.01.2021, 08:38
Компания Mozilla объявила (https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/) о добавлении в выпуск Firefox 85, намеченный на 26 января, поддержки механизма ECH (Encrypted Client Hello) для шифрования информации о параметрах TLS-сеансов, таких как запрошенное доменное имя. Для включения ECH в about:config следует активировать настройки "network.dns.echconfig.enabled" и "network.dns.use_https_rr_as_altsvc". Поддержка тестируемого на протяжении последних двух лет механизма ESNI (Encrypted Server Name Indication) в Firefox 85 будет прекращена, но какое-то время сохранится в ESR-выпусках Firefox.
Спецификация ECH продолжает развитие ESNI и находится на стадии черновика (https://tools.ietf.org/html/draft-ietf-tls-esni-09), претендующего на роль стандарта IETF. Для организации работы на одном IP-адресе нескольких HTTPS-сайтов в своё время было разработано TLS-расширение SNI, осуществляющее передачу имени хоста в открытом виде в сообщении ClientHello, передаваемом до установки шифрованного канала связи. Подобная особенность даёт возможность на стороне интернет-провайдера выборочно фильтровать HTTPS-трафик и анализировать какие сайты открывает пользователь, что не позволяет добиться полной конфиденциальности при применении HTTPS.
Для исключения утечки сведений о запрашиваемом сайте несколько лет назад было разработано расширение ESNI, реализующее шифрование данных с именем домена (кроме SNI источником утечки сведений также может быть DNS, поэтому кроме ESNI необходимо применение технологии DNS over HTTPS или DNS over TLS). В процессе попыток внедрения ESNI было выявлено, что предложенного механизма недостаточно для обеспечения полной конфиденциальности HTTPS-сеансов. В частности, при возобновлении ранее установленного сеанса имя домена в открытом виде фигурирует в числе параметров TLS-расширения PSK (Pre-Shared Key), т.е. одного шифрования полей SNI оказалось недостаточно и требовалось создания аналога ESNI для PSK, а в будущем, возможно, и для других полей. Кроме того, попытки внедрения ESNI выявили проблемы с совместимостью и масштабированием, которые мешали повсеместному распространению ESNI.
В ответ на потребность в шифровании параметров любых TLS-расширений был предложен универсальный механизм ECH, главное отличие которого от ESNI в том, что вместо отдельного поля шифруется всё сообщение ClientHello. ECH подразумевает (https://blog.cloudflare.com/encrypted-client-hello/) наличие двух типов сообщений ClientHello - шифрованное сообщение ClientHelloInner и незашифрованное базовое сообщение ClientHelloOuter. Если сервер поддерживает ECH и смог расшифровать ClientHelloInner, то он продолжает использовать данный тип для TLS-сеанса. В противном случае берутся данных из ClientHelloOuter.
ECH также использует иную схему распространения ключа для шифрования - информация об открытом ключе передаётся в DNS записи HTTPSSVC (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-httpssvc/), а не в записи с типом TXT. Для получения и шифрования ключа применяется аутентифицированное сквозное шифрование на основе механизма HPKE (https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/) (Hybrid Public Key Encryption). ECH также поддерживает безопасную повторную передачу ключа с сервера, что может применяться в случае ротации ключей на сервере и для решения проблем при получении устаревших ключей из кэша DNS.
Дополнительно можно отметить решение (https://www.soeren-hentzschel.at/firefox/bildformat-avif-firefox-86/) включить (https://bugzilla.mozilla.org/show_bug.cgi?id=1682995) по умолчанию в Firefox 86 поддержку формата изображений AVIF (https://aomediacodec.github.io/av1-avif/) (AV1 Image Format), в котором задействованы технологии внутрикадрового сжатия из формата кодирования видео AV1. Контейнер для распространения сжатых данных в AVIF полностью аналогичен HEIF. AVIF поддерживает как изображения в HDR (High Dynamic Range) и цветовом пространстве Wide-gamut, так и в стандартном динамическом диапазоне (SDR). Ранее для включения AVIF требовалась установка параметра "image.avif.enabled" в about:config.
09.01.2021
https://www.opennet.ru/opennews/art.shtml?num=54384
Спецификация ECH продолжает развитие ESNI и находится на стадии черновика (https://tools.ietf.org/html/draft-ietf-tls-esni-09), претендующего на роль стандарта IETF. Для организации работы на одном IP-адресе нескольких HTTPS-сайтов в своё время было разработано TLS-расширение SNI, осуществляющее передачу имени хоста в открытом виде в сообщении ClientHello, передаваемом до установки шифрованного канала связи. Подобная особенность даёт возможность на стороне интернет-провайдера выборочно фильтровать HTTPS-трафик и анализировать какие сайты открывает пользователь, что не позволяет добиться полной конфиденциальности при применении HTTPS.
Для исключения утечки сведений о запрашиваемом сайте несколько лет назад было разработано расширение ESNI, реализующее шифрование данных с именем домена (кроме SNI источником утечки сведений также может быть DNS, поэтому кроме ESNI необходимо применение технологии DNS over HTTPS или DNS over TLS). В процессе попыток внедрения ESNI было выявлено, что предложенного механизма недостаточно для обеспечения полной конфиденциальности HTTPS-сеансов. В частности, при возобновлении ранее установленного сеанса имя домена в открытом виде фигурирует в числе параметров TLS-расширения PSK (Pre-Shared Key), т.е. одного шифрования полей SNI оказалось недостаточно и требовалось создания аналога ESNI для PSK, а в будущем, возможно, и для других полей. Кроме того, попытки внедрения ESNI выявили проблемы с совместимостью и масштабированием, которые мешали повсеместному распространению ESNI.
В ответ на потребность в шифровании параметров любых TLS-расширений был предложен универсальный механизм ECH, главное отличие которого от ESNI в том, что вместо отдельного поля шифруется всё сообщение ClientHello. ECH подразумевает (https://blog.cloudflare.com/encrypted-client-hello/) наличие двух типов сообщений ClientHello - шифрованное сообщение ClientHelloInner и незашифрованное базовое сообщение ClientHelloOuter. Если сервер поддерживает ECH и смог расшифровать ClientHelloInner, то он продолжает использовать данный тип для TLS-сеанса. В противном случае берутся данных из ClientHelloOuter.
ECH также использует иную схему распространения ключа для шифрования - информация об открытом ключе передаётся в DNS записи HTTPSSVC (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-httpssvc/), а не в записи с типом TXT. Для получения и шифрования ключа применяется аутентифицированное сквозное шифрование на основе механизма HPKE (https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/) (Hybrid Public Key Encryption). ECH также поддерживает безопасную повторную передачу ключа с сервера, что может применяться в случае ротации ключей на сервере и для решения проблем при получении устаревших ключей из кэша DNS.
Дополнительно можно отметить решение (https://www.soeren-hentzschel.at/firefox/bildformat-avif-firefox-86/) включить (https://bugzilla.mozilla.org/show_bug.cgi?id=1682995) по умолчанию в Firefox 86 поддержку формата изображений AVIF (https://aomediacodec.github.io/av1-avif/) (AV1 Image Format), в котором задействованы технологии внутрикадрового сжатия из формата кодирования видео AV1. Контейнер для распространения сжатых данных в AVIF полностью аналогичен HEIF. AVIF поддерживает как изображения в HDR (High Dynamic Range) и цветовом пространстве Wide-gamut, так и в стандартном динамическом диапазоне (SDR). Ранее для включения AVIF требовалась установка параметра "image.avif.enabled" в about:config.
09.01.2021
https://www.opennet.ru/opennews/art.shtml?num=54384