Как работает SSL? Я только что понял, что у нас на самом деле нет окончательного ответа на этот вопрос, и это стоит обсудить.

Мне бы хотелось увидеть подробности в следующих аспектах:

• Высокий уровень описания протокола.
• Как работает обмен ключами.
• Как обеспечивается подлинность, целостность и конфиденциальность.
• Какова цель наличия ЦП и как они выдают сертификаты.
• Детали любых важных технологий и стандартов (например, PKCS), которые участвуют.

Общее

SSL (и его преемник, TLS) — это протокол, который работает непосредственно поверх TCP (хотя существуют реализация и для протоколов на основе датаграм, таких как UDP). Таким образом, протоколы верхних уровней (например, HTTP) могут оставаться неизменными, обеспечивая при этом защищенное соединение. Под слоем SSL HTTP идентичен HTTPS.

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

В типичных условиях злоумышленник также сможет выяснить, к какому имени хоста вы подключаетесь (но не всю URL-адрес): хотя HTTPS не раскрывает само имя хоста, ваш браузер обычно должен сначала выполнить DNS-запрос, чтобы узнать, на какой IP-адрес отправить запрос.

Высокий уровень описания протокола

После установки TCP-соединения клиент начинает процедуру рукопожатия SSL. Клиент (который может быть браузером, а также любой другой программой, такой как Windows Update или Thunderbird) отправляет ряд спецификаций:

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

Сервер определяет наивысшую версию SSL/TLS, поддерживаемую как им, так и клиентом, выбирает шифр из предложенных клиентом (если он поддерживает один из них) и, при желании, выбирает метод сжатия.

После этого базовая настройка завершена, сервер отправляет свой сертификат. Этот сертификат должен быть доверен либо самим клиентом, либо стороной, которой доверяет клиент. Например, если клиент доверяет GeoTrust, то клиент может доверять сертификату от Google.com, потому что GeoTrust криптографически подписал сертификат Google.

После подтверждения подлинности сертификата и уверенности в том, что этот сервер действительно тот, за кого он себя выдает (а не это третье лицо), происходит обмен ключами. Это может быть открытый ключ, “PreMasterSecret” или просто ничего, в зависимости от выбранного шифра. Теперь как сервер, так и клиент могут вычислить ключ для симметричного шифрования ^{почему не PKE?}. Клиент сообщает серверу, что с этого момента все коммуникации будут зашифрованы, и отправляет зашифрованное и аутентифицированное сообщение серверу.

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

Рукопожатие завершено, и два хоста могут безопасно обмениваться данными. Для получения дополнительной информации смотрите technet.microsoft.com/en-us/library/cc785811 и en.wikipedia.org/wiki/Secure_Sockets_Layer.

Для закрытия соединения используется сигнал close_notify. Если злоумышленник попытаться прервать соединение, завершив TCP-соединение (вставив пакет FIN), обе стороны будут знать, что соединение было неправомерно завершено. Тем не менее, соединение не может быть скомпрометировано таким образом, оно только будет прервано.

Некоторые дополнительные детали

Почему вы можете доверять Google.com, доверяя GeoTrust?

Сайт хочет общаться с вами безопасно. Чтобы доказать свою личность и убедиться, что он не является злоумышленником, у вас должен быть открытый ключ сервера. Однако вы вряд ли сможете хранить все ключи от всех сайтов на Земле, база данных была бы огромной, и обновления должны были бы выполняться каждый час!

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

Когда сервер Google отправляет вам свой сертификат, он также упоминает, что он подписан GeoTrust. Если вы доверяете GeoTrust, вы можете проверить (с помощью открытого ключа GeoTrust), что GeoTrust действительно подписал сертификат сервера. Чтобы самостоятельно подписать сертификат, вам нужен закрытый ключ, который известен только GeoTrust. Таким образом, злоумышленник не может сам подписать сертификат и неправильно заявить, что он является Google.com. Когда сертификат модифицируется хотя бы на один бит, подпись будет неверной, и клиент отклонит ее.

Так если я знаю открытый ключ, сервер может доказать свою личность?

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

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

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

Но ЦП могут заставить меня доверять любому серверу, который они хотят!

Да, и вот здесь начинается доверие. Вы должны доверять ЦП, чтобы они не выдавали сертификаты по своему усмотрению. Однако когда такие организации, как Microsoft, Apple и Mozilla доверяют ЦП, у ЦП должны быть аудиты; другая организация периодически проверяет их, чтобы убедиться, что все по-прежнему идет по правилам.

Выдача сертификата осуществляется только в том случае, если регистрант может доказать, что он владеет доменом, для которого выдан сертификат.

Каков этот MAC для аутентификации сообщения?

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

Например, с ключом “correct horse battery staple” и сообщением “example”, я могу вычислить MAC “58393”. Когда я отправляю это сообщение с MAC вам (вы уже знаете ключ), вы можете произвести то же самое вычисление и сопоставить вычисленный MAC с тем, который я отправил.

Злоумышленник может изменить сообщение, но не знает ключа. Он не сможет вычислить правильный MAC, и вы узнаете, что сообщение не аутентично.

Включив номер последовательности при вычислении MAC, вы можете устранить атаки повторов. SSL делает это.

Вы сказали, что клиент отправляет ключ, который затем используется для установки симметричного шифрования. Что мешает злоумышленнику его использовать?

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

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

Как взломать SSL

