Snc client encryption что это за программа

Snc client encryption что это за программа

Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.

What can I do to prevent this in the future?

If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.

If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Another way to prevent getting this page in the future is to use Privacy Pass. You may need to download version 2.0 now from the Chrome Web Store.

Cloudflare Ray ID: 71aa34b0286f9ba4 • Your IP : 82.102.23.104 • Performance & security by Cloudflare

Проект по внедрению Single Sign On в SAP

Для меня этот год запомнился проектом внедрения Single Sign On (SSO) между SAP и Windows. В этой статье расскажу об опыте внедрения и проектного менеджмента, подводных камнях, находках и выводах.

Компания — крупное транспортное предприятие в Бельгии, объединяющее метро, трамвай и автобус. Сотрудников более 10 тысяч, из них почти две тысячи это backoffice, использующий много инструментов: корпоративный сайт, почту, службу заявок, sharepoint, архивариус и, конечно, SAP.

SAP повсюду: от бухгалтерии и HR до регистрации движения транспортных единиц, документации аварий, аналитики, закупок, складирования и т.д.

Проблема:

• SAP для пользователя PC — это отдельное приложение, для входа в которое нужен свой пароль
• Сначала пароль нужно запросить, а потом помнить. Техподдержка вынуждена принимать звонки по созданию и смене паролей.
• С точки зрения пользователя лишний пароль — это лишние хлопоты. Люди хранят пароли на бумажках или делают их слишком простыми. Безопасность вопит о грубых нарушениях.
• Минимальные требования для пароля от PC не совпадают с параметрами паролей в SAP. Если приводить их к единому знаменателю, то лучше сразу внедрить SSO.

Задача: внедрить SSO между Windows и SAP, чтобы, заходя в свою учётную запись на PC, пользователь мог залогиниться в SAP не вводя пароль.

Если вы не имеете дела с SAP вам будет интересна эта статья с точки зрения менеджмента проекта, для сапёров тех детали будут приведены (в скобках).

1. Scope
   1.1 Scope Люди
   1.2 Scope системы
2. Компоненты
   2.1 Изменение параметров системы
   2.2 Windows Active Directory (AD)
   2.3 SAP Secure Login Client (SLC)
   2.4 Привязка пользователя SAP к его AD
   2.5 Модификация файла SAP logon.ini
3. Тестирование
4. SNC это дыра в безопасности
5. Командная работа
6. Информация для бизнеса
7. Трудности перевода
8. Итоги и выводы

Введение

Забегая вперёд, если вы не горите желанием набивать стандартные шишки, вот список вопросов, которые вы должны прояснить для себя в самом начале проекта:

• Scope проекта (Системы, пользователи – в каком порядке внедряем, где приоритет и что можно отбросить если что-то пойдёт не так, какие пользователи должны получить доступ и т.д.)
• Основные отделы, затронутые проектом (Даже если проект по ним проходит «по касательной», всё равно важно, чтобы все были в курсе заранее)
• Ваши полномочия (Здесь не сильно можно разбежаться – в европейской компании всё строится на согласии и добровольном желании помочь. Если отдел скажет, что у них нет ресурсов, то надавить и «заставить» практически невозможно. Но можно позвать стороннего консультанта для помощи, например)
• Сроки (Для всего проекта в целом и для конкретных частей)
• Процедуры согласования (Бюрократические регламенты — в большой компании это далеко не последний вопрос)
• Возможные сложности (Все. Возможные. Сложности.)

У нас состав участников проекта менялся несколько раз: сначала это был только отдел авторизации в SAP и отдел администраторов (Basic Components). Затем к ним присоединились отдел занимающийся авторизацией в Windows (Active Directory, AD) и отдел внедрения обновлений (Packaging), затем отдел баз данных и отдел мобильных приложений, и т.д.

Для технической стороны дела был приглашён внешний консультант, а Project Manager (ПМ) стала я, как человек занимающийся авторизациями в SAP (поэтому деталей по авторизациям в SAP в этой статье будет больше, чем других).

