тут блог
Общественные обязательства интроверта.
Сообщения на ИТ тематику, но не обязательно.
О STARTTLS
SSL, который Secure Sockets Layer, бывает разный. И как минимум с 1999 года он называется TLS — Transport Layer Security. Впрочем, сути это не меняет.
Внезапно оказалось, что почти все протоколы Интернета передают ценные данные открытым текстом. И любой чувак, который сможет перехватить трафик, сможет извлечь эти ценные данные. Конечно, фоточки котиков и фильмы известного содержания — не очень-то и ценны. Но вот логин-пароль для платного доступа к котикам, или идентификатор сессии, когда логин-пароль уже введён, — уже ценны.
Поэтому придумали SSL. С точки зрения приложения — почти такой же обычный TCP сокет, вот только передаваемые данные зашифрованы. И никакой чувак посередине ваших котиков больше не увидит. Если, конечно, он не работает в правильных организациях, чьей обязанностью является бдить.
SSL/TLS — это гибридная криптосистема. У нас есть клиент, и есть сервер. Клиент всегда подключается к серверу. У сервера есть приватный ключ, который всегда при нём. И у сервера есть публичный ключ, в виде сертификата, подписанного каким-то центром сертификации. Ну или подписанный ключом самого сервера — самоподписанный сертификат. Сертификат содержит имя сервера, сведения о его владельце и прочее. Правильность этих сведений подтверждается подписью. Центры сертификации подписывают сертификаты за деньги. Это организации, которые дорожат своей репутацией, а мы им доверяем. И на этом доверии всё и держится.
Клиент, когда подключается к серверу, получает его сертификат. Он проверяет: а действительно ли это сертификат того сервера, к которому мы подключаемся? А не истёк ли срок действия сертификата? А доверяем ли мы тому центру сертификации, что подписал этот сертификат? Иногда сертификат бывает и у клиента, и он предъявляет его серверу, а сервер производит подобные же проверки. Если всё ок, то идём дальше.
Используя ассиметричное шифрование, приватные ключи и публичные ключи из сертификатов, клиент и сервер договариваются о ключе сессии. Это ключ уже симметричного шифрования. И этим ключом будут зашифрованы последующие данные. Всё секурно и красиво, если вы пользуетесь свеженькими реализациями TLS. Все SSL, версии от 1.0 до 3.0, нынче считаются небезопасными. Безопасные — это TLS 1.1 или 1.2, и, может быть, TLS 1.0.
Хорошо, у нас есть надёжный способ шифровать TCP соединения. Но у нас есть и старые добрые, уже работающие протоколы. Как добавить к ним шифрование?
Поначалу решили: а давайте назовём это новым протоколом и повесим на отдельный TCP порт. К имени протокола как правило добавляют буковку S — Secure. Так HTTP стал HTTPS и переехал с порта 80 на порт 443. FTP стал FTPS, вместо портов 21-20 стал использовать порты 990-989. Не путать с SFTP, который использует шифрование SSH, а не SSL. SMTP, протокол пересылки почты, стал SMTPS и перехал с порта 25 на порт 465. В почте вообще много протоколов: POP3→POP3S — 110→995, IMAP→IMAPS — 143→993. Даже в Jabber, он же XMPP, сначала пошли по этому пути, для клиентских SSL подключений вместо порта 5222 взяли порт 5223, для междусерверных подключений вместо 5269 взяли порт 5270. О боже, даже telnets придумали, на порту 992.
Этот подход, когда для SSL шифрования выделяется отдельный порт, сам исходный протокол никак не меняется, а просто заворачивается в SSL, называется SSL wrapping. Даже была утилитка, которая так и называлась sslwrap, и позволяла добавить SSL к любому протоколу.
У такого оборачивания есть свои недостатки. У нас добавляется целый новый порт. По-хорошему, его надо регистрировать в IANA. Его надо открывать в файерволах. Этот порт должен кто-то слушать, а значит, у нас будет в два раза больше демонов: на старом незашифрованном порту, и на новом SSL порту. Наконец, так как обмен сертификатами и договорённость о параметрах шифрования происходят ещё до начала работы нашего прикладного протокола, некоторые возможности этого протокола перестают работать.
В попытке обойти эти трудности решили пойти другим путём. Расширить протоколы, чтобы можно было начать сеанс связи без шифрования, а потом переключиться на шифрование, если и клиент, и сервер его поддерживают. Это красиво называется Opportunistic TLS. А команда, включающая шифрование, называется STARTTLS.
Сначала клиент подключается к серверу как обычно, без шифрования. В ходе начала переговоров, по правилам данного протокола, клиент и сервер выясняют свои возможности. Если и клиент, и сервер могут и хотят шифроваться, клиент посылает команду STARTTLS. После этого начинается обычная для TLS процедура обмена сертификатами и согласования ключей. Если она завершается успешно, последующие команды в сеансе между клиентом и сервером уже идут по зашифрованному каналу.
В OpenSSL есть встроенный клиент, который умеет делать STARTTLS. Например для SMTP.
Использовать один и тот же порт для незашифрованных и для шифрованных соединений оказалось так удобно, что отдельные порты для SSL быстренько объявили устаревшими. Так что теперь стандартный и кошерный способ делать TLS — это STARTTLS.
Может показаться, что это небезопасно, ведь мы начинаем сессию без шифрования. Но шифрование включается сразу же, как обе стороны решат, что оно им нужно. Открытым текстом видны только общие поддерживаемые возможности клиента и сервера. И клиент, и сервер можно настроить так, чтобы они требовали использование команды STARTTLS. В этом случае требуется, чтобы STARTTLS был одной из первых команд в сессии, до передачи важных данных. Иначе дальнейшая работа блокируется согласно протоколу.
А вот с HTTPS как-то не сложилось. Возможно, потому, что в HTTP не предусмотрено длительных сессий между клиентом и сервером, STARTTLS просто некуда воткнуть. Впрочем, подобная попытка предпринималась в RFC 2817, но не прижилась. Там предлагалось делать Upgrade протокола до TLS, примерно как сейчас делается для WebSocket или для одновременной поддержки HTTP и HTTP/2.
OpenSSLный клиент можно и для SSL wrapper использовать. (Заголовок Host для запроса в HTTP/1.1 является обязательным)
Тем не менее, для HTTP/2 есть забавный черновик Opportunistic Security for HTTP. Чтобы для http URL работал TLS, если клиент с сервером договорятся. Вместо одной команды STARTTLS в этом черновике предполагается обмен JSONами.
SSL/TLS
Содержание
Протоколы SSL и TLS [ править ]
SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.
Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:
Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).
История SSL [ править ]
Из-за невозможности гарантировать безопасность сети, через которую передается информация наилучшим способом защитить ее было выбрано шифрование и дешифрование на концах устанавливаемого соединения соответственно. Netscape могли бы встроить этот подход напрямую в свой браузер, но это бы не предоставило единого решения, которое другие приложения могли бы использовать. Требовалось получить более общный, независимый от приложения подход.
В итоге, Netscape разработал протокол SSL работающий поверх TCP, а также предоставляющий TCP-подобный интерфейс для приложений более высокого уровня. В теории, одним из преимуществ SSL для разработчиков являлась возможность заменить все традиционные TCP вызовы на новые SSL вызовы. Специфические детали того, как SSL шифрует и дешифрует данные были относительно прозрачны.
Устройство протокола SSL [ править ]
Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.
Работу протокола можно разделить на два уровня:
Первый слой, в свою очередь, состоит из трех подпротоколов:
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хэширование и сжатие. Следующий этап — аутентификация участников, которая осуществляется также протоколом подтверждения подключения.
Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.
Предупредительный протокол содержит сообщение, которое показывает сторонам изменение статуса или сообщает о возможной ошибке. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Протокол записи [ править ]
Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.
Существует четыре протокола записи:
Принцип работы SSL [ править ]
Принцип работы SSL состоит из двух фаз: фаза рукопожатия и фаза передачи данных. Во время фазы рукопожатия клиент и сервер используют шифрование открытым ключом для того, чтобы определить параметры секретного ключа, используемого клиентом и сервером для шифрования во время фазы передачи данных.
Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.
Для проверки сертификата сервера клиент использует публичный ключ центра сертификации для расшифровки подписи. Затем клиент самостоятельно считает отпечаток сертификата сервера и сверяет с расшифрованным. Если они не совпадают, то сертификат был подделан. Естественно, для расшифровки подписи у клиента должен быть публичный ключ центра авторизации. Поэтому клиент хранит у себя список публичных ключей подтвержденных центров сертификации. По факту, многие браузерные приложения имеют подобный список, находящийся непосредственно в их коде. Когда клиент установил подлинность сервера (сервер также может запросить сертификат у клиента), сервер использует шифрование открытым ключом для определения секретного ключа для обмена информацией.
Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.
Цифровые сертификаты [ править ]
Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.
Способы получения SSL-сертификата:
Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.
Хэширование [ править ]
Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.
Шифрование [ править ]
Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).
Открытый ключ [ править ]
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.
Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA)
Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA)
RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.
Секретный ключ [ править ]
При шифровании секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.
Комбинированный подход [ править ]
Алгоритмы симметричного шифрования часто включают установленное число добавок и сдвигов. Такие алгоритмы часто используют ключ для помощи при битовых манипуляциях или для того, чтобы шифруемые данные стали более случайными. Другими словами, при увеличении размера секретного ключа может увеличиться случайность шифруемых данных, но не обязательно возрастет сложность вычислений при расшифровке. Однако, шифрование открытым ключом использует ключ как экспоненту, поэтому значительное увеличения ключа сильно увеличивает количество вычислений, требуемых для шифрования / дешифрования данных.
Таким образом хотя алгоритмы шифрования открытым ключом не сталкиваются с проблемой распределения, с которой сталкиваются алгоритмы шифрования секретным ключом, они требует значительно больше вычислительной мощности. Для использования сильных сторон обоих типов алгоритмов протоколы безопасности обычно используют шифрование открытым ключом для передачи секретных ключей. Как только секретный ключ доставлен начинается передача данных с использованием симметричного шифрования.
Существует еще один подход, использующий открытый ключ как соглашение, а не как способ доставки секретного ключа другим. Обе стороны обмениваются публичными ключами и независимо генерируют секретный ключ. Самой распространенной формой такого соглашения является протокол Диффи-Хеллмана. Хотя SSL поддерживает протокол Диффи-Хеллмана, большинство SSL транзакций не используют его. Вместо него используется алгоритм RSA, который решает проблему распределения секретных ключей.
Аутентификация и обмен ключами [ править ]
SSL поддерживает 3 типа аутентификации:
Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.
Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента.
Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).
Анонимный обмен ключами [ править ]
Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).
Аутентификация и обмен ключами при использовании RSA [ править ]
В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.
Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.
Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана [ править ]
В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Восстановление сессии [ править ]
Создатели SSL знали, что алгоритмы шифрования открытым ключом вычислительно сложные, и клиент, создающий несколько новых соединений к одному и тому же серверу в течение короткого промежутка времени может сильно нагрузить сервер, что приведет к заметным временным задержкам ответа. Однако, если клиент и сервер уже установили соединение, то ему будет соответствовать уникальный идентификатор сессии, позволяющий ссылаться на него и использовать такой же секретный ключ при последующих соединениях в рамках некоторого временного отрезка. Безусловно, такой подход привносит определенный риск в безопасность соединения. Поэтому, если необходимо, клиент может пересоздать новые идентификатор и секретный ключ для данной сессии. Microsoft’s Internet Explorer, например, проделывают эту операцию каждые 2 минуты.
Администрирование [ править ]
Обслуживание сертификатов и ключей [ править ]
Если клиент планирует обратиться к серверу, который требует клиентской аутентификации, он должен хранить свой сертификат и связанный с ним приватный ключ. Сервер должен всегда хранить свой сертификат и связанный с ним приватный ключ.
Хранилище идентификаторов сессий [ править ]
Клиент и сервер обязаны хранить идентификаторы сессий и связанные с ними секретные ключи для использования во время восстановления соединения.
SSL 1.0, 2.0, 3.0 и TLS [ править ]
Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.
Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.
Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.
Принцип работы TLS [ править ]
Протокол TLS делится на два слоя: TLS Record и TLS Handshake.
Подтверждение связи (handshake) [ править ]
Возобновление сессии [ править ]
Протокол записи (TLS Record) [ править ]
Этот слой защищает данные с помощью ключей, полученных при подтверждении связи, и проверяет целостность и источник входящих сообщений. Он выполняет следующие функции:
После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.