В кратком изложении:

• Проверьте, игнорирует ли пользователь предупреждения о сертификате;
• Приложение может загружать данные из незашифрованного канала (например, HTTP), что может быть подделано;
• Незащищенная страница входа, которая отправляется на HTTPS, может быть изменена так, чтобы отправляться на HTTP;
• Необновленные приложения могут быть уязвимы к таким уязвимостям, как BEAST и CRIME;
• Используйте другие методы, такие как физическая атака;
• Эксплуатируйте боковые каналы, такие как длина сообщения и время, необходимое для формирования сообщения;
• Ждите квантовые атаки.

Смотрите также: Схема с множеством векторов атаки на SSL от Ивана Ристича ^(png)

Подробно:

Нет простого и понятного способа; SSL безопасен, если его правильно использовать. Однако злоумышленник может попробовать, игнорирует ли пользователь предупреждения о сертификате, что моментально нарушило бы безопасность. Когда пользователь это делает, злоумышленнику не нужен закрытый ключ от ЦП, чтобы подделать сертификат, ему просто нужно отправить сертификат своего собственного.

Другой способ — это ошибка в приложении (со стороны сервера или клиента). Простым примером являются веб-сайты: если один из ресурсов, используемых сайтом (например, изображение или скрипт), загружается через HTTP, конфиденциальность больше не может быть гарантирована. Несмотря на то, что браузеры не отправляют HTTP Referer заголовок при запросе незащищенных ресурсов с защищенной страницы (источник), все еще возможно для кого-то, прослушивающего трафик, угадать, откуда вы пришли; например, если они знают, что изображения X, Y и Z используются на одной странице, они могут предположить, что вы посещаете эту страницу, когда видят, что ваш браузер запрашивает эти три изображения одновременно. Кроме того, при загрузке Javascript вся страница может быть подвержена компрометации. Злоумышленник может выполнить любой скрипт на странице, изменив, например, то, кому будет отправлен банковский перевод.

Когда это происходит (ресурс загружается через HTTP), браузер выдаст предупреждение о смешанном содержимом: Chrome, Firefox, Internet Explorer 9

Другим трюком для HTTP является незащищенная страница входа, отправляющаяся на HTTPS. “Отлично”, – вероятно, подумал разработчик, “теперь я снимаю нагрузку с сервера, и пароль все еще отправляется шифрованным!” Проблема заключается в sslstrip, инструменте, который изменяет незащищенную страницу входа так, чтобы она отправлялась куда-то, откуда злоумышленник может прочитать ее.

В последние несколько лет также имели место различные атаки, такие как уязвимость повторного согласования TLS, sslsniff, BEAST и совсем недавно CRIME. Однако все распространенные браузеры защищены от всех этих атак, так что эти уязвимости не представляют опасности, если вы используете обновленный браузер.

Наконец, но не менее важно, вы можете прибегнуть к другим методам, чтобы получить информацию, которую SSL отказывает вам в получении. Если вы уже видите и вмешиваетесь в соединение пользователя, возможно, не так уж сложно заменить одно из его загрузок .exe на кейлоггер или просто физически атаковать этого человека. Криптография может быть довольно надежной, но люди и человеческие ошибки по-прежнему остаются слабым звеном. Согласно данным этой работы от Verizon, 10% утечек данных были связаны с физическими атаками (см. страницу 3), так что это определенно стоит учитывать.

Поскольку общий концепт SSL уже обсуждался в некоторых других вопросах (например, в этом и том), на этот раз я сосредоточусь на деталях. Подробности важны. Этот ответ будет несколько многословным.

История

SSL — это протокол с долгой историей и несколькими версиями. Первые прототипы были разработаны компанией Netscape, когда они разрабатывали первые версии своего флагманского браузера, Netscape Navigator (этот браузер убил Mosaic в ранние времена Браузерных войн, которые все еще продолжаются, хотя теперь с новыми конкурентами). Версия 1 никогда не была обнародована, и мы не знаем, как она выглядела. Версия SSL 2 описана в черновике, который можно прочитать здесь; у нее есть ряд уязвимостей, некоторые из которых довольно серьезные, поэтому она считается устаревшей, и новые реализации SSL/TLS не поддерживают ее (в то время как старые отключены по умолчанию). Я не буду говорить о SSL версии 2 далее, кроме как как об эпизодической справке.

SSL версии 3 (которую я буду называть “SSLv3”) был усовершенствованным протоколом, который до сих пор работает и широко поддерживается. Хотя он все еще является собственностью Netscape Communications (или того, кто сейчас ее владеет), протокол был опубликован как “исторический RFC” (RFC 6101). Тем временем, протокол был стандартизирован, с новым именем, чтобы избежать юридических проблем; новое имя – TLS.

До сих пор были запущены три версии TLS, каждая с собственным RFC: TLS 1.0, TLS 1.1 и TLS 1.2. Они внутренне очень похожи друг на друга и на SSLv3, до такой степени, что реализация может легко поддерживать SSLv3 и все три версии TLS с использованием как минимум 95% общего кода. Тем не менее, внутренне все версии обозначаются номером версии в формате major.minor; SSLv3 это 3.0, в то время как версии TLS, соответственно, 3.1, 3.2 и 3.3. Таким образом, неудивительно, что TLS 1.0 иногда называют SSL 3.1 (и это не неверно). SSL 3.0 и TLS 1.0 отличаются лишь несколькими незначительными деталями.
TLS 1.1 и 1.2 еще не широко поддерживаются, хотя есть инициатива для этого, из-за возможных уязвимостей (см. ниже, по атаке “BEAST”). SSLv3 и TLS 1.0 поддерживаются “везде” (даже IE 6.0 знает их).