Важное уточнение: весь доступ, который мы даём в SAP, кастомизирован. Мы не пользуемся стандартными ролями, которые предлагает система, а создаём новые, под отдел, под позиции, под функции. На сегодняшний день у нас нет синхронизации между пользователями SAP и Windows AD. Например, если у вас пользователь обладает правами администратора в локальной сети, то это не значит, что он также администратор в SAP.

1. Scope

1.1 Scope Люди

Люди в нашей компании пользуются SAPом через приложение на личном компьютере (тонкий клиент — SAP Logon GUI), но не только. Как считать пользователей, попадающих под раздачу?

Мы взяли за основу всех, кто ежедневно подключается через SAP Logon (SAP user type Dialogue) с ноутбуков. В этой категории весь backoffice — сотрудники администрации, бухи, ичары, разработчики, тестировщики, логистика и т.д.

• тех, у кого стационарный компьютер, а не ноут
• 8 тысяч пользователей, которые никогда не открывают SAP logon, а пользуются SAPом через сайт и приложения (SAP user type Communication)
• всех внешних пользователей (не сотрудники, но должны логиниться в системе через VPN)

1.2 Scope Systems

В нашей компании в SAPе используются шесть активных landscapes (ECC, BI, SRM, Netweaver, PI, Solution manager), не считая песочниц. У каждой из них свои DEV, ACC, PRD — т.е. фактически это 6*3 = 18 систем.

Гласным голосованием было решено взять только первые четыре landscapes. PI и SM используются узким кругом администраторов и требуют обновления самой системы (по крайней мере обновления SAP_BASIS component до версии 740). Иначе транзакция sncwizard не поддерживается, а вручную это делать слишком хлопотно ради 10-20 человек.

2. Компоненты

Люди, интересующиеся тех деталями, найдут на сайте SAP пошаговую инструкцию, так же как и различные доступные способы (мы выбрали SSO based on Kerberos, но это не всегда очевидный вариант).

С очень упрощенной точки зрения (моей), SSO это надстройка в SAP, позволяющая вам заходить в систему, используя свою учётную запись Windows. Вы включаете компьютер, вводите пароль, и для того чтобы зайти в SAP вам достаточно двойного клика.

Чтобы магия сработала нужно 5 составляющих:

2.1 Изменение параметров системы (instances SAP)

В системе SAP (ECC, BI, SRM, Netweaver) нужно активировать параметр snc/enable =1. Это делается через sncwizard и включает подготовку, перезагрузку системы и окончательные шаги активации.

С параметрами до и после мы разобрались силами тех консультанта, помощи со стороны других отделов и методом проб и ошибок. Самое сложное здесь был рестарт системы.

На производстве всегда сложно перезапускать PRD, работа идёт круглосуточно. А в транспортной компании это вдвойне сложнее: транспорт двигается с пяти утра и до часу ночи, даже по выходным. Любые сложности с PRD влияют не только на сотрудников компании, но на весь город и десятки тысяч людей. Другими словами — нужно минимизировать время, когда система недоступна и по возможности совместить с другими обновлениями. При этом нельзя недооценивать бюрократию: рестарт это заранее согласованные по регламенту даты, время, продолжительность (если с первого раза параметры не сохранятся) и уведомление бизнеса.

У нас было четыре системы SAP PRD: ECC, Netweaver, SRM, BI – для перезагрузки

ECC — самая важная, на неё завязаны все данные реального времени и основной транспорт: автобусы, трамваи.

Данные системы Netweaver (аварии, мобильные приложения), как и системы ECC используются даже в 3 часа ночи — если трамваи не ходят, то ходят ремонтные бригады.

Система SRM — в основном используется для закупок и была доступна в любой день после 18:00.

С BI сложность в том, что на выходных в систему идут потоки загрузки данных из ECC, кроме того, иногда отчёты из BI, используются высшим менеджментом вне рабочих часов.

В совокупности на перезагрузки всех PRD ушло 2 недели.
P.S. Рестарту каждой из систем PRD предшествовали рестарты всех DEV и ACC, которые проще в согласовании, но также требуют планирования.

2.2 Windows Active Directory (AD)

