Комментарии 27
Добрый день, данная тема хорошо раскрыта у CloudFlare здесь. В двух словах — имя ресурса к которому мы запрашиваем доступ не передается в открытом виде в течение всей сессии. Что это дает и почему это важно:
1. Провайдер не знает на какие сайты мы ходим
2. Системы блокировки веб сайтов (которые фильтруют сайты по именам) не могут распознать имя сайта.
Все что известно о сессии это то что произошло соединение с определенным IP адресом. Какой конкретно ресурс мы запрашиваем — неизвестно. В этом основная суть. Готов прокомментировать подробнее.
1. Провайдер не знает на какие сайты мы ходим
2. Системы блокировки веб сайтов (которые фильтруют сайты по именам) не могут распознать имя сайта.
Все что известно о сессии это то что произошло соединение с определенным IP адресом. Какой конкретно ресурс мы запрашиваем — неизвестно. В этом основная суть. Готов прокомментировать подробнее.
Системы блокировки веб сайтов (которые фильтруют сайты по именам) не могут распознать имя сайта и блокируют целиком IP…
Да, так и есть, поэтому это конечно не панацея и не единственный вариант (известны случаи массовой блокировки IP адресов облачных провайдеров, ну и что дальше было — тоже известно). Кстати далеко не все блокировщики работают по такому принципу.
Прежде всего здесь конфиденциальность — перехваченный трафик не содержит информации в открытом виде. Каждый для себя решает сам, на сколько ему это важно.
Прежде всего здесь конфиденциальность — перехваченный трафик не содержит информации в открытом виде. Каждый для себя решает сам, на сколько ему это важно.
далеко не все блокировщики работают по такому принципу
Через некоторое время, похоже, останется один «блокировщик» от RDP, гордо именуемый в официальных документах «ТСПУ» — «технические средства противодействия угрозам», который будет управляться НЕ оператором, и как оно будет работать можно только гадать.
конфиденциальностьДополню…
Не следует считать, что включив у себя поддержку еSNI при перехвате трафика невозможно будет определить посещённый ресурс, размещённый у облачного провайдера.
Промежуточный узел видит IP и может сделать reverse DNS lookup, если владелец ресурса указал PTR запись. Актуально как минимум относительно почтовых сервисов.
Провайдер не знает на какие сайты мы ходим
А что тут такого? Кроме доменного имени там ничего нет, url все равно зашифрован.
Например, узнают, что Вы ходите на сайт криптобиржи и потом уже приедут братки с паяльником узнавать доступы к кошельку. Утрировано, но взято не с потолка.
Если Вы думаете, что нечего скрывать, ведь Вы честный и ни к чему нельзя придраться, то просто попробуйте открыть данные хуиз домена Вашего пет-проекта, включая реальный телефон и поймёте почему данные закрывают.
Если Вы думаете, что нечего скрывать, ведь Вы честный и ни к чему нельзя придраться, то просто попробуйте открыть данные хуиз домена Вашего пет-проекта, включая реальный телефон и поймёте почему данные закрывают.
Тема и здесь раскрыта хорошо, спасибо за статью.
Спасибо за статью, было интересно, но хотелось бы больше узнать о том насколько ЕСНИ делает безопасным сёрфинг для конечного пользователя и какой профит для веб-сайта это даёт. А то в статье ни слова.
Примечательно, что с TLS на RPS очень сильно влияет тип сертификата.
Я недавно тесты проводил и обнаружил, что замена RSA-сертификата на ECDSA может позволить поднять скорость обработки запросов на 40-50%. Ожидаемо, но этим часто пренебрегают. И получать ECDSA от LE пока «менее просто», чем RSA.
Я недавно тесты проводил и обнаружил, что замена RSA-сертификата на ECDSA может позволить поднять скорость обработки запросов на 40-50%. Ожидаемо, но этим часто пренебрегают. И получать ECDSA от LE пока «менее просто», чем RSA.
Удалил
А вы сами-то его где-то используете уже? Хотелось бы посмотреть на это вживую, а в статье только скриншоты и ни исходников, ни демо-сервера.
Большинство сайтов на Cloudflare и он сам.
У них своё решение используется, в статье своё, я спрашивал про конкретную реализацию.
В статье сообщалось, что бы были использованы инструменты Cloudflare, но да, без уточнений/деталей.
Не помешал бы, к примеру, файл Docker Compose.
Не помешал бы, к примеру, файл Docker Compose.
Давайте уточню. У CloudFlare мы взяли реализацию ESNI поверх TLS 1.3, почему именно у них — потому что это единственная реализацию которую поддерживает FireFox (хардкод конкретных cipher-suite и прочая специфика). Собственно на базе их реализации мы собрали небольшой прокси — ESNI reverse proxy. Исходники тут, с подробной инструкцией как собрать и запустить. Докер образ конечно тоже имеется но он не опубликован на docker hub. Если поможет, могу также поделится докер файлом для сборки ESNI reverse proxy.
У CloudFlare есть что-то подобное, но свою реализацию они не выложили в открытый доступ, поэтому мы реализовали свою версию.
У CloudFlare есть что-то подобное, но свою реализацию они не выложили в открытый доступ, поэтому мы реализовали свою версию.
Уточню, мы используем это решение абсолютно независимо от СloudFlare. В качестве клиента — FireFox.
Фактически, ответа на вопрос из заголовка в статье не содержится.
Посмотрите вот этот комментарий. Ответил на вопрос?
Да, вполне, благодарю Вас! А можно ли вживую посмотреть на какой-либо сервер (не важно, тестовый или нет), на котором это работает?
К сожалению не могу раскрывать информацию о том, на каких ресурсах мы используем ESNI (могу сказать что используем на продакшене).
Если Вам нужно протестировать саму технологию, то я думаю вполне подойдет тот же сайт www.cloudflar.com. Как я писал в статье, сайты CloudFlare используют ESNI. Т.е. настроив FireFox, Вы можете открыть данный сайт и, например, проверить (с помощью WireShark) как выглядит «Client Hello».
Если Вам нужно протестировать собственный сайт, то используйте ESNI proxy. В репозитории, на который ссылка выше, подробная инструкция про генерацию ESNI ключей и добавление записей в DNS. Т.е. к примеру, если у Вас уже есть некий сайт, то нужно добавить только DNS TXT запись вида "_esni.FQDN" с публичным ESNI ключом, и запустить прокси «перед» сайтом. Если нужны подробные комментарии могу пояснить как конкретно это сделать, например в AWS.
Если Вам нужно протестировать саму технологию, то я думаю вполне подойдет тот же сайт www.cloudflar.com. Как я писал в статье, сайты CloudFlare используют ESNI. Т.е. настроив FireFox, Вы можете открыть данный сайт и, например, проверить (с помощью WireShark) как выглядит «Client Hello».
Если Вам нужно протестировать собственный сайт, то используйте ESNI proxy. В репозитории, на который ссылка выше, подробная инструкция про генерацию ESNI ключей и добавление записей в DNS. Т.е. к примеру, если у Вас уже есть некий сайт, то нужно добавить только DNS TXT запись вида "_esni.FQDN" с публичным ESNI ключом, и запустить прокси «перед» сайтом. Если нужны подробные комментарии могу пояснить как конкретно это сделать, например в AWS.
Здравствуйте! ESNI поддерживается на тестовом сервере TLS 1.3 вот здесь: tls13.1d.pw
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как защитить свой публичный сайт с ESNI