Безопасность в интернете: как протокол TLS и набор средств PKI защищают данные

Протокол TLS — преемник более раннего протокола SSL (Secure Sockets Layer), который создан на основе его версии 3.0, разработанной компанией Netscape Communications. В настоящее время развитием стандарта TLS занимается организация IETF (Internet Engineering Task Force). 

Как и SSL, протокол TLS для аутентификации и обмена ключами при установлении соединения использует асимметричное шифрование, а для защиты конфиденциальности данных соединения — симметричное.

Симметричное шифрование

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

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

Тогда пользователь отправляет на сервер банка ключ, с помощью которого сообщение было зашифровано, что вновь открывает доступ к данным для злоумышленника. 

Этот способ шифрования называется симметричным. Он предполагает использование одного ключа для шифровки и дешифровки данных. Работает быстро и эффективно, но требует предварительного обмена ключом между компьютером и сервером, в ходе которого ключ могут перехватить.

Асимметричное шифрование

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

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

• приватный ключ надежно защищен и находится только у одного пользователя;

• публичный ключ может быть у кого угодно, на то он и публичный. 

Рассмотрим наиболее простой случай использования ассиметричного шифрования на примере настройки SSH-подключения к серверу без использования пароля.

Шаг 1. Администратор генерирует парные ключи командой ssh-keygen. Результатом ее выполнения будут два файла: id_rsa  — приватный ключ и id_rsa.pub — публичный ключ.

Шаг 2. Затем администратор отключает на сервере возможность подключения по паролю, настраивая его только по ключу. Публичный ключ он помещает внутрь директории учетной записи на сервере в файл ~/.ssh/authorized_keys.

Таким образом, теперь к серверу можно подключиться по SSH только при наличии второй части — приватного ключа.

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

То есть, если новому пользователю требуется доступ к этим же серверам, он генерирует парные ключи той же командой и передает публичный ключ администратору, который загружает его на все сервера в файл ~/.ssh/authorized_keys. 

Вернемся к примеру с авторизацией в личный кабинете на сайте или в приложении банка, но сейчас будем применять асимметричное шифрование. Если ранее использовались парные ключи, сгенерированные с помощью ssh-keygen, то для настройки защищенного соединения по https парные ключи на сервере можно создать с помощью OpenSSL — открытой криптографической библиотеки для TLS и SSL.

Шаг 1. Администратор генерирует приватный ключ и создает публичный ключ на его основе. 

Шаг 2. Пользователь, при первом подключении к сайту по протоколу HTTPS, получает его публичный ключ. При этом хакер, который прослушивает сеть, тоже получает ключ. 

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

Шаг 4. А вот сервер, получая сообщение, зашифрованное публичным ключом, расшифровывает его и получает симметричный ключ пользователя.

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

Иными словами, с помощью асимметричного шифрования симметричный ключ безопасно доставляется от пользователя к серверу. Теперь сервер и пользователь могут шифровать и расшифровывать сообщения симметричным ключом и отправлять их друг другу. Хакер будет видеть только зашифрованные сообщения и не сможет их расшифровать без симметричного ключа. Цель достигнута!

Таким образом, использование асимметричного шифрования TLS гарантирует, что соединение между двумя участниками транзакции защищено.

Однако перехват ключей пользователя в процессе передачи — не единственный способ, который хакеры могут использовать для получения конфиденциальных данных пользователя. Есть и другие — такие, от которых средствами протокола TLS не защититься. И здесь на помощь приходит набор средств PKI. 

В каком случае пригодится PKI? Представьте, что хакер намеревается получить реквизиты доступа напрямую от пользователя. Для этого он создает веб-сайт на собственном сервере, который выглядит точно также, как веб-сайт банка, и генерирует парные ключи, устанавливая защищенное соединение с браузером пользователя. Дополнительно он настраивает окружение пользователя или используемую им сеть так, чтобы перенаправлять подключения к сайту банка на свой сервер. 

Тогда происходит следующее: ничего не подозревающий пользователь заходит на сайт банка по защищенному протоколу и вводит реквизиты доступа от своего аккаунта. Браузер пользователя получает публичный ключ сервера и шифрует им симметричный ключ пользователя, а затем отправляет его серверу. Сервер расшифровывает сообщение своим приватным ключом и получает симметричный ключ пользователя. 