В Active Directory требуется создание специального технического пользователя (SAP Kerberos). Этот пользователь будет связываться с Windows чтобы получить копию входного «тикета» для SAP. Достаточно одного такого сервисного пользователя AD для всех систем SAP.

Эта часть была целиком сделана нашим внешним консультантом и командой Active Directory, включала в себя несколько итераций по уточнению параметров и настройке спец.библиотеки, но для меня в большей степени осталась «чёрным ящиком».

2.3 Установка на компьютер пользователя программы SAP Secure Login Client (SLC)

Эта программа сама по себе ничего не делает. Она нужна, чтобы хранить тикет от AD, подтверждающий вашего пользователя при входе в сессию Windows, и при необходимости предоставлять этот тикет в SAP для авторизации. SLC можно установить всем пользователям сразу в начале проекта — без остальных компонентов SSO она всё равно работать не будет.

2.4 Привязка пользователя SAP к его пользователю AD

Как уже было сказано, в нашей компании нет единого управления пользователями, доступ в разных системах получают от разных команд. При этом login пользователя в SAP отличается от имени пользователя в Windows, например пользователь #45011 в AD это Иван Иванов или ИВАНОВИ. Именно эту связку и надо заполнить в SNC (через транзакцию SU01, поле SNC, p:CN=ADname@domain).

В нашей компании нет SAP Identity Management. Поэтому надо было решить две задачи: создание новых пользователей и обновление параметров существующих.

Создание новых пользователей
В основной системе (ECC) каждый рабочий день создаётся 4-6 новых логина, это за год почти 1000 новых пользователей. Процесс автоматизирован: при создании пользователя программа заполняет его адрес, имя, базовые настройки. Мы решили, что программа также должна заполнять поле SNC на этапе создания пользователя, независимо от того, потребуется ли человеку SSO в SAP впоследствии или нет.

Загвоздка была в том, что для каждого пользователя надо заполнить уникальное собственное имя в AD, т.е. это не одинаковый для всех параметр — т.е. надо чтобы программа сама искала имя пользователя в AD и заполняла его в SAP.

Разработчик быстро обновил программу. На код и базовое тестирование ушло 2 дня, но данные для проверки в ACC нам не подходили (AD не обновлялась), поэтому мы сразу отправили изменения в PRD. Там выяснилось что всё сложнее, чем мы думали. В процессе расследования пришли вот к такой схеме:

1. Сначала пользователи создаются в HR системе (в SAPе их можно увидеть в PA20)
2. Потом они копируются в Z-таблицу, вместе с данными про отдел, должность, позицию, является ли руководящим звеном и т.д.
3. Затем данные по пользователям отсылаются в AD и здесь система создаёт пользователя в Windows, и даёт ему имя в AD и почту
4. Поток PI в этой схеме просто чтобы понимать, что это сторонний процесс третьей системы
5. Данные копируются обратно в SAP (в новую Z-таблицу), на этот раз просто имена AD и почтовые адреса
6. На последнем этапе запускается Z-программа, которая создаёт пользователей в SAP (SU01). Не все пользователи, кто создан в HR системе будут созданы последствии в SAP, есть немало таких, кто в итоге ни в каком виде не пользуется SAPом

Почти две недели ушло на поиск, согласование изменений, согласование графика обновления и загрузки-выгрузки таблиц. Дело было в синхронизации — программа по созданию пользователей (пункт 6) должна строго запускаться после того, как все другие программы уже отработали и данные скопированы в таблицы. В итоге две недели мы отслеживали, когда какая программа завершилась и в какое время, и отлаживали схему.

Когда пользователи создаются с заполненным полем SNC, но без нужных AD имён, в SU01 можно увидеть всех юзеров-соратников по несчастью, привязанных к одному, несуществующему пользователю AD.

Обновление параметров существующих пользователей
Именно потому что у нас login SAP и Windows не совпадают, мы не смогли воспользоваться стандартным решением от SAP для массового заполнения поля SNC (программа RSUSR300 via SNC1).

В итоге данные 10 тысяч существующих пользователей я обновляла с помощью самодельного скрипта (SAP eCATT), выгрузив данные по пользователям вручную и создав variant. Для успеха пришлось открыть для изменений и eCATT системы в PRD и ACC и пообещать разработчикам миллионы печенек.

