Что такое ssl-сертификат и чем он опасен

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного , нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

server {
  server_name sheensay.ru www.sheensay.ru;

  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP

  # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице
  add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report";

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже:
  ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048
  ### После генерации расскомментируем строку ниже
  ssl_dhparam /etc/letsencrypt/dhparam.pem;
  
  ### Дальше другие настройки сервера
  ### ...

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

Сертификаты

Хотя Алиса может послать банку секретное сообщение, подписать его, и быть уверенной, что оно не будет изменено, ей нужно быть уверенной, что открытый ключ в действительности принадлежит банку. Банк тоже должен быть уверенным в том, что цифровая подпись действительно принадлежит Алисе. Если каждый имеет сертификат, в котором сказано кто его владелец, содержится открытый ключ и все это подписано доверенной организацией, то они могут полагать, что они связываются действительно с теми, с кем предполагалось. Такая доверенная организация называется центром сертификации (Certificate Authority, CA), и сертификаты используются для аутентификации.

Содержимое сертификата

Содержимое сертификата:

Субъект: отличительное имя, открытый ключ
Кем выдан: отличительное имя, подпись
Сроки действия: дата начала действия, дата окончания действия
Служебная информация: версия, порядковый номер
Расширения:

Отличительное имя используется для идентификации в определенном контексте (например, человек может иметь личный сертификат и сертификат как сотрудник фирмы). Отличительные имена определены в стандарте X.509 [], в котором определены имена, их аббревиатуры и требования к содержанию. Центр сертификации может определить правила, в которых определено какие поля обязательны, а какие нет. Могут так же определяться требования к содержимому полей. Например, браузер Netscape требует, чтоб в поле Common Name сертификата сервера было регулярное выражение для его доменного имени (например *.opengroup.org).

Отличительное имя:

общее имя (CN) Имя субъекта, например CN=Frederick Hirsch
Организация или компания (O) Имя данной организации, например O=The Open Group
Организационная единица (OU) Имя организационной единицы, отдела, подразделения и т. п., например, OU=Research Institute
Город/Расположение (L) Город, в котором расположен субъект, например Cambridge
Область/Район (SP) Область/Район, например Massachusetts
Страна (C)
  
  -----BEGIN CERTIFICATE-----
  
  -----END CERTIFICATE-----
  

6.5.1.2. Формат информационных записей SSL

Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном ниже порядке):

MAC-DATA
ACTUAL-DATA
PADDING-DATA

ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA — это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code).

Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:

MAC-DATA = HASH

где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA>, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи — «big endian»).

MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).

Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).

SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются.

Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай «I/O Error» (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).

Окончательная проверка соответствия выполняется, когда используется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место «I/O Error» (что вызовет разрыв соединения).

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

Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.

Редирект с http на https

После установки вам захочется, чтобы все пользователи работали по защищенному соединению. Да и поисковые системы должны произвести склейку, иначе будет какая-то неразбериха: один и тот же сайт с http и https будет считаться как два разных. Нам нужно, чтобы это не произошло. Поэтому мы должны настроить редиректы.

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

Просто добавляем в начало файла этот кусок кода и вуаля – ваш сайт имеет 301-й редирект с http на https.

Теперь мы можем проверить наличие переадресации, просто зайдя на сайт без прописывания протокола (или с http протоколом). Если мы все сделали правильно, то нас перекинет на https://сайт.ру.

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

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

Например, добавить в файл robots.txt строчку Host с указанием главного зеркала вашего веб-ресурса. Там же нужно прописать и https-протокол, чтобы поисковые системы считали этот вариант приоритетным.

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

Принцип работы SSL[править]

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

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

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

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

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

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

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

Устройство протокола 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);

Включение и отключение TLS 1.2Enable and Disable TLS 1.2

Используйте следующие разделы реестра и их значения для включения и отключения TLS 1,2.Use the following registry keys and their values to enable and disable TLS 1.2.

