DNSsec поддерживает и некоторые другие типы записей. Так, для хранения сертификатов (например, стандарта X.509) можно использовать запись CERT. Зачем нужна такая запись? Дело в том, что есть желающие превратить DNS в инфраструктуру PKI. Случится это на самом деле или нет, пока еще неизвестно. На этом мы заканчиваем обсуждение DNSsec. Более подробную информацию вы найдете в RFC 2535.
8.9.3. SSL — протокол защищенных сокетов
Ну, что ж, защита имен ресурсов — это неплохое начало, однако этим не обеспечивается в полной мере безопасность во Всемирной паутине. Следующий шаг состоит в установлении безопасных соединений. Сейчас мы рассмотрим, как это делается. Все, что связано с безопасностью, — сложно, и эта тема не исключение.
Когда веб-технологии были впервые представлены широкой публике, они использовались для распространения статических страниц. Однако еще давным-давно некоторые компании задумались об использовании Всемирной паутины для выполнения финансовых транзакций, таких как покупка товаров по кредитным картам, онлайновые банковские операции, электронная торговля ценными бумагами. Для таких приложений требовалась организация защищенных соединений. В 1995 году тогдашний лидер среди производителей браузеров, корпорация Netscape Communications, в ответ на это представила систему безопасности под названием SSL (Secure Sockets Layer — протокол защищенных сокетов). Соответствующее программное обеспечение, как и сам протокол, в наше время используется очень широко (в том числе программами Firefox, Safari, Internet Explorer), поэтому стоит рассмотреть SSL более детально.
Итак, SSL создает защищенное соединение между двумя сокетами, позволяющее:
1) клиенту и серверу договориться об используемых параметрах;
2) провести аутентификацию сервера клиентом;
3) организовать тайное общение;
4) обеспечить защиту целостности данных.
Все перечисленные пункты нам уже знакомы, поэтому мы не будем их комментировать.
Расположение SSL в структуре обычного стека протоколов показано на рис. 8.44. По сути дела, между прикладным и транспортным уровнями появляется новый уровень, принимающий запросы от браузера и отсылающий их по TCP для передачи серверу. После установки защищенного соединения основная задача SSL заключается в поддержке сжатия и шифрования. Если поверх SSL используется HTTP, этот вариант называется HTTPS (Secure HTTP — защищенный HTTP), несмотря на то что это обычный протокол HTTP. Впрочем, возможно и отличие: скажем, доступ может осуществляться через новый порт (443) вместо стандартного (80). Кстати говоря, область применения SSL не ограничивается исключительно веб-браузерами, но это наиболее распространенное применение. Он также может обеспечивать взаимную аутентификацию.
Существует несколько версий протокола SSL. Ниже мы будем обсуждать только версию 3, так она распространена наиболее широко. SSL может обладать разными дополнительными функциями, среди которых наличие или отсутствие сжатия, тот или иной алгоритм шифрования, а также некоторые вещи, связанные с ограничениями экспорта в криптографии. Последнее в основном предназначено для того, чтобы можно было удостовериться, что серьезная криптография используется лишь тогда, когда оба конца соединения находятся в США. В других случаях длину ключа ограничивают 40 битами, что криптографы воспринимают как своего рода шутку. Однако Netscape должна была ввести это ограничение, чтобы получить лицензию на экспорт от правительства США.
SSL состоит из двух субпротоколов, один из которых предназначен для установления защищенного соединения, а второй — для использования этого соединения. Начнем с рассмотрения вопроса установления соединения. Работа субпротокола, занимающегося этим, показана на рис. 8.44. Все начинается с сообщения 1, в котором Алиса посылает Бобу запрос на установку соединения. В нем указывается версия SSL,
а также предпочтения Алисы относительно сжатия и алгоритмов шифрования. Также в нем содержится нонс RA, который будет использован впоследствии.
Рис 8.44. Уровни (и протоколы), используемые обычным домашним браузером с SSL
Теперь наступает очередь Боба. В сообщении 2 он выбирает один из алгоритмов, поддерживаемых Алисой, и посылает собственный нонс RB. В сообщении 3 он отсылает сертификат со своим открытым ключом. Если сертификат не подписан какой-нибудь уважаемой организацией, он также отправляет цепочку сертификатов, по которым Алиса может удостовериться в том, что сертификату Боба действительно можно доверять. Все браузеры, включая тот, что установлен у Алисы, изначально снабжаются примерно сотней открытых ключей, поэтому если среди присланных Бобом сертификатов встретится один из этих ключей, Алиса сможет по нему восстановить ключ Боба и проверить его. В этот момент Боб может прислать и другие сообщения (например, запрос на получение сертификата Алисы с ее открытым ключом). После окончания выполнения своей части протокола Боб посылает сообщение 4, в котором говорит, что настала очередь Алисы.
Алиса в ответ выбирает 384-разрядный подготовительный ключ (premaster key)
и посылает его Бобу, зашифровав предварительно своим открытым ключом (сообщение 5). Настоящий ключ сеанса вычисляется при помощи подготовительного ключа и нонсов обеих сторон. Это достаточно сложная процедура. После получения сообщения 5 и Алиса, и Боб могут вычислить ключ сеанса. Для этого Алиса просит Боба переключиться на новый шифр (сообщение 6), а также сообщает о том, что она считает субпротокол установления соединения оконченным (сообщение 7). Боб соглашается с ней (сообщения 8 и 9).
Однако, несмотря на то что Алиса знает, кто такой Боб, последний Алису не знает (если только у нее нет открытого ключа и сертификата к нему, что довольно необычно для обычного физического лица). Поэтому первым сообщением для Алисы запросто может оказаться просьба пройти регистрацию, используя полученные ранее имя пользователя и пароль. Впрочем, протокол регистрации в системе выходит за область полномочий SSL. Так или иначе, по окончании этой серии запросов-подтверждений может начинаться передача данных.
Рис. 8.45. Упрощенный вариант субпротокола SSL установления соединения
Как уже говорилось, SSL поддерживает разнообразные криптографические алгоритмы. Наиболее сильный из них использует для шифрования тройной DES с тремя отдельными ключами и SHA-1 для обеспечения целостности данных. Такое сочетание алгоритмов работает довольно медленно, поэтому применяется в основном при выполнении банковских операций и в других приложениях, в которых требуется высокий уровень защиты. В обычных приложениях электронной коммерции для шифрования применяется RC4 с 128-разрядным ключом, а для аутентификации — MD5. В качестве исходных данных RC4 передается 128-разрядный ключ, который разрастается во много раз при работе алгоритма. Это внутреннее число используется для создания ключевого потока. Последний суммируется по модулю 2 с открытым текстом, в результате чего получается обычный потоковый шифр, как было показано на рис. 8.12. Экспортные версии алгоритма также работают с алгоритмом RC4 и 128-разрядным ключом, однако 88 из этих разрядов делаются открытыми, что позволяет довольно быстро взломать шифр.
Для реальной передачи данных используется второй субпротокол, показанный на рис. 8.46. Сообщения, поступающие от браузера, разбиваются на единицы данных размером до 16 Кбайт. Если сжатие данных включено, каждая из этих единиц независимо сжимается. Затем по двум нонсам и подготовительному ключу вычисляется закрытый ключ, который объединяется со сжатым текстом, и результат хэшируется по согласованному алгоритму (чаще всего MD5). Хэш добавляется к каждому фрагменту в виде MAC (Message Authetication Code — код аутентификации сообщения). Этот сжатый фрагмент вместе с MAC кодируется согласованным алгоритмом с симметричным ключом (обычно это суммирование по модулю 2 с ключевым потоком RC4). Наконец, присоединяется заголовок фрагмента, и фрагмент передается по TCP-соединению.