2.5 Модификация файла SAP logon.ini

Технически это дело 1 минуты. Надо лишь отметить в свойствах файла, что доступно подключение через SNC.

Сложность в том, что этот файлик находится локально на PC пользователя и надо поменять его у двух тысяч пользователей.

Фактически для нас финальное внедрение было моментом распределения нового файла sap.logon.ini среди пользователей, а не изменение параметров PRD. Потому что даже если первые четыре составляющие уже сделаны, а последняя пятая нет, то магия не случится.

С последним пунктом вышел небольшой казус. Я отчиталась перед руководством, что у нас 2000 пользователей, у кого будет установлено обновление, а когда пришло время внедрять, мне прислали статус, где их было 3500. Стало не по себе. Всё потому, что я со своей стороны видела только активных пользователей SAP, а в действительности обновление было отправлено на все персональные ноутбуки, которых в компании гораздо больше. Слава богу никаких багов с технической стороны не возникло.

3. Тестирование

Как тестировать SSO? Либо он работает, либо нет. Наш разработчик фыркал и говорил, что тестировать ничего не нужно, и как только всё заработает в «песочнице», нужно отсылать в продакшн. Конечно. Nobody will say he writes code with bugs.

• работает ли вход в SAP с SSO сразу после перезагрузки
• могут ли пользователи пользоваться SSO когда подключены с VPN
• сложности для разработчиков для других систем, для модификации SAP logon

SSO это не программа, её сложно внедрять последовательно DEV — ACC — PRD. Но тем не менее первичное тестирование необходимо, чтобы уловить всё, что потенциально может пойти не так. Тестирование в данном случае это распределение нового SAP logon.ini, когда все компоненты уже запущены. Мы тестировали DEV и ACC с разработчиками и новый SAP logon.ini c PRD c выборкой бизнес пользователей.

• иногда (1 случай на 500) надо полностью переустановить SAP logon или SLC
• key users, у которых есть права менять других пользователей (об этом в след пункте)

4. SNC это дыра в безопасности

Как быть с модификацией поля SNC?
Дело в том, что изменив поле SNC у другого пользователя (в SU01) на своё, вы можете подключиться под чужим аккаунтом, даже не меняя пароля. Система вас просто спросит какого пользователя выбрать, вашего или чужого. При этом, если вы это сделаете, завтра никто ничего не заметит, потому что пароль остался неизменным.

В любой компании есть люди, которые занимаются user management. Обычно эти люди следят за созданием пользователей (SU01) и доступа для них (PFCG), а также обновлением паролей. Совершенно логично, что они также могут заполнять поле SNC.

Проблема возникает, когда в компании надо разделять user management и просто key users. Администраторы создают пользователей, а key users при необходимости меняют их данные: параметры пользователя, его язык, его место локации и т.д.

В SAP для измененеия поля SNC нет отдельного этапа контроля. Все у кого есть права для изменения юзера (объект S_USER_GRP, ACTVT 02) также могут менять поле SNC (тогда как для изменения пароля требуется тот же объект, но c ACTVT 05).

Решений может быть несколько:

• забрать права доступа к SU01 у ключевых пользователей, а в ответ всем дать SU2 и SU3, где пользователь может поменять собственные параметры
• забрать права доступа к SU01, а в обмен дать z-транзакцию, где вкладка SNC показана не будет
• оставить SU01, но защитить поле SNC специальным контролем

Мы в итоге выбрали последний вариант, сделав custom authorisation object и завязав программу SU01 на него. Правда, как выяснилось потом, у SAP есть похожее решение — можно активировать extended maintenance (note 1882254) для отдельных полей SU01.

5. Командная работа

За время проекта я столкнулась со всеми сложностями командной работы и открыла для себя много базовых истин:

