ЛЕКЦИЯ 12. SSL-СЕРТИФИКАТ: СОДЕРЖАНИЕ, ФОРМИРОВАНИЕ ЗАПРОСА, ПРОВЕРКА ДАННЫХ С ПОМОЩЬЮ СЕРВИСОВ

1.  SSL-сертификат

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

Цифровые SSL-сертификаты (сокращение от Secure Socket Layer) — это стандартная интернет-технология безопасности, которая используется, чтобы обеспечить зашифрованное, безопасное соединение между веб-сервером (сервером) и браузером (сайтом, клиентом)  по открытым каналам связи.

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

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

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

Для того чтобы активировать возможность работы протокола HTTPS, как раз и нужны цифровые SSL-сертификаты.

Обмен данными в SSL

Процесс обмена данными при помощи протокола SSL представлен на рисунке.

Рисунок - . Взаимодействие клиента и сервера при помощи протокола SSL

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

Сеанс SSL характеризуется следующими значениями.

·         Идентификатор сеанса (Session_ID) - случайное число, генерируемое на стороне клиента и позволяющее вернуться к уже установленному сеансу.

·         Сертификаты узла (Client_Certificate и Server_Certificate) - сертификат участника информационного взаимодействия в соответствии со стандартом ISO/IEC 9594-8[3GPP TR 21.905: Vocabulary for 3GPP Specifications.].

·         Метод сжатия - алгоритм сжатия передаваемых данных. Поддерживаемые алгоритмы указаны в RFC 3749[EMV ICC Specification for Payment Systems.].

·         Спецификация шифра - определяет параметры криптоалгоритмов:

o    для обмена ключами и проверки их подлинности: криптосистема с открытым ключом RSA, протокол выработки общего секретного ключа Диффи—Хеллмана (Diffie—Hellman), DSA (Digital Signature Algorithm), Fortezza.

o    для симметричного шифрования: RC2, RC4, DES, 3DES, IDEA, AES;

o    для хеширования: SHA, MD5.

·         Секретный ключ сеанса (Master_Secret) - разделяемый клиентом и сервером секретный ключ.

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

·         Соединение SSL характеризуется следующими значениями.

·         Случайные числа (Client_Random и Server_Random), применяемые при выработке общего секретного ключа.

·         Ключи для шифрования/расшифрования информации (Client_Write_Secret = Server_Read_Secret и Server_Write_Secret = Client_Read_Secret).

·         Ключи для подписи сообщений (секретные Server_ MAC_Write_Secret и Client_MAC_Write_Secret).

·         Векторы инициализации (Server_IV и Client_IV) - синхропосылки для блочных алгоритмов шифрования.

·         Два последовательных числа для сервера и клиента, предотвращающие атаки перехвата и повтора сообщения.

Протоколы SSL

SSL включает в себя четыре протокола:

Протокол 1. Handshake. Данный протокол предназначен для взаимной аутентификации клиента и сервера, установки сеанса или соединения.

Установка сеанса, схематично представленная на рисунке3, как правило, инициализируется клиентом при помощи сообщения ClientHello (иногда инициатором выступает сервер, посылая сообщение HelloRequest, символизирующее о том, что сервер готов к процедуре Handshake), в котором клиент передает следующие параметры:

·         версия SSL, поддерживаемая клиентом;

·         идентификатор сеанса - значение, по которому впоследствии можно возобновить сеанс;

·         случайное число Client_Random;

·         список алгоритмов сжатия, шифрования и хеширования информации, поддерживаемых клиентом.

В ответ на это сообщение сервер высылает сообщение ServerHello, содержащее следующие параметры:

·         версия SSL, поддерживаемая сервером;

·         случайное число Server_Random;

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

Кроме этого сообщения сервер высылает свой сертификат. В том случае, если используемые алгоритмы требуют сертификата клиента, сервер высылает клиенту запрос на сертификат - CertificateRequest. Затем сервер высылает клиенту сообщение ServerHelloDone, символизирующее об окончании передачи сообщения ServerHello.

Если клиент не поддерживает алгоритмы, предложенные сервером, или не выслал свой сертификат в ответ на соответствующий запрос, то установка сеанса прерывается. В противном случае клиент проверяет сертификат сервера, генерирует Pre_Master_Secret, зашифровывает его на открытом ключе сервера, полученном из сертификата последнего, и отсылает полученное значение в сообщении ClientKeyExchange. Сервер расшифровывает полученное сообщение при помощи своего секретного ключа и извлекает Pre_Master_Secret. Таким образом, обе стороны (клиент и сервер) обладают тремя значениями - Server_Random, Client_Random и Pre_Master_Secret и могут выработать Master_Secret по схеме, представленной на рисунке.

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

На рисунке  схематично представлена установка соединения.

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

В ответ на сообщение ClientHello сервер высылает сообщение ServerHello, содержащее Server_Random. Зная Server_Random, Client_Random и Master_Secret клиент и сервер могут выработать значения, характеризующие текущее соединение (риунок)

Выработка параметров соединения

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

Протокол 2. Record. Данный протокол предназначен для преобразования данных, передаваемых сеансовым уровнем транспортному и обратно. Преобразование данных происходит по схеме, приведенной на р

 Обработка данных в протоколе Record

Передаваемая отправителем информация разбивается на блоки размером не более 2^14 + 2048 байт каждый. Затем каждый блок сжимается при помощи выбранного алгоритма сжатия. После этого вычисляется MAC каждого блока и прикрепляется к последнему. Полученные фрагменты последовательно нумеруются для предотвращения атак, зашифровываются при помощи выбранного алгоритма и передаются на транспортный уровень. Получатель расшифровывает полученные фрагменты, проверяет последовательность следования их номеров и целостность сообщений. Затем фрагменты распаковываются и объединяются в единое сообщение.

Протокол 3. CSS. Протокол CSS состоит из единственного сообщения, разрешающего протоколу Record осуществлять преобразование данных с использованием выбранных алгоритмов.

Протокол 4. Alert. Данный протокол формирует сообщения об ошибках, возникающих в процессе передачи данных или установки сеанса или соединения. В зависимости от характера ошибок будет выдано предупреждение или разорвано соединение/сеанс. Примеры ошибок приведены в таблице.

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

–  бесплатный способ — это так называемый самоподписной сертификат (self-signed), который можно сгенерировать прямо на веб-сервере. Однако на такой сертификат все браузеры будут выдавать ошибку с предупреждением, что сайт не проверен.

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

–  платные сертификаты, выдаваемые центром сертификации. Данные в сертификате проверены центром сертификации, и при использовании такого сертификата на сайте ваш посетитель никогда не увидит огромную ошибку на весь экран.

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

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

Получение SSL-сертификата включает следующие шаги:

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

- Создание запроса на подпись SSL-сертификата (CSR) на вашем сервере. С этим действием может помочь ваша хостинговая компания.

- Отправка запроса в центр сертификации для проверки данных о вашем домене и компании.

- Установка полученного сертификата после завершения процесса.

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

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