Включите протокол TLS 1.2.Enable TLS 1.2

  • «Enabled»=dword:00000001 «Enabled»=dword:00000001
  • «DisabledByDefault»=dword:00000000 «DisabledByDefault»=dword:00000000
  • «Enabled»=dword:00000001 «Enabled»=dword:00000001
  • «DisabledByDefault»=dword:00000000 «DisabledByDefault»=dword:00000000

Отключение протокола TLS 1.2Disable TLS 1.2

  • «Enabled»=dword:00000000 «Enabled»=dword:00000000
  • «DisabledByDefault»=dword:00000001 «DisabledByDefault»=dword:00000001
  • «Enabled»=dword:00000000 «Enabled»=dword:00000000
  • «DisabledByDefault»=dword:00000001 «DisabledByDefault»=dword:00000001

Включение и отключение SSL 2,0Enable and Disable SSL 2.0

Используйте следующие разделы реестра и их значения для включения и отключения SSL 2,0.Use the following registry keys and their values to enable and disable SSL 2.0.

Включение SSL 2,0Enable SSL 2.0

  • «Enabled» = DWORD: 00000001 «Enabled»=dword:00000001
  • «DisabledByDefault» = DWORD: 00000000 «DisabledByDefault»=dword:00000000
  • «Enabled» = DWORD: 00000001 «Enabled»=dword:00000001
  • «DisabledByDefault» = DWORD: 00000000 «DisabledByDefault»=dword:00000000

Отключение SSL 2,0Disable SSL 2.0

  • «Enabled» = DWORD: 00000000 «Enabled»=dword:00000000
  • «DisabledByDefault» = DWORD: 00000001 «DisabledByDefault»=dword:00000001
  • «Enabled» = DWORD: 00000000 «Enabled»=dword:00000000
  • «DisabledByDefault» = DWORD: 00000001 «DisabledByDefault»=dword:00000001

Зачем нужен этот сертификат

В последнее время остается все меньше сайтов, у которых нет сертификата SSL. Но когда возникает вопрос: а зачем он нужен, первый ответ – ну Google же требует. Ответ на самом деле формальный. На деле же речь идет об очень важных вещах – безопасности и защите информации. Сегодня пользователи оставляют на сайтах не только разнообразные персональные данные, но и более «опасную» информацию, например, номера счетов или реквизиты банковских карт. Задача владельца сайта – сделать так, чтобы эти данные не попали в руки злоумышленников. Именно поэтому Google отдает предпочтение тем сайтам, которые защищают персональную информацию от «угона».

Как проверить сертификаты SSL/TLS

Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.  

SeoLik

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

Проверяем наличие HTTPS соединения:

  1. Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ». 
  2. В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков. 

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

SSL Shopper

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

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

Wormly Web Server Tester

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

  1. Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
  2. Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires». 

Данный сервис позволяет просматривать шифры сертификатов, что может быть полезно для веб-разработчиков. 

Immuni Web

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

При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report». 

SSL Checker

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

На этом моя статья подходит к концу. Теперь вы знаете, как можно проверить SSL и TLS сертификаты на сайте

Спасибо за внимание!

Про установку SSL-сертификатов вы можете почитать тут и тут.

Почему SSL-сертификат — это важно

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

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

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

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

И, конечно, наличие рассматриваемого сертификата играет важную роль для продвижения сайта в одной из популярных поисковых систем (ПС) — Google. Если еще несколько лет назад доля сайтов с SSL среди лидеров поисковой выдачи составляла всего 30%, сегодня она больше 80%.

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

Какие преимущества дает использование SSL?

Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам — это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей

В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе — крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.

В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.