• Времени много не бывает. Запас времени — это лучшее, что может предусмотреть ПМ.
• Должен быть базовый план проекта, но пересматривать его нужно каждую неделю, оставляя большой запас для гибкости. Где-то мы двигались быстрее, где-то топтались на месте.
• Взрослые дяди в ИТ отделе иногда по поведению не отличаются от девчонок в бухгалтерии: отказываются работать с друг с другом, просто потому что человек им не нравится. И требуется лишний раз урегулировать вопросы субординации.
• Часто отделы тормозят согласование проекта, потому что не понятно на чьей ответственности лежит внедрение и на чей бюджет ложатся дополнительные часы работы. Важно дать менеджерам всё обговорить напрямую.
• То и дело возникают непредвиденные ситуации. Лучшее, что может быть, это своевременная коммуникация, письмо, звонок, смс всем задействованным людям.
• Нет ничего лучше, чем личная встреча. Вопросы решаются в разы быстрее, чем при обсуждении по почте. С другой стороны все личные договоренности должны тут же сопровождаться последующим письмом (чтобы закрепить и не забыть)
• ПМ в ИТ проекте может только доверять людям. На деле вы понятия не имеете сколько реально по времени будет занимать то или иное действие: например, создание пользователя в AD для Kerberos,10 минут или три дня? И нет никакой возможности проверить реально ли стопорилось тестирование или кто-то валял дурака. Остаётся только доверять.

Кроме всего от настойчивости консультанта зависит многое. Кто-то один, или консультант-разработчик или ПМ должен быть как пуля дерзким и пробивать стены бюрократии. В данном случае мне отчасти повезло, наш приглашённый консультант был назойливым и порой невыносимым (сложно было заставить его что-то услышать), но своё дело знал: о любых проблемах и остановках сообщал немедленно и не успокаивался пока проблема не разрешалась.

6. Информация для бизнеса

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

В нашем случае надо было проинформировать всех пользователей, что теперь им не нужен пароль для входа в SAP. Также, надо было предоставить техдокументацию для 1ой линии поддержки со всеми возможными ошибками, которые могут возникнуть после внедрения.

Надо признаться, что с коммуникацией всё что могло, пошло не так.

Во-первых, мы объявили пользователям об SSO на корпоративном сайте, а не письмом. Как часто вы читаете корпоративный сайт? Многие просто ничего не заметили до тех пор пока их SAP внезапно не перестал запрашивать пароль.

Во-вторых, девушка, ответственная за размещение инфы, заболела, перепоручила, не проверила, мне сказали подождать неделю, я отказалась (в конце концов из-за оповещения задерживать проект?) и мой текст оказался на сайте без вычитки, с кучей очепяток.

В-третьих, техподдержка написала мне в день Go Live, что они не поддерживают изменения, если документация им пришла меньше чем за неделю (я отправила документацию за 2 дня), и что в случае звонков мы будем выкручиваться сами. Хорошо что технических ошибок не было.

7. Трудности перевода или последний fuck-up

Проект запустился и уже вовсю шёл 5-ый день эры SSO в нашем SAP, когда мы обнаружили слона, которого никто не заметил.

В компании присутствует два языка: голландский и французский. Априори, благо компания расположена в Брюсселе — у всех стоит французский. Но тем не менее многие сотрудники подключаются через голландский или английский. В общей сложности из 2-х тысяч активных пользователей, почти 500 человек это голландско-говорящие. Раньше они сами всякий раз меняли язык в окошке подключения.

Теперь у всех по дефолту оказался французский. Причём если бы мы оставили галочку “use a default language SAP logon” пустой — никаких вопросов не возникло бы, каждый бы подключался с тем языком, какой у него отмечен в параметрах (SU01, вкладка Defaults). После внедрения посыпались звонки с просьбой «сменить пользователю SAP».

На этапе тестирования проблемы замечено не было, потому что почти все тестировщики оказались французско-говорящими, либо подключались на французском в повседневной работе.

Решили проблему отправкой инструкцией о смене языка всем нидерландо-говорящим пользователям дабы предовратить их новые звонки в техподдержку.

8. Итоги и выводы

В целом внедрить SSO — это просто, когда вы это уже сделали хотя бы один раз в жизни. Говорят, что это вопрос 1-2 недель работы, но никак не 3-х месяцев.

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

