Что такое TLS / Habr
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Протокол TLS предназначен для предоставления трёх услуг всем приложениям, работающим над ним, а именно: шифрование, аутентификацию и целостность. Технически, не все три могут использоваться, однако на практике, для обеспечения безопасности, как правило используются все три:
- Шифрование – сокрытие информации, передаваемой от одного компьютера к другому;
- Аутентификация – проверка авторства передаваемой информации;
- Целостность – обнаружение подмены информации подделкой.
Для того чтобы установить криптографически безопасный канал данных, узлы соединения должны согласовать используемые методы шифрования и ключи. Протокол TLS однозначно определяет данную процедуру, подробнее это рассмотрено в пункте TLS Handshake. Следует отметить, что TLS использует криптографию с открытым ключом, которая позволяет узлам установить общий секретный ключ шифрования без каких-либо предварительных знаний друг о друге.
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, которые предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Разберём подробнее каждый шаг данной процедуры:
- Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
- После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
- Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
- Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
- Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
- Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.
Ясно, что установление соединения TLS является, вообще говоря, длительным и трудоёмким процессом, поэтому в стандарте TLS есть несколько оптимизаций. В частности, имеется процедура под названием “abbreviated handshake”, которая позволяет использовать ранее согласованные параметры для восстановления соединения (естественно, если клиент и сервер устанавливали TLS-соединение в прошлом). Данную процедура рассмотрена подробнее в пункте «Возобновление сессии».
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Аутентификация является неотъемлемой частью каждого TLS соединения. Рассмотрим простейший процесс аутентификации между Алисой и Бобом:
- И Алиса, и Боб генерируют собственные открытые и закрытые ключи.
- Алиса и Боб обмениваются открытыми ключами.
- Алиса генерирует сообщение, шифрует его своим закрытым ключом и отправляет Бобу.
- Боб использует полученный от Алисы ключ, чтобы расшифровать сообщение и таким образом проверяет подлинность полученного сообщения.
Очевидно, что данная схема построена на доверии между Алисой и Бобом. Предполагается, что обмен открытыми ключами произошёл, например, при личной встрече, и, таким образом, Алиса уверена, что получила ключ непосредственно от Боба, а Боб, в свою очередь, уверен, что получил открытый ключ Алисы.
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Здесь очевидно присутствует некоторая техническая нерациональность: для проверки лишь одного сертификата требуется запрашивать весь список отозванных сертификатов, что влечёт замедление работы. Для борьбы с этим был разработан механизм под названием «Протокол статусов сертификатов» (OCSP – Online Certificate Status Protocol). Он позволяет осуществлять проверку статуса сертификата динамически. Естественно, это снижает нагрузку на пропускную способность сети, но в то же время порождает несколько проблем:
- Центры сертификации должны справляться с нагрузкой в режиме реального времени;
- Центры сертификации должны гарантировать свою доступность в любое время;
- Из-за запросов реального времени центры сертификации получают информацию о том, какие сайты посещал каждый конкретный пользователь.
Собственно, во всех современных браузерах оба решения (OCSP и CRL) дополняют друг друга, более того, как правило имеется возможность настройки предпочитаемой политики проверки статуса сертификата.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.
habr.com
TLS и SSL: Необходимый минимум знаний
TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.Что такое SSL и что такое TLS?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:
SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года
Принцип работы SSL и TLS
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
Корневой сертификат
Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Запрос на подпись (CSR, Certificate Sign Request)
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
Цепочка действий по генерации сертификатов
Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.
Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.
$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus ..........+++ ...........................................+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:IT Service Common Name (e.g. server FQDN or YOUR name) []:My Company Root Certificate Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] Getting Private key
Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.
Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.
Просмотр информации о сертификате
Содержимое сертификата можно просмотреть таким образом:
$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] notAfter=Jan 22 11:49:41 2025 GMT
Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.
Серверный сертификат
Для подписи сертификата для сервера нам нужно выполнить следующие действия:
1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно
В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата
$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus ...................................................................................+++ ..........................+++ e is 65537 (0x10001) $ openssl req -new -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:IT Service Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] notAfter=Jan 25 12:22:32 2016 GMT
Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.
Установка SSL/TLS-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):
server {
listen 443;
server_name www.mycompany.com;
root html;
index index.html index.htm;
ssl on;
ssl_certificate server.pem;
ssl_certificate_key server.key;
ssl_session_timeout 5m;
# Не рекомендуется использовать SSLv3 !!!
# Он здесь только для примера
ssl_protocols SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_prefer_server_ciphers on;
location / {
try_files $uri $uri/ =404;
}
}3) Перезапустить nginx
4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.
Установка SSL/TLS-сертификата на сервер с Apache
Установка SSL/TLS-сертификата на Apache выглядит примерно так же.
1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории
2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен
3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.pem
SSLCertificateKeyFile /etc/ssl/private/server.key
# Эта директива добавляет файл, содержащий список
# всех сертификатов, которыми подписан сертификат сервера
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
<IfModule mod_ssl.c>
Listen 443
</IfModule>
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
NameVirtualHost *:443
Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf
4) Перезапустить веб-сервер Apache
Создание клиентского сертификата
Клиентский сертификат создается примерно так же, как серверный.
$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus ........................+++ ..................................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Saint-Petersburg Locality Name (eg, city) []:^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petrersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Engineering Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] notAfter=Jan 25 13:17:15 2016 GMT
Если необходим клиентский сертификат в формате PKCS12, создаем его:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:
Теперь можно использовать клиентский сертификат для работы с нашим сервером.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
# Корневой сертификат(ы), которым(и) подписан клиентский ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Возможные варианты: on | off | optional | optional_no_ca ssl_verify_client optional; # Глубина проверки цепочки сертификатов, которыми подписан клиентский ssl_verify_depth 2;
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Настройка Apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
# Директория, содержащая корневые сертификаты для проверки клиентов SSLCARevocationPath /etc/apache2/ssl.crl/ # или файл, содержащий сертификаты SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опция верификации клиента. Возможные варианты: # none, optional, require and optional_no_ca SSLVerifyClient require # Глубина просмотра цепочки подписей. По умолчанию 1 SSLVerifyDepth 2
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
«Прослушка» информации о сертификате при помощи openssl
Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.
На стороне сервера запускаем прослушку порта при помощи openssl:
openssl s_server -accept 443 -cert server.pem -key server.key -state
На стороне клиента обращаемся к серверу, например, culr’ом:
curl -k https://127.0.0.1:443
В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.
Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:
openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
Со стороны сервера ошибка выглядит так:
140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:
Со стороны клиента так:
curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):
curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key
Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.
- Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
- Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
- Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
- Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
- Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
- Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
- Нажмите, чтобы поделиться в Skype (Открывается в новом окне)
mnorin.com
знакомство с SSL/TLS / 1cloud.ru corporate blog / Habr
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
/ Flickr / David Goehring / CC-BY
SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.
Цель протокола — обеспечить защищенную передачу данных. При этом для аутентификации используются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Первый тип шифрования более ресурсоемкий, поэтому его комбинация с симметричным алгоритмом помогает сохранить высокую скорость обработки данных.
Рукопожатие
Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.
Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.
Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.
Алгоритмы шифрования
Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.
Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.
Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.
Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.
Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.
DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.
Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.
Хеш и MAC
Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.
Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.
В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.
Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.
Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.
Сертификаты бывают разные
Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.
Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.
Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.
Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.
Он нужен веб-сайтам, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтвержденные сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей.
Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:
habr.com
Уходим с SSL на TLS
Привет.
Введение
Протоколу SSL уже много времени, и ему пора на покой. Тем более – замена ему достаточно давно уже есть. Выглядит она как протокол TLS, который вырос, возмужал, и готов к работе. Я попробую чуть-чуть пробежаться по тому, что и как для этого надо сделать в Windows Server и основных серверных приложениях.
У данной статьи есть обновлённая и расширенная версия – Бронируем TLS в Windows Server
Оглавление
- Краткая история вопроса – SSL
- Версии и преимущества TLS
- Про TLS 1.0
- Про TLS 1.1
- Про TLS 1.2
- Про TLS 1.2 и Windows XP SP3
- Про TLS 1.2 и Windows 2003 SP2
- BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0
- Включаем TLS на Windows-системе
- Отключаем SSL на Windows-системе
- Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе
- Атака на SSL/TLS – THC-SSL-DOS
- Закручиваем гайки: настройки криптоалгоритмов на хосте
- Управляем настройками согласования SSL/TLS в браузерах
- Проверяем работу TLS 1.1 и 1.2
- Что делать, если у меня нет возможности включить TLS новых версий
Приступим.
Краткая история вопроса – SSL
Протокол SSL был разработан фирмой Netscape, достаточно давно. Я осознанно пропущу исторические подробности, так как они сейчас уже не особо интересны. В его задачи входило следующее:
- Обязательность подтверждения подлинности сервером
- Опциональная проверка подлинности клиента
- Совместная генерация случайного сеансового ключа
- Поддержка различных симметричных алгоритмов для шифрования данных
- Поддержка различных алгоритмов хэширования для реализации проверки целостности через MAC
Первая версия SSL не особо показывалась публике, отсчёт рабочих версий можно начинать с SSL 2.0 (1995й год). Эта версия была первой, которая эксплуатировалась в production, и достаточно оперативно она была доработана до SSL 3.0. Заметим, что хотя это произошло достаточно давно – в 1996 году – стандарт от этого не стал общим и открытым; он оставался стандартом, разработанным конкретной фирмой Netscape, и для его использования в ряде случаев нужна была лицензия. Опубликован IETF он был совсем недавно, в августе; RFC 6101 описывает то, что 15 лет уже стандарт де-факто для защиты сессий множества приложений. Но по сути, с ним уже давно пора прощаться; TLS существует годы (с 1999, если быть точнее), а достаточно безопасная на данный момент версия 1.1 – с 2006 года. Пора, пора.
Версии и преимущества TLS
На данный момент есть три версии протокола TLS: 1.0, 1.1 и 1.2. Они, соответственно, имеют внутренние идентификаторы версии 3.1, 3.2 и 3.3, поэтому иногда называются SSL 3.1, SSL 3.2 и SSL 3.3. Все эти версии поддерживаются как клиентским, так и серверным ПО Microsoft (начиная с IIS 7.5 и IE9), надо только включить. Про клиентское ПО (типа того же Internet Explorer) я уточню ниже, в отдельном пункте – на то оно и клиентское, чтобы включение поддержки данного функционала было бы там несложной операцией. Основное в статье – про серверные вопросы. Давайте чуть разберёмся в функционале версий протокола TLS, а после – включим их поддержку, отключим SSL и закрутим гайки.
Про TLS 1.0
Версия 1.0, по сути, является базовой, и представляет собой доработанный и открытый для всех, а не только для Netscape, вариант SSL 3.0. Хотя, надо отметить, напрямую TLS 1.0 и SSL 3.0 не совместимы; TLS 1.0 “умеет” работать в режиме совместимости с SSL, но именно в режиме, а не “идентично”, как иногда можно прочитать.
Например, у SSL 3.0 есть встроенная в протокол неприятность – половина master key будет создаваться из MD5-хэша достаточно предсказуемых данных, что может привести (учитывая текущее положение MD5) к успешной атаке на коллизию (в результате станет известна половина бит ключа, которым будет шифроваться сессия, а это практически равнозначно компрометации процесса). У TLS 1.0 это поправили, и схема усложнена – берутся и MD5 и SHA-1 хэши, после чего xor’ятся, что сводит возможность вышеуказанной атаки к нулю.
Кстати, из-за этого момента в алгоритме – завязанности ключевой части процесса на MD5, SSL 3.0 не является FIPS140-2 совместимым и при включении FIPS140-2 не согласовывается.
Про TLS 1.1
В версии TLS 1.1 делаются небольшие изменения – в частности, меняется логика задания IV (вектора инициализации), для защиты от атак, имеющих своей целью слабость реализации метода CBC в TLS 1.0, улучшается обработка ошибок и переподключения, а также вносятся другие мелкие изменения, не являющиеся фундаментальными с точки зрения использования протокола. Но по сути, это самая минимальная версия TLS, для которой отсутствуют известные атаки, поэтому её использование – это правильный выбор.
Про TLS 1.2
В TLS 1.2 же список добавлений относительно велик – в нём будут многочисленные улучшения поддержки новых криптографических протоколов, отказ от потенциально уязвимых моментов (например, для процесса генерации псевдослучайного числа – замена MD5/SHA-1 на SHA-256 либо на явно указанную хэш-функцию), ужесточение многих проверок, обязательность реализации AES и отключение одиночного DES и IDEA, отмена обязательности совместимости реализации с SSLv2 и подобное.
Для нас ключевым является разумное повышение уровня безопасности, поэтому мы будем нацеливаться на TLS 1.1. Не потому что TLS 1.2 плохой, а потому что если “закрутить гайки” только на TLS 1.2, не все клиенты смогут корректно подключаться. Если бы все браузеры с криптографической точки зрения были бы уровня IE9, то можно было бы и TLS 1.2 включить, а остальное объявить старым, но реальность состоит в том, что нам надо хотя бы отсечь гарантированно старые и уязвимые протоколы.
Про TLS 1.2 и Windows XP SP3
Например вот один момент, который надо учитывать при поддержке TLS 1.2. Дело в том, что стандартным методом проверки целостности (MAC – Message Authentication Code), используемым в TLS 1.2, является SHA-2. SHA-2 – это семейство алгоритмов, состоящее из SHA-224, SHA-256, SHA-384, SHA-512, и подобных. Соответственно, “натуральная” поддержка этих алгоритмов приходит только в ядре NT 6.0, с новой версией CryptoAPI. В распространённой же Windows XP данная поддержка (т.е. просто понимаение, что есть SHA-2) появляется только в Service Pack 3, притом поддерживается только 3 варианта SHA-2 – SHA-256, SHA-384, SHA-512. То есть, говоря проще, XP SP2 нормально с TLS 1.2 работать не может никак. Вообще. Потому что будет NTE_BAD_ALGID.
Про TLS 1.2 и Windows Server 2003 SP2
К сожалению, ситуация с поддержкой TLS 1.2 на Windows Server 2003 SP2 хуже, чем на XP. В последний Service Pack для 2003го сервера поддержка SHA-2 не вошла. Поэтому попытка проверить целостность в TLS 1.2 при помощи одного из алгоритмов семейства SHA-2, да и, к примеру, посчитать хэш у x.509 сертификата или *.crl приведёт к ошибке.
Поддержка SHA-2 аналогичная XP SP3 реализована через патч 938397. Но это ещё не всё. Ведь приключения, связанные с тем, что у NT 5.1 / NT 5.2 есть CAPI2, а у NT 6.0 – CNG, только начинаются. В случае, если в Вашей сети есть Windows XP и/или Windows Server 2003, и есть служба Certification Authority на Windows 2008 и старше, то даже в случае установленного патча 938397 они не смогут корректно запрашивать сертификаты у этого CA. Чтобы они могли это делать, есть патч 968730. Он и добавляет частичную поддержку SHA-2, и учит CAPI2 дружить на уровне запросов сертификата с CNG. Полностью перекрывая собой предыдущий патч. Обязательно установите 968730 на Windows XP SP3 / Windows Server 2003 SP2, если ещё не сделали это.
BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0
Эта достаточно нашумевшая атака (ну, благодаря прессе, у неё статус “Конец Интернета Почти Вот-Вот”), на самом деле, устроена достаточно просто.
Суть в том, что во всех протоколах до TLS 1.1 вместо генерации нового случайного IV (для каждого нового TLS message), использовался последний блок предыдущего TLS message. BEAST пользуется этим, чтобы значительно упростить процесс атаки на ключ – в частности, получив доступ к сессии, он может значительно упростить себе процедуру перебора сессионного ключа, влияя на состав нового вектора инициализации. В TLS 1.1 халтурить перестали, поэтому данная атака там просто не работает.
Если попробовать рамочно описать алгоритм атаки, можно это сделать так.
- Пользователь инициирует SSL-сессию к ресурсу (например, к веб-серверу). В этой сессии он постоянно передаёт какой-то элемент (например, жмёт на кнопку Like). Ну т.е. сессия одна, а он ходит по сайтам и делает что-то, что сопровождается хотя бы частично совпадающим обменом данными.
- Например, предположим, что согласовался протокол AES-128 (заметьте – стойкость самого протокола не критична, я его выбрал просто для удобного примера). Его блок будет равняться 128 / 8 = 16 байт.
- Атакующий участвует в обмене трафиком так, что может добавлять свои данные перед данными пользователя. Вариантов много – например, доп.заголовок в HTTP, или модификация исходных данных на уровне источника. Суть в том, чтобы атакующий мог добавить свои данные так, чтобы получился блок “Добавленные_данные_известные_атакующему + нормальные_данные_неизвестные_атакующему”. Т.е. исходное в атаке – это MITM. Если вы думаете, что условий дофига и это всё малореально, просто представьте себе обычного пользователя, который игнорирует антивирус, потому как, к примеру, верит рекламе “В нашей ОС нет вирусов, т.к. у неё красивые скруглённые уголочки да и цена намекает, что качество ну просто обязано быть”, который хочет в онлайне что-нибудь оплатить по карте и видит успокаивающую надпись “Protected by SSL 2.0/3.0 128bit cipher”.
- Атакующий начинает работать. Он вкидывает такие блоки данных в поток, чтобы последним получился блок, у которого 15 байт – добавленные данные, а единственный оставшийся – секретные. После пробует тестово расшифровывать этот блок перебором – перебирать-то интересно, т.к. из 16 байт 15 известны. А подбор 2^8 – это уже очень перспективно, учитывая, что в случае выигрыша можно будет вскрыть всю сессию (ведь никто не мешает впрок отправлять куда-нибудь полный дамп сессии, а после, в случае успеха метода, расшифровать всё целиком).
- Вскрыли 1 байт? Теперь будем подгадывать так, чтобы наших байт в блоке было 14, плюс один известный, плюс один пока что неизвестный
Очевидно, что при реализации этой штуки через ботсеть можно наловить очень много полезного.
Обращу внимание, что атака не зависит от используемого симметричного алгоритма, а лишь использует то, что в SSL/TLS используется схема CBC, а не ECB. AES-128, как понятно, я выбрал, чтобы блок был 16 байт. Как понимаете, в случае AES-256 время вырастет не на 2^128, как в случае линейного криптоанализа, а всего лишь в два раза – надо будет вскрыть не 16, а 32 байта. Ну, а в случае DES с блоком в 64 бита, всё только грустнее.
Поэтому надо защищаться.
Включаем TLS на Windows-системе
Сразу обращаю внимание – этот метод включает TLS на уровне операционной системы. Продукты в большинстве своём просто пытаются согласовать варианты протоколов SSL/TLS, начиная “с верхнего доступного”, явных настроек у них обычно нет.
Для отключения TLS 1.0 и включения поддержки TLS 1.1 и TLS 1.2 необходимо проделать следующие действия – зайти в реестр, открыть ключ
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
создать в нём значение DisabledByDefault и выставить его в единицу, а в ключах
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\ServerHKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
выставить то же самое значение в нуль. Это нужно сделать обязательно, т.к. отсутствие этого ключа равняется “отсутствию отмены запрета на поддержку TLS 1.x”.
В случае необходимости в явном виде управлять данными протоколами на уровне клиента – всё то же самое, но вместо раздела \Server надо указать \Client.
Теперь пора отключить небезопасные протоколы.
Отключаем SSL на Windows-системе
Согласно RFC 6176 от марта 2011 года, все, кто думают о безопасности, и хотят называться TLS-серверами и клиентами, должны вести себя так:
- TLS-клиенты обязаны никогда не отправлять в сообщениях CLIENT-HELLO версии ниже 3.0
- TLS-сервера обязаны сразу прерывать попытку подключения, если противоположная сторона сообщает о том, что максимально поддерживаемая ей версия протокола – 2.0
Вот так, достаточно четко и строго.
Давайте сделаем всё так же.
Для этого надо будет отключить PCT 1.0 (т.к. он тоже не TLS, если что) и SSL 2.0. SSL 3.0 отключается абсолютно аналогично.
Как отключить SSL 2.0/3.0 на Windows-системе
Нам надо зайти в ключ реестра
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
и поставить там значение DisabledByDefault (вида DWORD32) в единицу. Аналогично – для ключа
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
Если сразу хотите отключить и SSL 3.0, то поступите по аналогии, создав (если его нет, что часто бывает) ключ с именем SSL 3.0 на том же уровне иерархии, где находится раздел с SSL 2.0, и создав соответствующие подключи \Client и \Server.
Как отключить PCT 1.0 на Windows-системе
Тут чуть иначе.
Если у Вас Windows Server 2003 – этот протокол уже выключен. Если 2008 – то даже не включится. Но на всякий случай – знайте, как это делается. Надо зайти в ключ
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server
и добавить в него значение Enabled (вида DWORD32), выставив его в нуль.
Вроде как всё. PCT 1.0 убили, все SSL тоже, TLS 1.0 тоже. Делайте это всё аккуратно, очень тщательно проверяя, что ПО после этого функционирует. Учтите, что при закручивании гаек в плане “Давайте выключим весь SSL на клиентах” – т.е. не при добавлении старших версий TLS, а при явном запрете младших – с гарантией часть внешних сервисов будет недоступна. Например, большинство социальных сетей, которые декларируют “Доступ к нам теперь по HTTPS, а, значит, безопасен!”, на самом деле крайне экономят силы, включая согласование минимальных версий и самых простых криптоалгоритмов. Их можно понять; 99.9% клиентов глубоко пофиг, DES там или 3DES, а вот что вычислительно задача станет в 3 раза сложнее – очевидно. По моему личному опыту, при “замораживании” на клиенте TLS 1.1 и выше, например, не работает https://twitter.com/ . Т.е. будьте осторожны и тестируйте. Вполне возможно, что вполне даже рабочие ресурсы – типа электронной торговой площадки – будут использовать старые алгоритмы.
Ну, а теперь давайте закручивать гайки.
Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе
К стандартам семейства TLS есть интересные дополнительные механизмы, не вошедшие в основные спецификации. Данные механизмы известны гораздо меньше, чем что-то вида “ну ё, TLS же новый, SSL старый, значит включаешь TLS и безопаснее становится”, но не в моих правилах подходить к вопросу с такой стороны.
Безопасное пересогласование TLS описывается в стандарте RFC 5746 и решает проблему безопасности, которая возникает в случае работы классического TLS 1.2, который по RFC 5246.
По сути, Windows-хост может работать в плане этого RFC в двух режимах – в режиме совместимости (т.е. допускать и небезопасное, “классическое” пересогласование TLS 1.2), и в “безопасном”, допуская только пересогласование в новом формате. По умолчанию, работа идёт в режиме совместимости. Это не всегда полезно, поэтому надо знать, как включать только безопасное пересогласование TLS 1.2.
Включаем поддержку TLS Renegotiation Indication Extension
Мы будем работать с ключом реестра
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
В нём будет необходимо создать следующие ключи: AllowInsecureRenegoClients, AllowInsecureRenegoServers, UseScsvForTls, DisableRenegoOnClient, DisableRenegoOnServer. Все – обычные DWORD 32. Теперь подробнее про каждый.
Параметр AllowInsecureRenegoClients будет обозначать, можно ли клиентам, подключающимся к данному хосту, использовать небезопасный вариант пересогласования. Обратите внимание – это серверная настройка; т.е. она анализируется, когда какой-либо сервис на этом хосте “слушает” входящие подключения по TLS. Например, IIS. Если хотите, чтобы можно было подключаться всем – поставьте единицу, если только “умным” клиентам, поддерживающим RFC 5746 – то нуль.
Параметр AllowInsecureRenegoServers будет обозначать, можно ли будет с этого хоста подключаться к серверам, которые не поддерживают механизм безопасного пересогласования. Если параметр равен нулю – клиенты будут прерывать фазу согласования TLS, если сервер ведёт себя некорректно. Если хотите, чтобы можно было подключаться к любым TLS-серверам, вне зависимости от реализации на них поддержки RFC 5746 – поставьте единицу.
Параметр UseScsvForTls заслуживает отдельного обсуждения. Дело в том, что в RFC 5746 указывается, что данное расширение необходимо упаковывать в сообщение “ClientHello” протокола TLS. Но это может быть причиной проблем, потому что некоторые сервера – заметьте, именно сервера, т.е. это клиентская настройка – которые не поддерживают данный стандарт, не просто не смогут переключиться на новый механизм, а просто не смогут обработать этот неизвестный им подвид сообщения ClientHello. Это, например, Vista без SP. Чтобы подстраховаться от ситуации, когда “новый” клиент посылает “новый вариант” ClientHello и серверная сторона рвёт связь, надо установить этот параметр в единицу. В этом случае клиент просто отправит т.н. “Signaling Cipher Suite Value” (как раз SCSV). Ставьте этот параметр только в случае, когда Вам реально нужно подключаться к системе, которая “сбрасывает” сессию после ClientHello.
Можно и масштабнее. Если параметры выше описывали варианты поведения при пересогласовании TLS, то следующие будут включать-выключать поддержку пересогласования как такового.
Если параметр DisableRenegoOnClient есть и не равен нулю, то клиент со своей стороны не будет пробовать проводить пересогласование TLS (например, периодически) и не будет отвечать на запросы пересогласования (будет не рвать сессию, а именно игнорировать). Если же параметр равен нулю (или отсутствует), то всё ОК – клиент будет поддерживать пересогласование и пробовать делать его сам.
Если параметр DisableRenegoOnServer есть и не равен нулю, то сервер со своей стороны не будет пробовать проводить пересогласование TLS и не будет отвечать на запросы пересогласования (тоже будет не рвать сессию, а именно игнорировать). Если же параметр равен нулю (или отсутствует), сервер будет поддерживать пересогласование и пробовать делать его сам.
Атака на SSL/TLS – THC-SSL-DOS
Достаточно предсказуемая атака, в основе которой лежит идея, что крайне малыми силами со стороны клиента (по сути, просто запросив) можно заставить сервер выполнить математически относительно сложную задачу по перегенерации ключевой информации. В своей практике я сталкивался с таким в 2004 году, в случае с ipsec; один талантливый админ поставил настройки смены ключей так, что они менялись через каждые 100 килобайт (он хотел мегабайты, просто ошибся). В результате сеть работала, но медленно – ipsec в основном занимался IKE/ISAKMP задачами, а не трафиком.
Атака серьёзна – при полутысяче запросов в секунду (выполнимо с домашней машины при наличии обычного широкополосного доступа на 4-8 мегабита) полностью “ложится” процессор уровня Intel Xeon E5645. 100%го способа защиты от атаки сейчас нет. Поэтому надо максимально уменьшить её вероятность.
Для борьбы можно использовать следующие методы:
- Разгрузку SSL-задач при помощи аппаратных ускорителей
- Отключение пересогласования TLS
- Ограничение количества TLS-сессий – как вообще в сумме, так и с одного source ip
- Упрощение схемы генерации ключей
Защита от THC-SSL-DOS путём покупки SSL-ускорителя
Метод не оптимален, но всё же в ряде случаев изменит ситуацию. Суть в том, чтобы SSL/TLS сессии терминировались не на целевом сервере, а на выделенном устройстве, которое ощутимо быстрее выполняет SSL/TLS – задачи. Проблема в том, что все такие ускорители обычно ускоряют саму работу SSL/TLS – то есть симметричное шифрование трафика и проверку его целостности, а операции вида “генерация и смена ключей”, в силу их относительно малого процента в доле нагрузки при нормальной сессии делаются на таких appliance программно. Специализированного appliance, которое умеет очень быстро именно генерить новые сеансовы ключи для TLS, а не шифровать трафик, видимо, не существует в природе. Увы.
Защита от THC-SSL-DOS путём отключения пересогласования TLS
Это то, что Вы реально можете сделать. Учтите, это может повлиять на совместимость с клиентским ПО, которое в обязательном порядке хочет время от времени менять ключи сессии. Я проверял и не нашёл такого ПО среди обычно используемого в сетях на базе продуктов Microsoft (тестировались Exchange 2010 SP1, Sharepoint 2010 SP1, трафик DC/GC поверх SSL, TMG 2010 SP1). Мной не было найдено аномалий поведения, разрывов TLS-сессий по причине rekeying и прочего. Поэтому Вы можете промотать эту статью чуть выше (до предыдущего пункта) и выставить в единицу параметр DisableRenegoOnServer.
Защита от THC-SSL-DOS путём ограничения количества TLS-сессий – как вообще в сумме, так и с одного source ip
Если Вы отключили пересогласование TLS, то Вы отсекли одну из возможностей данной атаки; впрочем, опубликованный вчера эксплойт как раз её и использовал. Но существует альтернативный вариант – когда Ваш сервер перегружают не частым пересогласованием сессии, а многими фейковыми сессиями. Здесь Вы можете бороться только на сетевом уровне – ограничивая количество сессий с одного адреса, добавляя тайм-аут между установкой новых TLS-сессий, и лимитируя общее количество TLS-сессий у сервера вообще. Лучше применить все 3 этих подхода – например, сделать тайм-аут между TLS-сессиями хотя бы 10 ms (то есть не более 100 новых сессий в секунду до сервера), и разумно ограничить допустимое количество сессий с 1го адреса.
Упрощение схемы генерации ключей
Это – ожидаемое решение со стороны реализации TLS. Навряд ли Вы сделаете это сами. 🙂
Закручиваем гайки: настройки криптоалгоритмов на хосте
Цель – отключить слабые алгоритмы шифрования. Чтобы они просто не участвовали в процессе согласования. Потому что на данный момент, допустим, наличие в списке поддерживаемых алгоритмов RC2 40bit – это очень плохо, и это необходимо убирать незамедлительно.
Алгоритмы, используемые в SSL/TLS, можно модифицировать двумя основными способами – через групповые политики или через реестр. Первый способ, так как является штатным, предпочтительнее. Выполняется он следующим способом.
Как через групповую политику изменить список поддерживаемых SSL/TLS криптоалгоритмов
Откройте объект групповой политики, через который Вы решите это сделать. Если настраиваете локальный хост – gpedit.msc. Выберите там раздел для компьютера, потом административные шаблоны, потом сеть, потом SSL Configuration Settings. Откройте данный параметр и сделайте следующее.
- Скопируйте в Блокнот все cipher suites, которые там есть.
- Удалите те, которые включают в себя согласование нестойких алгоритмов и методов (например, RC2, RC4, DES, MD5 и прочее. всякие ужасы вида TLS_RSA_WITH_NULL_MD5 Вам же не нужны, правда?).
- Превратите список в одну большую строку, которая состоит из cipher suites, разделённых запятыми, и не содержит больше ничего. Пробелов тоже.
- Вставьте эту строку в окно данной настройки групповой политики.
Учтите, что не всё, что поддерживается системой, присутствует в этом списке. И наоборот – данный список не прикажет системе начать поддерживать неизвестные ей криптоалгоритмы. Например, если у Вас есть системы на Windows XP / Windows Server 2003, убедитесь, что на них установлено обновление KB 948963, которое добавляет поддержку AES-128 и AES-256, необходимых для TLS.
А вот как можно изменить этот список через реестр.
Как через реестр изменить список поддерживаемых SSL/TLS криптоалгоритмов
Откройте редактор реестра. Ваша задача – ключи вида:HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\идентификатор_алгоритма размерность_ключа1/размерность_ключа2
где идентификатор алгоритма – это, например, RC4, а размерность ключа – например, 128. Понятное дело, что данных комбинаций фиксированное число, поэтому для отключения всех из них в явном виде надо забежать в MSDN и найти эти комбинации. Например, для старых симметричных алгоритмов семейства RCx это будут:
- RC4 128/128
- RC2 128/128
- RC4 64/128
- RC4 56/128
- RC2 56/128
- RC4 40/128
- RC2 40/128
Во всех этих ключах надо будет создать параметр Enabled (как обычно, DWORD32) и выставить его в нуль.
Интересным моментом является отключение возможности установить “пустой” SSL – без криптоалгоритма. Ну, типа как в PPP можно вообще без фазы авторизации, так и тут – есть такая тонкость. Чтобы эту тонкость тоже убрать, надо зайти в ключ:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL
и опять же создать там Enabled со значением 0x0.
Отключаем использование хэш-функции MD5 в SSL/TLS
И даже это можно. Через групповую политику нет (только вручную удалив из полного списка все suites с упоминанием MD5), а через реестр – пожалуйста.
Учтите только, что данная настройка – лидер по количеству приключений после её применения. Классика – умирающий SharePoint 2010; он использует MD5 для генерации внутренних идентификаторов безопасности, поэтому не найдя её очень страдает.
Заходим:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5
и отключаем аналогично – Enabled в 0x0. Заодно и MD4 можно, он в принципе может встретиться в IPSec, но если не используется в реальности – имеет смысл его отключить аналогичным способом.
Проверяем работу TLS 1.1 и 1.2
Если Вы выяснили, что после отключения поддержки TLS 1.0 вы никуда не можете зайти, и подозреваете, что браузер сломался, есть отличный тестовый сайт:
https://tls.woodgrovebank.com/
Это специальный сайт, который зарегистрирован на одну из вымышленных и использующихся в курсах Microsoft организаций – Woodgrove Bank, а по сути – голый IIS с самоподписанным сертификатом, который поддерживает все виды SSL/TLS и нужен для диагностики. Зайдите на него, установите сертификат (их, кстати, несколько – специально для проверки поддержки различных криптоалгоритмов подписи) и проверите, что и как работает.
Есть второй вариант – https://www.mikestoolbox.net/. Тут возможностей поменьше, но зато быстрее и нагляднее видно – какой протокол поддерживается, что согласовалось.
Управляем настройками согласования SSL/TLS в браузерах
Internet Explorer
Если Вы дочитали до этого места и всё поняли, но не знаете, как включить TLS в IE, то это, по сути, уникальная ситуация. Но тем не менее. Для включения поддержки TLS старших версий необходимо зайти в меню Internet Options -> Advanced, там в списке промотать до раздела Security и сделать соответствующие изменения (как минимум отключить SSL 2.0 и включить TLS 1.1 и TLS 1.2, остальное – на усмотрение).
Google Chrome
У меня под рукой кроме IE только хром, но, как известно из фольклора, оно не браузер. Что хорошо подтверждается тем, что никакого TLS 1.1 и TLS 1.2 в доступной сейчас рабочей версии (14.0.835.137) нет. Т.е. можно сказать проще – на сегодняшний день, 2.10.2011, все поддерживаемые хромом виды безопасных соединений на основе SSL/TLS уязвимы для сентябрьской атаки и данный инструмент не имеет смысла использовать для, допустим, финансовых транзакций, онлайн-платежей и прочих security sensitive штук.
Opera
Поставил оперу 11.51. Пожалуй, тут лучше всех сделано – можно не только выставить нужные протоколы (доступен выбор из SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2), но и нужные комплекты алгоритмов. Делается это зайдя в меню, там – Settings -> Preferences -> Advanced -> Security -> Security Protocols -> Details.
Правда, сделано плохо, потому что при включенном варианте “TLS 1.0 + 1.1 + 1.2” согласовывать начинает с TLS 1.0. Специально перепроверил, плюс посмотрел через netmon – удивительно, реально начинает с 1.0, согласовывает и успокаивается. Т.е. если включить все эти 3 протокола в Internet Explorer, то на тестовых сайтах клиент будет определяться как “TLS 1.2 compatible”, а в случае оперы – “TLS 1.0”. Плохо, по сути перечеркивает всё преимущество тонкой настройки – т.е. ну поддерживает она 1.2, что с того-то, если согласовывать пробует 1.0 для начала. То есть или надо вручную выключать TLS 1.0 (тогда бо
www.atraining.ru
Мы включили TLS 1.3. Почему вам стоит сделать то же самое / Qrator Labs corporate blog / Habr
В начале года, в отчете о проблемах и доступности интернета за 2018-2019 мы уже писали, что распространение TLS 1.3 неизбежно. Некоторое время назад мы сами развернули версию 1.3 протокола Transport Layer Security и, после сбора и анализа данных, наконец, готовы рассказать об особенностях этого перехода.
Председатели рабочей группы IETF TLS пишут:
«Вкратце, TLS 1.3 должен предоставить фундамент более безопасного и эффективного Интернета на следующие 20 лет».
Разработка TLS 1.3 заняла долгих 10 лет. Мы в Qrator Labs, вместе со всей остальной отраслью, внимательно следили за процессом создания протокола от первоначального проекта. За это время потребовалось написать 28 последовательных версий черновика для того, чтобы в конечном счёте в 2019 году свет увидел сбалансированный и удобный в развертывании протокол. Активная поддержка TLS 1.3 рынком уже очевидна: внедрение проверенного и надежного протокола безопасности отвечает требованиям времени.
По словам Эрика Рескорлы (технического директора Firefox и единственного автора TLS 1.3) в интервью The Register:
«Это полная замена TLS 1.2, использующая те же ключи и сертификаты, поэтому клиент и сервер могут автоматически общаться по TLS 1.3, если оба его поддерживают», — сказал он. «Уже есть хорошая поддержка на уровне библиотек, а Chrome и Firefox по умолчанию включают TLS 1.3».
Параллельно в рабочей группе IETF TLS заканчивается подготовка RFC, объявляющего старые версии TLS (за исключением только TLS 1.2) устаревшими и непригодными для использования. Вероятнее всего, финальный RFC увидит свет до конца лета. Это ещё один сигнал IT-индустрии: обновление протоколов шифрования не стоит откладывать.
Список текущих реализаций TLS 1.3 доступен на Github для всех, кто ищет наиболее подходящую библиотеку: https://github.com/tlswg/tls13-spec/wiki/Implementations. Очевидно, что принятие и поддержка обновленного протокола будет — и уже идет — быстрыми шагами. Понимание того, насколько фундаментальным стало шифрование в современном мире, распространилось достаточно широко.
Что изменилось по-сравнению с TLS 1.2?
Из заметки Internet Society:
«Как TLS 1.3 делает мир лучше?
TLS 1.3 включает определённые технические преимущества — такие, как упрощенный процесс рукопожатия (handshake) для установления безопасного соединения — а также позволяет клиентам быстрее возобновлять сессии с серверами. Эти меры призваны уменьшить задержку на установку соединения и количество неудачных соединений на слабых каналах, которые часто используются в качестве оправдания для предоставления только нешифрованных HTTP-соединений.
Не менее важно и то, что устранена поддержка нескольких устаревших и небезопасных алгоритмов шифрования и хеширования, которые все еще разрешено (хотя и не рекомендуется) использовать с более ранними версиями TLS, включая SHA-1, MD5, DES, 3DES и AES-CBC, одновременно добавляя поддержку новых наборов шифров. Другие усовершенствования включают в себя больше зашифрованных элементов рукопожатия (например, теперь зашифрован обмен информацией о сертификате), чтобы уменьшить объем подсказок потенциальному перехватчику трафика, а также улучшения в forward secrecy при использовании определенных режимов обмена ключами, так что связь в любой момент времени должна оставаться безопасной, даже если алгоритмы, используемые для ее шифрования, будут скомпрометированы в будущем».
Разработка современных протоколов и DDoS
Как вы, возможно, уже читали, во время разработки протокола и даже после, в рабочей группе IETF TLS возникали серьезные противоречия. Уже теперь очевидно, что отдельным предприятиям (включая финансовые учреждения) придется изменить способ обеспечения безопасности собственной сети для того, чтобы приспособиться к ныне встроенной в протокол perfect forward secrecy.
Причины, по которым это может потребоваться, изложены в документе, написанном Стивом Фентером. В 20-страничной бумаге упоминается несколько примеров, когда предприятие может захотеть выполнить расшифровку out-of-band трафика (что PFS делать не позволяет), в целях мониторинга, соответствия нормативным требованиям или обеспечения защиты от DDoS-атак на прикладном уровне (L7).
Хотя мы определенно не готовы рассуждать о нормативных требованиях, наш собственный продукт для нейтрализации прикладных DDoS-атак (включая решение, не требующее раскрытия чувствительной и/или конфиденциальной информации) был создан в 2012 году с учётом PFS, поэтому нашим клиентам и партнёрам никаких изменений в их инфраструктуре после обновления версии TLS на стороне сервера производить не потребовалось.
Также, за прошедшее с момента внедрения время никаких проблем, связанных с транспортным шифрованием, выявлено не было. Официально: TLS 1.3 готов к использованию в продакшене.
Впрочем, есть всё же проблема, связанная с разработкой протоколов следующего поколения. Она заключается в том, что обычно прогресс в развитии протоколов в IETF сильно зависит от результатов научных исследований, а состояние академических исследований в отрасли нейтрализации распределенных атак на отказ в обслуживании — весьма плачевное.
Так, хорошим примером может выступать раздел 4.4 черновика IETF “QUIC Manageability” («Управление QUIC»), являющегося частью будущего набора протоколов QUIC: в нем говорится, что «современные методы обнаружения и нейтрализации [DDoS-атак] обычно включают пассивное измерение с использованием данных о сетевых потоках».
Последнее, на самом деле, очень редко встречается в реальных корпоративных средах (и лишь отчасти применимо к интернет-провайдерам), и в любом случае вряд ли является «общим случаем» в реальном мире — но постоянно фигурирует в научных публикациях, обычно не подкрепленных тестированием всего спектра потенциальных DDoS-атак, включая атаки прикладного уровня. Последние, в силу хотя бы всемирного развертывания TLS, очевидно никак не могут быть обнаружены пассивным измерением сетевых пакетов и потоков.
Аналогично, мы пока не знаем, как производители оборудования для нейтрализации DDoS будут адаптироваться к реалиям TLS 1.3. Из-за технической сложности поддержки out-of-band протокола, может уйти некоторое время на апгрейд.
Постановка правильных целей для направления научных исследований — серьёзная задача для провайдеров услуг нейтрализации DDoS. Одна из областей, в которой можно начать развитие — исследовательская группа SMART в IRTF, где исследователи могут сотрудничать с отраслью для уточнения собственных знаний в проблемной отрасли и поиска новых направлений исследований. Мы также готовы тепло поприветствовать всех исследователей, если таковые найдутся — с нами можно связаться по вопросам или предложениям, связанным DDoS-исследованиями или с исследовательской группой SMART, по адресу [email protected]
habr.com
TLS 1.3 признан стандартом / ИТ-ГРАД corporate blog / Habr
Ранее мы писали, что Инженерный совет Интернета (IETF) одобрил новую версию TLS — 1.3. На прошлой неделе протокол был признан стандартом. Сегодня — поговорим о его возможностях.
/ фото Charles Dyer CC
Особенности TLS 1.3
Над обновлением протокола начали работать еще в 2014 году. Неофициально работа над TLS 1.3 закончилась в марте этого года, однако инженерам понадобилось еще несколько месяцев на проведение дополнительных проверок.
Создатели утверждают, что итоговый вариант TLS 1.3 — более безопасный и производительный: в его алгоритмах шифрования закрыты все известные (на сегодняшний день) уязвимости TLS 1.2, а процесс «рукопожатия» проходит в два раза быстрее, чем у предшественника. Разработчики также добавили forward secrecy и новые фичи вроде 0-RTT.
В TLS 1.3 внесли самое большое количество значимых изменений за всю историю протокола. По этой причине некоторые даже предлагали назвать его TLS 2.0.
Теперь, когда новая версия протокола TLS 1.3 (RFC 8446) официально одобрена, осталось реализовать его для всех подключений по сети.
Сложности с реализацией
TLS обладает своеобразной обратной совместимостью. При установлении соединения между клиентом и сервером происходит обмен поддерживаемыми версиями протокола и выбирается та, с которой могут работать обе стороны. Однако эта возможность используется не везде. С появлением TLS 1.3 более 3% серверов с поддержкой TLS 1.2 просто разрывали соединение вместо того, чтобы отправлять клиенту номер поддерживаемой версии.
Похожая проблема возникла с промежуточными узлами (middlebox). Из-за того, что TLS особо не менялся, штуки вроде файрволов, NAT и балансировщиков нагрузки отказались работать с новой версией протокола.
Этот феномен инженеры окрестили оссификацией (окостенение). Тот факт, что некоторые разработчики не используют гибкие возможности протокола, внедрение новых его реализаций затрудняется. В качестве аналогии участники индустрии приводят пример со старой дверью. Если ее долго не трогать, петли ржавеют, и та открывается со скрипом.
/ фото Christopher Sessums CC
Получается, что предыдущий протокол устарел, но внедрить новый по умолчанию не получится. Больше по теме можно почитать, например, в прошлогоднем исследовании от IEEE (PDF).
Решение проблемы нашел Дэвид Бенджамин (David Benjamin), работающий над Chromium. Он предложил замаскировать первое сообщение от клиента, поддерживающего TLS 1.3, под сообщение TLS 1.2. И это сработало: упомянутые 3% серверов перестали разрывать соединение. Для узлов-посредников Кайл Некритц (Kyle Nekritz) из Facebook предложил использовать тот же подход. Это позволило сократить число сбоев на 6,5% в Chrome и на 2% в Firefox.
Чтобы проверить, совместимы ли middlebox’ы с новой версией протокола, можно воспользоваться тестом, разработанным в Cloudflare.
Как упростить внедрение
Как утверждает Эрик Рескорла (Eric Rescorla), один из разработчиков спецификаций для TLS и HTTPS, в целом внедрить TLS 1.3 не так уже и сложно. Инженерный совет старался сделать этот процесс максимально простым. TLS 1.3 использует те же ключи и сертификаты, что и TLS 1.2. Это позволяет клиенту и серверу автоматически устанавливать соединение по TLS 1.3, если они оба поддерживают новую версию протокола.
Кроме того, есть ряд библиотек, которые помогут развернуть протокол быстрее. К примеру, в начале прошлой недели Facebook передали свою библиотеку TLS 1.3 Fizz в open source. Fizz уменьшает латентность при трансляции данных, а также нагрузку на CPU.
Разработчики подготовили руководство, как начать пользоваться Fizz на Ubuntu 16.04 LTS. Оно находится в официальном репозитории на GitHub (там также есть руководство для MacOS).
Сперва нужно установить необходимые зависимости folly и libsodium:
sudo apt-get install \
g++ \
cmake \
libboost-all-dev \
libevent-dev \
libdouble-conversion-dev \
libgoogle-glog-dev \
libgflags-dev \
libiberty-dev \
liblz4-dev \
liblzma-dev \
libsnappy-dev \
make \
zlib1g-dev \
binutils-dev \
libjemalloc-dev \
libssl-dev \
pkg-config \
libsodium-dev
Далее нужно собрать и установить folly:
git clone https://github.com/facebook/folly
mkdir folly/build_ && cd folly/build_
cmake configure ..
make -j $(nproc)
sudo make install
Затем можно переходить к установке Fizz:
cd ../..
git clone https://github.com/facebookincubator/fizz
mkdir fizz/build_ && cd fizz/build_
cmake configure ../fizz
make -j $(nproc)
sudo make install
Помимо Fizz в сети есть и другие библиотеки, например, wolfSSL, GnuTLS или rustls.
Будущее протокола
Чтобы окончательно разрешить проблему с «окостенением» протокола, Дэвид Бенджамин предложил помимо официальной версии стандарта использовать ряд его вариаций, которые будут выпускаться каждые шесть недель (вместе с релизами новых версий Chrome). Таким образом, серверы и промежуточные узлы будут обязаны соблюдать все правила установления соединения, иначе большая часть клиентов не сможет подключаться к сервисам.
За счет этого разработчики надеются избежать возможных сбоев загрузки веб-страниц, а также аналогичных проблем с будущими версиями TLS.
Ожидается, что общая безопасность в сети после внедрения TLS 1.3 значительно вырастет. А поспособствовать массовому распространению должны будут библиотеки, упрощающие развертывание новой версии протокола.
P.S. Другие материалы из нашего блога о корпоративном IaaS:
Чем мы занимаемся в ИТ-ГРАД — основные направления:
Виртуальная инфраструктура (IaaS) | PCI DSS хостинг | Облако ФЗ-152
habr.com
Различия между SSL и TLS / Varonis Systems corporate blog / Habr
Хроническая эпидемия расстройства восприятия лиц у жителей Метрополиса, из-за которой никто не замечает, что Кларк Кент и чудаковатый летающий пришелец, похожий на него как две капли воды, — это в действительности одно и то же лицо, распространяется и на технический сектор, где мы постоянно спорим о том, насколько строго нужно различать протоколы SSL и TLS.
Справедливости ради стоит сказать, что это не ситуация из разряда «SSL с Земли, TLS с Криптона», а достойный подражания пример постоянного усовершенствования стандартов шифрования и отказа от устаревших и ненадежных методов обмена данными между клиентами и серверами для повышения общей безопасности Интернета.
Более 20 лет назад компания Netscape разработала версию 1.0 протокола SSL (Secure Sockets Layer), чтобы в браузерах можно было просматривать страницы Geocities и обмениваться ASCII-графикой по мотивам «Звездного пути», не беспокоясь о безопасности.
Версии SSL 1.0–3.0, как и все первые попытки создать эффективный алгоритм шифрования, подверглись критике из-за наличия серьезных проблем с безопасностью, в связи с чем потребовался выпуск нескольких доработанных версий с улучшенной архитектурой системы безопасности.
В 1999 году была выпущена версия 1.0 протокола TLS (Transport Layer Security): tools.ietf.org/html/rfc2246. Название было изменено для того, чтобы подчеркнуть открытый характер стандарта, благодаря чему кто угодно мог использовать его в своих проектах, и тем самым отделить его от фирменного продукта компании Netscape (которая на тот момент еще продавала программное обеспечение для веб-серверов Netscape Enterprise Server, использующее SSL для шифрования данных из внешних каналов). Кроме того, протокол TLS разрабатывался как протокол, независимый от приложений, тогда как SSL изначально планировалось использовать только для подключений HTTP.
В лингвистическом противостоянии («Как называется протокол, при использовании которого появляется зеленый замочек?») победил термин SSL. Если вам нужно доказательство, посмотрите сравнение «SSL и TLS» на сайте Google Trends.
Именно поэтому в материалах об общей концепции или при рассказе об этой концепции людям без профильных знаний используется общепринятый термин SSL, так как он у всех на слуху, а правильное понимание терминологии в таких вопросах имеет огромное значение.
При обсуждении _протокола_ как такового и версий SSL/TLS, которые должны быть включены, более правильным будет термин TLS.
Однако на практике специалисту по обеспечению безопасности и администрированию необходимо знать следующее.
• Существуют различные версии SSL/TLS.
• При несовпадении протоколов более старые системы не могут обмениваться данными с более новыми. Если вы когда-либо задумывались над тем, почему браузер Internet Explorer при установке Windows 95 на новом компьютере не открывает сайты HTTPS, то теперь вы знаете ответ.
• Необходимо создать корпоративную политику, позволяющую включать только более поздние версии TLS (номер текущей версии — 1.2).
• Многие устройства и приложения по-прежнему поддерживают устаревшие и небезопасные версии TLS/SSL, которые необходимо отключать специально.
В общем и целом вопрос «В чем заключается разница между SSL и TLS?» очень интересен, если обсуждать только практические моменты и доказывать, почему мелкие различия между протоколами безопасности так важны.
habr.com