mutual authentication что это
История одного SSL рукопожатия
Недавно мне пришлось прикручивать SSL с двухсторонней аутентификацией (mutual authentication) к Spring Reactive Webclient. Казалось бы, дело нехитрое, но вылилось оно в блуждание в исходниках JDK с неожиданным финалом. Опыта набралось на целую статью, которая может оказаться полезной инженерам в повседневных задачах или при подготовке к собеседованию.
Постановка задачи
Есть REST-сервис на стороне заказчика, который работает через HTTPS.
Необходимо обращаться к нему из клиентского Java приложения.
Далее следовало правильно сконфигурировать клиентское Java приложение.
Для REST-запросов я использовала Spring Reactive WebClient с неблокирующим вводом-выводом.
В документации есть пример, как его можно кастомизировать, прокинув ему объект SslContext, который как раз хранит сертификаты и приватные ключи.
Моя конфигурация в упрощённом варианте была практически копипастой из документации:
Придерживаясь принципа TDD, я также написала тест, в котором вместо WebClient используется WebTestClient, выводящий кучу отладочной информации. Самый первый assertion был таким:
Этот простой тест сразу же не прошёл: сервер вернул 500 с таким же body, как и в случае, если в Postman не указать клиентский сертификат.
Отдельно отмечу, что на время отладки, я включила опцию «не проверять серверный сертификат», а именно — передала инстанс InsecureTrustManagerFactory в качестве TrustManager для SslContext. Эта мера была избыточной, но исключала половину вариантов наверняка.
Отладочная информация в тесте не проливала свет на проблему, но выглядело всё, будто что-то пошло не так на этапе SSL handshake, поэтому я решила более подробно сравнить как происходит соединение в обоих случаях: для Postman и для Java клиента. Всё это можно посмотреть используя Wireshark — это такой популярный анализатор сетевого трафика. Заодно увидела как происходит SSL handshake с двухсторонней аутентификацией, так сказать, вживую (это очень любят спрашивать на собеседованиях):
Дальше мне нужно было бы посмотреть сначала в спецификацию протокола TLS, которая говорит буквально следующее:
If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.
Речь идёт о списке certificate_authorities, указанном в Certificate Request message, приходящем от сервера. Клиентский сертификат (хотя бы один из цепочки) должен быть подписан одним из issuers, перечисленных в этом списке. Назовём это проверкой X.
Я об этом условии не знала и обнаружила его, когда дошла в отладке до глубин JDK (у меня это JDK9). Netty HttpClient, который лежит в основе Spring WebClient, использует по умолчанию SslEngine из JDK. Альтернативно можно переключить его на OpenSSL провайдер, добавив необходимые зависимости, но мне это, в конечном счёте, не потребовалось.
Итак, я расставила брейкпоинты внутри sun.security.ssl.ClientHandshaker класса и в хэндлере для serverHelloDone сообщения обнаружилась проверка X, которая не проходила: ни один из issuer-ов в цепочке клиентского сертификата не находился в списке issuer-ов, которым доверяет сервер (из Certificate Request message от сервера).
Я обратилась к заказчику за новым сертификатом, но заказчик возразил, что у него всё работает отлично, и вручил Python скрипт, которым он обычно проверял работоспособность сертификатов. Скрипт не делал ничего лишнего, кроме отправки HTTPS запроса с использованием Requests библиотеки, и возвращал 200 OK. Окончательно я удивилась, когда старый добрый curl тоже вернул 200 OK. Сразу вспомнился анекдот: «Вся рота идет не в ногу, один поручик шагает в ногу».
Curl — это, конечно, авторитетная утилита, но и TLS стандарт тоже не кусок туалетной бумаги. Не зная, что ещё можно проверить, я полезла бесцельно бродить по документации к curl, и на Github, где обнаружила вот такой известный баг.
Репортер описывал точь-в-точь проверку X: в curl с дефолтным бекэндом (OpenSSL) она не выполнялась, в отличие от curl с GnuTLS бекендом. Я не поленилась, собрала curl из исходников с опцией —with-gnutls, и отправила многострадальный реквест. И, наконец-то, ещё один клиент, кроме JDK, вернул HTTP статус 500 вместе с «Secutiry exception»!
Я написала об этом заказчику в ответ на аргумент «Ну curl-же работает» и получила новый сертификат, заново сгенеренный и аккуратно установленный на сервере. С ним моя конфигурация для WebClient заработала отлично. Happy End.
Эпопея с настройкой SSL заняла со всеми переписками больше двух недель (туда же вошло изучение подробных логов Java, ковыряние кода другого проекта, который у заказчика работает, и просто ковыряние в носу).
Что меня долго сбивало с толку, помимо разницы в поведении клиентов, так это то, что сервер был настроен таким образом, что сертификат запрашивал, но не проверял. Однако, и на это есть пояснения в спеке:
СОДЕРЖАНИЕ
Этапы процесса и проверка
Чтобы убедиться, что взаимная аутентификация прошла успешно, логика Барроуза-Абади-Нидхема ( логика BAN) является хорошо зарекомендовавшим и широко распространенным методом, поскольку она проверяет, что сообщение пришло от надежного объекта. Логика BAN сначала предполагает, что объекту нельзя доверять, а затем проверяет его законность.
Защиты
Взаимная проверка подлинности поддерживает сети с нулевым доверием, поскольку она может защитить коммуникации от враждебных атак, в частности:
Взаимная аутентификация также обеспечивает целостность информации, поскольку, если стороны подтверждают, что они являются правильным источником, полученная информация также является надежной.
Облегченные схемы против защищенных схем
Хотя упрощенные схемы и схемы безопасности не исключают друг друга, добавление этапа взаимной аутентификации к протоколам передачи данных часто может увеличить время выполнения и вычислительные затраты. Это может стать проблемой для сетевых систем, которые не могут обрабатывать большие объемы данных или тех, которые постоянно должны обновляться для получения новых данных в реальном времени (например, отслеживание местоположения, данные о состоянии здоровья в реальном времени).
Приложения, которые полагаются исключительно на связь между устройствами (D2D), когда несколько устройств могут взаимодействовать локально в непосредственной близости, удаляют стороннюю сеть. Это, в свою очередь, может ускорить время общения. Однако аутентификация по-прежнему происходит по незащищенным каналам, поэтому исследователи считают, что по-прежнему важно обеспечить взаимную аутентификацию, чтобы сохранить безопасную схему.
Схемы могут принести в жертву лучшее время выполнения или стоимость хранения при обеспечении взаимной аутентификации, чтобы сделать приоритетом защиту конфиденциальных данных.
Схемы на основе паролей
В схемах взаимной аутентификации, которые требуют ввода пароля пользователя как части процесса проверки, существует более высокая уязвимость для хакеров, поскольку пароль создается человеком, а не сертификатом, созданным компьютером. Хотя приложения могут просто требовать от пользователей использования пароля, сгенерированного компьютером, людям неудобно его запоминать. Создаваемые пользователем пароли и возможность изменить свой пароль важны для того, чтобы сделать приложение удобным для пользователя, поэтому многие схемы работают, чтобы учесть характеристики. Исследователи отмечают, что протокол на основе паролей с взаимной аутентификацией важен, потому что идентификационные данные пользователей и пароли по-прежнему защищены, поскольку сообщения доступны для чтения только двум вовлеченным сторонам.
Многофакторная аутентификация
В последнее время все больше схем имеют более высокий уровень аутентификации, чем схемы на основе пароля. В то время как аутентификация на основе пароля рассматривается как «однофакторная аутентификация», в схемах начинают реализовываться схемы аутентификации на основе смарт-карт ( двухфакторная ) или биометрическая (трехфакторная). Смарт-карты проще реализовать и легко аутентифицировать, но все же есть риск взлома. Биометрия стала более популярной по сравнению со схемами на основе паролей, потому что при использовании биометрии сложнее копировать или угадывать ключи сеанса, но может быть сложно зашифровать зашумленные данные. Из-за этих рисков и ограничений безопасности схемы могут по-прежнему использовать взаимную аутентификацию независимо от того, сколько факторов аутентификации добавлено.
Схемы на основе сертификатов и системные приложения
Взаимная аутентификация часто встречается в схемах, используемых в Интернете вещей (IoT), где физические объекты включены в Интернет и могут связываться через IP-адрес. Схемы аутентификации могут применяться ко многим типам систем, которые включают передачу данных. Поскольку присутствие Интернета в механических системах увеличивается, написание эффективных схем безопасности для большого числа пользователей, объектов и серверов может стать сложной задачей, особенно когда требуется, чтобы схемы были легкими и имели низкие вычислительные затраты. Вместо аутентификации на основе пароля устройства будут использовать сертификаты для проверки личности друг друга.
Радиосети
Взаимная аутентификация может быть удовлетворена в схемах радиосети, где передача данных через радиочастоты является безопасной после проверки отправителя и получателя.
Метки радиочастотной идентификации (RFID) обычно используются для обнаружения объектов, которые многие производители внедряют в свои складские системы для автоматизации. Это позволяет быстрее вести инвентаризацию и отслеживать объекты. Однако отслеживание элементов в системе с помощью RFID-меток, которые передают данные на облачный сервер, увеличивает шансы на угрозу безопасности, поскольку теперь существует больше цифровых элементов, которые необходимо отслеживать. Между RFID-метками, считывателями меток и облачной сетью, в которой хранятся эти данные, может происходить трехсторонняя взаимная аутентификация, чтобы обеспечить безопасность данных RFID-меток и их невозможность манипулировать.
Аналогичным образом, альтернативная система RFID-меток и считывателей, которая назначает назначенные считыватели меткам, была предложена для дополнительной безопасности и низкой стоимости памяти. Вместо того, чтобы рассматривать все считыватели тегов как одно целое, только определенные считыватели могут читать определенные теги. При использовании этого метода, если читатель взломан, это не повлияет на всю систему. Отдельные считыватели будут взаимодействовать с определенными тегами во время взаимной проверки подлинности, которая выполняется в постоянное время, поскольку считыватели используют один и тот же закрытый ключ для процесса проверки подлинности.
Многие системы электронного здравоохранения, которые удаленно контролируют данные о здоровье пациентов, используют беспроводные сети тела (WBAN), которые передают данные через радиочастоты. Это полезно для пациентов, которых не следует беспокоить во время наблюдения, и может снизить нагрузку на медицинских работников и позволить им сосредоточиться на более практических задачах. Однако большую озабоченность поставщиков медицинских услуг и пациентов по поводу использования удаленного отслеживания медицинских данных вызывает то, что конфиденциальные данные пациента передаются по незащищенным каналам, поэтому аутентификация происходит между пользователем локальной сети медицинского органа (пациентом) и поставщиком медицинских услуг (HSP). и доверенная третья сторона.
Облачные вычисления
Машинная проверка
Многие системы, не требующие участия человека в системе, также имеют протоколы, которые взаимно аутентифицируют стороны. В системах беспилотных летательных аппаратов (БПЛА) происходит аутентификация платформы, а не аутентификация пользователя. Взаимная аутентификация во время связи с транспортным средством предотвращает взлом системы одного транспортного средства, что может негативно повлиять на всю систему. Например, система дронов может использоваться для сельскохозяйственных работ и доставки грузов, но если один дрон будет взломан, вся система может рухнуть.
Взаимная аутентификация
Чтобы убедиться, что взаимная аутентификация прошла успешно, логика Барроуза-Абади-Нидхема ( логика BAN) является хорошо зарекомендовавшим и широко распространенным методом, поскольку она проверяет, что сообщение пришло от надежного объекта. Логика BAN сначала предполагает, что объекту нельзя доверять, а затем проверяет его законность. [1] [2] [6] [7]
Взаимная аутентификация поддерживает сети с нулевым доверием, поскольку она может защитить коммуникации от злоумышленников, [8] в частности:
Взаимная аутентификация также обеспечивает целостность информации, поскольку, если стороны подтверждают, что они являются правильным источником, полученная информация также является надежной. [6]
Хотя упрощенные схемы и схемы безопасности не исключают друг друга, добавление этапа взаимной аутентификации к протоколам передачи данных часто может увеличить время выполнения и вычислительные затраты. [2] Это может стать проблемой для сетевых систем, которые не могут обрабатывать большие объемы данных или тех, которые постоянно должны обновляться для получения новых данных в реальном времени (например, отслеживание местоположения, данные о состоянии здоровья в реальном времени). [2] [10]
Приложения, которые полагаются исключительно на связь между устройствами (D2D), когда несколько устройств могут взаимодействовать локально в непосредственной близости, удаляют стороннюю сеть. Это, в свою очередь, может ускорить время общения. [14] Однако аутентификация по-прежнему происходит по незащищенным каналам, поэтому исследователи считают, что по-прежнему важно обеспечить взаимную аутентификацию, чтобы сохранить безопасную схему. [14]
Схемы могут принести в жертву лучшее время выполнения или стоимость хранения при обеспечении взаимной аутентификации, чтобы сделать приоритетом защиту конфиденциальных данных. [2] [12]
В схемах взаимной аутентификации, требующих ввода пароля пользователем в процессе проверки, существует более высокая уязвимость для хакеров, поскольку пароль создается человеком, а не сертификатом, созданным компьютером. Хотя приложения могут просто требовать от пользователей использования пароля, сгенерированного компьютером, людям неудобно его запоминать. Пользовательские пароли и возможность изменить свой пароль важны для того, чтобы сделать приложение удобным для пользователя [15], поэтому многие схемы работают, чтобы приспособиться к характеристикам. Исследователи отмечают, что протокол на основе паролей с взаимной аутентификацией важен, потому что идентификаторы пользователей и пароли по-прежнему защищены, поскольку сообщения доступны для чтения только двум вовлеченным сторонам. [16]
Однако отрицательным аспектом аутентификации на основе пароля является то, что таблицы паролей могут занимать много места в памяти. [15] Одним из способов использования большого объема памяти во время схемы аутентификации на основе пароля является использование одноразовых паролей (OTP), которые представляют собой пароль, отправляемый пользователю по SMS или электронной почте. Одноразовые пароли чувствительны ко времени, что означает, что их срок действия истечет через определенное время, и что память не нужно хранить. [17]
Многофакторная аутентификация
В последнее время все больше схем имеют более высокий уровень аутентификации, чем схемы на основе пароля. В то время как аутентификация на основе пароля рассматривается как «однофакторная аутентификация», в схемах начинают реализовываться схемы аутентификации на основе смарт-карт ( двухфакторная ) [15] или биометрическая (трехфакторная). Смарт-карты проще реализовать и легко аутентифицировать, но все же есть риск взлома. [15] Биометрия стала более популярной по сравнению со схемами на основе паролей, потому что при использовании биометрии сложнее копировать или угадывать ключи сеанса [7], но может быть сложно зашифровать зашумленные данные. [17] Из-за этих рисков и ограничений безопасности схемы могут по-прежнему использовать взаимную аутентификацию независимо от того, сколько факторов аутентификации добавлено. [7]
Взаимная аутентификация часто встречается в схемах, используемых в Интернете вещей (IoT), где физические объекты включены в Интернет и могут связываться через IP-адрес. [11] Схемы аутентификации могут применяться ко многим типам систем, которые включают передачу данных. [14] Поскольку присутствие Интернета в механических системах увеличивается, написание эффективных схем безопасности для большого числа пользователей, объектов и серверов может стать сложной задачей, особенно когда требуется, чтобы схемы были легкими и имели низкие вычислительные затраты. Вместо аутентификации на основе пароля устройства будут использовать сертификаты для проверки личности друг друга.
Радиосети
Взаимная аутентификация может быть удовлетворена в схемах радиосети, где передача данных через радиочастоты является безопасной после проверки отправителя и получателя. [12] [18]
Метки радиочастотной идентификации (RFID) обычно используются для обнаружения объектов, которые многие производители внедряют в свои складские системы для автоматизации. [19] Это позволяет быстрее вести инвентаризацию и отслеживать объекты. Однако отслеживание элементов в системе с помощью RFID-меток, которые передают данные на облачный сервер, увеличивает шансы на угрозу безопасности, поскольку теперь есть больше цифровых элементов, которые нужно отслеживать. [19] Трехсторонняя взаимная аутентификация может происходить между RFID-метками, считывателями меток и облачной сетью, в которой хранятся эти данные, чтобы обеспечить безопасность данных RFID-меток и их невозможность манипулировать. [19]
Точно так же для дополнительной безопасности и низкой стоимости памяти была предложена альтернативная система RFID-меток и считывателей, которая назначает назначенные считыватели меткам. [20] Вместо того, чтобы рассматривать все считыватели тегов как одно целое, только определенные считыватели могут читать определенные теги. При использовании этого метода, если читатель взломан, это не повлияет на всю систему. Отдельные считыватели будут взаимодействовать с определенными тегами во время взаимной проверки подлинности, которая выполняется в постоянное время, поскольку считыватели используют один и тот же закрытый ключ для процесса проверки подлинности.
Многие системы электронного здравоохранения, которые удаленно отслеживают данные о здоровье пациентов, используют беспроводные сети тела (WBAN), которые передают данные по радиочастотам. [12] Это полезно для пациентов, которых не следует беспокоить во время наблюдения, и может снизить нагрузку на медицинских работников и позволить им сосредоточиться на более практической работе. Однако большую озабоченность поставщиков медицинских услуг и пациентов по поводу использования удаленного отслеживания медицинских данных вызывает то, что конфиденциальные данные пациента передаются по незащищенным каналам [9], поэтому аутентификация происходит между пользователем локальной сети медицинского органа (пациентом), поставщиком медицинских услуг. (HSP) и доверенная третья сторона.
Облачные вычисления
Машинная проверка
Многие системы, не требующие участия человека в системе, также имеют протоколы, которые взаимно аутентифицируют стороны. В системах беспилотных летательных аппаратов (БПЛА) происходит аутентификация платформы, а не аутентификация пользователя. [2] Взаимная аутентификация во время связи транспортного средства предотвращает взлом системы одного транспортного средства, что может негативно повлиять на всю систему. Например, система дронов может использоваться для сельскохозяйственных работ и доставки грузов, но если один дрон будет взломан, вся система может рухнуть. [2] [23]
Что такое TLS
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.
Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, который предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.