Многие вещи про SSO были, возможно, уже давно известны, как минимум, гуглу. Например про запрос сервера к AD, или поле SNC. Но есть такая вещь, как вечная нехватка времени. Как специалист вы обязаны гуглить, а как менеджер проекта (особенно если вы не можете разобраться в первые полчаса, и у вас нет профильного образования) — вы должны найти самый короткий путь к решению.

До свидания, ESNI, привет ECH

Большая часть коммуникации в современном интернете зашифрована, а ее содержание доступно только двум конечным точкам, клиенту и серверу. Однако, любое шифрование требует ключа, который нужно согласовать, не раскрывая потенциальным злоумышленникам. Чаще всего для этой задачи используют так называемое TLS-рукопожатие (Transport Layer Security). В этом тексте мы рассмотрим новое расширение для TLS, которое называется ECH (Encrypted Client Hello). Оно должно серьезно повысить надежность этого критически важного протокола.

Сегодня ряд крайне важных параметров TLS-соединений передается в явном виде. Таким образом, у третьих лиц есть доступ к метаданным, включая информацию о конечных точках, характере использования соединения и так далее.

ECH может исправить это, закладывая основу для добавления будущих функций безопасности и повышения производительности TLS. Влияние на конфиденциальность конечных пользователей при этом будет минимальной. ECH — это продукт тесного сотрудничества между учеными и технологическими компаниями. Среди участников: IETF (Инженерный совет интернета), Cloudflare, Fastly, Mozilla и другие.

ECH основан на передовых технологиях, которые только начинают применяться. Например, DNS over HTTPS. Как таковой, протокол еще не готов к развертыванию в масштабе интернета, но этот текст поможет лучше понять, какие возможности дает ECH.

Предыстория

История TLS — это история интернета. По мере развития сети, протокол развивался с учетом постоянно меняющихся требований безопасности, опыта использования и новых угроз.

Клиент и сервер не просто обмениваются ключами. Они обсуждают широкий спектр функций и параметров: точный метод обмена ключами, алгоритм шифрования, процесс аутентификации, какой протокол прикладного уровня использовать после рукопожатия и многое другое. Все эти параметры так или иначе влияют на свойства безопасности канала связи.

Пример такого параметра — расширение SNI (Server Name Indication, Индикация имени сервера). С его помощью клиент сообщает серверу, какой сайт он хочет посетить. Для интернета это очень важно, так как сейчас многие серверы находятся за одним TLS-оператором. Оператор использует SNI для определения того, кто будет аутентифицировать соединение: без этого невозможно будет узнать, какой TLS-сертификат представить клиенту.

Проблема заключается в том, что SNI идентифицирует сервер, к которому клиент хочет подключиться, потенциально позволяя третьим лицам получать множество метаданных. Но это не единственный чувствительный к конфиденциальности параметр, который клиент и сервер обговаривают между собой.

Другой параметр — это расширение ALPN (Application-Layer Protocol Negotiation, Согласование протоколов уровня приложений). Оно используется, чтобы принимать решение, какой протокол прикладного уровня использовать после установки TLS-соединения. Клиент отправляет серверу список используемых приложений (электронная почта, мессенджеры и другое), которые используют TLS, а сервер сообщает клиенту свой выбор. Таким образом, клиент и сервер приходят к согласию, для каких возможностей и задач может быть использовано соединение.

Некоторые функции настолько чувствительны к конфиденциальности, что не включаются в рукопожатие сразу. Ранее высказывалась идея заменить обмен ключами в TLS на обмен ключами c аутентификацией паролем. Это позволит использовать аутентификацию на основе пароля вместе (или вместо) аутентификации на основе сертификата, что сделает TLS более надежным и подходящим для более широкого круга приложений. Проблема конфиденциальности здесь такая же, как и в случае с SNI: серверы обычно ассоциируют уникальный идентификатор который используется для получения учетных данных c каждым клиентом (например имя пользователя или адрес электронной почты). Клиент должен каким-то образом передать его серверу во время рукопожатия. Если отправлять эту информацию в открытом виде, она будет доступна любому внешнему наблюдателю в сети.