Контекст

SSL направлен на предоставление безопасного двунаправленного канала для произвольных данных. Рассмотрим TCP, хорошо известный протокол для передачи данных через Интернет. TCP работает с IP “пакетами” и обеспечивает двунаправленный туннель для байтов; он работает для всех значений байтов и отправляет их в два потока, которые могут работать одновременно. TCP выполняет тяжелую работу по разбиению данных на пакеты, их подтверждению, сбору обратно в правильном порядке, удаляя дубликаты и повторно отправляя потерянные пакеты. С точки зрения приложения, которое использует TCP, есть только два потока, и пакеты невидимы; в частности, потоки не разбиваются на “сообщения” (это зависит от приложения, если оно хочет установить свои собственные правила кодирования, чтобы иметь сообщения, и это именно то, что HTTP делает).

TCP надежен в случае “несчастных случаев”, т.е. ошибок передачи из-за ненадежного оборудования, перегрузки сети, людей со смартфонами, которые выходят за пределы радиуса действия данной базовой станции, и других не злонамеренных событий. Однако злонамеренный человек (злоумышленник), имеющий доступ к транспортным средствам, может читать все переданные данные и/или намеренно изменять их, и TCP против этого не защищает. Вот почему нужен SSL.

SSL предполагает, что он работает поверх протокола, подобного TCP, который обеспечивает надежный поток; SSL не реализует повторную отправку потерянных пакетов и прочие такие вещи. Предполагается, что злоумышленник может полностью нарушить связь незаменимым образом (например, он может перерезать кабели), и задача SSL состоит в том, чтобы:

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

SSL в значительной степени (но не абсолютно) выполняет эти цели.

Записи

SSL имеет многослойную структуру, и нижний уровень — это протокол записи. Любые данные, отправляемые в SSL-канале, разбиваются на записи. В сети (в подлежащем TCP-сокете или TCP-подобной среде) запись выглядит следующим образом:

HH V1:V2 L1:L2 данные

где:

• HH — это один байт, который указывает тип данных в записи. Определено четыре типа: change_cipher_spec (20), alert (21), handshake (22) и application_data (23).
• V1:V2 — это версия протокола, состоящая из двух байтов. Для всех в настоящее время определенных версий V1 имеет значение 0x03, в то время как V2 имеет значение 0x00 для SSLv3, 0x01 для TLS 1.0, 0x02 для TLS 1.1 и 0x03 для TLS 1.2.
• L1:L2 — это длина данных в байтах (используется соглашение big-endian: длина равна 256*L1+L2). Общая длина данных не может превышать 18432 байт, но на практике она даже не может достичь этого значения.

Таким образом, запись имеет пятибайтовый заголовок, за которым следует максимум 18 кБ данных. Данные — это место, где применяются симметричное шифрование и проверки целостности. Когда запись отправляется, и отправитель и получатель должны согласовать, какие криптографические алгоритмы в настоящее время применяются, и с какими ключами; это согласие достигается через протокол рукопожатия, описанный в следующем разделе. Сжатие, если таковое имеется, также применяется в этот момент.

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

• Изначально есть несколько байтов для передачи; это — данные приложения или какие-то другие байты. Этот нагрузка состоит максимум из 16384 байтов, но может быть и меньше (нагрузка длиной 0 является законной, но оказывается, что Internet Explorer 6.0 совсем не любил этого).
• Нагрузка затем сжимается с помощью любого алгоритма сжатия, который в настоящее время был согласован. Сжатие является зависимым от состояния и таким образом может зависеть от содержания предыдущих записей. На практике, сжатие — это либо “нулевое” (абсолютно никакого сжатия), либо “Deflate” (RFC 3749), последний сейчас вежливо, но решительно показывают выходную дверь в контексте Интернета, из-за недавней атаки CRIME. Сжатие направлено на уменьшение размеров данных, но оно обязательно немного увеличивает их в некоторых неблагоприятных ситуациях (из-за принципа детской ниши). SSL допускает увеличение не более чем на 1024 байта. Конечно, нулевое сжатие никогда не увеличивает (но и не уменьшает); Deflate увеличит не более чем на 10 байтов, если реализация достаточно хороша.
• Сжатая нагрузка защищается от изменений и шифруется. Если текущие алгоритмы шифрования и проверки целостности “нулевые”, то этот шаг является операцией “без действия”. В противном случае добавляется MAC, затем некоторое дополнение (в зависимости от алгоритма шифрования), и результат шифруется. Эти шаги снова приводят к некоторому увеличению, что стандарт SSL ограничивает до 1024 дополнительных байтов (вместе с максимальным увеличением из шага сжатия, это приводит нас к 18432 байтам, к которым мы должны добавить 5-байтовый заголовок).