Говоря в общем, SSL-сертификаты содержат и отображают (как минимум одно из) ваше доменное имя, ваше название организации, ваш адрес, город и страницу. Также сертификат всегда имеет дату окончания и данные о центре сертификации, ответственного за выпуск сертификата. Браузер подключается к защищенному сайту, получает от него SSL-сертификат и делает ряд проверок: не просрочен ли сертификат, потом он проверяет, выпущен ли сертификат известным ему центром сертификации (CA), используется ли сертификат на сайте, для которого он был выпущен.

Если один из этих параметров не проходит проверку, браузер отображает предупреждение посетителю, чтобы уведомить, что этот сайт не использует

безопасное соединение SSL. Он предлагает покинуть сайт или продолжить просмотр, но с большой осторожностью.

Что такое центры сертификации (CA)?

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

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

Говоря в общем, SSL сертификаты содержат и отображают (как минимум одно из) ваше доменное имя, ваше название организации, ваш адрес, город и страницу. Также сертификат всегда имеет дату окончания и данные о центре сертификации, ответственного за выпуск сертификата. Браузер подключается к защищенному сайту, получает от него SSL сертификат и делает ряд проверок: он не просрочен ли сертификат, потом он проверяет, выпущен ли сертификат известным ему центром сертификации (CA) используется ли сертификат на сайте, для которого он был выпущен.

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

Центров сертификации существует достаточно много, вот перечень самых популярных:

Comodo — работает с 1998 штабквартира в Jersey City, New Jersey, США.

Geotrust — основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, США

Symantec — бывший Verisign в состав которого входит и Geotrust. Купил всех в 2010 году.

Thawte — основан в 1995, продан Verisign в 1999.

Trustwave — работает с 1995, штабквартира Chicago, Illinois, США.

Как видим самый крупный игрок на рынке SSL сертификатов это Symantec, который владеет тремя крупнейшими центрами сертификации — Thawte, Verisgin и Geotrust.

Есть ли разница в каком центре сертификации заказывать сертификат?

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

Что касается перечисленных выше центров сертификации, то их корневые сертификаты установлены в, пожалуй, 99,99% всех существующих браузеров.

Чтобы проверить, корневые сертификаты каких центров сертификации установлены в вашем браузере, достаточно в настройках вашего браузера найти такую опцию. (В Chrome Настройки -> показать дополнительные настройки -> управление сертификатами -> Доверенные корневые центры сертификации). В Chrome установлено более 50 таких корневых сертификатов.

Важный момент — частенько у клиентов возникала ситуация, когда SSL сертификат на серверe установлен, но при заходе на сайт браузер все равно выдает ошибку. Такая ситуация может возникнуть или из-за отсутствия в файле ca-bundle.crt корневого сертификата центра выдавшего сертификат или из-за того, что корневой сертификат устарел. Корневые сертификаты также имеют свой срок действия (в браузерах они обновляются при обновлении браузера).

С июля 2010 года сертификационные центры перешли на использование ключей 2048bit RSA Keys, поэтому для корректной работы всех новых сертификатов необходимо устанавливать новые корневые сертификаты.

Если новые корневые сертификаты не установлены — это может вызвать проблемы с корректной установкой сертификата и распознаванием его некоторыми из браузеров.

2.  Принцип работы SSL-сертификата

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

Публичный ключ не является секретным, и он помещается в запрос CSR.

Вот пример такого запроса:

-----BEGIN CERTIFICATE REQUEST----- MIIC3zCCAccCAQAwgZkxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIEw

RLaWV2MQ0wCwYDVQQHEwRLaWV2MRQwEgYDVQQKEwtIb3N0QXV0b2 1hdDEQMA4GA1UECxMHaG9zdGluZzEmMCQGCSqGSIb3DQEJARYXc3Vwc

G9ydEBob3N0YXV0b21hdC5jb20xHDAaBgNVBAMTE3d3dy5ob3N0YXV0b21h dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTg7iUv/i X+SyZl74GcUVFHjFC5IqlTNEzWgLWrsSmxGxlGzXkUKidNyXWa0O3ayJHOiv1 BSX1l672tTqeHxhGuM6F7l5FTRWUyFHUxSU2Kmci6vR6fw5ccgWOMMNdMg7 V5bMOD8tfI74oBkVE7hV95Ds3c594u7kMLvHR+xui2S3z2JJQEwChmflIojGnSC O/iv64RL9vjZ5B4jAWJwrruIXO5ILTdis41Z1nNIx3bBqkif0H/G4eO5WF6fFb7etm 8M+d8ebkqEztRAVdhXvTGBZ4Mt2DOV/bV4e/ffmQJxffTYEqWg8wb465GdAJc LhhiSaHgqRzrprKns7QSGjdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQE AuCfJKehyjt7N1IDv44dd+V61MIqlDhna0LCXH1uT7R9H8mdlnuk8yevEcCRIkrn WAlA9GT3VkOY3Il4WTGg3wmtq6WAgLkVXQnhIpGDdYAflpAVeMKil8Z46B GIhKQGngL2PjWdhMVLlRTB/01nVSKSEk2jhO8+7yLOY1MoGIvwAEF4CL1lAj ov8U4XGNfQldSWT1o8z9sDeGsGSf5DAXpcccx0gCyk90HFJxhbm/vTxjJgchUFro

/0goVpBcredpKxtkwBMuCzeSyDnkQft0eLtZ9b9Q4+ZNDWsPPKxo/zWHm6Pa/4F 4o2QKvPCPx9x4fm+/xHqkhkR79LxJ+EHzQ==

-----END CERTIFICATE REQUEST-----

Данные, которые содержатся в этом ключе, можно легко проверить с по- мощью сервисов CSR Decoder. Как пример: CSR Decoder 1 или CSR Decoder 2. Второй сервис выдает больше информации о CSR и проверяет ее на валидность, поле Signature в результатах проверки.

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

CSR Information:

Common Name: tuthost.ua — доменное имя, которое мы защищаем таким сертификатом.

Organization: TutHost — название организации, которой принадлежит до мен

Organization Unit: Hosting department — подразделение организации. Locality: Kiev — город, где находится офис организации.

State: Kiev — область или штат.

Country: UA — двухбуквенный код страны офиса.

Email: support@tuthost.com — контактный email технического админист ратора или службы поддержки.

Важный момент — обратите внимание на поле Country — формат этого поля подразумевает только двухбуквенный код по стандарту ISO 3166-1, если вы не уверены в коде вашей страны, то проверить его можно например тут: Таблица ISO-3166-1.

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

После того как CSR сгенерирован, можно приступать к оформлению за- явки на выпуск сертификата. Во время этого процесса центр сертификации (CA — Certification Authority) произведет проверку введенных вами данных и в случае успешной проверки выпустит SSL-сертификат с вашими данными и даст возможность вам использовать HTTPS. Ваш сервер автоматически сопоставит выпущенный сертификат со сгенерированным приватным ключом. Это означа- ет, что вы готовы предоставлять зашифрованное и безопасное соединение меж- ду вашим сайтом и браузером клиентов.

В SSL-сертификате хранится следующая информация:

–  полное (уникальное) имя владельца сертификата;

–  открытый ключ владельца;

