Основы IT: SSL

Давно зрела мысль попытаться описать основные моменты из сферы IT простым языком, ибо дремучесть народа в комментариях порой удручает. Хотел начать с DNS, но волею случая жребий пал на SSL.

Основная задача SSL – это установить между клиентом и сервером зашифрованное соединение. Для этого нужно договориться о «пароле» (секретном ключе сессии) и основную опасность тут представляет Man-in-the-Middle: в процессе передачи данных на одном из промежуточных узлов их могут подслушивать, а в некоторых случаях даже подменять проходящие пакеты. В качестве Man-in-the-Middle может выступать как государство (система СОРМ-2 и её зарубежные аналоги), так и сторонний злоумышленник, прицепившейся к вашему WiFi. Таким образом, для безопасной передачи данных нужно как-то секретно договориться с сервером о протоколе, параметрах и ключе шифрования.

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

Имеется пара закрытый (приватный) ключ PRIV и открытый (публичный) ключ PUB для которых:

1. Имеется однозначное и единственное соответствие ключей друг-другу – по приватному ключу PRIV можно однозначно вычислить единственный и уникальный ключ PUB
2. Шифрование – используя публичный ключ PUB, любой может зашифровать сообщение msg так, что расшифровать его можно только при помощи закрытого ключа PRIV. Иными словами, сообщение, закодированное публичным ключом может быть декодировано только приватным ключом.
3. Подпись – используя закрытый ключ PRIV можно защитить сообщение msg от любых изменений, в отсутствии которых можно удостоверится при помощи открытого ключа PUB. Иными словами, получив сообщение и его сигнатуру, мы можем проверить его целостность – декодирование сигнатуры публичным ключом должно выдавать сообщение, идентичное незашифрованному.

Таким образом, алгоритм действий следующий:

1. Клиент запрашивает у сервера сессию и его публичный ключ;
2. Сервер отдаёт публичный ключ;
3. Клиент кодирует им временный пароль сессии;
4. Клиент отдаёт закодированный пароль сессии серверу;
5. Дальнейшие коммуникации идут с симметричным шифрованием используя этот временный пароль.

Но что, если зловредный Man in the Middle может не только прослушивать траффик, но и подменять данные? В таком случае, он может на шаге 1 «подслушать» публичный ключ сервера, на шаге 2 отдать свой публичный ключ, прочитать пароль сессии на шаге 3 и отдать его серверу снова закодировав публичным ключом сервера на шаге 4.

Вот тут-то и используется третье свойство ассиметричного шифрования – цифровая подпись. Пускай будет N авторитетных организаций, которые могут подписать публичный ключ сервера своим приватным ключом. Их публичные ключи будут всегда доступны, и клиент сможет с их помощью проверить, а действительно ли никто не подменил данные сервера на шаге 2.

Также, для надёжности давайте с сервера отдавать не просто публичный ключ и его цифровую подпись, а еще и некоторые дополнительные мета-данные (время действия, имя домена, название организации и т.д.). Это и называется SSL Certificate, стандарт X.509

Такие организации называются Trusted Root Certificate Authorities, а их сертификаты зашиты в системные библиотеки SSL или непосредственно в браузер.

https://en.wikipedia.org/wiki/Certificate_authority#/media/File:PublicKe...

Более того, Root Certificate Authority может выдавать не только сертификаты конечным пользователям, но и выдать специальный Intermediate Certificate какой-то другой организации, которая в свою очередь сможет подписывать конечные сертификаты. Такие организации называются Intermediate Certificate Authorities, а цепочка от конечного сертификата до Root Certificate Authority называется Chain of Trust (может быть больше одного промежуточного Authority).

https://upload.wikimedia.org/wikipedia/commons/0/02/Chain_Of_Trust.svg

Поскольку может так получиться, что у клиента нет в SSL библиотеке сертификата для какой-то специфической Intermediate Certificate Authority, сервер вместе со своим сертификатом также отдаёт сертификат Intermediate Certificate Authority его выпустившего. На клиенте цепочка сертификатов последовательно разбирается, пока не дойдут до известного Root Certificate Authority.

В итоге SSL Handshake (протокол рукопожатия) выглядит вот так:

https://www.ssl.com/wp-content/uploads/2015/07/SSLTLS_handshake.png

1. Клиент посылает серверу номер версии SSL клиента, поддерживаемые алгоритмы шифрования и сжатия, специфичные данные для сеанса и другую информацию, которая нужна серверу, чтобы общаться с клиентом, используя SSL.
2. Сервер посылает клиенту номер версии SSL сервера, алгоритм сжатия и шифрования (выбранные из посланных ранее клиентом), специфичные данные для сеанса и другую информацию, которая нужна клиенту, чтобы общаться с сервером по протоколу SSL. Сервер также посылает свой сертификат, который требует проверки подлинности клиента.
3. Клиент использует информацию, переданную сервером для проверки подлинности. Если сервер не может быть проверен, пользователь получает предупреждение о проблеме и о том, что шифрование и аутентификация соединения не может быть установлена. Клиент создаёт предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера, отправленного на 2-м шаге), а затем отправляет его на сервер.
4. Сервер расшифровывает секрет сессии используя свой закрытый ключ.
5. На этом этапе и клиент и сервер имеют одинаковый секрет сессии. И клиент, и сервер используют секрет для генерации ключей сеансов, которые являются симметричными ключами, использующиеся для шифрования и расшифрования информации, которой обмениваются во время SSL сессии. Происходит проверка целостности (то есть, для обнаружения любых изменений в данных между временем когда он был послан, и временем его получения на SSL-соединении).
6. Клиент посылает сообщение серверу, информируя его, что будущие сообщения от клиента будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.
7. И в заключение, сервер посылает сообщение клиенту, информируя его, что будущие сообщения от сервера будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.

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

Также, потребовалась процедура для экстренного отзыва сертификатов – например, когда стало достоверно известно, что сертификат взломали. Или, что хуже, приватный ключ Certificate Authority стал известен злоумышленникам. Управляется это через CRL (Certificate Revocation List) или используя OCSP (Online Certificate Status Protocol). Хочу подчеркнуть, что это уже дополнительная надстройка, существенным недостатком которой является необходимость обращения к каким-то дополнительным внешним сервисам во время SSL handshake. Тут процесс еще пока находится в стадии развития, разные системы и браузеры используют разные способы и методы.

Ну и теперь кратко об инфоповоде, побудившем меня всё это написать – якобы отзыве сертификатов fsb.ru и kremlin.ru (и в 2018 отзыве сертификата oprf.ru). На данной стадии развития - это полный бред. Технически да, можно добавить сертификат конечного сайта в CRL. Но нету возможности проконтролировать, что все браузеры его вовремя обновят. Для конечных пользователей это бы выглядело так – у половины всё работает нормально, у другой браузер ругается на «плохой» сертификат. Основной целью отзыва является защита от возможной прослушки, когда какой-то сертификат скомпрометирован. Причём, как пишут на ssl.com

For website owners, it seems wise to assume that the various browser programs are focused on high-priority/emergency incidents such as revoked root and intermediate CA certificates, and that revocations of garden-variety end-entity certificates are likely to pass unnoticed for an indefinite period.

Для владельцев сайтов разумно будет полагать, что производители различных браузеров в первую очередь сфокусированы на решении таких критических задач, как отзыв root и intermediate CA сертификатов, в то время как отзыв одного сертификата конкретного сайта может занять неопределённое количество времени.