MAC, как правило, является HMAC с одним из широко используемых хеш-функций (в основном MD5, SHA-1 или SHA-256) (с SSLv3, это не “настоящий” HMAC, но что-то очень похожее и, насколько нам известно, так же безопасно, как HMAC). Шифрование будет использовать либо блочный шифр в режиме CBC, либо потоковый шифр RC4. Обратите внимание, что, теоретически, могут быть использованы другие виды режимов или алгоритмов, например, один из этих удачных режимов, которые сочетает шифрование и проверки целостности; на самом деле, даже некоторые RFC для этого. Однако, на практике, реализованные реализации пока не знают об этом, поэтому они делают HMAC и CBC. Критически важно, что MAC сначала вычисляется и добавляется к данным, а затем результат шифруется. Это MAC-затем-шифрование, и это, на самом деле, не очень хорошая идея. MAC вычисляется по конкатенации (сжатой) нагрузки и номера последовательности, так что трудолюбивый злоумышленник не может поменять записи местами.

Рукопожатие

Рукопожатие — это протокол, который проходит внутри протокола записи. Его цель — установить алгоритмы и ключи, которые будут использоваться для записей. Он состоит из сообщений. Каждое сообщение рукопожатия начинается с 4-байтного заголовка, одного байта, описывающего тип сообщения, а затем трех байтов для длины сообщения (соглашение big-endian). Затем последовательные сообщения рукопожатия отправляются с записями, имеющими тип “рукопожатие” (первый байт заголовка каждой записи имеет значение 22).

Обратите внимание на уровни: сообщения рукопожатия, полные с 4-байтовым заголовком, затем отправляются как записи, и каждая запись также имеет свой собственный заголовок. Более того, несколько сообщений рукопожатия могут быть отправлены в одной записи, и заданное сообщение рукопожатия может быть разбито на несколько записей. С точки зрения модуля, который создает сообщения рукопожатия, “записи” — это просто поток, в котором могут быть отправлены байты; он не осведомлен о фактическом разделе этого потока на записи.

Полное рукопожатие

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

Первое сообщение рукопожатия — это ClientHello. Это сообщение, с помощью которого клиент заявляет о своем намерении сделать SSL. Обратите внимание, что “клиент” — это символическая роль; это означает “сторону, которая говорит первой”. В контексте HTTPS, который представляет собой HTTP в SSL в TCP, все три уровня имеют представление о “клиенте” и “сервере”, и все они согласны (TCP-клиент также является SSL-клиентом и HTTP-клиентом), но это скорее случайность.

Сообщение ClientHello содержит:

• максимальную версию протокола, которую клиент хочет поддерживать;
• случайное число клиента (32 байта, из которых 28 должны быть сгенерированы с помощью криптографически стойкого генератора случайных чисел);
• идентификатор сеанса (если клиент хочет возобновить сеанс в сокращенном рукопожатии, смотрите ниже);
• список “шифровальных комплектов”, которые знает клиент, упорядоченный по предпочтению клиента;
• список алгоритмов сжатия, которые знает клиент, упорядоченный по предпочтению клиента;
• некоторые дополнительные расширения.

Шифровальный комплект — это 16-битный символический идентификатор для набора криптографических алгоритмов. Например, шифровальный комплект TLS_RSA_WITH_AES_128_CBC_SHA имеет значение 0x002F и означает “записи используют HMAC/SHA-1 и AES шифрование с 128-битным ключом, а обмен ключами осуществляется путем шифрования случайного ключа с помощью открытого ключа RSA сервера”.

Сервер отвечает на сообщение ClientHello сообщением ServerHello, которое содержит:

• версия протокола, которую клиент и сервер будут использовать;
• “случайное число сервера” (32 байта, включая 28 случайных байтов);
• идентификатор сеанса для этого соединения;
• шифровальный комплект, который будет использоваться;
• алгоритм сжатия, который будет использоваться;
• опционально, некоторые расширения.

Полное рукопожатие выглядит так:

  Клиент                                               Сервер

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

(Эта схема была без стыда скопирована из RFC.)

Мы видим ClientHello и ServerHello. Затем сервер отправляет несколько других сообщений, которые зависят от шифровального набора и некоторых других параметров:

• Certificate: сертификат сервера, который содержит его открытый ключ. Подробнее об этом ниже. Это сообщение почти всегда отправляется, кроме случаев, когда шифровальный набор требует рукопожатия без сертификата.
• ServerKeyExchange: некоторые дополнительные значения для обмена ключами, если то, что в сертификате, недостаточно. В частности, шифровальные комплекты “DHE” используют эпремальный обмен ключами Диффи-Хеллмана, который требует этого сообщения.
• CertificateRequest: сообщение, запрашивающее, чтобы клиент также идентифицировался своими собственным сертификатом. Это сообщение содержит список имён доверенных центров сертификации (так называемых “корневых сертификатов”), которые сервер будет использовать для проверки сертификата клиента.
• ServerHelloDone: маркерное сообщение (длиной ноль), которое указывает, что сервер закончил, и теперь клиент должен говорить.

Клиент должен затем ответить:

• Certificate: сертификат клиента, если сервер запросил его. Между версиями имеются тонкие отличия (с SSLv3 клиент должен опустить это сообщение, если у него нет сертификата; с TLS 1.0+ в той же ситуации он должен отправить сообщение Certificate с пустым списком сертификатов).
• ClientKeyExchange: клиентская часть фактического обмена ключами (например, значение, зашифрованное с помощью ключа RSA сервера).
• CertificateVerify: цифровая подпись, вычисленная клиентом по всем предыдущим сообщениям рукопожатия. Это сообщение отправляется, когда сервер запрашивал сертификат клиента, и клиент это выполнил. Таким образом, клиент доказывает серверу, что он действительно “владеет” открытым ключом, который закодирован в сертификате, который он отправил.