Необходимое условие для устранения проблемы — шифрование сообщений о рукопожатии в дополнение к данным приложения. Звучит достаточно просто, но возникает проблема. Как клиент и сервер согласовывают ключ шифрования, если рукопожатие само по себе является средством обмена ключами? Некоторые параметры, конечно же, должны отправляться в открытом виде, поэтому целью ECH является шифрование всех параметров рукопожатия, за исключением тех, которые необходимы для завершения обмена ключами.

Чтобы понять ECH и решения в его основе, стоит немного разобраться в истории шифрования рукопожатий в TLS.

Шифрование рукопожатий в TLS

До выхода TLS 1.3 рукопожатия не шифровались. После разоблачений Сноудена в 2013 году сообщество IETF (Инженерный совет интернета) начало думать над противодействием угрозе, которую представляет собой массовое наблюдение за открытым интернетом. Когда в 2014 году начался процесс стандартизации TLS 1.3, одной из целей разработки было максимально возможное шифрование рукопожатий. К сожалению, стандарт TLS 1.3 не может обеспечить этого, а некоторые параметры, в том числе SNI, все еще передаются в чистом виде. Давайте разберемся, почему.

Работа протокола TLS 1.3 показана на рисунке 1. Шифрование рукопожатия начинается как только клиент и сервер договариваются об общей секретной информации. Для этого клиент отправляет серверу ключ с сообщением ClientHello, а тот отвечает ему сообщением ServerHello со своим собственным ключом. Обменявшись этим, клиент и сервер могут получить shared secret (данные, известные только заинтересованным сторонам в защищенном обмене данными). Каждое последующее рукопожатие шифруется с помощью ключа трафика, полученного из shared secret.

Первое зашифрованное сообщение в рукопожатии — EncryptedExtensions от сервера. Его задача — защитить чувствительные параметры рукопожатия, включая ALPN-расширение сервера, которое содержит приложение, выбранное из клиентского списка ALPN-клиентов. Параметры обмена ключами отправляются в незашифрованном виде в сообщениях ClientHello и ServerHello. Все параметры рукопожатия, как чувствительные, так и нет, отправляются в сообщении ClientHello.

Рисунок 1: Рукопожатие TLS 1.3.
Взглянув на рисунок 1 можно задуматься, как переделать процесс рукопожатия так, чтобы зашифровать больше компонентов, возможно, за счет дополнительных задержек (большего количества циклов в сети). Однако, такие расширения, как SNI создают классическую проблему «курица или яйцо».

Клиент ничего не зашифрует, пока не проверит идентичность сервера (это работа сообщений CertificateVerify), а сервер не подтвердит, что знает shared secret (это работа сообщения Finished). Эти меры обеспечивают аутентификацию с помощью обмена ключами, предотвращая таким образом атаки monster-in-the-middle (MITM), где хакер выдает себя клиенту за сервер, что позволяет расшифровать сообщения. Поскольку SNI нужен серверу для выбора сертификата, он должен быть передан до аутентификации с помощью обмена ключами.

В общем, обеспечение конфиденциальности параметров рукопожатия, используемых для аутентификации, возможно только в том случае, если клиент и сервер уже имеют общий ключ шифрования. Но откуда может взяться этот ключ?

Полное шифрование рукопожатий в TLS 1.3. Интересно, что полное шифрование рукопожатий было однажды предложено в качестве основной функции TLS 1.3. В ранних версиях протокола (draft-10, около 2015 года) сервер предлагал клиенту долгоживущий открытый ключ во время рукопожатия, который клиент использовал для шифрования при последующих рукопожатиях. Эта схема пришла из протокола под названием OPTLS, который, в свою очередь, был основан на протоколе QUIC.

Режим назвали «0-RTT» и он использовался в первую очередь для того, чтобы дать клиенту возможность отправлять данные приложения до завершения процесса рукопожатия.

Кроме того, это позволило бы клиенту зашифровать первую серию сообщений рукопожатия следующую за ClientHello, включая его собственные EncryptedExtensions, которые могли использоваться для защиты конфиденциальных параметров рукопожатия клиента.

