Ssl tls что это

Сертификаты SSL и TLS: что это такое, зачем нужны и как выполнить их проверку онлайн

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

Зачем нужна проверка сертификата сайта

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

Существует 2 основных сертификата защиты, но оба они являются развитием одной технологии.

• SSL (Secure Socket Layer) переводится как уровень защищенных сокетов.
• TLS (Transport Layer Security) обозначает безопасность транспортного уровня.

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

Позже на базе этой технологии разработали TLS. Для максимальной защиты разработчики применяют их в связке, что позволяет взаимодействовать с новыми и старыми устройствами. Таким образом, чтобы сохранить репутацию и предотвратить онлайн-воровство, компании устанавливают сертификаты безопасности, которые подтверждают надёжность сайта.

Как работают сертификаты безопасности

Когда TLS и SSL не подключены, соединение между устройством пользователя и сайтом происходит через канал HTTP. Это означает, что все данные открыты, то есть третьи лица могут получить к ним доступ. Если сертификаты безопасности подключены, соединение устанавливается с веб-сервером HTTPS, который защищает конфиденциальную информацию.

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

Какие задачи решает проверка TLS и SSL

По сути, сертификаты безопасности представляют собой уникальную цифровую подпись сайта и выполняют 4 важных задачи.

1. Гарантируют безопасность данных за счёт применения протокола шифрования.
2. Повышает доверие к сайту и компании в целом. Когда пользователь находит в поисковике сайт с TLS или SSL, он видит напротив него символ зелёного замка или щита. Зная, что его данные будут в безопасности, он выберет именно его, а не ресурсы конкурентов без аналогичных обозначений.
3. Даёт возможность подключать сторонние сервисы. Например, многие платёжные системы и голосовые помощники работают только на тех сайтах, подключения к которым происходит через HTTPS протокол.
4. Упрощает SEO-продвижение. Поддержка HTTPS протокола является важным фактором ранжирования в Google.

Какие проблемы могут быть с сертификатами безопасности

Независим от версии браузеры всегда проверяют TLS и SSL. Но даже если с ним всё в порядке, собственники сайтов могут столкнуться с проблемой, когда вылетает сообщение об ошибке сертификата SSL со стороны сервера.

Произойти это может по нескольким причинам.

• Закончился срок активации сертификата.
• Сертификат выдал центр без достаточных полномочий.
• Произошел сброс системного времени.
• Некорректно работает антивирус.
• Какое-либо из расширений препятствует работе сертификата.
• Заражение устройства вирусами.

Как проверить срок действия SSL сертификата сайта

Самая распространённая проблема, по которой сертификат безопасности не работает – это человеческий фактор. То есть владелец сайта или системный администратор банально забыл продлить срок его действия.

Чтобы ситуация не повторилась, целесообразно подключить автоплатёж. А сам срок действия можно уточнить в личном кабинете хостинга.

Как проверить сертификат сайта на подлинность

Это можно сделать с помощью специальных сервисов. Дополнительно они помогут выявить слабые места сайта, поэтому проверка сертификата HTTP актуальна для всех ресурсов, собственники которых заинтересованы в обеспечение информационной безопасности. Рассмотрим самые распространённые инструменты.

Сервис от российских разработчиков, который кроме основной проверки позволяет просканировать порты, узнать свой IP-адрес и выполнить другие действия с сайтом.

Работает он через браузер . На главной странице нужно ввести домен и нажать кнопку «Анализ». После сканирования отобразится подробная информация о TLS и SSL. Проверка SSL сертификата онлайн занимает всего несколько минут.

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

1. Wormly Web Server Tester

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

Wormly Web Server Tester работает по аналогии с предыдущими сервисами. Только можно выбрать формат анализа. Но даже базовая проверка выдаёт сведения о безопасности сайта в разделе «Expires».