Затем клиент отправляет сообщение ChangeCipherSpec, которое не является сообщением рукопожатия: оно имеет свой собственный тип записи, поэтому оно будет отправлено в отдельной записи. Его содержимое чисто символическое (один байт со значением 1). Это сообщение отмечает момент, когда клиент переключается на только что согласованный шифровальный комплект и ключи. Последующие записи от клиента затем будут зашифрованы.

Сообщение Finished — это криптографическая контрольная сумма, вычисленная по всем предыдущим сообщениям рукопожатия (как от клиента, так и от сервера). Поскольку оно отправляется после ChangeCipherSpec, оно также покрыто проверкой целостности и шифрованием. Когда сервер получает это сообщение и проверяет его содержимое, он получает доказательство того, что на самом деле говорил с одним и тем же клиентом все это время. Это сообщение защищает рукопожатие от изменений (злоумышленник не может изменить сообщения рукопожатия и при этом получить правильное сообщение Finished).

Сервер в конце концов отвечает своим собственным ChangeCipherSpec, а затем Finished. В этот момент рукопожатие завершено, и клиент и сервер могут обмениваться данными приложений (в зашифрованных записях, помеченных как таковые).

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

Сокращенное рукопожатие

В полном рукопожатии сервер отправляет “идентификатор сеанса” (т.е. набор из максимума 32 байтов) клиенту. Позже клиент может вернуться и отправить тот же идентификатор сеанса в своем ClientHello. Это означает, что клиент все еще помнит шифровальный комплект и ключи из предыдущего рукопожатия и хотел бы повторно использовать эти параметры. Если сервер также помнит шифровальный комплект и ключи, то он копирует этот конкретный идентификатор сеанса в своем ServerHello, и затем следует сокращенное рукопожатие:

  Клиент                                                Сервер

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

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

Обмен ключами

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

• RSA: ключ сервера типа RSA. Клиент генерирует случайное значение (предварительный мастер-ключ длиной 48 байт, из которых 46 байт случайные) и шифрует его с помощью открытого ключа сервера. Здесь нет ServerKeyExchange.
• DHE_RSA: ключ сервера типа RSA, но используется только для подписи. Фактический обмен ключами использует Диффи-Хеллмана. Сервер отправляет ServerKeyExchange сообщение, содержащее параметры DH (модуль, генератор) и вновь сгенерированный открытый ключ DH; более того, сервер подписывает это сообщение. Клиент ответит сообщением ClientKeyExchange, которое также содержит вновь сгенерированный открытый ключ DH. DH дает “предварительный мастер-ключ”.
• DHE_DSS: как DHE_RSA, но у сервера есть ключ DSS (“DSS” также известен как ДСА). DSS — это алгоритм только для подписи.

Менее распространенные алгоритмы обмена ключами включают:

• DH: ключ сервера типа Диффи-Хеллмана (мы говорим о сертификате, который содержит ключ DH). Это было “популярно”, с административной точки зрения (федеральное правительство США предписывало его использование), когда патент на RSA все еще действовал (это было в прошлом веке). Несмотря на бюрократическое давление, он никогда не использовался так широко, как RSA.
• DH_anon: как DHE наборы, но без подписи от сервера. Это шифровальный комплект без сертификата. По конструкции он уязвим к атакам “человек посередине”, поэтому крайне редко активируется.
• PSK: шифровальные комплекты с предшествующим ключом. Симметричный обмен ключами, основанный на заранее установленном общем секрете.
• SRP: применение протокола SRP, который является протоколом аутентификации ключа. Клиент и сервер аутентифицируют друг друга по отношению к общему секрету, который может быть несложным паролем (в то время как PSK требует высокого энтропийного общего секрета). Очень интересно. Еще не широко поддерживается.
• Эпремальный RSA ключ: как DHE, но с вновь сгенерированной парой ключей RSA. Поскольку генерация RSA ключей дорогостоящая, это не популярный вариант, и был указан только как часть “экспортных” шифровальных наборов, которые соответствовали законам, ограничивающим экспорт криптографии в США в довоенные времена (т.е. RSA ключей не более чем 512 бит). В настоящее время никто этого не делает.
• Варианты алгоритмов DH* с эллиптическими кривыми. Очень модно. Должно стать общим в будущем.

Сертификаты и аутентификация

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

SSL должен использовать X.509. Это стандарт для сертификатов. Каждый сертификат подписан Центром сертификации. Идея заключается в том, что клиент с самой собой знает открытые ключи нескольких ЦП (это “документальные ключи” или “корневые сертификаты”). С использованием этих ключей клиент может проверить подпись, вычисленную ЦП по сертификату, который был выдан серверу. Этот процесс можно рекурсивно расширить: ЦП может выдавать сертификаты для других ЦП (т.е. подписывать структуру сертификата, которая содержит имя и ключ другого ЦП). Цепочка сертификатов, начинающаяся с корневого ЦП и заканчивающая сертификатом сервера, с промежуточными сертификатами ЦП между, каждый сертификат подписывается относительно открытого ключа, который закодирован в предыдущем сертификате, называется, без особой фантазии, цепочкой сертификатов.

Таким образом, клиент должен делать следующее:

