###Сертификаты X.509
Термин X.509 представляет собой название стандарта Международного союза электросвязи (International Telecommunication Union, ITU), в котором описаны эти сертификаты. Сертификат представляет собой элемент структурированных данных, содержащий информацию о его владельце, а также открытый ключ шифрования, предназначенный для обмена информацией с его владельцем. Этот открытый ключ входит в пару «открытый/секретный ключ».
Как демонстрирует рисунок, неотъемлемыми элементами информации, содержащейся в сертификате, являются:
* название сущности, которую идентифицирует данный сертификат, то есть субъекта (subject). Название субъекта обычно представляет собой доменное имя. На практике, в сертификатах обычно есть поле «Другие названия субъекта», благодаря которому сертификат может идентифицировать субъект по нескольким названиям;
* открытый ключ субъекта;
* название центра сертификации, выдавшего сертификат.
* действительность сертификата, то есть дата и время истечения его срока действия.
### Пары «открытый/секретный ключ»
Как ясно из названия, открытым ключом можно делиться с кем угодно. Каждому открытому ключу соответствует секретный, который владелец никогда не должен обнародовать.
Сначала генерируется секретный ключ, а затем уже вычисляется соответствующий открытый. Пару «открытый/секретный ключ» можно использовать для двух полезных целей.
* Как показано на рис., открытый ключ можно применять для шифрования сообщения, которое затем сможет расшифровать только тот, у кого есть соответствующий секретный ключ.
* Секретный ключ можно использовать для создания цифровой подписи сообщения, с помощью которой любой владелец соответствующего открытого ключа сможет убедиться, что сообщение поступило от владельца секретного.
При установлении защищенных соединений возможности пар «открытый/секретный ключ» используются как для шифрования, так и для создания подписей.
Представьте, что вы хотите обмениваться со мной сообщениями. Я генерирую пару ключей и передаю вам открытый ключ, поэтому вы можете отправлять мне зашифрованные сообщения. Но если я отправлю вам открытый ключ, то как вы узнаете, что он действительно пришел от меня, а не от самозванца? Чтобы вы могли удостовериться, что я — та, за кого себя выдаю, необходима третья сторона, которой вы доверяете и которая за меня поручится. Эти функции выполняет центр сертификации (certificate authority, CA).
### Центры сертификации
Центр сертификации (ЦС) — доверенный орган, подписывающий сертификат и тем самым подтверждающий правильность информации о владельце, которая содержится в этом сертификате. Следует доверять только сертификатам, подписанным центрами, которым вы доверяете.
Открывая TLS-соединение с конкретным адресатом, инициирующий соединение клиент получает сертификат с другого конца соединения и проверяет его, чтобы убедиться, что его собеседник — тот, за кого себя выдает. Например, при открытии веб-соединения с банком браузер проверяет, что сертификат соответствует URL банка, а также проверяет, какой ЦС подписал этот сертификат.
Другие компоненты нуждаются в том, чтобы неким образом безопасно идентифицировать ЦС, поэтому ему соответствует свой сертификат. Но
этот сертификат также должен быть подписан каким-то центром, «личность» которого тоже нужно проверить, для чего требуется еще один сертификат и так далее до бесконечности. Похоже, получается бесконечная цепочка сертификатов! В конце концов, должен быть какой-то сертификат, которому мы можем просто доверять.
На практике цепочка заканчивается так называемым самоподписанным сертификатом: сертификатом X.509, который центр подписал для себя. Другими словами, этот сертификат представляет того же, чей секретный ключ был использован для подписания сертификата. Если вы доверяете данному лицу, то можете доверять и сертификату.
### Запросы на подписание сертификатов
Запрос на подписание сертификата (сertificate signing request, CSR) представляет собой файл, включающий такую информацию:
* открытый ключ, который нужно включить в сертификат;
* доменное имя (имена), с которым (-и) должен работать этот сертификат;
* информацию о владельце данного сертификата (например, название компании или организации).
Вы создаете CSR и отправляете его в ЦС, чтобы запросить сертификат X.509. Как вы знаете из изложенного ранее в данной главе, сертификат включает нужную информацию плюс подпись центра, поэтому его как раз и имеет смысл включить в CSR.
Создать новую пару ключей и CSR за один шаг можно с помощью таких утилит, как openssl. Некоторую путаницу, возможно, вызывает то, что openssl может использовать секретный ключ в качестве входных данных для генерации CSR. Соответствующий этому сертификату компонент задействует секретный ключ для расшифровки и подписывания сообщений (как вы скоро увидите), но никогда не использует сам открытый ключ. Последний нужен прочим компонентам, с которыми он обменивается информацией, и они получают этот открытый ключ из сертификата. А этому компоненту нужен секретный ключ, а также сертификат для отправки другим компонентам.
Теперь, когда вы уже понимаете, что такое сертификаты, обсудим, как они используются для TLS-соединений.
### TLS-соединения
Организатором соединений транспортного уровня является компонент, называемый клиентом. А компонент, с которым он обменивается информацией, называется сервером. Вполне возможно, что такая взаимосвязь «клиент — сервер» имеет место только на транспортном уровне, а на более высоких уровнях ранг компонентов, которые обмениваются информацией, будет одинаковым.
Клиент открывает сокет и запрашивает сетевое соединение с сервером. Если соединение защищено, то клиент запрашивает у сервера сертификат. Как вы уже знаете из этой главы, сертификат содержит два важных элемента информации: название сервера и его открытый ключ.Смысл в том, чтобы клиент мог выяснить, стоит ли доверять серверу. Клиент проверяет, подписан ли сертификат сервера доверенным ЦС, что служит подтверждением: серверу можно доверять, клиент может использовать открытый ключ сервера для шифрования отправляемых серверу сообщений. Клиент и сервер приходят к соглашению относительно симметричного ключа, который будет применяться для дальнейших сообщений, передаваемых по этому соединению, — быстродействие при этом выше, чем при использовании асимметричной пары «открытый/секретный ключ».
Процедура установления связи TLS
Вероятно, вам встречался термин «пропуск проверки» (skip verify). Он описывает вариант, когда клиент на транспортном уровне пропускает проверку, был ли сертификат подписан известным ему ЦС. Клиент при этом просто предполагает, что сервер — тот, за кого себя выдает. Это удобно при разработке, поскольку можно не тратить усилия на то, чтобы настроить клиент, задать на нем информацию о центрах сертификации, и можно просто использовать самоподписанные сертификаты. При этом обмен информацией между компонентами все равно остается зашифрованным, но нет уверенности, что эти компоненты не «самозванцы», поэтому не используйте вариант пропуска проверки сертификатов в промышленной эксплуатации!
Проверив подлинность сервера, клиент может ему доверять. Но может ли этот сервер доверять данному клиенту?
Если речь идет о сайте, на котором у вас есть учетная запись, например о сайте банка, то важно, чтобы сервер проверял, с кем имеет дело, перед выдачей, скажем, информации о состоянии банковского счета. При настоящей связи «клиент — сервер» наподобие входа на сайт банка эта задача решается с помощью аутентификации на уровне 7. Вы указываете имя пользователя и пароль, возможно, с многофакторной аутентификацией в виде ввода кода, отправленного в текстовом сообщении, или одноразового пароля, сгенерированного Yubikey или мобильным приложением — Authy, 1Password или Google Auth.
Еще один способ подтвердить «личность» клиента — воспользоваться еще одним сертификатом X.509.
### Отзыв сертификатов
Представьте, что злоумышленник каким-то образом раздобыл секретный ключ. Теперь он может выдавать себя за того, кому принадлежит этот ключ, поскольку может расшифровывать сообщения, зашифрованные открытым ключом, вложенным в соответствующие сертификаты. Чтобы это предотвратить, необходимо иметь способ немедленно аннулировать сертификаты, а не ждать истечения срока их действия.
Подобное аннулирование называется отзывом сертификатов (certificate revocation), для него используется специальный список отозванных сертификатов (certificate revocation list, CRL), содержащий сертификаты, которые более не следует принимать.
Старайтесь не задействовать субъекты (и их сертификаты) сразу для нескольких компонентов и пользователей. Возможно, создание субъектов и сертификатов для каждого компонента требует дополнительных усилий, но позволяет отзывать сертификаты субъектов по отдельности, не генерируя заново сертификаты для всех остальных (нормальных) пользователей. Вдобавок дает возможность разделять ответственность, предоставляя каждому субъекту свой набор прав.