Московский государственный университет имени М.В.Ломоносова
Опубликован: 21.09.2006 | Доступ: свободный | Студентов: 5053 / 926 | Оценка: 4.32 / 4.09 | Длительность: 19:19:00
ISBN: 978-5-9556-0076-0
Лекция 11:

Технологии аутентификации и шифрования

SSL/TLS

Протоколы SSL и TLS обеспечивают аутентификацию сервера и клиента и шифрование соединений. SSL был впервые введен компанией Netscape Communication в 1994 году и дважды пересматривался (последней версией SSL является версия 3). В 1996 году IETF основало рабочую группу TLS, чтобы определить протокол SSL в качестве стандарта Интернета. Протокол TLS версии 1.0 специфицирован в RFC 2246 в 1999 году и основывается на SSL версии 3. Можно считать, что SSL версии 3 и TLS версии 1 идентичны, поэтому они будут обсуждаться вместе. Протоколы TCP/IP управляют транспортом и роутингом данных в Интернете. Протоколы прикладного уровня, такие как НТТР, LDAP, IMAP, выполняются поверх TCP. SSL/TLS расположен между протоколом ТСР и протоколами прикладного уровня.

Возможности SSL/TLS

SSL/TLS обеспечивает следующие возможности.

  • Аутентификация сервераSSL/TLS позволяет web-клиенту убедиться в идентификации сервера. Поддерживающие SSL/TLS клиенты могут использовать стандартные технологии криптографии с открытым ключом для проверки имени сервера и открытого ключа, содержащихся в действительном сертификате, выпущенном СА, который перечислен в списке доверенных САs. Эта проверка может быть важна, если, например, пользователь посылает номер кредитной карты по сети и хочет иметь подтверждение идентификации получающего сервера.
  • Аутентификация клиентаSSL/TLS позволяет web-серверу запрашивать идентификацию пользователя, используя ту же технологию, которая использовалась при аутентификации сервера. Поддерживающее SSL/TLS ПО web-сервера может убедиться, что сертификат клиента действительный и выпущен СА, перечисленном в списке доверенных САs. Это подтверждение может быть важным, если сервер, например, является банком и посылает конфиденциальную финансовую информацию потребителям, и при этом он хочет иметь подтверждение идентификации получателя.
  • Шифрование и целостность соединенияSSL/TLS может шифровать и обеспечивать целостность информации, передаваемой между клиентом и сервером. При выборе соответствующего алгоритма шифрования SSL/TLS обеспечивает высокую степень конфиденциальности. Также обеспечивается целостность данных.
Слабые места SSL/TLS

SSL/TLS присущи некоторые ограничения. Пакеты шифруются выше уровня ТСР, таким образом, информация на уровне IP не зашифрована. Хотя это и защищает передаваемые web-данные, при просмотре соединений SSL/TLS сессии можно определить как отправителя, так и получателя с помощью незашифрованной информации IP-адреса. Кроме того, SSL/TLS защищает только передаваемые данные. Он не шифрует данные, хранимые на конечных точках. Таким образом, при хранении данные становятся уязвимыми (например, база данных кредитных карт), если не предприняты дополнительные гарантии на конечных точках.

SSL/TLS также уязвим для атаки "man-in-the-middle" при отсутствии аутентификации сервера или использовании им самоподписанного сертификата. В случае анонимного сервера общий секрет вырабатывается по алгоритму Диффи-Хеллмана, который уязвим для атак "man-in-the-middle". Аналогичная ситуация возникает, когда пользователь принимает сертификат сервера без проверки его действительности вручную или при отсутствии в браузере открытого ключа выпустившего сертификат СА.

При этом атакующий устанавливает одно множество ключей сессии для использования с настоящим сервером, и другое множество ключей – для использования с клиентом. Это позволяет атакующему не только читать все данные, которые передаются между клиентом и сервером, но и изменять данные без обнаружения этого. Следовательно, очень важно для пользователей понимать опасность данного типа атаки и проверять действительность сертификата, прежде, чем полагаться на безопасность SSL/TLS сессии. Данная угроза может быть понижена, если клиент доверяет сертификатам, выпущенным доверенными CAs, или самоподписанные сертификаты получены с использованием некоторых внешних механизмов. Предоставление самоподписанного сертификата может означать, что происходит атака "man-in-the-middle". Последние версии браузеров выполняют некоторые проверки автоматически, но на это нельзя полагаться во всех случаях.

Пример SSL/TLS-сессии

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

Основные шаги можно просуммировать следующим образом:

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

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

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

  • Требуемая безопасность:

    • Ценность данных.
    • Время, в течение которого используются данные: если данные используются только в течение короткого промежутка времени, то могут применяться более слабые и, как правило, более быстрые алгоритмы шифрования.
    • Возможные угрозы данным.
    • Другие меры защиты, которые уменьшают необходимость сильного шифрования. Например, использование защищенных методов коммуникаций, таких как выделенные каналы вместо Интернета.
  • Требуемое выполнение. Требование быстрого выполнения может означать необходимость дополнительных ресурсов, например, специальной криптографической аппаратуры.
  • Системные ресурсы. Наличие меньшего количества ресурсов (например, процессор, память) может привести к необходимости использовать более слабое шифрование.
  • Ограничения экспорта и импорта.
  • Схемы шифрования, поддерживаемые сервером.
  • Схемы шифрования, поддерживаемые клиентом.
Нияз Сабиров
Нияз Сабиров

Здравствуйте. А уточните, пожалуйста, по какой причине стоимость изменилась? Была стоимость в 1 рубль, стала в 9900 рублей.

Елена Сапегова
Елена Сапегова

для получения диплома нужно ли кроме теоретической части еще и практическую делать? написание самого диплома требуется?