• Получить цепочку сертификатов, заканчивающуюся сертификатом сервера. Сообщение Certificate от сервера должно содержать именно такую цепочку.
• Проверить цепочку, т.е. проверить все подписи и имена и различные элементы X.509. Также клиент должен проверить статус отзыва всех сертификатов в цепочке, что является сложным и трудоемким процессом (веб-браузеры сейчас делают это более или менее, но это недавняя разработка).
• Проверить, что предназначенное имя сервера действительно написано в сертификате сервера. Поскольку клиент не только хочет использовать проверенный открытый ключ, он также хочет использовать открытый ключ конкретного сервера. См. RFC 2818 для получения дополнительной информации о том, как это делается в контексте HTTPS.

Модель сертификации с сертификатами X.509 часто подвергалась критике, не столько по техническим причинам, сколько по политико-экономическим. Она концентрирует власть проверки в руках нескольких игроков, которые не обязательно являются добрыми, или, по крайней мере, не всегда компетентны. Время от времени публикуются предложения для других систем (например, Convergence или DNSSEC), но ни одно из них так и не получило широкого признания (пока).

Для аутентификации клиентов на основе сертификатов всеобщее решение за сервером, чтобы решить, что делать с сертификатом клиента (и также что делать с клиентом, который отказался предоставить сертификат). В мире Windows/IIS/Active Directory клиентский сертификат должен содержать имя учетной записи в виде “User Principal Name” (закодированное в расширении Subject Alt Name сертификата); сервер ищет это имя в своем сервере Active Directory.

Рукопожатие снова

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

В любое время клиент или сервер могут инициировать новое рукопожатие (сервер может отправить сообщение HelloRequest, чтобы инициировать его; клиент просто отправляет ClientHello). Типичная ситуация выглядит следующим образом:

• HTTPS-сервер настроен на прослушивание запросов SSL.
• Клиент подключается, и рукопожатие выполняется.
• После завершения рукопожатия клиент отправляет свои “данные приложения”, которые представляют собой HTTP-запрос. В этот момент (и только в этот момент) сервер узнает целевой путь. До этого момента URL, который клиент хочет достичь, был неизвестен серверу (сервер мог быть осведомлен о целевом имени сервера через расширение Server Name Indication SSL, но это не включает путь).
• При виде пути сервер может узнать, что это относится к части его данных, которые должны быть доступны только клиентам, аутентифицированным с помощью сертификатов. Но сервер не запрашивал сертификат клиента во время рукопожатия (в частности, потому что не так давно веб-браузеры выводили странные всплывающие окна при запросе сертификата, особенно если у них его не было, поэтому сервер бы воздерживался от запроса сертификата, если у него не было хороших причин полагать, что у клиента есть один и он знает, как его использовать).
• Поэтому сервер инициирует новое рукопожатие, на этот раз запрашивая сертификат.

В описанной ситуации имеется интересная уязвимость; смотрите RFC 5746 для обходного пути. В концептуальном смысле SSL передает характеристику безопасности только в “прямом” направлении. При выполнении нового рукопожатия любая информация о клиенте до нового рукопожатия по-прежнему действительна после (например, если клиент отправил правильное имя пользователя и пароль внутри туннеля), но не наоборот. В вышеописанной ситуации первый HTTP-запрос, который был получен до нового рукопожатия, не защищен аутентификацией на основе сертификата второго рукопожатия, и его мог выбрать злоумышленник! К сожалению, некоторые веб-серверы просто предполагали, что аутентификация клиента из второго рукопожатия распространяется на то, что было отправлено до второго рукопожатия, и это дало возможность злоумышленнику провести некоторые хитрые трюки. RFC 5746 пытается исправить это.

Опасения

Сообщения тревоги — это просто предупреждения и сообщения об ошибках. Они довольно неинтересные, за исключением того, что их можно подделать из-за некоторых атак (смотрите далее).

Существует важное сообщение тревоги, называемое close_notify: это сообщение, которое клиент или сервер отправляет, когда он хочет закрыть соединение. При получении этого сообщения сервер или клиент также должет ответить с помощью close_notify и затем считать туннель закрытым (но сеанс остается действительным и может быть повторно использован в последующем сокращенном рукопожатии). Интересная часть заключается в том, что эти сообщения тревоги такие же, как и все остальные записи, защищенные шифрованием и MAC. Таким образом, закрытие соединения охватывается криптографическим зонтом.

Это важно в контексте (старого) HTTP, где некоторые данные могут быть отправлены сервером без явной “длины содержимого”: данные продолжаются до конца транспортного потока. Старый HTTP с SSLv2 (который не имел close_notify) позволял злоумышленнику принуждать к закрытию соединения (на уровне TCP), которое клиент воспринял бы как нормальное закрытие; таким образом злоумышленник мог обрезать данные, не будучи пойманным. Это одна из проблем с SSLv2 (наверное, худшая), и SSLv3 решает ее. Обратите внимание, что “современный” HTTP использует заголовки “Content-Length” и/или кодирование по частям, которые не уязвимы к такому обрезанию, даже если уровень SSL это допускал. Тем не менее приятно знать, что SSL предлагает защиту событий закрытия.

Атаки

Существует ограничение на длину ответа Stack Exchange, поэтому описание некоторых атак на SSL будет в другом ответе (к тому же, мне нужно приготовить блины). Оставайтесь на связи.

