Сертификат r3 что это

Корневые сертификаты

Наши корневые сертификаты хранятся в надёжном месте и недоступны онлайн. Мы выпускаем сертификаты для пользователей на основе промежуточных сертификатов из следующего раздела. Для дополнительной совместимости с новым Root X2 с различными корневыми хранилищами, мы также подписали его с Root X1.

Активные
ISRG Root X1 ( RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1 )
: der, pem, txt : der, pem, txt
ISRG Root X2 ( ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2 )
: der, pem, txt : der, pem, txt

Мы создали сайты для проверки цепочки сертификатов вплоть до активных корневых.

• ISRG Root X1

Промежуточные сертификаты

Как правило, сертификаты, выпущенные Let’s Encrypt, создаются на основе “R3”, промежуточного RSA. В настоящее время выпуск сертификатов из “E1”, промежуточного ECDSA-сертификата, возможен только для ключей ECDSA из разрешенных аккаунтов. В будущем выпуск сертификатов из “Е1” будет доступен для всех.

Дополнительные промежуточные сертификаты (“R4” и “E2”) зарезервированы для восстановления после стихийных бедствий, и будут использованы только в том случае, если мы потеряем доступ к нашими основным межуточным сертификатам. Мы больше не используем промежуточные сертификаты X1, X2, X3 и X4.

IdenTrust кросс-подписал наши промежуточные сертификаты RSA для дополнительной совместимости.

Активные
Let’s Encrypt R3 ( RSA 2048, O = Let’s Encrypt, CN = R3 )
: der, pem, txt : der, pem, txt (Retired)
Let’s Encrypt E1 ( ECDSA P-384, O = Let’s Encrypt, CN = E1 )
: der, pem, txt
Let’s Encrypt R4 ( RSA 2048, O = Let’s Encrypt, CN = R4 )
: der, pem, txt : der, pem, txt (Retired)
: der, pem, txt
Let’s Encrypt Authority X1 ( RSA 2048, O = Let’s Encrypt, CN = Let’s Encrypt Authority X1 )
: der, pem, txt : der, pem, txt
: der, pem, txt : der, pem, txt
: der, pem, txt : der, pem, txt
: der, pem, txt : der, pem, txt

Кросс-подпись

Промежуточные сертификаты

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

Наши промежуточные RSA-сертификаты подписаны ISRG Root X1. На данный момент ISRG Root X1 пользуется широким доверием, но у наших промежуточных RSA по-прежнему кросс-подпись “DST Root CA X3” IdenTrust (теперь он называется “TrustID X3 Root”) для дополнительной клиент-совместимости. Корневой сертификат IdenTrust существует дольше и поэтому лучше совместим со старыми устройствами и операционными системами (например, Windows XP, Android 7). Вы можете загрузить “TrustID X3 Root” из IdenTrust (или, как вариант, вы можете скачать копию у нас).

Кросс-подпись означает, что каждый из наших промежуточных сертификатов имеет два сертификата, представляющих один и тот же ключ подписи. Один подписан DST Root CA X3, другой подписан ISRG Root X1. Самый простой способ отличить их — посмотреть на поле “Issuer” (издатель).

При настройке web-сервера, администратор указывает не только листовые сертификаты, но и список промежуточных сертификатов. Это помогает браузеру проверить, входит ли листовой сертификат в цепочку доверия, ведущую к корневому сертификату. Почти все операторы серверов будут выбирать для обслуживания цепочку, включающую промежуточный сертификат с субъектом “R3” и издателем “ISRG Root X1”. Рекомендуемое клиентское программное обеспечение Let’s Encrypt, Certbot, выполнит эту задачу без затруднений.

Корневые сертификаты

Как и промежуточные сертификаты, корневые сертификаты могут быть кросс-подписаны, часто для увеличения клиентской совместимости. Наш корневой ECDSA-сертификат, ISRG Root X2 был создан осенью 2020 года и является корневым сертификатом для иерархии ECDSA. Он представлен двумя сертификатами: самоподписанным и подписанным ISRG Root X1.

