Шрифт:
Закладка:
DNSSEC поддерживает и некоторые другие типы записей. Так, для хранения сертификатов (например, стандарта X.509) можно использовать запись CERT. Зачем она нужна? Дело в том, что некоторые хотят превратить DNS в PKI. Случится это на самом деле или нет, пока неизвестно. На этом мы заканчиваем обсуждение DNSSEC. Более подробную информацию вы можете найти в спецификациях RFC.
8.12.3. Протокол TLS
Защита имен ресурсов — неплохое начало, но веб-безопасность этим не исчерпывается. Теперь мы поговорим об установлении защищенных соединений. Это довольно сложная тема (как и все связанное с безопасностью).
Когда веб-технологии стали достоянием общественности, их применяли для распространения статических страниц. Но вскоре некоторые компании задумались об использовании Всемирной паутины для выполнения финансовых транзакций, таких как покупка товаров по кредитным картам, онлайновые банковские операции, электронная торговля ценными бумагами. Для этого требовались защищенные соединения, поэтому в 1995 году компания Netscape Communications, на тот момент доминирующий на рынке разработчик браузера, представила пакет безопасности SSL (Secure Sockets Layer — уровень защищенных сокетов). Теперь он называется TLS (Transport Layer Security — защита транспортного уровня). Сегодня это программное обеспечение вместе с соответствующим протоколом получило широкое распространение (в частности, оно используется в браузерах Firefox, Brave, Safari и Chrome), и потому его стоит рассмотреть более подробно.
Итак, SSL создает защищенное соединение между двумя сокетами, при этом обеспечивается:
1. Согласование параметров между клиентом и сервером.
2. Аутентификация сервера клиентом.
3. Конфиденциальная передача данных.
4. Защита целостности данных.
Поскольку все перечисленные пункты нам уже знакомы, мы не будем на них подробно останавливаться.
Расположение SSL в структуре типичного стека протоколов показано на илл. 8.48. Фактически между прикладным и транспортным уровнями появляется новый уровень, который принимает запросы от браузера и отсылает их TCP для передачи серверу. После установления защищенного соединения основная задача SSL заключается в обеспечении сжатия и шифрования. При использовании протокола HTTP поверх SSL он называется HTTPS (Secure HTTP — защищенный HTTP), хотя по сути это тот же HTTP. Правда, часто доступ осуществляется через новый порт (443) вместо стандартного (80). К слову, SSL используется не только в веб-браузерах, хотя это самое распространенное применение. Также он обеспечивает взаимную аутентификацию.
Прикладной (HTTP)
Защиты (SSL)
Транспортный (TCP)
Сетевой (IP)
Канальный (PPP)
Физический (модемное соединение, ADSL, кабельное ТВ)
Илл. 8.48. Уровни (и протоколы), используемые обычным домашним браузером с SSL
Существует несколько версий протокола SSL. Ниже мы обсудим только версию 3, так как она является самой популярной. SSL предусматривает множество различных вариантов: с наличием или отсутствием сжатия, тем или иным алгоритмом шифрования, а также инструментами ограничения экспорта в криптографии. Последнее в основном предназначено для того, чтобы убедиться в корректном применении серьезного шифрования. Его можно использовать, только если данные передаются в пределах США. В иных случаях длину ключа ограничивают 40 битами, что криптографы воспринимают как насмешку. Но Netscape была вынуждена ввести это ограничение, чтобы получить лицензию на экспорт от правительства США.
SSL состоит из двух подпротоколов, один из которых предназначен для установления защищенного соединения, а второй — для его использования. Рассмотрим первый подпротокол (илл. 8.49). Все начинается с сообщения 1, в котором Алиса отправляет Бобу запрос на установление соединения. В запросе указывается версия SSL, а также предпочтения Алисы относительно сжатия и алгоритмов шифрования. Также в нем содержится нонс RA, который будет применен впоследствии.
Илл. 8.49. Упрощенный вариант подпротокола SSL установления соединения
Теперь очередь Боба. Он выбирает один из алгоритмов, поддерживаемых Алисой, и отсылает собственный нонс RB (сообщение 2). Затем он отправляет сертификат со своим открытым ключом (сообщение 3). Если сертификат не подписан какой-нибудь уважаемой организацией, Боб отсылает цепочку сертификатов, по которым Алиса может убедиться, что его сертификату действительно можно доверять. Все браузеры, включая тот, что установлен у Алисы, изначально снабжаются примерно сотней открытых ключей. Если среди присланных Бобом сертификатов встретится один из этих ключей, Алиса сможет восстановить по нему ключ Боба и проверить его. В этот момент Боб может прислать и другие сообщения (например, запрос на получение сертификата Алисы с ее открытым ключом). После выполнения своей части протокола Боб отправляет сообщение 4, в котором говорит, что настала очередь Алисы.
Алиса отвечает Бобу случайно выбранным 384-разрядным подготовительным ключом (premaster key), который она зашифровала открытым ключом Боба (сообщение 5). Действующий ключ сеанса вычисляется при помощи подготовительного ключа и нонсов обеих сторон. Это достаточно сложная процедура. После получения сообщения 5 оба собеседника могут вычислить ключ сеанса. Для этого Алиса просит Боба переключиться на новый шифр (сообщение 6), а также сообщает, что она считает подпротокол установления соединения оконченным (сообщение 7). Боб соглашается с ней (сообщения 8 и 9).
Несмотря на то что Алиса знает, кто такой Боб, сам Боб Алису не знает (если только у нее нет открытого ключа и сертификата к нему, что довольно необычно для физического лица). Поэтому первым сообщением Боба вполне может быть просьба войти в систему, используя полученные ранее имя пользователя и пароль. Впрочем, протокол входа находится за рамками SSL. Так или иначе, по окончании этой серии запросов-подтверждений можно переходить к передаче данных.
Как уже говорилось, SSL поддерживает многочисленные криптографические алгоритмы. Один из них использует для шифрования тройной DES с тремя отдельными ключами и SHA для обеспечения целостности сообщений. Эта комбинация алгоритмов работает довольно медленно, поэтому ее использовали в основном при выполнении банковских операций и в других случаях, требующих высокого уровня защиты. Для шифрования данных в обычных приложениях электронной коммерции применялся алгоритм RC4 с 128-разрядным ключом, а для аутентификации сообщений — алгоритм MD5. В качестве исходных данных RC4 использует 128-разрядный ключ, который значительно увеличивается в процессе работы алгоритма. С помощью этого внутреннего числа генерируется ключевой поток, который затем суммируется по модулю 2 с открытым текстом. В результате получается обычный потоковый шифр (см. илл. 8.18). В экспортных версиях также используется алгоритм RC4 со 128-разрядными ключами, но при этом 88 разрядов являются открытыми, что позволяет достаточно легко взломать шифр.
Для передачи данных используется второй подпротокол (илл. 8.50). Поступающие от браузера сообщения разбиваются на единицы данных размером
Илл. 8.50. Передача данных с использованием SSL
до 16 Кбайт. Если включено сжатие, то каждая единица сжимается отдельно. Далее по двум нонсам и подготовительному ключу вычисляется закрытый ключ, который объединяется со сжатым текстом. Результат
