Только что появились новости о том, что Apple, Cloudflare, Fastly и Mozilla совместно работают над улучшением шифрования механизма идентификации имени сервера для HTTPS на IETF 102 Hackathon, о чем свидетельствует твит Ника Салливана из Cloudflare. В твите поздравили команду микширования из четырех технологических гигантов, сказав «Отличная работа» и поделившись ссылкой на рабочие серверы на esni.examp1e.net и cloudflare-esni.com .
Отличная работа на хакатоне IETF 102 командой зашифрованного SNI, состоящей из людей из @Cloudflare @fastly @mozilla и @яблоко . Сейчас есть реализации в BoringSSL, NSS и picotls.
Рабочие серверы находятся на https://t.co/sLI9xLRjlK и https://t.co/AoC2SIlJ7N .
- Ник Салливан (@grittygrease) 15 июля 2018 г.
IETF Hackathon - это платформа, которая приглашает молодых разработчиков и технических энтузиастов объединить свои усилия в разработке решений технических проблем, с которыми сегодня сталкиваются обычные пользователи. В мероприятиях можно участвовать бесплатно, они открыты для всех, и они поощряют командную работу, а не соревнования. В этом году хакатон IETF прошел в Монреале 14thи 15thиюля. Самым выдающимся достижением, по-видимому, является шифрование индикации имени сервера (SNI) Transport Layer Security (TLS), проблема, которая преследовала разработчиков в течение последнего десятилетия, и которую члены Apple, Cloudflare, Fastly , и Mozilla предложили решение проблемы.
Событие IETF Hackathon. IETF
За последние полтора десятилетия произошел явный глобальный переход от протокола передачи гипертекста (HTTP) к протоколу передачи гипертекста (TLS SNI HTTPS) с указанием имени сервера на транспортном уровне. В проблема Результатом оптимизации системы TLS SNI HTTPS стала способность хакера использовать SNI против своей цели, чтобы согласовать передачу данных для последующего дешифрования.
До разработки SNI было сложно установить безопасные соединения с несколькими виртуальными серверами с использованием одного и того же первого рукопожатия клиента. Когда один IP-адрес взаимодействовал с одним сервером, оба обменивались «приветами», сервер отправлял свои сертификаты, компьютер отправлял свой клиентский ключ, оба обменивались командами «ChangeCipherSpec», а затем взаимодействие завершалось, когда соединение было установлено. Это может показаться простым, как это только что было сказано, но процесс включал в себя несколько обменов и ответов, которые легко могли стать довольно проблематичными по мере увеличения числа серверов, с которыми осуществляется связь. Если все сайты использовали одни и те же сертификаты, это не представляло большой проблемы, но, к сожалению, это было редко. Когда несколько сайтов отправляли различные сертификаты туда и обратно, серверу было трудно определить, какой сертификат искал компьютер, а в сложной сети обменов стало трудно определить, кто что и когда отправил, тем самым прекращая всю деятельность с предупреждающим сообщением.
Затем в июне 2003 года на саммите IETF был представлен протокол TLS SNI, и его цель, в некотором смысле, заключалась в создании тегов имен для компьютеров и служб, участвующих в сети обмена. Это сделало процесс обмена приветствиями между сервером и клиентом намного более простым, поскольку сервер получил возможность предоставлять точные необходимые сертификаты, и оба получили возможность вести собственный диалог, не запутавшись в том, кто что сказал. Это немного похоже на то, чтобы иметь имена контактов для чатов и не запутаться в том, откуда приходят сообщения, а также иметь возможность надлежащим образом отвечать на каждый запрос, предоставляя нужные документы любому компьютеру, который в этом нуждается. Именно это определение SNI вызвало наибольшую проблему с этим методом оптимизации процесса обмена.
Борьба, с которой столкнулись многие фирмы при переходе на HTTPS, заключалась в адаптации многих сертификатов к формату SNI с индивидуальными IP-адресами для выполнения запросов для каждого сертификата. Для них TLS упростил создание сертификатов для ответа на такие запросы, а SNI еще больше устранил необходимость в индивидуальных выделенных IP-адресах сертификатов, добавив целую систему идентификации по всей сети Интернета. Что произошло с обновлением века, так это то, что оно позволило хакерам использовать установленные «контактные имена» для отслеживания и теневой передачи данных и извлечения информации, необходимой для расшифровки на более позднем этапе.
Хотя TLS позволял передавать данные туда и обратно по зашифрованному каналу, при этом SNI гарантировал, что они достигают правильного места назначения, последний также предоставлял хакерам средства для отслеживания онлайн-активности и сопоставления ее с ее источником, следуя запросам DNS, IP-адресам. , и потоки данных. Хотя более строгие политики кодирования SNI были реализованы путем передачи информации DNS через канал TLS, у хакеров остается небольшое окно, чтобы использовать это в качестве средства идентификации для отслеживания части информации, которую они хотели бы извлечь и изолировать. расшифровка. Сложные серверы, которые имеют дело с большим трафиком зашифрованных данных TLS, используют простой текстовый SNI для отправки сообщений на своих серверах, и это то, что упрощает хакерам определение каналов и потоков информации, по которым они хотят отслеживать. Как только хакер может извлечь информацию SNI интересующих данных, он / она может настроить искусственное воспроизведение команды в отдельном TLS-соединении с сервером, отправив украденную информацию SNI и получив информацию, которая был связан с этим. В прошлом было несколько попыток решить эту проблему SNI, но большинство из них противоречили принципу простоты, по которому SNI работает, чтобы сделать его удобным методом идентификации для серверов.
Возвращаясь к саммиту, на котором впервые был разработан этот метод, участники из четырех технологических гигантов вернулись на конференцию в Монреале, чтобы разработать шифрование для TLS SNI, потому что, несмотря на большую эффективность в смежной системе с несколькими HTTPS, безопасность по-прежнему остается проблемой. так же, как и раньше.
Чтобы скрыть SNI в TLS, «Скрытая служба» должна находиться под демонстрацией «Фронтинг-службы», которую может увидеть хакер. Не имея возможности напрямую наблюдать за скрытой службой, хакер будет введен в заблуждение из-за внешней маскировки, под которой он скрывается в виде обычного текста, не имея возможности идентифицировать основные параметры секретной службы, используемые для передачи зашифрованных данных. По мере того как наблюдатель следует по следу фронтальной службы, данные будут удалены из наблюдаемого канала, поскольку они перенаправляются на предполагаемую скрытую службу, после чего хакер потеряет свой след. Поскольку сервер также будет доступен для фронтальной службы, по мере того, как данные попадают туда, второй параллельный сигнал SNI будет отправлен во фронтальную службу для перенаправления данных в скрытую службу, и в этом процессе изменения направления хакер будет затеряться в сети сервера. Этот механизм двойных билетов далее развивается в комбинированный билет под тем же SNI. Когда один фрагмент данных отправляется на сервер, данные создают взаимодействующий перенаправитель SNI, и оба работают вместе, чтобы доставить зашифрованные данные TLS туда, где они должны быть. Не имея возможности взломать службу рандомизированного фронтинга, которая охватывает оба трека SNI, хакер не сможет проследить за данными, но сервер все равно сможет соединить эти два и расшифровать скрытую службу как конечное местоположение данных. Это позволяет серверам продолжать использовать SNI для оптимизации передачи данных в шифровании TLS, гарантируя, что хакеры не смогут воспользоваться преимуществами механизма SNI.