Но эта функция не была включена в окончательную версию стандарта RFC 8446, опубликованную в 2018 году. Главной причиной было то, что сложность реализации перевешивала потенциальную пользу. Кроме того, функция никак не защищает первоначальное рукопожатие, когда клиент узнает публичный ключ сервера. Такие параметры, как SNI все равно будут передаваться в открытом виде.

Тем не менее, эта схема примечательна как предшественница других механизмов шифрования рукопожатий, таких как ECH, которые используют шифрование с открытым ключом для защиты чувствительных параметров ClientHello.

До ECH было (и есть) ESNI

Непосредственным предшественником ECH было расширение Encrypted SNI (ESNI). Как следует из названия, целью ESNI было обеспечение конфиденциальности SNI. Работает оно так. Клиент шифрует свое расширение SNI под открытым ключом сервера и отправляет шифрованный текст на сервер. Сервер пытается расшифровать текст, используя секретный ключ, соответствующий его открытому ключу. Если дешифровка прошла успешно, сервер устанавливает соединение, используя расшифрованный SNI. В противном случае, он прерывает рукопожатие. Весь процесс показан на рисунке 2.

Рисунок 2: Рукопожатие TLS 1.3 с расширением ESNI. Оно идентично рукопожатию TLS 1.3, за исключением того, что расширение SNI было заменено на ESNI

Несмотря на то, что ESNI сделал значительный шаг вперед, он не соответствует цели полного шифрования рукопожатий. Помимо того, что ESNI защищает только SNI, он уязвим к нескольким сложным атакам, которые, хотя и трудновыполнимы, но указывают на теоретические недостатки в конструкции протокола, которые необходимо устранить. Однако практическая польза от ESNI в плане конфиденциальности существенна.

Плюсы и минусы ECH

Цель ECH — полностью зашифровать ClientHello, закрыв соответствующий пробел в TLS 1.3 и ESNI, защитив все чувствительные к конфиденциальности параметры рукопожатия. Подобно ESNI, протокол использует открытый ключ, распространяемый через DNS и полученный с помощью DoH. Однако в ECH есть улучшения в распределении ключей, которые делают протокол более устойчивым к несовпадениям в DNS-кэше. В то время как ESNI-сервер прерывает соединение в случае сбоя дешифровки, ECH-сервер пытается завершить рукопожатие и предоставить клиенту открытый ключ, который он может использовать для повторных попыток соединения.

Но как сервер может завершить рукопожатие, если он не может расшифровать ClientHello? Как показано на рисунке 3, протокол ECH включает два ClientHello сообщения:

• ClientHelloOuter, который отправляется в открытом виде;
• ClientHelloInner, который зашифрован и отправляется в качестве расширения ClientHelloOuter.

Сервер завершает рукопожатие только одним из этих ClientHello: если дешифровка прошла успешно, то он продолжает работать с ClientHelloInner; в противном случае, он продолжает работать с ClientHelloOuter. Как минимум, оба ClientHello должны содержать параметры рукопожатия, необходимые для аутентифицированного сервером обмена ключами.

Рисунок 3: Рукопожатие TLS 1.3 с расширением ECH.

Такая конструкция решает большинство проблем безопасного развертывания шифрования рукопожатий. Важно отметить, что ECH был задуман не в вакууме. Протокол отражает различные точки зрения сообщества IETF, и его разработка согласуется со стандартами IETF. Актуальная спецификация ECH сегодня достаточно стабильна. Но остается еще несколько детальных вопросов, которые нужно решить.

Заключение

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

Старая версия TLS-рукопожатия слишком уязвима для сторонних наблюдателей в сети. И расширение ECH должно устранить этот пробел за счет шифрования всего процесса рукопожатия. Это поможет сохранить конфиденциальность конечных пользователей по мере развития протокола.

ECH нуждается в доработке, чтобы помешать третьим лицам анализировать трафик. Например, длина зашифрованного ClientHello может дать третьим лицам достаточную подсказку о его ценности. Этот риск велик для доменных имен, которые или слишком короткие, или слишком длинные. Поэтому важно сделать так, чтобы длина каждого зашифрованного текста не зависела от значений параметров, чувствительных к конфиденциальности. Повышение устойчивости ECH — важное направление для будущей работы, которой еще много.