Это вариант для тех, кому нужна подробная информация о сайте и сертификатах. В том числе он определяет совместимость PCI DSS, поддержку различных протоколов и т.д. Имя домена нужно ввести на главной странице, затем нажать стрелку напротив. Появится окно с детальными сведениями. Информация о сроке действия сертификата находится в самом конце.

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

Как проверить SSL сертификат сайта на уязвимости

Собственникам крупных платформ кроме информации о подлинности и сроке действия сертификата важно выявить «слабые» параметры и оптимизировать их. В этом помогают более сложные IT-продукты.

• Free SSL Server Test дополнительно может выдавать сведения о контенте третьих лиц, главных наборов шифров, соответствии принципам NIST и т.д. Подробный отчёт доступен для скачивания в PDF.
• COMODO SSL Analyzer информирует о таких параметрах как отпечаток, защита от атак Downgrade, активные наборы шифрования и т.д.
• HowsMySSL проверяет браузер клиента и даёт оценку по 4 ключевым параметрам: версия протокола, сжатие, поддержка session ticket, шифрование.

Кроме того, существует множество инструментов для проверки конкретных уязвимостей: POODLE, FREAK, LogJam, SHA-1

Подобных сервисов довольно много. Чтобы выбрать наиболее подходящий, нужно понять, что именно вы хотите проверить.

Заключение

Сертификаты TLS и SSL необходимы для защиты персональных данных, включая платёжную информацию. Если они подключены, проводить расчёты на сайте безопасно. В статье мы рассмотрели, как посмотреть сертификат сайта и определить возможные уязвимости веб-ресурса. Сделать это можно онлайн, установка программ не требуется. А выбор конкретного продукта для анализа зависит от того, какие именно сведения вы хотите получить.

SSL/TLS

SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.

Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:

• Безопасность: симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицами.
• Аутентификация: «личность» участника соединения можно проверить с помощью асимметричного шифрования.
• Целостность: каждое сообщение содержит код (Message Authentication Code, MAC), с помощью которого можно проверить, что данные не были изменены или потеряны в процессе передачи.

Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).

История SSL

SSL изначально разработан компанией Netscape для добавления протокола — HTTPS в свой веб-браузер Netscape Navigator, потому что компания считала, что безопасное соединение между клиентом и сервером в первую очередь послужит успехом развитию Интернета как инструмента бизнеса.

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

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

Устройство протокола SSL

Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.

Работу протокола можно разделить на два уровня:

• Слой протокола подтверждения подключения (Handshake Protocol Layer)
• Слой протокола записи

Первый слой, в свою очередь, состоит из трех подпротоколов:

• Протокол подтверждения подключения (Handshake Protocol)
• Протокол изменения параметров шифра (Cipher Spec Protocol)
• Предупредительный протокол (Alert Protocol)

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

Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.

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

Протокол записи

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

• Протокол рукопожатия (handshake protocol);
• Протокол тревоги (alert protocol);
• Протокол изменения шифра (the change cipher spec protocol);
• Протокол приложения (application data protocol);

Принцип работы SSL

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

Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.

Сертификат — это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.

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

Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.

Цифровые сертификаты

Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.

Способы получения SSL-сертификата:

• Использовать сертификат, выданный центром сертификации (Certification authority)
• Использовать самоподписанный сертификат
• Использовать «пустой» сертификат

Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки 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)

1. Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (англ. CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
2. Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
3. Клиент проверяет сертификат сервера.
4. Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
5. Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
6. Сервер проверяет сертификат клиента.
7. Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
8. Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
9. Аналогичные действия производит сервер.
10. На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.

Возобновление сессии

1. Клиент посылает сообщение ClientHello, используя ID сессии, которую нужно возобновить.
2. Сервер проверяет, есть ли у него в кэше соответствующий идентификатор. Если есть и сервер способен возобновить сессию, он отсылает клиенту сообщение ServerHello с этим же ID сессии. Если нет, сервер генерирует новый ID сессии и выполняет процедуру handshake с клиентом.
3. Клиент и сервер обмениваются сообщениями ChangeCipherSpec, а затем Finished.
4. Передача данных по защищенному каналу возобновляется.

Протокол записи (TLS Record)

Этот слой защищает данные с помощью ключей, полученных при подтверждении связи, и проверяет целостность и источник входящих сообщений. Он выполняет следующие функции:

• Разбиение исходящих сообщений на блоки нужного размера и «склеивание» входящих сообщений.
• Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
• Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
• Шифрование исходящих сообщений и дешифровку входящих.

После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

Состав записи

• Content type: тип сообщения — подтверждение связи (22), обычное сообщение (23) или оповещение (21).
• Version: версия SSL/TLS.
• Length: длина оставшейся части сообщения.
• Payload: собственно зашифрованные данные.
• MAC: код аутентификации.
• Padding: «отступ» для получения нужного размера сообщения.

Цифровые сертификаты (стандарт X.509)

• Удобный способ показать, что кто-то владеет публичным ключом.
• Выпускаются центрами сертификации (Certificate Authority, CA): GlobalSign, Comodo и др.
• PKI (public key infrastructure) — механизм, регулирующий распространение и использование сертификатов (включая создание, отзыв и проверку подлинности).
• Список доверенных CA поддерживается приложением (у браузеров свои списки).
• Сертификаты подписываются другими сертификатами, что повышает надежность.
• Сертификат может быть отозван. Система поддерживает список таких сертификатов (Certificate Revocation List, CRL). На стороне CA список обновляется каждые несколько часов.

Получение сертификата

1. Пользователь генерирует ключ и посылает запрос серверу CA.
2. CA отвечает сообщением со своим сертификатом.
3. Пользователь собирает данные, необходимые для выдачи сертификата (email, отпечаток ключа и т.д.).
4. Пользователь отправляет данные в CA, зашифровав их публичным ключом CA.
5. CA проверяет полученные данные и отправляет сертификат пользователю.

Структура сертификата

• Собственно сертификат
  • Версия
  • Серийный номер
  • Эмитент (тот, кто выпустил сертификат)
  • Субъект
  • Публичный ключ субъекта
  • Период действия
  • Дополнительные поля

  Меры безопасности в TLS

  • Защита от downgrade-атаки — понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования;
  • Нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения (MAC);
  • Использование ключа в идентификаторе сообщения (только владелец ключа может сгенерировать код аутентификации сообщения).
  • Сообщение, которым заканчивается подтверждение связи («Finished»), содержит хэш всех handshake-сообщений, отправленных обеими сторонами, что позволяет проверить подлинность выбранных параметров TLS-соединения.
  • Псевдослучайная функция делит подаваемые ей на вход данные пополам, применяет к половинкам разные хэш-алгоритмы (MD5 и SHA-1), а затем XOR’ит результаты для получения MAC. Это повышает безопасность в случае, если в одном из алгоритмов обнаружится уязвимость.

  Ключевые отличия SSL и TLS

  • Аутентификация сообщений: в TLS используется HMAC, работающий с любой хэш-функцией (а не только с MD5 или SHA, как в SSL).
  • Генерация ключа: в TLS при создании ключа используется псевдослучайная функция стандарта HMAC; в SSL — RSA, Diffie-Hellman или Fortezza/DMS.
  • Проверка сертификата: в SSL проверка требует передачи сложной последовательности сообщений; в TLS информация о проверке полностью передается в сообщениях во время handshake.
  • Методы шифрования: SSL поддерживает только алгоритмы RSA, Diffie-Hellman и Fortezza/DMS. В TLS отказались от поддержки Fortezza/DMS, но возможно добавление новых методов шифрования в последующих версиях.

  Виды возможных атак

  • Атака по словарю
  • Атака отражением
  • Атака протокола рукопожатия
  • Взлом SSL-соединений внутри ЦОД
  • BEAST атака
  • Раскрытие шифров
  • Атака «злоумышленник посередине»
  • THC-SSL-DOS
  • SSLstrip

  Источники информации

  • SSL and TLS: A Beginner’s Guide
  • Wikipedia: Secure Sockets Layer
  • Inside SSL: The Secure Sockets Layer Protocol
  • Tanenbaum-Structured-Computer-Organization-6th-Edition
  • SSL/TLS Strong Encryption: An Introduction
  • Wikipedia: Transport Layer Security
  • Microsoft Developer Resources: Transport Layer Security Protocol
  • IBM Knowledge Center: Cryptographic security protocols: SSL and TLS
  • Thomas, Stephen. SSL and TLS Essentials: Securing the Web.

  Полезные материалы

  • Криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT
  • How To Create an SSL Certificate on Nginx for Ubuntu 14.04
  • Usage Statistics and Market Share of SSL Certificate Authorities

  Что такое протокол безопасности TLS

  В основе функционирования интернета лежит работа различных протоколов (TCP, IP и других). Все они работают сообща и каждый из них выполняет конкретную функцию.

  В 1995 году был внедрён SSL (англ. Secure Sockets Layer) — криптографический протокол, обеспечивающий безопасную связь между пользователем и сервером. Благодаря его работе можно было безопасно передавать информацию или обмениваться данными. Однако в 2014 году в его работе обнаружили уязвимости. И на основе SSL 3.0 был разработан новый стандарт — TLS.

  Протокол TLS (англ. Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. Протокол работает на трёх уровнях защиты:

  • отвечает за конфиденциальность передаваемых от компьютера к компьютеру данных,
  • проводит аутентификацию,
  • следит за целостностью передаваемой информации.

  При разработке были учтены и исправлены все ошибки предшественника. В отличие от SSL новый протокол регулярно обновляется и продолжает развитие. В настоящее время для защиты соединения применяется только TLS-протокол. Поэтому, когда речь идёт о протоколе SSL, на самом деле подразумевается протокол TLS.

  TLS-протокол лежит в основе безопасного обмена информацией, но не обеспечивает его сам по себе. Чтобы защищённое соединение состоялось, нужно настроить одно из безопасных интернет-соединений, например — FTP (для передачи и загрузки файлов), IMAP/POP3/SMTP (для почтовых протоколов) и HTTPS (для интернет-страниц).

  HTTPS — самый известный протокол безопасного соединения, который защищает данные на уровне браузера.

  

  Однако, чтобы сайт заработал по безопасному соединению HTTPS, нужно выбрать и установить для сайта SSL-сертификат. Подробнее об этом читайте в статье Что такое протокол https и принципы его работы и Что такое secure sockets layer и как работает SSL.

  Параметры безопасности протокола TLS

  Любое действие в сети представляет собой обмен данными между компьютером (сервером) пользователя и сервером, на котором хранится информация. При каждом вводе запроса в поисковую строку, авторизации в аккаунте или переходе с одной страницы сайта на другую, пользователь и сервер взаимодействуют друг с другом. Такие взаимодействия называются транзакциями, а их совокупность — сессией. TLS отвечает за безопасность транзакций и сессии в целом.

  Протокол TLS обеспечивает защиту в три этапа:

  • Handshake,
  • False Start,
  • Chain of trust.

  На этапе TLS Handshake (рукопожатие) происходит согласование параметров соединения (версии протокола, способа шифрования и соединения) между клиентом и сервером. Для этого используется обмен ключами по алгоритму RSA:

  

  Для каждой такой проверки требуется большое количество вычислительных ресурсов. Чтобы не устанавливать новое соединение и не проверять сертификат повторно каждую транзакцию, была разработана процедура TLS False Start.

  TLS False Start (фальстарт) — процедура возобновления сессии. Если транзакции выполняются в пределах одной запущенной сессии, данный этап позволяет пропустить процедуру Handshake. Протокол повторно использует те данные, которые уже были обработаны и подтверждены в начале сессии. При этом каждая сессия имеет свой срок жизни. Как только срок сессии истекает, с помощью TLS Handshake запускается новая сессия.

  Также обязательная процедура TLS-соединения — TLS Chain of trust (цепочка доверия). Она отвечает за аутентификацию между клиентом и сервером. «Цепочка доверия» работает на основе регулярной проверки подлинности — соответствия сертификатов стандартам Сертификационных центров, которые их выдают. Подлинность сертификата регулярно проверяется в течение сессии. Если обнаружится, что сертификат скомпрометирован (то есть данные под его защитой были перехвачены), данные будут отозваны, транзакция не состоится и сессия будет прервана.

  Таким образом, при передаче данных сначала вызывается процедура Handshake или False Start, которая согласовывает параметры, а затем Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации). Подробнее о принципах работы TLS читайте в официальной документации Datatracker.

  Влияние SSL/TLS на SEO

  SEO (Search Engine Optimization, поисковая оптимизация) – это всестороннее развитие и продвижение сайта для его выхода на первые позиции в результатах выдачи поисковых систем (SERPs). Поисковая оптимизация способствует увеличению посещаемости сайта.

  Использование SSL-сертификата влияет на SEO-показатели, однако это влияние является скорее косвенным. С 2015 года Google отдаёт приоритет ранжирования (то есть назначения сайту места в поисковой выдаче) тем сайтам, которые работают по протоколу HTTPS. Такой же политики придерживается компании Яндекс и Mozilla.

  Браузер Google Chrome — один из самых популярных браузеров в рунете. С недавнего времени Chrome отмечает HTTP-сайты как небезопасные:

  

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

  Установка SSL/TLS

  В компании REG.RU вы можете приобрести SSL-сертификат, который работает по TLS версии 1.2. Для этого выберите подходящий сертификат и выполните три шага — закажите, активируйте и установите его на сайт.

  Если вам не удалось создать защищенный канал SSL/TLS или у вас возникли проблемы с настройкой протокола SSL, обратитесь за помощью к нашим специалистам через заявку в службу поддержки.

  Проверка сайта на SSL/TLS

  Помимо быстрой проверки через поисковую строку браузера, любой сайт можно дополнительно проверить на наличие безопасного соединения через специальные сервисы. В статье Как проверить SSL-сертификат мы подробно рассказали про самые популярные сервисы проверки. С их помощью также можно точно определить, по какому протоколу работает сайт.

  Рассмотрим вариант проверки сайта с помощью сервиса SSL Server Test. Для этого:

  В браузере перейдите на страницу SSL Server Test.

  

  В поле «Hostname» введите домен и нажмите Submit:

  

  Дождитесь окончания проверки. В блоке «Configuration» вы увидите протоколы, которые поддерживает сайт:

  Такой результат показывает, что сайт работает по безопасному подключению TLS версии 1.2. Если в результатах выдачи вы увидите «Yes» напротив пунктов SSL 2 или 3 — значит сайту нельзя доверять.

  Помогла ли вам статья?

  Спасибо за оценку. Рады помочь ��

  MNorin.com

  Блог про Linux, Bash и другие информационные технологии

  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 []:it@mycompany.com 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/emailAddress=it@mycompany.com 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/emailAddress=it@mycompany.com 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 []:webmaster@mycompany.com 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/emailAddress=webmaster@mycompany.com 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/emailAddress=it@mycompany.com subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com 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 порт. Конфиг будет выглядеть примерно так:

    ServerAdmin webmaster@mycompany.com DocumentRoot /var/www Options FollowSymLinks AllowOverride None Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all ErrorLog $/error.log LogLevel warn CustomLog $/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 SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown 

  При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

   Listen 443 

  Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

  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 []:iivanov@mycompany.com 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/emailAddress=iivanov@mycompany.com 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/emailAddress=it@mycompany.com subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com 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. Если есть вопросы/дополнения, пишите в комментарии.

  Похожие посты:

  • PHP Warning: require_once(): open_basedir restriction in effect.
  • Параллельное выполнение в bash
  • Как записать терминальную сессию в Linux
  • Где в России можно сдать все LPIC и получить сертификат?
  • Несколько способов ускорить bash-скрипты
  • Создание сети для начинающих. Часть 2.
  • Генератор паролей на bash
  • Сохраняем входящую и исходящую почту в postfix
  • Мониторинг сети при помощи MTR
  • Корпоративная информационная культура
  • Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
  • Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
  • Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
  • Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
  • Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
  • Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
  • Нажмите, чтобы поделиться в Skype (Открывается в новом окне)

  TLS и SSL: Необходимый минимум знаний : 29 комментариев

  1. cl-service.com12.07.2015 в 01:36 CSR клиент генерирует сам при заказе сертификата, где сохранять закрытый ключ также решает клиент, для выпуска сертификата нам не нужен закрытый ключ и клиент нам его никак не передает. Естественно если это происходит на обычном виртуальном, то у администраторов с root доступом к серверу есть доступ и к ключам, которые там хранятся.
  1. mnorin Автор записи 12.07.2015 в 01:52 Так и есть. Но некоторые сертификационные центры генерируют CSR сами, например, WoSign. Клиент и не должен передавать ключ, он должен передавать только sign request. На виртуальном сервере у администраторов хостинга есть доступ вообще ко всему. Но тут есть один момент. Если использовать ключевую фразу, то доступ к сертификату с ключом без нее бесполезен. Хотя тут есть и минус. При запуске сервера придется руками эту фразу вводить, поэтому сервер автоматически стартовать при старте системы не сможет.
  1. mnorin Автор записи 22.09.2016 в 12:25 Как говорится, отрицаешь — предлагай.
     Тема с описанной технологией связана напрямую, потому что именно то, что описано, в большинстве случаев и называют «Как работает SSL».
     Ну и RFC по заявке читателя:
     RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0
     RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
     И да, тебе тоже добра.
  1. mnorin Автор записи 07.10.2016 в 04:31 Какой-то определенной программы для этих целей я еще не встречал, но пару советов по этому поводу могу дать.
     Можно использовать, например, Chromium или Google Chrome. Возьмем, например, сайт https://www.thawte.com/ — компания, которая собственно цифровымисертификатами и занимается.
     В адресной строке будет написано название компании и зеленый замочек. Это значит, что организация проверена, это как минимум SSL OV.
     Если кликнуть на замочек, а в выпавшем окошке «Details», а затем «View Certificate», то можно увидеть информацию о сертификате. Для Thawte сертификат подписан следующим сертификатом: «thawte Extended Validation SHA256 SSL CA», а сертификат для click.alfabank.ru тоже подписан Thawte, но другим сертификатом. Это «thawte EV SSL CA — G3», то есть они тоже проходили Extended Validation.
     Как-то так.
  1. xfiles10.06.2017 в 00:11 зеленую строку с названием организации можно получить только с EV сертификатом ?
  1. Maxim Norin Автор записи 11.06.2017 в 11:30 Насколько я помню, да
  1. Maxim Norin Автор записи 11.01.2017 в 11:34 Я лучше дам ссылку на technet.microsoft.com , раздел «Key exchange». В статье написано, естественно, упрощенно, чтобы просто объяснить принцип работы, при этом не сильно вдаваясь в детали.
  1. Maxim Norin Автор записи 15.01.2017 в 21:34 Вообще различия есть. Корневой сертификат обычно самоподписанный. И он используется исключительно для подписи других сертификатов. Серверный сертификат обычно подписан либо корневым, либо промежуточным, который подписан корневым. Корневые сертификаты распространяются публично в составе обновлений операционных систем, серверные не распространяются. Ну, а с точки зрения криптографии это, в принципе, одно и то же.
  1. Maxim Norin Автор записи 26.01.2017 в 04:03 Добрый день.
     Это не должно так работать однозначно. Обычно в нормальных сертификатах указываются ДНС имена, для которых он выдан (с www и без www).
     То, что вы описываете, бывает либо с сертификатами, в которых DNS-имена не указаны, либо с wildcard-сертификатами.
     Я думаю, что это кривые сертификаты и настройки у хостера все-таки.
     Плюс, возможно на самом сайте захардкожен протокол http в разных местах, поэтому контент отображается частично. Такие проблемы решаются либо проксированием, либо правкой сайта.
  1. Виталий26.01.2017 в 04:12 Спасибо, Максим.
     То, что сайт в одном из компонентов стал криво отображаться из-за захардкоженного http, я понял. Но оказалось, что и в админку стало не попасть для того, чтобы проверить эти косяки )))
     А техподдержка хостера предлагает восстановление из бэкапа ))) Вместо того, чтобы, по моему пониманию, разобраться с настройками сервера, который, несмотря на удаление сертификата, по-прежнему инициирует https-соединение.
     Пока спорил с ними, и читал про SSL, во время чего и попал к Вам на сайт, немного понял, как это должно работать, и что на деле работает некорректно.
     Спасибо за подтверждение моих предположений. Мне следует осваивать тему глубже.
     С уважением,
     Виталий
  1. Maxim Norin Автор записи 10.07.2017 в 23:18 Добрый день. Нужно сгенерировать новые сертификаты с указанием IP в качестве имени сервера (поле CN), оно же FQDN. С уже сгенерированными сертификатами ничего сделать не получится.
  1. Сергей10.07.2017 в 23:41 Что, помимо сертификата, необходимо для доступа по https? Настройка веб-сервера? Ткните в сторону нужного направления.
  1. Maxim Norin Автор записи 10.07.2017 в 23:51 Сертификат, ключ, цепочка сертификатов, которыми подписан сертификат сервера (чаще всего), и да, настройка веб-сервера, нужно в настройках указать путь к файлу сертификата, ключа, иногда к цепочке. Но обычно цепочка просто дописывается в сертификат сервера. В статье как раз есть примеры настройки Nginx и Apache
  1. Maxim Norin Автор записи 05.11.2017 в 02:05 Добрый день.
     Вариантов очень много. С учетом той информации, которую вы сообщили, вот несколько:
     1) Вирусы на вашем компьютере
     2) Сетевые проблемы у провайдера
     3) Происходит фоновое скачивание чего-то (обновления Windows, например, торренты, еще что-то)
     4) Активная работа фоновых приложений (тот же антивирус) или слабый процессор
     5) Давно не перезагружались
     Более точно сложно сказать что-то, вы даже не сказали, о какой операционной системе и каком браузере речь. Тем не менее, очень маленькие шансы, что это связано с самим TLS как-то, больше похоже либо на высокую нагрузку на процессор или сеть, либо на проблему сетевого характера, либо на вирус/троян/зловредное расширение для браузера. Сайты через HTTP открываются быстро?
  1. Maxim Norin Автор записи 28.11.2017 в 01:00 Да, влияет, конечно, как и на передачу по любому другому протоколу, работающему поверх TCP/IP. Потеря пакетов приводит к повторной их передаче как раз на уровне TCP/IP, поэтому разница не должна быть заметна. В теории возможны какие-то дополнительные задержки на стороне отправителя или получателя, связанные с необходимостью кодирования/декодирования пнредаваемых и получаемых данных
  1. xfiles30.11.2017 в 11:21 Дополню ответ автора. Если речь о dial-up скорости и существенные потери, например 5-10%, то http легче влетит в браузер чем https, т.к. на https затрачивается время на подготовку соединенияи. На очень медленных скоростях это будет заметно.
     По теме: https://stackoverflow.com/questions/149274/http-vs-https-performance
  1. Maxim Norin Автор записи 30.11.2017 в 11:40 Полностью поддерживаю
  1. Maxim Norin Автор записи 01.03.2018 в 21:27 Здравствуйте. Без правильного ключа ничего подписать не получится. А ключ, в отличие от сертификата, нигде не публикуется.
  Похожие публикации:

  1. Odex файлы что это
  2. Как добавить шрифт в адоб акробат
  3. Как написать текст наискосок в ворде
  4. Как отправить сообщение себе в ватсап