Все сертификаты, подписанные промежуточным ECDSA-сертификатом “E1”, будут иметь цепочку с промежуточным сертификатом, у которого субъект “ISRG Root X2”, а издатель “ISRG Root X1”. Почти все сервера выберут для обслуживания эту цепочку, поскольку она обеспечивает наибольшую совместимость до тех пор, пока ISRG Root X2 не получит широкого доверия.

Сертификат подписания ответов OCSP

Этот сертификат используется для подписания ответов OCSP для промежуточных Центров Сертификации Let’s Encrypt. Таким образом нам не нужно иметь онлайне-доступ к корневому сертификату, чтобы подписать эти ответы. Копия сертификата подписания включена в ответ OCSP для информирования, дополнительно пользователям ничего делать не нужно.

• ISRG Root OCSP X1 ([Подписанный ISRG Root X1](https://crt. sh/? [der](/certs/isrg-root-ocsp-x1. der), [pem](/certs/isrg-root-ocsp-x1. pem), [txt](/certs/isrg-root-ocsp-x1. txt)

У наших новых промежуточных сертификатов нет OCSP URL-адресов (их информация об отзыве вместо этого используется CRL), поэтому мы не выпустили сертификат подписи OCSP от ISRG Root X2.

Прозрачность сертификата

В Let’s Encrypt мы в нацелены на прозрачность в наших процессах и в сертификатах, которые выпускаем. Мы записываем сертификаты в журнал Certificate Transparency сразу, как только выпускаем их. Все наши сертификаты доступны по ссылкам:

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

Let’s Encrypt — это бесплатный, автоматизированный и открытый Центр Сертификации, созданный для вас некоммерческой организацией Internet Security Research Group (ISRG).

Держи свой трафик в тайне. SSL Pinning — ещё раз о том же самом

Меня зовут Юрий Шабалин, как вы, наверное, уже знаете, я один из основателей компании Стингрей Технолоджиз, разработчика платформы анализа защищенности мобильных приложений iOS и Android.

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



Оглавление

Введение

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

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

Немного про протоколы

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (тех, которые могут содержать ссылки, позволяющие организовать переход к другим документам).

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Последняя на данный момент версия протокола, HTTP/2, описана в спецификации RFC 7540. Также готовится к публикации третяя версия протокола (HTTP/3)

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

Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер), и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.

API многих программных продуктов также подразумевает использование HTTP для передачи данных. Информация при этом может иметь любой формат, например, XML или JSON.

Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80, но могут быть задействованы и другие порты. Если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений.

За описание протокола HTTP простыми словами спасибо вот этой статье.

HTTPS

Описание

Как известно, протокол HTTP передает данные в открытом виде, то есть любой человек в сети может прослушать трафик и прочитать все сообщения, которыми обмениваются стороны. Для того, чтобы предотвратить возможность чтения и модификации запросов, поверх обычного HTTP добавили SSL и появился протокол HTTPS, где буква S расшифровывается как Secure, то есть безопасный. При HTTPS соединении все данные зашифровываются и расшифровать их могут только те, кому они предназначены (отправляющая и принимающая стороны). Реализовано это с применением SSL/TLS уровней защиты (Secure Sockets Layer / Transport Level Security). Давайте посмотрим, что это такое, и чем они отличаются друг от друга.



История версий протоколов SSL/TLS

SSL и TLS — это протоколы для защищенной передачи данных. TLS является прямым продолжением и, если можно так сказать, наследником SSL. Эти протоколы содержат в себе различные шифронаборы (Cipher Suites), которые можно использовать для осуществления операций шифрования, а также разнообразные правила коммуникации и многое другое. Первый протокол появился около 1995 года. От версии к версии он немного трансформировался: в него добавляли новые шифронаборы, убирали устаревшие, исправляли уязвимости и немного меняли сам протокол.

Шифронаборы

Что такое шифронаборы и почему они важны для нас?

Шифронабор — это некоторая строка вида “ TLS_DH_RSA_WITH_AES_256_CBC_SHA256 ”, которая определяет, с использованием каких алгоритмов и по каким правилам будет осуществляться общение клиента и сервера. Давайте разберем по порядку, что за чем следует и что за что отвечает, — понимание этого потребуется нам в дальнейшем.

Protocol ( TLS ) – Протокол, по которому осуществляется соединение, а именно TLS или SSL.

Key Exchange ( DH ) – Алгоритм, по которому осуществляется обмен ключами. Это может быть RSA / DH (Диффи Хелман) / DHE (эфемерный Диффи Хелман) / ECDH (Диффи Хелман на эллиптических кривых) / ECDHE (эфемерный Диффи Хелман на эллиптических кривых) и другие. Чуть позже мы поймем, зачем я в обязательном порядке отметил эфемерные шифронаборы и дал каждому алгоритму расшифровку.

Authentication ( RSA ) – определяет, по какому алгоритму будет проходить аутентификация сторон (RSA / DSA / ECDSA / . )

Stream encryption ( AES_256_CBC ) — определяет, по каким протоколам будет осуществляться шифрование потока. При этом указывается длина ключа и режим (RC4_128 / AES_256_CBC / 3DES_EDE_CBC / . )

Message Authentication ( SHA256 )— определяет, каким алгоритмом будет осуществляться подпись сообщений (MD5 / SHA / SHA256 / . )

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

Даже некоторые регуляторы и мировые стандарты рекомендуют обращать пристальное внимание на используемую версию протокола и применяемые шифронаборы. Если обратиться к PCI DSS, то можно найти рекомендацию по обязательному отключению SSL/early TLS и использованию “Strong Cryptography“.



Выдержка из PCI DSS

При этом, включая только последние версии TLS с правильно настроенными шифронаборами, мы автоматически применяем свойство некоторых алгоритмов — Forward Secrecy (иногда Perfect FS). Его особенность в том, что компрометация сессионных ключей не происходит при компрометации одного из долговременных ключей. Работает эта опция только для эфемерных алгоритмов. То есть, речь идет про шифронаборы, начинающиеся с:

TLS_DHE_* (EDH) Ephemeral DH

TLS_ECDHE _* (EECDH) Ephemeral ECDH

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

TLS handshake (RSA)

Схематично можно изобразить TLS-рукопожатие (процесс установки защищенного соединения) в виде следующей схемы:



TLS-рукопожатие (RSA)

Разберемся простыми словами, что при этом происходит:

Чтобы соединиться с сервером, клиент отправляет ему некоторый Hello-запрос. Условно, он говорит: “Привет сервер, я хотел бы начать с тобой общение“.

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

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

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

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

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

TLS handshake (DHE/ECDHE)

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



TLS-рукопожатие (DHE/ECDHE)

И снова разберем, что происходит, и посмотрим на отличия:

В первой части отличий никаких: клиент также отправляет запрос на подключение к серверу.

Затем сервер так же возвращает клиенту свой публичный ключ из пары ключей вместе с сертификатом.

А вот с этого момента применяются свойства эфемерных шифронаборов, а также немного криптографической магии. Вместо генерации предварительного секрета и его шифрования на публичном ключе, клиентская сторона вырабатывает свою пару ключей Диффи Хелмана, и открытый (публичный) ключ отправляет на сервер.

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

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

После этого на основе Главного секрета вырабатываются сеансовые ключи и начинается процесс передачи зашифрованных данных.

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

Подведем итоги. При использовании TLS_DHE/ECDHE_* сессионный ключ не передается по сети. Общий секрет вырабатывается на основе DH с временными ключами, действительными только для текущей сессии.

К слову, в iOS, при включенном и настроенном App Transport Security, приложение будет использовать PFS по умолчанию. Для детальной настройки реализована возможность управлять этой функцией с помощью ключа NSExceptionRequiresForwardSecrecy в plist файле. Выключение этого режима позволит использовать версии TLS, которые не поддерживают PFS.

“Man In The Middle”, или “Человек посередине“

Теперь, когда мы знаем, что такое HTTPS и как работает установка безопасного соединения, можно поговорить и о такой знаменитой атаке, как “Man In The Middle”. В русскоязычной литературе ее называют “Человек посередине“. Это атака на канал связи, при которой злоумышленник находится в одной сети с вами и обладает контролем над точкой доступа, или каким-то образом может перенаправить вас на свой прокси-сервер внутри сети. Злоумышленник для клиента представляется конечным сервером, а для сервера — клиентом. Он стоит “посередине“ между ними и способен читать и модифицировать трафик, проходящий через него. Но как это может быть реализовано? Ведь трафик зашифрован, и просто так прочитать его не получится. Проще всего это показать на небольшой схеме:



Процесс атаки «Человек посередине»

Если рассмотреть процесс подключения клиента (мобильного приложения) к своему серверу через подконтрольную точку доступа у злоумышленника, то он будет выглядеть так:

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

На этой точке доступа развернут Proxy-сервер, через который проходит весь трафик.

При запросе на соединение со своим сервером, Proxy “представляется” конечным адресатом, и в ответ на клиентский SSL-запрос возвращает свой собственный сертификат со своим публичным ключом.

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

Таким образом, защищенное подключение устанавливается именно со “зловредным“ сервером и он, как принимающая сторона, видит весь трафик.

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

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



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

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

Давайте рассмотрим на практическом примере, как выглядит сертификат при осуществлении прямого соединения и соединения через Proxy. Для этого воспользуемся браузером и замечательным Proxy-сервером с практически неограниченным функционалом — Burp Suite.

Для начала, откроем какой-нибудь сайт по протоколу HTTPS и посмотрим на сертификат, который он нам отдаст. Допустим, мы переходим по адресу https://stingray-mobile.ru/ :



Сертификат сайта при подключении напрямую

Мы видим, что сертификат имеет три шага, подписан промежуточным центром сертификации R3 (в свою очередь, подписанным корневым центром сертификации ISRG Root X1), выдан сроком на один год для доменного имени stingray-mobile.ru . Вместе с сертификатом к нам доставлен открытый ключ и его отпечаток. Обычно здесь содержится много информации: кому выдан, кем выдан, различные мета-данные самого сертификата и организаций, принимавших участие в его выдаче, и многое другое. Корневой центр сертификации ISRG Root X1 находится в списке доверенных внутри наших операционных систем. Это значит, что сертификаты, выданные данной компанией, валидные, и им можно доверять.

Теперь откроем наш прокси Burp Suite и пустим трафик от браузера через него. Вот что мы увидим:



Сертификат сайта при подключении через Proxy

Изменилось абсолютно всё. Корневой центр сертификации теперь некий “PortSwigger CA“, организация, выпустившая сертификат, теперь тоже “PortSwigger“, изменился открытый ключ. Неизменным осталось только имя сервера — stingray-mobile.ru . При этом, мы полностью увидим все данные, которые мы отправили на сервер и которые получили от него:



Дамп трафика в открытом виде

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

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

Другой, более интересный способ заставить пользователя поставить нужный сертификат — прибегнуть к помощи фейковых точек доступа и Captive-порталов. С такими порталами вы наверняка сталкивались при попытке использовать какую-либо публичную сеть. Когда мы нажимаем “подключиться“, открывается страничка с просьбой, например, ввести свой номер телефона и проверочный код из СМС, или посмотреть рекламу, или что угодно еще.

Как злоумышленник может использовать это для своих целей? Возможен такой сценарий: создается публичная точка доступа с популярным именем, например, METRO_FREE или что-то подобное. Далее, формируется Captive-портал с предупреждением о том, что “мы очень заботимся о вашей безопасности и хотим, чтобы вы всегда оставались защищенными”, ну и так далее. А в конце выводится кнопка, при нажатии на которую на подключившееся устройство скачивается сертификат и запускается мастер установки (для этого в запрос надо включить несколько специальных заголовков). Вот, собственно, и все — сертификат на устройстве, установлен, можно смотреть и слушать трафик!

Другой важный вопрос: как заставить пользователей подключиться к фейковой точке доступа? Здесь на помощь приходят сами устройства и их способ определения, к какой точке и как подключаться. Выбор сети для подключения внутри телефонов очень прост: точка доступа идентифицируется по SSID (имени сети) и паролю. То есть, телефон видит сеть со знакомым именем и пытается подключиться к ней с сохраненным паролем (если установлен флаг “автоматическое подключение“). Но, если точка открытая и пароля на ней нет, то ее идентификация происходит только по имени сети. Но что делать, если рядом — две точки с одинаковым именем? Здесь главное, что нужно злоумышленнику, — подключиться к той точке, у которой сигнал выше. Для этого он может сделать следующее: купить направленную антенну, какой-нибудь одноплатник вроде raspberry, настроить Captive-портал, пойти в публичное место с открытым Wi-Fi, назвать свою точку доступа аналогично и ловить подключения! И тогда трафик клиентов, установивших сертификат на свой телефон, станет доступен тому самому “человеку посередине“.

Похоже на сценарий какого-то фильма, далекий от реальности? А вот и нет. Однажды на одной конференции по безопасности в конце второго дня на сцену позвали участника и вручили ему приз — футболку, на которой были напечатаны адрес его электронной почты и пароль от неё. А на другом мероприятии на экран выводились логины и пароли, которые были пойманы в трафике (конечно, на второй день это заметили, и на экране стали выводить всякие неприличные рисунки в ASCII, и этот аттракцион прикрыли).

А вот и не про конференции. Недавно я обедал в достаточно большом ресторане и подключился к местному Wi-Fi. В ожидании заказа решил проверить, что у них там по адресу маршрутизатора. И каково же было мое удивление, когда перейдя по адресу 192.168.88.1 , я попал в открытую админку роутера Mikrotik. Погуляв по настройкам, выяснил, что на нем не только развернута публичная точка доступа, но и подключено некоторое важное оборудование. А сколько таких вот открытых админок, наверное, только Shodan’у одному известно…

Так что подобные схемы — это вполне реальная история, и попасть под сниффинг трафика можно достаточно просто (особенно если вы любите посещать конференции).

Защита канала связи, или SSL Pinning

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

Для защиты клиента, если он вдруг попал в недоверенную/скомпрометированную сеть, если кто-то пытается прослушать его трафик и т.д.

Для того, чтобы нельзя было проанализировать backend и поискать ошибки, например, в бизнес-логике (классический Security through obscurity)

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

На мой взгляд, SSL Pinning призван решать одну единственную задачу — защищать клиента. По поводу двух оставшихся пунктов скажу кратко. Да, SSL Pinning может косвенно повлиять на них. То есть поможет и закрыть ваш API, и защитить от ботов (в теории), но это не серебряная пуля, а лишь способ обезопасить ваших клиентов.

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

А теперь немного о том, что же собственно такое SSL Pinning, как он устроен и как его применять. Суть этого метода в том, чтобы на этапе SSL Handshake после второго шага, когда сервер присылает нам свой сертификат с открытым ключом, приложение проверяло, что определенные параметры этого сертификата совпадают с тем, что ожидает получить приложение (то есть, некоторые данные, которые “зашиты“ в приложении и которые мы ожидаем получить от своего сервера). Схематично это можно представить в виде небольшой схемы:



Процесс SSL Pinning

Теперь посмотрим, что именно можно проверять и на каких этапах, и каким образом это можно реализовать.

Типы SSL Pinning

Certificate Pinning

Первая реализация — это Certificate Pinning. Проверяется непосредственно сам сертификат, включая метаданные (кому он выдан, срок окончания, данные владельца и т.д.). Такая реализация наиболее безопасна, поскольку даже небольшое изменение в сертификате вызовет несоответствие и приведет к невозможности установить соединение.

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

Public key Pinning

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

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

Какие сертификаты возможно проверять

Сертификат конечного сервера, с которым осуществляется соединение:

Гарантирует с почти 100% уверенностью, что это ваш сертификат, даже если корневой центр был скомпрометирован;

Если сертификат становится недействительным по какой-либо причине (либо по истечении срока действия, либо при компрометации), то осуществить соединение с сервером не получится, пока не выйдет обновление приложения;

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

Сертификат промежуточного центра сертификации:

Проверяя промежуточный сертификат, вы доверяете промежуточному центру сертификации;

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

Сертификат центра сертификации (корневой сертификат, CA):

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

Если корневой сертификат скомпрометирован, то соединение нельзя считать защищенным, и необходимо срочно менять все сертификаты.

Вся цепочка сертификатов:

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

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

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

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

Еще хочется рассказать об интересном наблюдении из практики, нередко сертификат, с которым будет сравниваться отпечаток сервера, хранится в виде файла на файловой системе (в директории или ресурсах приложения). Мы автоматизировали поиск таких ключей/сертификатов, а после того, как собрали неплохой результат, прогнав через сканер несколько сотен приложений, захотелось посмотреть, а что еще хранят приложения, какие сертификаты или файлы ключей?

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

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



Найденное хранилище ключей с приватными ключами

Как проверять

Android Network Security Config

Для каждой из возможных библиотек будет своя собственная реализация. Для Android, например, существует встроенный механизм реализации Pinning на уровне системы, а именно конфигурация сетевого взаимодействия (XML-файл, в котором настраиваются параметры сетевой безопасности). Данная настройка задается специальным атрибутом android:networkSecurityConfig в AndroidManifest.xml.

Network Security Config позволяет достаточно просто подключить механизм Certificate Pinning в приложение. Но при этом стоит учитывать определенные нюансы. Рассмотрим конфигурацию, которая с первого взгляда выглядит, как правильно настроенная, и разберем, как ее можно немного улучшить:

Этот пример имеет два небольших недостатка:

Для отпечатка сертификата (pin-set) не установлен срок действия;

Нет резервного сертификата.

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

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

Вот пример наиболее корректного использования функционала Certificate Pinning:

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

iOS App Transport Security

Что касается iOS, то встроенный механизм проверок в AppTransport Security появился только начиная с iOS 14 и очень похож на то, что есть в Android:

В этом примере конфигурации мы указываем, что отпечаток открытого ключа связан с доменом example.org и его поддоменами, например test.example.org . Но вот поддомены третьего уровня и выше уже в эту проверку не попадают (например notinclude.test.example.org ).

Как и в Android, можно сразу же указать несколько отпечатков, что может быть полезно при ротации сертификатов на сервере:

Более подробно об этом механизме и о сертификатах в том числе, можно прочитать в моей статье, посвященной AppTransportSecurity.

В нашем инструменте мы не только умеем выявлять отсутствие пиннинга, но и в обязательном порядке анализируем Network Security Config на предмет неправильной конфигурации и соответствия лучшим практикам безопасности:



Пример найденной небезопасной конфигурации Network Security Config

И, конечно, конфигурация App Transport Security не остается без внимания:



Пример найденной небезопасной конфигурации App Transport Security

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

OkHttp

При реализации в OkHttp можно воспользоваться классом CertificatePinner.

HttpUrlConnection

Если используется HttpUrlConnection , рекомендуется пересмотреть подход в сторону OkHttp. Версия HttpUrlConnection , встроенная в Android, зафиксирована, поэтому с обновлениями могут возникнуть сложности.

В документе Android «Security with HTTPS and SSL» предлагаемая реализация основана на pinning сертификатов с помощью собственного TrustManager и SSLSocketFactory . Однако, как и в случае с другими API, в данной рекомендации будут примеры с использованием SPKI.

Данная имплементация должна быть вызвана следующим образом:

Но не стоит забывать, что SSL Pinning — это не единственное, что может помочь в защите сетевого соединения. Другим немаловажным фактором является создание правильного протокола общения приложения с сервером, например, запрет на общение в открытом виде по HTTP или запрет на передачу чувствительной информации в параметрах GET-запросов. О последней проблеме хотелось бы поговорить чуть более подробно.

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

Любые прямые или обратные прокси-серверы между двумя конечными точками;

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



Найденный пароль, передаваемый в параметрах GET-запроса

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

Обнаружение уязвимостей отсутствия или некорректной реализации SSL Pinning

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

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



Выявленная уязвимость с указанием доменов, где был перехвачен трафик

Заключение

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

Реализовывать ли в приложении защиту сетевого соединения? Ответ не для всех разработчиков очевиден. Некоторых останавливает боязнь “протухания“ сертификатов, других — нехватка времени. На мой взгляд, это одна из первых вещей, которые необходимо запланировать к реализации для защиты ваших клиентов. Подумайте о них и не бойтесь реализовывать пиннинг. Даже ситуацию с “протуханием” сертификата можно попробовать обойти различными способами. В конце концов, есть и специальные продукты и решения, которые помогают в настройках, поиске сертификатов и корректности реализации сетевого взаимодействия. Буду рад помочь, если возникнут вопросы по теме!

What is R3 as Certificate Issuer?

Let’s Encrypt is a free SSL Certificate provider, issuing certificates automatically but only for 3 months.
You could see Let’s Encrypt Authority X3 by now new R3 name appears mostly.

Since this kind of changes could be suspicous we can confirm that, SSL Certificates signed by R3 is trustworthy and belongs to Let’s Encrypt.

But keep in mind, the SSL Certificates is for:

• Encapsulate your network traffic into encrypted channel driven by mostly TLSv1.2
  That means attacker likely cannot see your plaintext passwords, credit card info over the network, however the website still receive as plaintext, so it does not protect you against malicous, fake, scam websites..
• SSL Certificate can prove that the domain is genuine, so protect from Man In The Middle (MITM) attacks.
  However does not protect from a special attacks, like one: the link points to a very similar domain name which is also secured with SSL but the website is intended to steal informations, passwords, accounts.

Что такое SSL-сертификат – определение и описание



SSL-сертификат – это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение. Аббревиатура SSL означает Secure Sockets Layer – протокол безопасности, создающий зашифрованное соединение между веб-сервером и веб-браузером.

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

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

С момента создания протокола SSL около 25 лет назад, он был доступен в нескольких версиях. При использовании каждой из этих версий в определенный момент возникали проблемы безопасности. Затем появилась обновленная переименованная версия протокола – TLS (Transport Layer Security), которая используется до сих пор. Однако аббревиатура SSL прижилась, поэтому новая версия протокола по-прежнему часто называется старым именем.



Как работают SSL-сертификаты?

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

Процесс работает следующим образом:

1. Браузер или сервер пытается подключиться к веб-сайту (веб-серверу), защищенному с помощью SSL.
2. Браузер или сервер запрашивает идентификацию у веб-сервера.
3. В ответ веб-сервер отправляет браузеру или серверу копию своего SSL-сертификата.
4. Браузер или сервер проверяет, является ли этот SSL-сертификат доверенным. Если это так, он сообщает об этом веб-серверу.
5. Затем веб-сервер возвращает подтверждение с цифровой подписью и начинает сеанс, зашифрованный с использованием SSL.
6. Зашифрованные данные используются совместно браузером или сервером и веб-сервером.

Этот процесс иногда называют подтверждением SSL-соединения. Хотя по описанию этот процесс выглядит длительным, в реальности он занимает миллисекунды.

Если веб-сайт защищен SSL-сертификатом, в веб-адресе появляется аббревиатура HTTPS (безопасный протокол передачи гипертекста). Для сайтов без SSL-сертификата отображается аббревиатура HTTP, без буквы S, соответствующей Secure (безопасный). Также в адресной строке веб-адреса будет отображаться значок замка. Это свидетельствует о безопасности и обеспечивает уверенность посетителям веб-сайта.

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

• Доменное имя, для которого выпущен сертификат.
• Лицо, организация или устройство, для которого выпущен сертификат.
• Центр сертификации, выдавший сертификат.
• Цифровая подпись центра сертификации.
• Связанные поддомены.
• Дата выдачи сертификата.
• Срок действия сертификата.
• Открытый ключ (закрытый ключ не раскрывается).

Зачем нужен SSL-сертификат

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

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

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

SSL-сертификат помогает защитить такую информацию, как:

• Учетные данные для входа в систему.
• Операции по кредитной карте и информацию о банковском счете.
• Личную информацию: полное имя, адрес, дату рождения, номер телефона.
• Юридические документы и контракты.
• Медицинские документы.
• Конфиденциальную информацию.

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

Существуют разные типы SSL-сертификатов с разными уровнями проверки. Шесть основных типов:

1. Сертификаты с расширенной проверкой (EV SSL)
2. Сертификаты, подтверждающие организацию (OV SSL)
3. Сертификаты, подтверждающие домен (DV SSL)
4. Wildcard-сертификаты
5. Мультидоменные сертификаты (MDC)
6. Сертификаты унифицированных коммуникаций (UCC)

Сертификаты с расширенной проверкой (EV SSL)

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

Сертификаты, подтверждающие организацию (OV SSL)

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

Сертификаты, подтверждающие домен (DV SSL)

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

Wildcard-сертификаты

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

• yourdomain.com
• yourdomain.com
• yourdomain.com
• yourdomain.com
• yourdomain.com

Мультидоменные сертификаты (MDC)

Мультидоменные сертификаты можно использовать для защиты нескольких доменных и поддоменных имен, включая сочетания полностью уникальных доменов и поддоменов с разными доменами верхнего уровня (TLD), за исключением локальных / внутренних доменов.

• example.com
• org
• this-domain.net
• anything.com.au
• example.com
• example.org

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

Сертификаты унифицированных коммуникаций (UCC)

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

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

Как получить SSL-сертификат

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

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

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

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

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

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



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

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

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

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

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

Что происходит по истечении срока действия 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-сертификата.
• Для защищенных сайтов отображается значок закрытого замка, который можно щелкнуть и посмотреть сведения о безопасности. У самых надежных сайтов будут зеленые замки или адресные строки.
• Браузеры также показывают предупреждения, если соединение небезопасно, например красный замок, открытый замок, линию, пересекающую адрес веб-сайта, треугольник-предупреждение над значком замка.

Как обеспечить безопасность онлайн-сеанса

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

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

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

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

Чтобы избежать подобных атак:

• Всегда проверяйте, что домен сайта, на котором вы находитесь, написан правильно. Веб-адрес поддельного сайта может отличаться только одним символом, например, amaz0n.com вместо amazon.com. В случае сомнений введите домен прямо в браузере, чтобы убедиться, что вы подключаетесь именно к тому веб-сайту, который собираетесь посетить.
• Никогда не вводите логины, пароли, банковские реквизиты и другую личную информацию на сайте, если вы не уверены в его подлинности.
• Всегда оценивайте, что предлагается на сайте, не выглядит ли он подозрительным и действительно ли вам нужно на нем регистрироваться.
• Убедитесь, что ваши устройства защищены надлежащим образом: Kaspersky Internet Security проверяет веб-адреса по базе фишинговых сайтов и обнаруживает мошенничество независимо от того, насколько безопасным выглядит ресурс.

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

Читать:
Lenovo g560 какая максимальная оперативная память