–  дата выдачи SSL сертификата;

–  дата окончания сертификата;

–  полное (уникальное) имя центра сертификации;

–  цифровая подпись издателя.

3.  Виды SSL-сертификатов

Между собой сертификаты отличаются свойствами и уровнем валидации.

Типы сертификатов по типу валидации:

–  сертификаты, которые подтверждают только доменное имя (Domain Validation — DV);

–  сертификаты, которые подтверждают домен и организацию (Organiza- tion Validation — OV);

–  сертификаты с расширенной проверкой (Extendet Validation — EV).

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

Важный момент, что это письмо может быть отправлено только на так называемый approver email, который вы указываете при заказе сертификата. И к адресу approver email есть определенные требования, он должен быть либо в том же домене, для которого вы заказываете сертификат, либо он должен быть указан в whois домена. Если вы указываете email в том же домене, что и серти- фикат, то указывать любой emal тоже нельзя, он должен соответствовать одно- му из шаблонов:

admin@,

administrator@,

 hostmaster@,

postmaster@,

webmaster@.

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

стоит помнить, что есть небольшой шанс, что ваш сертификат будет выпущен не моментально.

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

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

Сертификаты с валидацией организации. В таком сертификате уже бу- дет указано название организации. Такой сертификат частное лицо получить не может. Срок выдачи таких сертификатов, как правило, от 3 до 10 рабочих дней и зависит от центра сертификации.

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

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

- Наличие организации в международных желтых страницах — проверяется не всеми центрами сертифации

- Наличие в whois домена названия вашей организации — а вот это уже проверят обязательно, и если такое название там не указано от вас скорей всего затребуют гарантийное письмо, в котором нужно указать, что домен действительно принадлежит организации, иногда могут затребовать подтверждение от регистратора

- Свидетельство о государственной регистрации — требуют все реже, чаще сейчас производится проверка через специальные компании, которые производят проверку существования организации по своим каналам. Например для Украины вас могут проверить по базе ЕДРПОУ

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

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

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

Сертификаты с расширенной проверкой. Это самые дорогие сертифи- каты, и получить их сложнее всего. В таких сертификатах есть так называемый green bar — т. е. при входе не сайт, где установлен такой сертификат, в адрес- ной строке браузера посетителя появится зеленая строка, в которой будет ука- зано название организации, получившей сертификат.

Вот как это выглядит на сайте у Thawte .

Зеленая строка

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

SSL-cертификаты с расширенной проверкой (EV) выпускаются только тогда, когда центр сертификации (CA) выполняет две проверки, чтобы убедить- ся, что организация имеет право использовать определенный домен, к тому же центр сертификации выполняет тщательную проверку самой организации. Процесс выпуска сертификатов EV стандартизирован и должен строго соотве- ствовать правилам EV, которые были созданы на специализированном форуме CA/Browser Forum в 2007 г.

Там указаны необходимые шаги, которые центр сертификации должен выполнить перед выпуском EV сертификата:

1.       Должен проверить правовую, физическую и операционную деятельности субъекта.

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

3.       Необходимо убедиться, что организация имеет исключительное право на использование домена, указанного в сертификате EV.

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

Список того, что конкретно будут проверять такой же как и для сертификатов с проверкой организации.

EV-сертификаты используются для всех типов бизнеса, в том числе для государственных и некоммерческих организаций. Для выпуска необходимо 10– 14 дней.

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

Типы SSL-сертификатов по своим свойствам:

–  обычные SSL-сертификаты — это сертификаты, которые выпускают- ся автоматически и подтверждают только домен. Подходят для всех сайтов;

–  SGC-сертификаты — сертификаты с поддержкой повышения уровня шифрования. Актуально для очень старых браузеров, которые поддерживали

–  только 40- или 56-битное шифрование. При использовании этого сертификата уровень шифрования принудительно повышается до 128 бит;

–  Wildcard-сертификаты — нужны в том случае, когда кроме основного домена нужно обеспечить шифрование также на всех поддоменах одного доме- на. Например, есть домен domain.com и вам нужно установить такой же серти- фикат на support.domain.com, forum.domain.com и billing.domain.com;

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

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

·           payments.yourdomain.com

·           login.yourdomain.com

·           mail.yourdomain.com

·           download.yourdomain.com

·           anything.yourdomain.com

– SAN-сертификаты — применяется, если необходимо использовать один сертификат для нескольких разных доменов, размещенных на одном сер- вере. Обычно в такой сертификат входит 5 доменов, и их количество можно увеличивать с шагом в 5;

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

– сертификаты c поддержкой IDN — как правило, не у всех центров сертификации указана эта опция в описании сертификата, но не все сертифика- ты поддерживают работу с IDN-доменами.

Список сертификатов, у которых есть такая поддержка:

Thawte SSL123 Certificate,

Thawte SSL Web Server,

Symantec Secure Site,

Thawte SGC SuperCerts,

Thawte SSL Web Server Wildcard,

Thawte SSL Web Server with EV,

Symantec Secure Site Pro,

Symantec Secure Site with EV,

 Symantec Secure Site Pro with EV

Можно ли использовать SSL-сертификат на нескольких серверах?

Один SSL-сертификат можно использовать для нескольких доменов на одном сервере. В зависимости от поставщика, можно также использовать один SSL-сертификат на нескольких серверах. Это позволяют мультидоменные SSL-сертификаты, описанные выше.

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

Мультидоменные SSL-сертификаты также называются SAN-сертификатами. SAN означает альтернативное имя субъекта. Каждый мультидоменный сертификат имеет дополнительные поля (например, альтернативные имена субъектов), которые можно использовать для перечисления дополнительных доменов, чтобы на них распространялся один сертификат.

Сертификаты унифицированных коммуникаций (UCC) и Wildcard-сертификаты также можно применять на нескольких доменах и, в последнем случае, на неограниченном количестве поддоменов.

Как выбрать самый дешевый сертификат?

У Geotrust самые дешевые SAN сертификаты. Сертификаты с валидацией только сайта, а также wildcard выгоднее всего у RapidSSL. EV сертификаты самые дешевые также у Geotrust. SGC сертификаты есть только у Thawte и Verisign, но у Thawte дешевле.

Чем еще отличаются сертификаты между собой

·                     Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего с EV валидацией, от 7 рабочих дней.

·                     Количество перевыпусков сертификата — у большинства центров сертификации неограниченно. Требуется, если допустили ошибку в данных об организации.

·                     Гарантия — для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрауда и потеряет деньги, то центр сертификации обязуется их ему компенсировать до суммы указанной в гарантии. То есть центр сертификации как бы дает гарантию на свои сертификаты и что их невозможно установить на «левый» домен. На практике такие случае мне не известны поэтому на этот параметр можно не обращать внимание.

·         Бесплатный тестовый период — из платных сертификатов есть у symantec secure site, geotrust rapidssl, comodo positive ssl, thawte ssl web server. Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free

·         Возврат средств — есть почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода moneyback

Полезные утилиты:

1.       OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
http://www.openssl.org/

2.       CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
CSR Decoder 1 или CSR Decoder 2

