Для чего нужен tls сертификат

Что такое TLS-сертификаты, и зачем их устанавливать на устройство?

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

В марте 2022 года иностранные компании, выдававшие такие сертификаты, стали отзывать их. Тогда в России начали выдавать отечественные TLS-сертификаты. Качественный аналог предоставляет Национальный удостоверяющий центр (НУЦ) Минцифры. Юрлица, владеющие сайтами, могут получить их бесплатно на «Госуслугах». Сертификат помогает передавать данные в зашифрованном виде, подтверждать подлинность сайта и защищает онлайн-транзакции.

Зачем мне устанавливать его? Я не владелец сайта.

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

Если у вас установлены российские браузеры «Яндекс» и «Атом», ничего дополнительно ставить не нужно.

Для других браузеров необходимо загрузить сертификат на ваше устройство — даже на смартфоны. На «Госуслугах» опубликовали подробную инструкцию по его установке на Windows, MacOS, Android и iOS. Это бесплатно.

«Как это работает»: знакомство с SSL/TLS

Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.

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

/ Flickr / David Goehring / CC-BY

SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.

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

Рукопожатие

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

Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.

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

Алгоритмы шифрования

Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.

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

Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.

Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.

Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.

DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.

ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.

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

Хеш и MAC

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

Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.

В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.

Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.

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

Сертификаты бывают разные

Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.

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

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

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

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

Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.

Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.

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

P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:

• Кириллические домены и SSL-сертификаты
• Цепочки SSL-сертификатов
• Зачем покупать SSL-сертификат
• Как узнать, из чего состоит SSL-сертификат
• SSL SSL-ю рознь: какой сертификат выбрать

Что такое TLS

Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.

Общие сведения о TLS

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.

Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:

После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.

Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).

Шифрование, аутентификация и целостность

• Шифрование – сокрытие информации, передаваемой от одного компьютера к другому;
• Аутентификация – проверка авторства передаваемой информации;
• Целостность – обнаружение подмены информации подделкой.

Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, который предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).

Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.

Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.

TLS Handshake

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

1. Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
2. После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
3. Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
4. Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
5. Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
6. Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.

Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.

Обмен ключами в протоколе TLS

По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.

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

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

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

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

Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.

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

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

Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.

TLS False Start

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

Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:

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

TLS Chain of trust

1. И Алиса, и Боб генерируют собственные открытые и закрытые ключи.
2. Алиса и Боб обмениваются открытыми ключами.
3. Алиса генерирует сообщение, шифрует его своим закрытым ключом и отправляет Бобу.
4. Боб использует полученный от Алисы ключ, чтобы расшифровать сообщение и таким образом проверяет подлинность полученного сообщения.

Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:

Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.

Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:

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

Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.

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

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

• Информационная безопасность
• Криптография

Сертификаты SSL и TLS: предназначение, отличия и проверка

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

Другое дело, когда спустя сотню запросов мы находим нужную вещь для покупки, но она расположена на сомнительном ресурсе. И тут уже возникает вопрос: «А не будет ли мне это стоить всего моего состояния?». Давайте разберемся, как уберечь себя от потери личных данных и проверить сайт на наличие SSL и TLS сертификатов.

Сертификаты SSL и TLS: зачем они нужны

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

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

SSL расшифровывается как Secure Socket Layer, что означает «уровень защищенных сокетов». TLS же обозначается как Transport Layer Security, «безопасность транспортного уровня». По своей сути обе технологии занимаются одним делом – защитой пользовательской информации от злоумышленников.

Их отличие состоит лишь только в том, что TLS основан на уже действующей спецификации SSL 3.0. А сам SSL уже давно устарел, разработчики редко его используют как единственную защиту. Чаще всего можно увидеть связку двух сертификатов SSL/TLS. Такая поддержка обеспечивает работу как с новыми, так и со старыми устройствами.

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

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Специфика работы сертификатов SSL/TLS

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

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

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

SSL/TLS используют ассиметричное шифрование для аутентификации пользователя и симметричное для сохранения целостности личной информации.

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

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

SeoLik

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

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

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

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

SSL Shopper

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

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

Wormly Web Server Tester

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

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

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

Immuni Web

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

1. Переходим по ссылке и в строку запроса «Enter your website or mail server address here» вписываем адрес для проверки. Далее кликаем по кнопке запуска справа от строки.
2. Как только появятся результаты, перед нами отобразится новая страница. Пролистываем немного вниз и находим две строчки «Valid From» и «Valid To». Первая информирует о том, когда был выдан сертификат, вторая указывает на окончание срока действия.

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

SSL Checker

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

1. Переходим по ссылке и вводим адрес. Справа от строки запроса кликаем по кнопке «Check».
2. Перед нами отобразится вся нужная информация. Для того чтобы напомнить об истечении срока действия сертификата, достаточно кликнуть по кнопке «Remind me SSL is about to expire» и указать свою почту.

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

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