После обширного представления SSL в предыдущем ответе, давайте перейдем к интересным вещам, а именно:

Атаки на SSL

На SSL было множество атак, некоторые основаны на ошибках реализации, другие — на действительно слабостях протокола.

Следует помнить, что хотя SSL является одним из наиболее атакуемых протоколов (поскольку он очень заметен: успешное приложение к SSL выглядит очень хорошо в аннотации исследовательской статьи), SSL также является одним из самых исправленных протоколов. Его следует считать надежным именно потому, что все известные способы атаки на транспортные протоколы были опробованы на SSL, и SSL был исправлен, где это было необходимо.

Откат версии

В ранние дни SSLv3 SSLv2 все еще широко использовался, и поэтому клиенты обычно отправляли совместимые с SSLv2 ClientHello сообщения, которые просто указывали, что SSLv3 также поддерживается; сервер затем брал это намек и отвечал на диалекте SSLv3+ (см. Приложение E RFC 2246 для получения деталей). Поскольку у SSLv2 были уязвимости, было в интересах злоумышленника организовать так, чтобы клиент и сервер, оба знающие SSLv3, тем не менее взаимодействовали друг с другом, используя SSLv2. Это называется атакой отката версии. Концепция формально распространяется и на более поздние версии.

Были добавлены колдуны, чтобы обнаруживать попытки отката. Для откатов на SSLv2 клиент, который знает SSLv3+, должен использовать специальное дополнение для шага RSA-шифрования (SSLv2 поддерживал только обмен ключами на базе RSA): в PKCS#1 данные, которые должны быть зашифрованы, должны быть дополнены набором случайных байтов; клиент, осведомленный о SSLv3, должен установить каждый из последних восьми байтов дополнения в фиксированное значение 0x03. Сервер затем проверяет эти байты; если восемь 0x03 найдены, то, вероятно, была предпринята попытка отката, и сервер отклоняет попытку (у клиента, работающего только на SSLv2, вероятность использовать такие байты дополнения исключительно из-за отсутствия удачи, что 255^-8, поэтому ложные срабатывания происходят с незначительной частотой).

Для откатов на старую версию SSL/TLS, но не старше SSLv3, была добавлена еще одна “колдовская” защита: в предварительном мастер-секрет длиной 48 байт, который клиент шифрует закрытым ключом RSA сервера, первые два байта не случайные, а должны равняться “максимально поддерживаемой версии протокола”, которую клиент записал в своем сообщении ClientHello. К сожалению, некоторые клиенты ошиблись, и эта “колдовская” защита сработает только с обменом ключами на основе RSA, так что защита от откатов там довольно ограниченная. К счастью, SSLv3+ имеет другую, гораздо более мощную защиту от откатов, которая заключается в том, что сообщения рукопожатия хэшируются вместе, когда строятся сообщения Finished. Это защищает от откатов, если “старая версия” не была бы настолько слабой, что злоумышленник мог бы полностью разрушить все шифрование до конца рукопожатия. Это еще не произошло (SSLv3 по-прежнему разумно надежен).

Слабые шифровальные комплекты

Некоторые стандартные шифровальные комплекты являются намеренно слабыми каким-то образом. Есть:

• некоторые шифровальные комплекты без какого-либо шифрования, только проверка целостности, например, TLS_RSA_WITH_NULL_SHA;
• некоторые шифровальные комплекты с 40-битным шифрованием, такие как TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (шифровальные комплекты, предназначенные для соблюдения строгих правил экспорта США с прошлого века — эти правила были в основном отменены к концу эры Билла Клинтона);
• некоторые шифровальные комплекты с 56-битным шифрованием, такие как TLS_RSA_WITH_DES_CBC_SHA. 56-битный DES поддается взлому с использованием существующей технологии, но это все еще довольно сложно для любителя (даже скучающего студента с доступом к нескольким сотням университетских машин), поэтому я склонен квалифицировать 56-битный DES как “среднюю силу”.

Это открывает дорогу для варианта атак отката версий, когда злоумышленник заставляет клиента и сервер согласиться на слабый шифровальный комплект, идея заключается в том, что злоумышленник изменяет список шифровальных комплектов, объявленный клиентом. Это выполнимо для злоумышленника, если выбранный шифровальный комплект так слаб, что он может взломать его, чтобы пересчитать кажущийся корректным Finished сообщение. На самом деле, используемый в SSLv3+ MAC (даже если он основан на MD5) достаточно надежен, чтобы предотвратить это. Поэтому здесь нет повода для беспокойства. Кроме того, на мой взгляд, любая реальная уязвимость здесь заключается в том, что клиент или сервер согласились использовать слабый шифровальный комплект вообще.

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

Кража закрытого ключа

Если SSL-соединение использует обмен ключами RSA, и злоумышленник хранит копию записей, а затем позже (возможно, через несколько месяцев, возможно, проверяя все резервные копии на выброшенных жестких дисках или кассетах) получает копию закрытого ключа, тогда он может расшифровать рукопожатие и расшифровать данные.

Идеальная Предварительная Тайна направлена на противодействие этому “позже”. Вы получаете это, используя DHE шифровальные комплекты. С шифровальным комплектом DHE фактический закрытый ключ, который может быть использован для расшифровки рукопожатия, — это эфемерный ключ Диффи-Хеллмана, а не закрытый ключ RSA (или DSS) сервера. Будучи эфемерным, он существовал только в оперативной памяти и никогда не был записан на жесткий диск; таким образом, он должен быть гораздо более устойчивым к последующей краже.

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