3.       DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
http://www.digicert.com/help/?rid=011592
http://www.sslshopper.com/ssl-checker.html

Что происходит по истечении срока действия SSL-сертификата?

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

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

Раньше SSL-сертификаты могли выдаваться на срок до пяти лет, который впоследствии был сокращен до трех лет, а в последнее время до двух лет плюс возможность использовать дополнительные три месяца. В 2020 году Google, Apple и Mozilla объявили, что будут применять годовые SSL-сертификаты, несмотря на то, что это предложение было отклонено Центрами сертификации / Форумом браузеров. Это решение вступило в силу в сентябре 2020 года. Не исключено, что в будущем срок действия SSL-сертификатов сократится еще.

Когда срок действия SSL-сертификата истекает, соответствующий сайт становится недоступным. Когда пользователь открывает веб-сайт в браузере, в течение нескольких миллисекунд проверяется действительность SSL-сертификата (в рамках подтверждения SSL-соединения). Если срок действия SSL-сертификата истек, посетители сайта получат сообщение: «Этот сайт небезопасен. Существуют возможные риски».

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

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

Если срок действия сертификата истечет, сертификат станет недействительным, и выполнять безопасные транзакции на веб-сайте станет невозможно. Центр сертификации предложит обновить SSL-сертификат до истечения срока его действия.

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

Как узнать, есть ли у сайта SSL-сертификат

Самый простой способ узнать, есть ли у сайта SSL-сертификат – обратить внимание на следующие элементы в адресной строке браузера:

·         Если веб-адрес начинается с HTTPS, а не с HTTP, значит он защищен с помощью SSL-сертификата.

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

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

.

КОНТРОЛЬНЫЕ ВОПРОСЫ

Общие сведения и принципы работы

1.      Что такое SSL-сертификат и для каких целей он используется?

2.      На каких уровнях модели OSI работает протокол SSL и какое это дает преимущество?

3.      Какой протокол обеспечивает безопасное соединение благодаря SSL-сертификату?

4.      Что такое SSL-сеанс и чем он отличается от SSL-соединения?

5.      Каков типичный срок действия SSL-сеанса?

6.      Перечислите основные характеристики, которыми характеризуется SSL-сеанс.

7.      Какие случайные значения используются при установлении SSL-соединения и для чего?

8.      Что такое Master_Secret и как он формируется?

Протоколы SSL
9. Назовите четыре протокола, входящих в состав SSL.
10. Какова основная функция протокола Handshake?
11. Какие параметры клиент передает серверу в сообщении ClientHello?
12. Что происходит, если клиент не поддерживает алгоритмы, предложенные сервером в ServerHello?
13. Какую роль в протоколе Handshake играет сообщение Finished?
14. Опишите процесс преобразования данных в протоколе Record.
15. Как протокол Record защищает передаваемые данные от атак?
16. Для чего предназначен протокол Change Cipher Specification (CSS)?
17. Какие типы сообщений формирует протокол Alert? Приведите примеры трех ошибок из таблицы.

Получение и содержание SSL-сертификата
18. В чем основное различие между самоподписанным (self-signed) SSL-сертификатом и сертификатом, выданным центром сертификации (CA)?
19. Каковы основные шаги процесса получения SSL-сертификата от центра сертификации?
20. Что такое CSR (Certificate Signing Request) и какие ключи создаются при его формировании?
21. Какую информацию содержит CSR? Укажите минимум 5 полей.
22. Почему важно правильно указывать двухбуквенный код страны в CSR?
23. Какая информация хранится в самом SSL-сертификате? Перечислите не менее 5 пунктов.
24. Какие проверки проводит браузер при подключении к сайту с SSL-сертификатом?

Центры сертификации (CA)
25. Что такое Центр сертификации (CA) и какова его роль?
26. Почему использование сертификата от неизвестного CA может привести к ошибке в браузере?
27. Назовите три крупных центра сертификации, упомянутых в лекции.
28. Что такое корневой сертификат и где он хранится?
29. Какая проблема может возникнуть, если на сервере не установлен актуальный корневой сертификат CA?

Типы SSL-сертификатов по уровню проверки (валидации)
30. Какие три основных типа SSL-сертификатов выделяют по уровню валидации?
31. Опишите процесс проверки для получения сертификата с проверкой домена (Domain Validation - DV).
32. Что такое "approver email" и каковы требования к нему для DV-сертификатов?
33. Какая информация отображается в адресной строке браузера при использовании DV-сертификата?
34. Чем сертификат с проверкой организации (Organization Validation - OV) отличается от DV?
35. Какие данные организации проверяются при выпуске OV-сертификата?
36. Что такое EV-сертификат и как он визуально выделяется в браузере?
37. Каковы стандартизированные шаги, которые CA должен выполнить перед выпуском EV-сертификата?
38. Какой тип сертификата рекомендуется для сайтов, связанных с онлайн-платежами, и почему?

Типы SSL-сертификатов по свойствам
39. Для чего предназначены Wildcard-сертификаты? Приведите пример.
40. Что такое SAN-сертификат (или мультидоменный сертификат) и в чем его преимущество?
41. Для решения каких задач были созданы SGC-сертификаты?
42. Какие сертификаты поддерживают работу с IDN-доменами (приведите 2-3 примера из списка)?
43. На какой срок могут выдаваться SSL-сертификаты согласно современным требованиям?

Практические аспекты, управление и проверка
44. Можно ли использовать один SSL-сертификат на нескольких серверах? Если да, то какие типы сертификатов это позволяют?
45. Каковы основные критерии при выборе самого дешевого сертификата среди разных CA?
46. Что такое "гарантия" у SSL-сертификата и для кого она предназначена?
47. Что происходит, когда срок действия SSL-сертификата истекает?
48. Почему срок действия SSL-сертификатов ограничен и со временем сокращается?
49. Как можно узнать, защищен ли сайт с помощью SSL-сертификата, взглянув на адресную строку браузера?
50. Назовите три полезные утилиты, упомянутые в лекции, и для чего каждая из них используется

Общие сведения и принципы работы

51.    Какие два типа криптографических ключей создаются на веб-сервере при формировании CSR?

52.    Какова роль протокола HTTPS по отношению к SSL-сертификату?

53.    Что означает аббревиатура SSL и какова ее расшифровка?

54.    Почему SSL считается аппаратно-независимым протоколом?

55.    Какие существуют основные подвиды SSL-сертификатов?

56.    Что такое «зеленая строка» (green bar) и при использовании какого сертификата она появляется?

57.    Какова типичная максимальная длина блока данных, обрабатываемого протоколом Record?

58.    Что такое сеансовый ключ (Master_Secret) и для чего он используется?

Протоколы SSL

59.  Какое сообщение протокола Handshake символизирует о готовности сервера к процедуре «рукопожатия»?

60.   Что содержится в сообщении ServerHelloDone и какую функцию оно выполняет?

61.  Как клиент и сервер приходят к общему значению Master_Secret после обмена случайными числами?

62.   Для чего в протоколе Record вычисляется и добавляется к блоку данных MAC (Message Authentication Code)?