При этом, хоть соединение и защищено, но так как общение происходит с сервером хакера, то злоумышленник получает доступ к личному кабинету пользователя.

Как вовремя распознать поддельный сайт и не оказаться обманутым? Рассмотрим ответы на самые частые вопросы, которые могут возникать при передаче данных по сети. 

Как убедиться, что публичный ключ сервера легитимен?

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

Посмотреть информацию о сертификате можно через браузер или с помощью сторонних сервисов, например, используя SSL Shopper.

Говоря подробнее, в сертификате обязательно будет указано доменное имя сайта, его псевдонимы (SANs), срок действия сертификата, а также его серийный номер и издатель. 

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

Что делать, чтобы создать легитимный сертификат? 

Легитимный сертификат — это сертификат, подписанный центром сертификации. То есть общеизвестной компанией, специализирующейся на выпуске и подписке сертификатов. Например, GlobalSign, Comodo, DigiCert.

Например, чтобы выпустить легитимный сертификат банка, нужно:

Шаг 1. Через OpenSSL сгенерировать запрос на сертификат (Certificate Signing Request, CSR) и направить его центру сертификации.

Шаг 2. Дождаться проверки сертификата сертификационным центром.

Шаг 3. После успешной проверки получить подписанный сертификат от сертификационного центра.

Кстати, в облаке личный SSL-сертификат можно легко добавить к своему CDN-ресурсу. А еще выпустить для него бесплатный SSL-сертификат Let’s Encrypt.

CDN — быстрая сеть доставки контента по всему миру

Ускоряйте доставку контента, улучшайте пользовательский опыт и показатели SEO, снижайте нагрузку на основные серверы

Как проверить, что сам центр сертификации — не подделка?

Чтобы проверить подлинность центра сертификации, стоит вспомнить о том, что каждый из действительных центров имеет свой собственный публичный и приватный ключи:

• приватный ключ используется для подписания сертификатов;

• публичный ключ публикуется в сети, чтобы разработчики браузеров могли добавлять его в свои браузеры. 

Проверить добавленные публичные ключи можно в используемом браузере. 

Для этого нужно:

• Перейти в настройки браузера и найти раздел, связанный с безопасностью или конфиденциальностью. В зависимости от браузера, это может быть раздел Безопасность, Конфиденциальность и безопасность или Настройки. 

• Найти пункт, отвечающий за управление сертификатами, например, Настроить сертификаты или Управление сертификатами. 

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

Что поможет банку или любой другой организации понять, что запросы делает хакер, а не реальный клиент?

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

То есть, чтобы наверняка знать, что запрос поступил от клиента, а не хакера, владельцы ресурсов внедряют: 

• Двухфакторную аутентификацию (2FA). Позволит запрашивать у клиента дополнительный код, отправляемый по SMS или на почту.

• Биометрическую аутентификацию. Даст возможность подтверждать личность через проверку отпечатков пальцев, распознавание лица или голоса. 

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

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

• Для настройки защищенного подключения к серверу по протоколу HTTPS требуется SSL-сертификат, подписанный сертификационный центром. Для его получения администратор формирует CSR-запрос и направляет его центру сертификации.

• При получении CSR-запроса центр сертификации проверяет, является ли отправитель запроса владельцем доменного имени сайта, указанного в CSR-запросе. После успешного прохождения проверки выпускает сертификат для домена и отправляет его администратору.

• Администратор настраивает на сервере доступ к сайту по защищенному протоколу с помощью публичного ключа полученного SSL-сертификата и приватного ключа, сгенерированного при создании CSR-запроса.

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

• Пользователь, а точнее его браузер, проверяет, кем был выпущен сертификат через публичный ключ сертификационного центра, который сохранен в браузере. Затем браузер генерирует симметричный ключ, шифрует его публичным ключом сервера и отправляет его серверу.

• Сервер использует приватный ключ от SSL-сертификата и расшифровывает сообщение, получив симметричный ключ пользователя (его браузера).

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