Проблемы с сертификатами

Вся эта проблема с сертификатами является больной темой в SSL.

Технически, SSL довольно независим от X.509. Цепочки сертификатов обмениваются как непрозрачные объекты. В какой-то момент клиент должен использовать открытый ключ сервера, но клиент свободен “знать” этот ключ любым способом, который он считает нужным. В некоторых специфических сценариях, где SSL может быть использован, клиент уже знает открытый ключ сервера (зашитый в код) и просто игнорирует сертификат, отправленный сервером. Тем не менее, в общем случае HTTPS клиент действительно проверяет цепочку сертификатов сервера, как описано в X.509 (прочитайте это на свой страх и риск; вы были предупреждены).

Это приводит к ряду векторов атаки, например:

• Проверка включает в себя проверку, что сертификаты все еще действительны на текущую дату. Как клиентская машина знает текущую дату? С помощью своего внутреннего часового механизма, а возможно, и общаясь с NTP-серверами (в довольно незащищенном виде!). Клиент может опаздывать на несколько минут, часов, дней, даже лет (я это видел), и, в некоторой степени, мощный злоумышленник мог бы заставить его это делать, манипулируя NTP-сообщениями. Это позволило бы злоумышленнику использовать устаревшие сертификаты, которые были отозваны много лет назад. Обратите внимание на интересный факт: SSL “случайное число клиента” и “случайное число сервера” должны содержать 28 случайных байтов и местную дату и время (в 4 байтах). Это включение времени было частью обходного пути против атак на основе времени. Я не знаю о каких-либо реализациях, которые действительно это проверяют.

• До 2003 года реализация проверки сертификатов в Internet Explorer/Windows не обрабатывала расширение “Базовые ограничения” должным образом. Чистый эффект заключался в том, что любой обладатель сертификата на 100 евро мог действовать в качестве ЦП и выдавать “сертификаты” с произвольно выбранным именем и ключами.

• X.509 включает в себя функцию ограничения ущерба, называемую отзывом: это публикация списка отзванных сертификатов, которые хорошо выглядят с криптографической точки зрения, но не должны быть доверенными (например, их закрытый ключ был украден или они содержат ошибочное имя). Отзыв действует только до тех пор, пока вовлеченные стороны (т.е. браузеры) согласны загружать огромные списки отзыва (которые могут занимать несколько мегабайт!) или контактировать с OCSP-серверами. Современные браузеры делают это сейчас, но немного неохотно, и многие все равно примут соединение, если не смогут своевременно получить информацию о статусе отзыва (потому что человеческий пользователь не терпелив). Общая ситуация улучшается с годами, но довольно медленно.

• Некоторые корневые центры сертификации действительно допустили ошибки в прошлом (например, Comodo и DigiNotar). Это привело к выдаче поддельных сертификатов (имя www.microsoft.com, но закрытый ключ вообще не находился в руках Microsoft…). Эти ошибки были обнаружены, а сертификаты отозваны, но это по-прежнему вызывает некоторые неудобные вопросы (например, есть ли другие ЦП, у которых были подобные проблемы, но которые не раскрыли их, или, еще хуже, никогда их не заметили?).

X.509 — это очень сложная совокупность алгоритмов, технологий, спецификаций и комитетов, и очень сложно добиться ее правильной работы. Попытка расшифровать сертификаты X.509 “вручную” в незащищенном языке программирования вроде C является простым способом получить переполнение буфера.

Атаки Блейхенбахера

Даниэль Блейхенбахер в 1998 году обнаружил интересную атаку против RSA. Когда вы шифруете кусок данных с помощью RSA (как это происходит для сообщения ClientKeyExchange в SSL), данные, которые должны быть зашифрованы, должны быть дополнены, чтобы сформировать последовательность байтов такой же длины, как модуль RSA. Дополнение состоит в основном из случайных байтов, но имеет некоторую структуру (в частности, первые два байта после дополнения должны быть 0x00 0x02).

При расшифровке (на сервере) дополнение должно быть найдено и удалено. Оказалось, что в то время, когда сервер расшифровывал, но получил недопустимое дополнение (байты 0x00 0x02 отсутствовали), он сообщал об этом с помощью сообщения тревоги (согласно спецификации SSL), в то время как допустимое дополнение приводило к тому, что сервер использовал, по-видимому, расшифрованное значение и продолжал рукопожатие.

Это явление известно как oracle дополнения. Оно позволяет злоумышленнику отправить произвольную последовательность байтов, как будто это зашифрованный предварительный мастер-ключ, и узнать, будет ли расшифровка этой последовательности давать допустимое дополнение или нет. Это всего лишь 1-битная информация, но ее достаточно, чтобы восстановить закрытый ключ с помощью нескольких миллионов запросов (с хитро продуманными “зашифрованными” строками).

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

Oracle дополнения наносит ответный удар

Еще одной областью, где была найдена oracle дополнения, является сами записи. Рассмотрим шифрование CBC и HMAC. Данные для шифрования сначала MACуются, затем результат шифруется. При шифровании CBC длина данных, подлежащих шифрованию, должна быть кратна размеру блока (8 байтов для 3DES, 16 байтов для AES). Поэтому применяется некоторое дополнение, с некоторой структурой.