63.  Что такое вектор инициализации (IV) в контексте SSL-соединения и для каких алгоритмов он используется?

64.   Какое единственное сообщение содержит протокол Change Cipher Specification (CSS)?

65.   Как протокол Alert классифицирует ошибки (например, предупреждение или фатальная ошибка)?

66.   Приведите пример ошибки из протокола Alert, которая приводит к немедленному разрыву соединения.

67.   Что происходит после отправки сообщения Finished обеими сторонами в протоколе Handshake?

Получение и содержание SSL-сертификата

68.   Какой email считается «approver email» для подтверждения права на домен при получении DV-сертификата?

69.   Что такое самоподписной (self-signed) сертификат и в каких случаях его использование оправдано?

70.    Какую информацию обязательно содержит SSL-сертификат, выданный центром сертификации?

71.   Что такое цифровая подпись издателя в SSL-сертификате и какую роль она играет?

72.  Почему срок действия SSL-сертификатов ограничен и не длится вечно?

73.   Каков типичный срок действия современных SSL-сертификатов согласно стандартам CA/Browser Forum?

74.   Что такое запрос на подпись сертификата (CSR) и какую информацию он в себе заключает?

Центры сертификации (CA)

75.    Какова основная функция центра сертификации (CA) в процессе выпуска SSL-сертификатов?

76.   Почему корневой сертификат центра сертификации должен быть установлен в браузере пользователя?

77.   Какие известные центры сертификации были упомянуты в лекции как крупнейшие игроки на рынке?

78.  Что может произойти, если на сервере отсутствует актуальный корневой сертификат центра сертификации?

79.  Какие шаги предпринимаются центром сертификации для проверки организации при выпуске OV-сертификата?

Типы SSL-сертификатов по уровню проверки (валидации)

80.    Какой тип SSL-сертификата обеспечивает наивысший уровень доверия и визуально выделяется в браузере?

81.  В чем заключается разница между DV, OV и EV сертификатами с точки зрения уровня проверки?

82.  Какой тип сертификата рекомендуется для сайтов, не связанных со сбором данных или онлайн-платежами?

83.  Что такое «гарантия» у SSL-сертификата и для кого она предназначена?

84.  Какой тип сертификата требует проверки прав организации на использование домена и ее юридического статуса?

Типы SSL-сертификатов по свойствам

85. Что такое Wildcard-сертификат и для каких целей он используется?
86. Какое преимущество предоставляет SAN-сертификат (мультидоменный) по сравнению с обычным SSL-сертификатом?
87. Для каких браузеров и сценариев были разработаны SGC-сертификаты?
88. Какой тип сертификата позволяет защитить неограниченное количество поддоменов одного домена?
89. Какие типы сертификатов поддерживают работу с IDN-доменами?
90. Какой тип сертификата рекомендуется для использования на нескольких физических серверах?

Практические аспекты, управление и проверка

91. Какие утилиты можно использовать для проверки корректности CSR перед отправкой в центр сертификации?
92. Что такое OpenSSL и для каких задач она применяется в контексте SSL-сертификатов?
93. Как проверить, правильно ли установлен SSL-сертификат на сервере?
94. Какие действия необходимо предпринять при истечении срока действия SSL-сертификата?
95. Какие методы используются для автоматического обновления SSL-сертификатов?
96.Как можно визуально определить, что соединение с сайтом защищено SSL-сертификатом?
97 Что такое «смешанный контент» (mixed content) и как он влияет на безопасность сайта?
98. Какие организации и стандарты регулируют срок действия и требования к SSL-сертификатам?
99. Какие шаги необходимо выполнить для продления SSL-сертификата до истечения его срока действия?
100. Какова роль протокола OCSP (Online Certificate Status Protocol) в проверке действительности SSL-сертификата?

ЗАДАНИЯ

Раздел 1: Основы SSL

1.      Объясните, какое место в модели OSI занимает протокол SSL и какие преимущества ему это дает.

2.      Опишите своими словами, какую основную проблему решает SSL-сертификат при передаче данных между браузером и сервером.

3.      Сравните понятия «сеанс SSL» и «соединение SSL». Чем они характеризуются и как связаны между собой?

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

5.    Схематично изобразите и подпишите все этапы и сообщения протокола Handshake при установке нового сеанса. Включите в схему обмен ClientHello, ServerHello, сертификатами, ClientKeyExchange и Finished.

6.    Сравните роли секретных ключей Client_Write_Secret и Client_MAC_Write_Secret в рамках одного SSL-соединения. Объясните, для каких целей используется каждый из них.

7.    Проанализируйте таблицу ошибок протокола Alert. Определите, какие из ошибок (например, bad_record_mac, handshake_failure) являются фатальными и немедленно разрывают соединение, а какие допускают его продолжение. Обоснуйте свой выбор.

8.    Опишите полный жизненный цикл фрагмента данных в протоколе Record: от получения от приложения, через сжатие, добавление MAC, шифрование и до передачи на транспортный уровень.

Раздел 2: Протоколы SSL

5.       

6.       

7.       

8.       

9.      Детально опишите процесс установки сеанса по протоколу Handshake. Какие сообщения передаются между клиентом и сервером и какую роль играет Pre_Master_Secret?

10.  Объясните, чем процедура установки нового сеанса отличается от возобновления существующего.

11.  Опишите шаги обработки данных в протоколе Record от момента получения от приложения до передачи на транспортный уровень.

12.  Каковы функции протоколов Alert и CCS (Change Cipher Specification) в рамках общего процесса SSL?

13.  Проанализируйте таблицу с ошибками протокола Alert. Сгруппируйте ошибки по степени критичности (например, которые приводят к разрыву соединения, и которые являются предупреждениями). Обоснуйте свой выбор.

14. . Объясните, как именно из значений Pre_Master_Secret, Client_Random и Server_Random генерируется общий Master_Secret. Почему для безопасности важен каждый из этих трех компонентов?
15. Составьте сравнительную таблицу алгоритмов, поддерживаемых SSL (RSA, Diffie-Hellman, DES, 3DES, AES, SHA, MD5), указав для каждого: тип (асимметричный/симметричный/хэш), примерную стойкость и современный статус (рекомендован/устарел/небезопасен).

Раздел 3: Получение и содержание сертификата

16. Сравните самоподписанные (self-signed) SSL-сертификаты и сертификаты, выданные центром сертификации (CA). В чем их ключевые различия с точки зрения безопасности, доверия и применения?

17.  Составьте пошаговый алгоритм действий для получения платного SSL-сертификата для вашего домена, начиная с подготовки сервера и заканчивая его установкой.

18.  Объясните, почему при генерации CSR так важен двухбуквенный код страны по стандарту ISO 3166-1. К каким последствиям приведет ошибка в этом поле?

19.  Что такое корневой сертификат центра сертификации и почему его наличие в хранилище браузера критически важно для корректной работы SSL?

20.  Представьте, что SSL-сертификат установлен на сервере, но браузер выдает ошибку. Назовите не менее трех возможных причин этой проблемы, связанных с корневыми сертификатами.

21.  Что такое "цепочка доверия" (Chain of Trust)? Объясните на примере, как браузер, имея корневой сертификат GeoTrust, проверяет сертификат вашего сайта, выпущенный промежуточным центром сертификации Thawte.
22.  Сравните два подхода: использование публичного центра сертификации (например, Symantec) и развертывание собственного Private CA внутри крупной организации. Укажите по 3 преимущества и недостатка для каждого подхода.

Раздел 4: Типы и валидация сертификатов

15.   

16.   

17.   

18.   

19.   

20.   

21.   

22.   

23.  Сравните три типа валидации SSL-сертификатов (DV, OV, EV) по следующим критериям: уровень проверки, скорость выдачи, стоимость, информация, отображаемая в браузере, и типичные сценарии использования.

24.  Опишите процесс подтверждения права на домен для получения DV-сертификата. Что такое «approver email» и каким требованиям он должен соответствовать?

25.  Составьте примерный список документов и действий, которые потребуются от компании для получения OV-сертификата.

26.  Что такое «зеленая строка» (green bar) в браузере и получение какого типа сертификата необходимо для ее появления? Опишите стандартизированный процесс, который должен пройти центр сертификации для выпуска такого сертификата.

27.  Объясните, в чем разница между Wildcard- и SAN-сертификатами. В каком случае вы порекомендуете каждый из них? Приведите конкретные примеры.

28.  Можно ли использовать один SSL-сертификат для нескольких физических серверов? Обоснуйте свой ответ, опираясь на типы сертификатов.

29.  Разработайте пошаговый чек-лист для системного администратора, который только что установил SSL-сертификат на веб-сервер. Чек-лист должен включать пункты для проверки корректности установки, отсутствия ошибок в цепочке доверия и правильности настройки протоколов.
30. . Представьте, что пользователь жалуется на ошибку "certificate_unknown" при переходе на ваш сайт. Составьте алгоритм диагностики для администратора, включающий проверку срока действия, имени в сертификате и наличия корневого сертификата CA в хранилище браузера.

Раздел 5: Практические аспекты и управление

31. Представьте, что вы системный администратор. Вам нужно проверить корректность сгенерированного CSR перед отправкой в центр сертификации. Какие инструменты вы используете и на что именно будете смотреть в результатах проверки?

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

33.  Объясните, почему SSL-сертификаты имеют ограниченный срок действия (не более 27 месяцев). Какие тенденции наблюдаются в индустрии относительно этого срока?

34.  Опишите последствия для веб-сайта и его посетителей, если срок действия SSL-сертификата истечет.

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

36.  Как простой пользователь может визуально определить, что соединение с сайтом защищено SSL-сертификатом? Перечислите все признаки в адресной строке браузера.

37.  Проанализируйте экономическую целесообразность покупки Wildcard-сертификата для домена company.com с 10 поддоменами versus покупки 10 отдельных DV-сертификатов. В расчет включите стоимость, трудозатраты на управление и фактор безопасности.
38. Объясните, почему стоимость EV-сертификата значительно выше, чем DV. Разбейте стоимость на компоненты, соответствующие этапам проверки, которые проводит центр сертификации.

Задания на обобщение и анализ

39. Объясните всю «цепочку доверия» (Chain of Trust) для SSL-сертификата, начиная от корневого сертификата CA в браузере и заканчивая шифрованием данных на конкретном сайте.

40.  Сравните гарантию, предоставляемую некоторыми центрами сертификации, с возможностью неограниченного количества перевыпусков. Для кого предназначена каждая из этих опций и в чем их практический смысл?

41.  Проанализируйте рынок центров сертификации. Почему, несмотря на наличие множества игроков, доминируют несколько крупных компаний (например, Symantec)? Какие факторы являются ключевыми при выборе CA?

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

43. Исследуйте концепцию "Post-Quantum Cryptography". Какие современные алгоритмы в SSL (из перечисленных в лекции) потенциально уязвимы для атак с использованием квантовых компьютеров? Какие алгоритмы рассматриваются в качестве замены?
44.  Спрогнозируйте, как дальнейшее сокращение максимального срока действия SSL-сертификатов (например, до 6 месяцев) повлияет на операционные процессы малого бизнеса и крупных корпораций. Предложите стратегии адаптации.

Раздел 6: Будущие тенденции и угрозы
45. Исследуйте концепцию "Post-Quantum Cryptography". Какие современные алгоритмы в SSL (из перечисленных в лекции) потенциально уязвимы для атак с использованием квантовых компьютеров? Какие алгоритмы рассматриваются в качестве замены?
46. Спрогнозируйте, как дальнейшее сокращение максимального срока действия SSL-сертификатов (например, до 6 месяцев) повлияет на операционные процессы малого бизнеса и крупных корпораций. Предложите стратегии адаптации.

Раздел 7: Взаимодействие с другими технологиями
47. Опишите, как технология OCSP Stapling устраняет две ключевые проблемы стандартной проверки OCSP: нагрузку на серверы CA и потенциальную утечку конфиденциальной информации о поведении пользователей.
48. Объясните, каким образом правильная настройка SSL-сертификата и протоколов влияет на рейтинг сайта в поисковых системах (SEO). Какие конкретные ошибки в конфигурации SSL могут негативно сказаться на SEO?

Раздел 8: Специфические сценарии использования
49. Разработайте инструкцию для веб-разработчика по полному переводу существующего HTTP-сайта на HTTPS. Инструкция должна включать этапы: получение сертификата, настройку сервера, перенаправление трафика и поиск/исправление "смешанного контента" (Mixed Content).
50. Опишите механизм аутентификации с использованием клиентских SSL-сертификатов. Чем процесс Handshake в этом случае отличается от стандартного? Какие сообщения протокола задействованы дополнительно?
51. Сравните уровень доверия, который вызывает у технически подкованного пользователя сайт с DV-сертификатом (замок) и сайт с EV-сертификатом (зеленая строка с названием компании). Обоснуйте, почему EV не является "серебряной пулей" против фишинга.
52. Предложите архитектуру системы управления сотнями SSL-сертификатов для крупного интернет-холдинга. Какие инструменты (платформы управления сертификатами) можно использовать? Как организовать процесс оповещения об истечении срока действия?

Кейс 1: Выбор сертификата для стартапа

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

Задание: Проанализируйте плюсы и минусы использования DV-сертификата от бюджетного CA (например, RapidSSL) versus самоподписанного сертификата для данного сценария. Какой путь вы порекомендуете и почему?

Кейс 2: Слияние компаний и консолидация инфраструктуры

Ситуация: Компания "А" поглотила компанию "Б". Теперь в распоряжении "А" 15 различных доменов и поддоменов компаний "А" и "Б". Текущая система управления SSL-сертификатами хаотична.

Задание: Разработайте стратегию консолидации SSL-сертификатов. Предложите, какие типы сертификатов (Wildcard, SAN/UCC, отдельные) и для каких групп доменов следует использовать, чтобы снизить costs и упростить управление.

Кейс 3: Инцидент с фишингом

Ситуация: Злоумышленники создали фишинговый сайт, внешне неотличимый от сайта вашего банка, и используют на нем легально полученный DV-сертификат для своего домена.

Задание: Объясните, почему DV-сертификат не помешал этой атаке. Какой тип сертификата на настоящем сайте банка мог бы помочь пользователю визуально отличить настоящий сайт от поддельного, и какая информация в браузере об этом сообщила бы?

Кейс 4: Миграция в облако и "сквозное" шифрование

Ситуация: Ваше приложение мигрирует в облако AWS. Пользователи подключаются к Application Load Balancer (ALB). Трафик между ALB и внутренними EC2-инстансами также должен быть защищен.

Задание: Опишите, где и какие SSL-сертификаты должны быть установлены (на ALB, на инстансах?). Нужно ли генерировать отдельные CSR для этого? Предложите архитектуру решения, обеспечивающую сквозное шифрование.

Кейс 5: Поддержка устаревшего оборудования

Ситуация: Крупное промышленное предприятие имеет критически важную внутреннюю систему, которая работает на сервере с ОС Windows Server 2008 R2 и использует самоподписанный сертификат. Старые клиентские машины подключаются к нему без проблем. При замене сертификата на выпущенный CA современные компьютеры работают, а старые — выдают ошибки.

Задание: В чем наиболее вероятная причина ошибок на старых клиентах? Предложите решение, которое обеспечит безопасное соединение для всех клиентов, не обновляя устаревшее ПО.

Кейс 6: Автоматизация и DevOps

Ситуация: Ваша компания использует методологию DevOps и CI/CD. Сервисы развертываются в контейнерах Docker с автоматическим созданием виртуальных хостнеймов (например, service-feature123.app.company.com). Нужно автоматически получать для них валидные SSL-сертификаты.

Задание: Какой подход и инструменты (например, Let's Encrypt, certbot) вы предложите для полной автоматизации получения и обновления SSL-сертификатов для таких кратковременных окружений?

Кейс 7: Аудит безопасности

Ситуация: При внешнем аудите безопасности вашего сайта был выявлен уязвимый алгоритм шифрования (например, RC4) в списке поддерживаемых cipher suites на вашем веб-сервере.

Задание: Опишите пошаговый план действий по устранению этой уязвимости. Какие протоколы (Handshake, Record) будут затронуты изменением настроек? Как убедиться, что после отключения уязвимого алгоритва не нарушится работа легальных клиентов?

Кейс 8: Внедрение HSTS

Ситуация: Вы хотите повысить безопасность своего сайта, внедрив HTTP Strict Transport Security (HSTS). Однако на одном из поддоменов временно используется HTTP для совместимости со старым API.

Задание: Какие риски возникают при включении HSTS с директивой includeSubDomains в данной конфигурации? Как правильно реализовать HSTS, не нарушив работу старого поддомена?

Кейс 9: Проблема с "смешанным" контентом (Mixed Content)

Ситуация: После перевода сайта на HTTPS некоторые элементы страницы (картинки, скрипты) перестали загружаться, и в консоли браузера появились предупреждения о "mixed content".

Задание: Объясните природу этой проблемы с точки зрения браузера и протокола HTTPS. Разработайте план по поиску и исправлению всех источников "смешанного" контента на сайте.

Кейс 10: Юридический кейс: Отзыв сертификата

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

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

Кейс 11: Мультитенантная архитектура

Ситуация: Вы разрабатываете SaaS-платформу, где каждый клиент получает свой поддомен ( client1.yoursaas.com, client2.yoursaas.com). Количество клиентов постоянно растет.

Задание: Сравните два решения: использование одного Wildcard-сертификата для *.yoursaas.com versus выдача отдельного DV-сертификата для каждого поддомена через API (например, Let's Encrypt). Какой вариант выберете вы и почему?

Кейс 12: Проблема с производительностью

Ситуация: После включения HTTPS и установки SSL-сертификата с ключом 4096 бит нагрузка на CPU сервера значительно возросла, что привело к замедлению работы сайта.

Задание: Какие этапы установления SSL-соединения наиболее ресурсоемки? Предложите 2-3 способа снизить нагрузку на сервер, связанную с обработкой SSL/TLS, не отказываясь от шифрования.

Кейс 13: Глобальная CDN и геоблокировки

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

Задание: Где должен быть установлен и как должен быть сконфигурирован SSL-сертификат (на вашем origin-сервере, на серверах CDN?), чтобы геоблокировка продолжала работать корректно?

Кейс 14: Истечение срока действия: Постмортем

Ситуация: Срок действия основного SSL-сертификата на корпоративном портале истек, что привело к простою на 4 часа до момента установки нового сертификата.

Задание: Составьте "постмортем" (post-mortem) анализ этого инцидента. Какие сбои в процессах привели к ситуации? Предложите конкретные технические и организационные изменения (напр., внедрение платформы управления сертификатами, автоматические оповещения), чтобы предотвратить повторение.

Кейс 15: Переход на постквантовую криптографию

Ситуация: Ваша компания работает в высокотехнологичной области и хочет быть готовой к будущим угрозам, связанным с появлением квантовых компьютеров, которые смогут взломать современные алгоритмы (RSA, ECC).

Задание: Исследуйте текущее состояние стандартов в области "post-quantum cryptography". Какие шаги вы можете предпринять уже сейчас, чтобы будущий переход на новые алгоритмы прошел для вашей инфраструктуры максимально гладко?

Кейс 16: OCSP Stapling и конфиденциальность

Ситуация: Для повышения производительности и конфиденциальности вы решили настроить на своем сервере OCSP Stapling.

Задание: Объясните, что такое OCSP Stapling, какую проблему производительности и конфиденциальности он решает? Опишите, как проверить, что он корректно работает на вашем сервере.

Кейс 17: EV-сертификат для некоммерческой организации

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

Задание: Обоснуйте, является ли получение EV-сертификата оправданной инвестицией в данном случае. Какие именно шаги проверки со стороны CA будут проведены для такого фонда, и как это повлияет на доверие доноров?

Кейс 18: Проблема с мобильными приложениями

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

Задание: В чем причина ошибки (unknown_ca)? Как решить эту проблему, не дожидаясь обновления ОС пользователями? (Рассмотрите вариант с Certificate Pinning).

Кейс 19: Идентификация по клиентским сертификатам

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

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

Кейс 20: Собственный Root CA для большой организации

Ситуация: Крупная корпорация с развитой внутренней инфраструктурой (интранет, корпоративные порталы, сервисы) хочет отказаться от покупки сотен публичных сертификатов для внутренних нужд.

Задание: Стоит ли ей развертывать собственный, изолированный Root Certificate Authority? Опишите плюсы, минусы и основные шаги по внедрению такой системы, включая распространение корневого сертификата на все компьютеры сотрудников.

Кейс 21: "Тихая" смена центра сертификации
Ситуация: Ваш провайдер хостинга сменил партнера – центр сертификации с которого он выпускает сертификаты по умолчанию. После автоматического обновления одного из ваших сертификатов некоторые пользователи в регионах Азии начали получать ошибки.
Задание: В чем наиболее вероятная причина ошибок и какие конкретно шаги вы предпримете для диагностики и решения проблемы?

Кейс 22: Сертификат для сервиса с "белым" IP
Ситуация: Вам необходимо обеспечить HTTPS-соединение для доступа к веб-интерфейсу сетевого устройства (например, маршрутизатора или МФУ), доступного только по IP-адресу (например, https://192.168.1.1).
Задание: Возможно ли для этого получить стандартный SSL-сертификат от публичного CA? Если нет, то какие альтернативные решения безопасности вы можете предложить?

Кейс 23: "Замороженный" домен
Ситуация: Компания хочет получить OV-сертификат для домена, но информация в WHOIS скрыта сервисом приватности (Whois Privacy). Центр сертификации отклоняет заявку.
Задание: Каковы возможные пути решения этой проблемы? Опишите процесс подтверждения прав на домен в данной ситуации.

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

Кейс 25: HTTPS для мультипортального приложения
Ситуация: Ваше веб-приложение работает на нестандартных портах (например, https://example.com:3000 и https://example.com:8443).
Задание: Нужен ли отдельный SSL-сертификат для каждого порта? Обоснуйте свой ответ с технической точки зрения.

Кейс 26: Аудит безопасности cipher suites
Ситуация: По результатам внешнего пентеста, ваш сервер поддерживает устаревшие и небезопасные наборы шифров (cipher suites), такие как те, что используют RC4 или алгоритмы без Perfect Forward Secrecy (PFS).
Задание: Составьте подробный план по аудиту текущего списка cipher suites на вашем веб-сервере (например, с помощью утилиты nmap или openssl s_client) и его безопасной настройке, обеспечив совместимость с современными браузерами.

Кейс 27: Проблема с "залипанием" сеанса
Ситуация: Пользователи вашего банковского приложения жалуются, что их сеанс работы не прерывается даже после длительного бездействия, что противоречит политике безопасности банка.
Задание: Объясните, какой параметр SSL-сеанса, описанный в лекции, отвечает за время его жизни. Как администратор может настроить этот параметр на веб-сервере?

Кейс 28: Сертификат для Docker-контейнера
Ситуация: Ваше приложение в Docker-контейнере генерирует CSR и получает сертификат динамически при каждом запуске. Однако это приводит к ошибкам из-за несоответствия закрытого ключа и сертификата при перезапуске контейнера.
Задание: Предложите архитектурное решение для безопасного и надежного управления SSL-сертификатами и ключами в среде с динамически создаваемыми контейнерами.

Кейс 29: Ложное срабатывание антивируса
Ситуация: Антивирусное ПО на компьютерах некоторых пользователей начинает блокировать доступ к вашему сайту, утверждая, что ваш SSL-сертификат "поддельный" или "недоверенный".
Задание: Каковы возможные причины такого поведения антивируса? Какие действия вы предпримете, чтобы убедиться в корректности вашего сертификата и решить проблему с производителем антивируса?

Кейс 30: Миграция с RSA на ECC
Ситуация: Вы хотите перейти с использования RSA-ключей на более современные и эффективные ECC (Elliptic-Curve Cryptography) ключи для вашего SSL-сертификата.
Задание: Опишите преимущества этого перехода. Составьте план миграции, учитывая необходимость проверки совместимости со старыми клиентами и обновления CSR.

Кейс 31: "Одноразовый" сайт для акции
Ситуация: Маркетинговая команда запускает краткосрочную промо-акцию на сайте promo.company.com, который просуществует всего 3 месяца.
Задание: Какой тип сертификата и какой центр сертификации вы посоветуете использовать, чтобы балансировать между стоимостью, скоростью получения и безопасностью?

Кейс 32: Нагрузка на ЦС при отзыве
Ситуация: Крупный центр сертификации, такой как Let's Encrypt, должен отозвать миллионы сертификатов из-за обнаруженной уязвимости в своем инфраструктурном ПО.
Задание: Опишите технические и организационные вызовы, с которыми столкнется CA. Как эта ситуация повлияет на владельцев сайтов и конечных пользователей?

Кейс 33: HTTPS для почтового сервера
Ситуация: Необходимо обеспечить шифрование соединения для веб-клиента почты (mail.company.com) и для протокола IMAPS (порт 993).
Задание: Можно ли использовать один и тот же SSL-сертификат для обеих этих служб? Нужен ли для этого Wildcard или SAN-сертификат? Обоснуйте.

Кейс 34: Проблема с "двойным" сертификатом
Ситуация: Для повышения производительности и совместимости вы решаете использовать одновременно два сертификата на одном веб-сервере: один RSA (для широкой совместимости), и один ECC (для современных клиентов).
Задание: Опишите, как работает механизм выбора сертификата в протоколе TLS во время Handshake (Algorithm Selection). Как правильно настроить сервер для реализации этой схемы?

Кейс 35: Гео-распределенный отказ
Ситуация: У одного из крупнейших центров сертификации происходит глобальный сбой, в результате которого их серверы OCSP и CRL становятся недоступны.
Задание: Как этот сбой повлияет на пользователей, пытающихся посетить сайты с сертификатами от этого CA? Что могут сделать владельцы сайтов, чтобы смягчить последствия?

Кейс 36: Юридическая проверка для нестандартной организации
Ситуация: Международная организация без традиционной юридической регистрации (например, открытый开源-проект или децентрализованная автономная организация - DAO) хочет получить OV или EV сертификат для своего сайта.
Задание: С какими трудностями она столкнется при проверке со стороны центра сертификации? Существуют ли для них легальные пути получения таких сертификатов?

Кейс 37: Атака "день рождения" на Record-протокол
Ситуация: Теоретически, злоумышленник может попытаться использовать коллизию в номерах последовательности фрагментов в протоколе Record для подмены данных.
Задание: Объясните, как механизм последовательной нумерации каждого фрагмента, описанный в лекции, предотвращает эту атаку.

Кейс 38: Сертификат для "Умного дома"
Ситуация: Вы разрабатываете устройство для "умного дома", которое должно безопасно связываться с облачным сервером производителя. Пользователи подключаются к устройству через локальную сеть.
Задание: Какой тип сертификата (самоподписной, от публичного CA, от собственного CA производителя) вы будете использовать на устройстве и почему? Как обеспечить его доверие на стороне клиента?

Кейс 39: "Невидимый" апгрейд TLS
Ситуация: Вы хотите отключить на своем сервере поддержку старого протокола TLS 1.0 и TLS 1.1, оставив только TLS 1.2 и 1.3.
Задание: Как заранее проанализировать, какая доля ваших реальных пользователей будет затронута этим изменением? Какие инструменты или логи вы будете использовать для сбора этой статистики?

Кейс 40: Безопасность против доступности
Ситуация: Ваш сервис критически важен для бизнеса. После ужесточения настроек безопасности SSL (отключение старых протоколов и cipher suites) небольшая, но важная группа партнеров, использующих устаревшее ПО, теряет возможность подключения.
Задание: Предложите стратегию решения этой дилеммы. Рассмотрите варианты: создание специального "легаси-шлюза", убеждение партнеров в обновлении, компромисс в настройках безопасности.

Скачано с www.znanio.ru