Похожие темы

  • SSL on ISC, Part 1: What is SSL and why should I care? (EN): оригинал статьи.
  • Self-signed server certificate (EN): пошаговая инструкция по созданию собственного сертификата
  • IBM Workplace Collaboration Services information center (EN): в этой статье объясняется, какие компоненты в различных Web-браузерах требуют подписанных проверенных сертификатов.
  • WebSphere Application Server and IBMJSSE (EN) — на этой странице ресурса InfoCenter приведена дополнительная информация по SSL.
  • Launch the ISC console thru Web Browser (EN): в этой статье показано, как запустить Integrated Solutions Console через Web-браузер после установки.(EN)
  • Embed the Integrated Solutions Console installation (EN) (developerWorks, март 2005 г.): эта статья демонстрирует, как с помощью установщика встраивать Integrated Solutions Console в другие продукты.
  • Дополнительная информация по Java, продуктам Tivoli и WebSphere products, Eclipse, безопасности а также безопасности имеется в соответствующих разделах сайтов developerWorks и alphaWorks.
  • Скачайте версию Integrated Solutions Console и ознакомьтесь с дополнительной информацией об этом продукте в Autonomic Computing Toolkit.(EN)
  • WebSphere Application Server 6.1 — это платформа для приложений на базе Java 2 Enterprise Edition и Web-сервисов. Кроме обычной версии, предлагаются также версия Express (включающая сервер приложений J2EE, примеры приложений, инструменты разработчика и мастера), а также бесплатная упрощенная версия Community Edition.(EN)

Управление протоколами TLS и SSL, а также комплектами шифровManaging the TLS/SSL Protocols and Cipher Suites

Важно!

В этом разделе содержатся инструкции по изменению реестра.This section contains steps that tell you how to modify the registry. При неправильном изменении реестра могут возникнуть серьезные проблемы.However, serious problems might occur if you modify the registry incorrectly. Поэтому будьте внимательны и в точности следуйте инструкциям.Therefore, make sure that you follow these steps carefully.

Имейте в виду, что изменение параметров безопасности по умолчанию для канала SCHANNEL может привести к нарушению или предотвращению обмена данными между определенными клиентами и серверами.Be aware that changing the default security settings for SCHANNEL could break or prevent communications between certain clients and servers. Это происходит, если требуется безопасная связь и у них нет протокола для согласования связи с.This will occur if secure communication is required and they do not have a protocol to negotiate communications with.

При применении этих изменений они должны быть применены ко всем AD FSным серверам в ферме.If you are applying these changes, they must be applied to all of your AD FS servers in your farm. После применения этих изменений требуется перезагрузка.After applying these changes a reboot is required.

В сегодняшний день и возраст, усиление защиты серверов и удаление старых или слабых комплектов шифров становится основным приоритетом для многих организаций.In today’s day and age, hardening your servers and removing older or weak cipher suites is becoming a major priority for many organizations. Доступны пакеты программного обеспечения, которые проверяют серверы и предоставляют подробные сведения об этих протоколах и наборах.Software suites are available that will test your servers and provide detailed information on these protocols and suites. Чтобы сохранить соответствие требованиям или обеспечить безопасность, удаление или отключение более слабых протоколов или наборов шифров стало необходимостью.In order to remain compliant or achieve secure ratings, removing or disabling weaker protocols or cipher suites has become a must. В оставшейся части этого документа содержатся инструкции по включению и отключению определенных протоколов и комплектов шифров.The remainder of this document will provide guidance on how to enable or disable certain protocols and cipher suites.

Приведенные ниже разделы реестра расположены в том же расположении: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.The registry keys below are located in the same location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Используйте Regedit или PowerShell, чтобы включить или отключить эти протоколы и комплекты шифров.Use regedit or PowerShell to enable or disable these protocols and cipher suites.

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-рукопожатия

Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.

Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.

На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.

6.5.2.4. Сообщения протокола диалога SSL

Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).

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

char MSG-EXAMPLE
char FIELD1
char FIELD2
char THING-MSB
char THING-LSB
char THING-DATA;

Эта нотация определяет данные в протокольном сообщении, включая код типа сообщения. Порядок передачи соответствует порядку перечисления.

Для записи «THING-DATA», значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий