Основы HTTPS, TLS, SSL. Создание собственных X.509 сертификатов. Пример настройки TLSv1.2 в Spring Boot / Хабр

Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!

Что не так с HTTP?

Проблема протокола HTTP в том, что данные передаются по сети в открытом незашифрованном виде. Это позволяет злоумышленнику слушать передаваемые пакеты и извлекать любую информацию из параметров, заголовков и тела сообщения. Для устранения уязвимости был разработан HTTPS (S в конце значит Secure) — он, хоть не является отдельным протоколом, всего лишь HTTP поверх SSL (а позже TLS), позволяет безопасно обмениваться данными. В отличие от HTTP со стандартным TCP/IP портом 80, для HTTPS используется порт 443.

SSL

Secure Sockets Layer (SSL) — это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. Располагается между транспортным уровнем и уровнем программы-клиента (FTP, HTTP и т.п.) (подробнее про уровни телекоммуникаций). Впервые был представлен публике в 1995 году, однако с 2015 года признан полностью устаревшим. На основе спецификации SSL 3.0 в 1996 был разработан TLS 1.0.

TLS

И так, что же такое TLS? Transport Layer Security — это развитие идей, заложенных в протоколе SSL. На данный момент актуальной является версия TLSv1.2, с августа 2018 активно вводится TLSv1.3, тогда как TLSv1.1, TLSv1.0, SSLv3.0, SSLv2.0, SSLv1.0 находятся в статусе deprecated. Протокол обеспечивает услуги: приватности (сокрытие передаваемой информации), целостности (обнаружение изменений), аутентификации (проверка авторства). Достигаются они за счет гибридного шифрования, то есть совместного использования ассиметричного и симметричного шифрования.

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

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

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

Что происходит на практике

1. Client Hello — клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.

   Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA — Риверт-Шамир-Адлеман, DH — Диффи-Хеллмана, ECDH — Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES — Advanced Encryption Standard, 3DES — Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 — Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др. ).

   Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.

2. Server Hello — сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.

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

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

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

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

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

   Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).

4. Server Key Exchange — этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Y_s=g^{случайно выбранное сервером число}mod p, где mod — это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Y_c=g^{случайно выбранное клиентом число}mod p. После этого сервер считает Y_c^{случайно выбранное сервером число}mod p, а клиент Y_s^{случайно выбранное клиентом число}mod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:

   • Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Y_s = 3⁶mod 17 = 15

   • Клиент случайно генерирует число 7 и возвращает серверу Y_c = 3⁷mod 17 = 11

   • Сервер считает итоговое число 11⁶mod 17= 8, и клиент 15⁷mod 17 = 8

5. Server Hello Done — сервер сообщает, что начальный этап установки соединения завершен

6. Client Key Exchange — как было уже сказано выше, когда сервер передал числа p, g, Y_s в Server Key Echange, клиент передает свое число Y_c в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret — предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.

7. Change Cipher Spec — клиент говорит серверу, что он готов перейти на защищенное соединение.

8. Finished — клиент зашифровывает симметричным ключом первое сообщение с MAC.

9. Change Cipher Spec — сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.

10. Finished — аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение

11. После этого соединение считается установленным, и происходит передача полезной информации

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

Двусторонний TLS

Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.

TLSv1.3

Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2018 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др. Интернет медленно но верно обновляется до TLSv1.3, однако все еще большинство сайтов работают по протоколу TLSv1.2. Поэтому информация в этой статье остается актуальной.

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем «password» длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096

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

• .key — для приватного ключа

• .csr — для запроса на подпись сертификата

• .pem — для сертификата в Privacy Enchanced Mail формате. Записывается в base64 между ——BEGIN CERTIFICATE—— и ——END CERTIFICATE——. Также существует Distinguished Encoding Rules (DER) формат, где информация хранится как binary.

• p12 — для хранилища ключей с сертификатами (keystore) и хранилища доверенных сертификатов (truststore) в формате Public-Key Cryptography Standards 12.

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте «CN=Certificate authority» (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password — все поля, кроме CN опциональны), приватный ключ и пароль от него:

openssl req -new -key CA-private-key.key -passin pass:password -subj "/CN=Certificate authority/" -out CA-certificate-signing-request.csr t $3

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key. key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE

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

openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj "/CN=localhost/" -out Server-certificate-signing-request.csrt $3
openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj "/CN=Client/" -out Client-certificate-signing-request.csr

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

openssl x509 -req -in Server-certificate-signing-request. csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем «password»:

openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12      

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt    

Для удобства, все описанные выше действия упакованы в bash script.

Настройка TLS в Spring Boot приложении

Основой для нашего проекта послужит шаблон с https://start.spring.io/ с одной лишь зависимостью Spring Web. Для включения TLS указываем в application.properties:

server.port=443
server.ssl.enabled=true
server.ssl.protocol=TLS
server.ssl.enabled-protocols=TLSv1.2

После этого указываем Spring тип keystore, путь к нему и пароль:

server.ssl.key-store-type=PKCS12
server.ssl.key-store=Server-keystore.p12
server.ssl.key-store-password=password

Для проверки доступа создадим минимальный контроллер:

@RestController
public class TlsController {
    @GetMapping
    public String helloWorld() {
        return "Hello, world!";
    }
}

Запускаем проект. Попробуем сделать запрос с помощью curl:

curl https://localhost/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Как видим, curl не доверяет сертификату сервера. Сделаем еще один запрос, указав наш CA сертификат в ключе —cacert:

curl --cacert CA-self-signed-certificate.pem https://localhost/
Hello, world!

На этот раз все сработало, TLS в Spring Boot работает! Мы на этом не остановимся, добавим в приложение аутентификацию клиента (указываем truststore):

server.ssl.client-auth=need
server.ssl.trust-store-type=PKCS12
server.ssl.trust-store=Server-truststore.p12
server.ssl.trust-store-password=password

Запускаем и снова пытаемся выполнить запрос:

curl --cacert CA-self-signed-certificate. pem https://localhost/
curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate     

Очевидно, что сервер закрыл соединение, так как curl не предоставил никакого сертификата. Дополним запрос клиентским сертификатом и его закрытым ключом:

curl --cacert CA-self-signed-certificate.pem --cert Client-certificate.pem:password --key Client-private-key.key https://localhost/     
Hello, world!

Итоги

В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!

безопасность, TLS и сертификаты, зачем переходить на HTTPS

Вам действительно нужен HTTPS?

Вы можете подумать: «Конечно, не все веб-сайты нуждаются в защите и безопасности». Если веб-сайт не обслуживает конфиденциальные данные или не отправляет какие-либо формы, было бы излишним покупать сертификаты и замедлять работу веб-сайта, просто чтобы получить маленькую зеленую отметку в строке URL с надписью «Защищено».

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

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

Посмотрим, стоит ли того.

HTTPS шифрует ваши сообщения и решает проблему MITM

В предыдущей части мы говорили о различных механизмах HTTP-аутентификации и их безопасности, а также недостатки. Проблема, которую не могут решить ни простая, ни дайджест-аутентификация, — это атака «Человек в середине». Атака «Человек посередине» представляет собой любую злонамеренную сторону, которая встает между вами и сайтом, с которым вы общаетесь. Его цель — перехватить исходные сообщения в обоих направлениях и скрыть их присутствие путем пересылки измененных сообщений.

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

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

Поехали.

HTTPS как критерий ранжирования

Не так давно Google сделал HTTPS критерием ранжирования.

Что это значит?

Это означает, что если вы веб-мастер и заботитесь о позициях вашего сайта в Google, то вам обязательно следует внедрить HTTPS на своем веб-сайте. Хотя это не так эффективно, как некоторые другие критерии, такие как качественный контент и обратные ссылки, он определенно имеет значение.

Тем самым Google побуждает веб-мастеров как можно скорее перейти на HTTPS и повысить общую безопасность Интернета.

Это можно сделать совершенно бесплатно

Чтобы включить HTTPS (SSL/TLS) для веб-сайта, вам понадобится сертификат, выданный центром сертификации. До недавнего времени сертификаты были дорогостоящими, и их приходилось обновлять каждый год.

Спасибо ребятам из Let’s encrypt, теперь вы можете получить очень доступные сертификаты. Серьезно, они совершенно бесплатны.

Сертификаты Let’s Encrypt, которые легко устанавливаются, пользуются поддержкой крупных компаний и большим сообществом людей. Взгляните на основных спонсоров и убедитесь сами в списке компаний, которые их поддерживают. Вы можете узнать несколько

Давайте шифровать выдает только сертификаты DV (проверка домена) и не планируем выпускать сертификаты организации (OV) или сертификаты расширенной проверки (EV). Срок действия сертификата составляет 90 дней, и его легко продлить.

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

Все дело в скорости

Многие люди связывают HTTPS с дополнительными расходами на скорость. Взгляните на httpvshttps. com.

Вот мои результаты для HTTP и HTTPS:

Так что же там произошло? Почему HTTPS намного быстрее? Как такое возможно?

HTTPS — это требование для использования протокола HTTP 2.0.

Если мы посмотрим на вкладку сети, мы увидим, что в случае HTTPS изображения были загружены по протоколу HTTP2.0.

HTTP 2.0 является преемником распространенного в настоящее время HTTP / 1.1.

У него много преимуществ перед HTTP / 1.1:

• Он двоичный, а не текстовый
• Он полностью мультиплексирован, что означает, что он может отправлять несколько запросов параллельно через одно TCP-соединение.
• Снижает накладные расходы за счет сжатия HPACK.
• Он использует новое расширение ALPN, которое позволяет ускорять зашифрованные соединения
• Это сокращает дополнительное время приема-передачи (RTT), что ускоряет загрузку вашего веб-сайта.
• Многие другие

Браузеры не одобряют сайты без HTTPS

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

Вот как это выглядело до и после версии Chrome 56.

А вот как это будет выглядеть в итоге.

Вы еще не уверены?

Переход на HTTPS сложен

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

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

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

Итак, это причины для перехода на HTTPS. Есть причина не делать этого?

Надеюсь, теперь я убедил вас в ценности HTTPS, и вы страстно хотите перевести свой сайт на HTTPS и понять, как это работает.

Основные концепции HTTPS

HTTPS означает безопасный протокол передачи гипертекста. Фактически это означает, что клиент и сервер обмениваются данными через HTTP, но через безопасное соединение SSL/TLS.

SSL против TLS

Термины SSL (Secure Socket Layer) и TLS (Transport Layer Security) взаимозаменяемы, но на самом деле сегодня когда кто-то упоминает SSL, они, вероятно, имеют в виду TLS.

Протокол SSL был первоначально разработан Netscape, но версия 1.0 так и не увидела свет. Версия 2.0 была представлена ​​в 1995 году, а версия 3.0 — в 1996 году, и они использовались долгое время после этого (по крайней мере, то, что считается долгим в ИТ), хотя их преемник TLS уже начал набирать обороты. Вплоть до 2014 года. Переход с TLS на SSL поддерживался серверами, и это было основной причиной Атака POODLE была настолько успешной.

После этого возврат к SSL был полностью отключен.

Если вы проверяете свой или любой другой веб-сайт с помощью инструмента Qualys SSL Labs, вы, вероятно, увидите что-то вроде этого:

Как видите, SSL 2 и 3 вообще не поддерживаются, а TLS 1. 3 еще не получил широкого распространения.

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

Теперь, когда мы разобрались с этим, я буду использовать TLS, так как он более уместен.

Итак, как клиент и сервер устанавливают безопасное соединение?

Подтверждение TLS

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

Вот как работает рукопожатие TLS (очень упрощенно, дополнительные ссылки ниже).

Зашифрованный обмен данными начинается после установления соединения.

Фактический механизм намного сложнее, чем этот, но для реализации HTTPS вам не нужно знать все фактические детали реализации установления связи TLS.

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

Если вы хотите точно узнать, как работает TLS Handshake, вы можете найти его в RFC 2246.

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

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

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

Цифровой сертификат позволяет пользователям веб-сайта безопасно общаться при использовании веб-сайта.

Если вы, например, используете Chrome, вы можете самостоятельно проверить сертификаты, перейдя на вкладку «Безопасность» в Инструментах разработчика (F12).

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

Это не помешает злоумышленникам украсть ваши учетные данные, если у них есть законный домен с законным сертификатом. Так что будьте осторожны. Зеленый «Безопасный» в верхнем левом углу просто означает, что вы общаетесь с нужным сайтом. Это ничего не говорит о честности владельца этого веб-сайта

С другой стороны, сертификаты расширенной проверки подтверждают, что веб-сайт контролируется юридическим лицом. Продолжаются дискуссии о том, полезны ли сертификаты EV для типичного пользователя Интернета. Вы можете распознать их по произвольному тексту слева от адресной строки. Например, при просмотре сайта twitter.com вы можете увидеть:

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

Цепочки сертификатов

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

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

Самый низкий из них — это сертификат моего домена, который подписан сертификатом, расположенным над ним, и так далее… Пока не будет достигнут корневой сертификат.

Но кто подписывает корневой сертификат, вы можете спросить?

Выдан: AddTrust External CA Root, Выдан: AddTrust External CA Root.

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

Вы можете проверить список доверенных корневых сертификатов в Windows, запустив диспетчер сертификатов, нажав кнопку Windows + R и набрав certmgr. msc. Затем вы можете найти доверенные сертификаты компьютера в разделе «Доверенные корневые центры сертификации». Этот список используется Windows, IE и Chrome. Firefox же, с другой стороны, управляет собственным списком.

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

Слабые стороны HTTPS

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

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

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

Заключение

На этом завершается серия статей по HTTP. Мы надеемся, что вы извлекли из этого что-то полезное и поняли некоторые концепции, которых раньше не понимали или не могли понять.

Сертификаты TLS и SSL от DigiCert

СЕРТИФИКАТЫ TLS/SSL

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

Обзор

• Краткий обзор
• Сравнить
• Упрощенное управление
• Обзор сертификата
• Основы SSL/TLS

Обновление сертификата

КРАТКИЙ ОБЗОР

TLS/SSL: преимущества помимо сертификатов

Печать Norton

Завоюйте доверие в Интернете, разместив подтверждение на своем сайте. Показать самый узнаваемый знак доверия в Интернете.

Ежедневное сканирование вредоносных программ

Он встроен прямо в каждый сертификат DigiCert для дополнительной защиты от вредоносных инфекций.

Круглосуточная поддержка клиентов

Больше 5-звездочных отзывов, чем у наших конкурентов вместе взятых.

СРАВНИТЬ

Сертификаты TLS/SSL

Функции

• Печать Norton

• ECC: Надежная защита

• Неограниченное количество поддоменов

• Оценка уязвимости

• Сканирование вредоносных программ

• Круглосуточный чат/электронная почта/KB поддержка

• Бесплатная перевыпуск/замена сертификата

• Средство автоматической установки

• Консоль управления

• Гарантийная цена
• 1 500 000 долларов США
• 1 750 000 долларов США
• 1 500 000 долларов США
• 1 750 000 долларов США
• 1 500 000 долларов США
• 1 750 000 долларов США

Просмотреть все функции

Просмотреть меньше функций

Просмотреть все функции

Просмотреть меньше функций

• Печать Нортона
• ECC: Сильнейшая защита
• Неограниченное количество поддоменов
• Оценка уязвимости
• Сканирование вредоносных программ
• Круглосуточная поддержка в чате/электронной почте/КБ
• Бесплатная перевыпуск/замена сертификата
• Средство автоматической установки
• Консоль управления
• 1 500 000 долларов США

• Печать Нортона
• ECC: Сильнейшая защита
• Неограниченное количество поддоменов
• Оценка уязвимости
• Сканирование вредоносных программ
• Круглосуточная поддержка в чате/электронной почте/КБ
• Бесплатная перевыпуск/замена сертификата
• Средство автоматической установки
• Консоль управления
• 1 750 000 долларов США

• Печать Нортона
• ECC: Сильнейшая безопасность
• Неограниченное количество поддоменов
• Оценка уязвимости
• Сканирование вредоносных программ
• Круглосуточная поддержка в чате/электронной почте/КБ
• Бесплатная перевыпуск/замена сертификата
• Средство автоматической установки
• Консоль управления
• 1 500 000 долларов

• Печать Нортона
• ECC: Сильнейшая защита
• Неограниченное количество поддоменов
• Оценка уязвимости
• Сканирование вредоносных программ
• Круглосуточная поддержка в чате/электронной почте/КБ
• Бесплатный повторный выпуск/замена сертификата
• Средство автоматической установки
• Консоль управления
• 1 750 000 долларов США

• Печать Нортона
• ECC: Сильнейшая защита
• Неограниченное количество поддоменов
• Оценка уязвимости
• Сканирование вредоносных программ
• Круглосуточная поддержка в чате/электронной почте/КБ
• Бесплатная перевыпуск/замена сертификата
• Средство автоматической установки
• Консоль управления
• 1 500 000 долларов США

• Нортон Печать
• ECC: Сильнейшая защита
• Неограниченное количество поддоменов
• Оценка уязвимости
• Сканирование вредоносных программ
• Круглосуточная поддержка в чате/электронной почте/КБ
• Бесплатная перевыпуск/замена сертификата
• Средство автоматической установки
• Консоль управления
• 1 750 000 долларов США

Просмотреть все функции

Показать меньше функций

ВСЕ О SSL/TLS

РУКОВОДСТВО ПО SSL/TLS ДЛЯ НАЧИНАЮЩИХ

Нужна помощь в выборе продукта?
ПОМОГИТЕ ВЫБРАТЬ

DigiCert CertCentral

Необычайно удобный

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

ПОЛУЧИТЕ ЦЕНТРАЛЬНЫЙ

Обзорное видео CertCentral

Обзорное видео CertCentral

ОБЗОР СЕРТИФИКАТОВ

Решение для любой потребности в безопасности

Шифрование

В настоящее время 97% всех веб-сайтов не зашифрованы, поэтому их бизнес и посетители подвергаются риску. Узнайте, как Encryption Everywhere меняет правила игры для малого бизнеса по всему миру.

Доверьтесь

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

Максимальная безопасность

Алгоритм ECC наших сертификатов EV обеспечивает 64 000-кратную надежность RSA и визуальных подсказок, которые вселяют уверенность в клиентов. Результат: повышение конверсии сайта для бизнеса в среднем на 17,8%.

ПОЧЕМУ DIGICERT

Уникальный знаменатель в решениях TLS, IoT и PKI

Доверенный на 90% от Fortune 500

90%

Самая признанная трастовая отметка в Интернете

TOP 100

Thomson Reuter ) 2016

ОСНОВЫ TLS/SSL

Начните с Secure Foundation

Защита от вторжений и угроз

Средство проверки установки SSL/TLS

Проверьте установку SSL сейчас

Защита от вторжений и угроз

Средство проверки установки SSL/TLS

Проверьте установку SSL сейчас

Шифрование

Появление прозрачности сертификатов

УЧИТЬ БОЛЬШЕ

Что такое SSL, TLS и HTTPS?

Обновлено 3 мая 2022 г.

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

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

Возьмем, к примеру, SSL, TLS и HTTPS.

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

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

Дополнительные сведения о том, что такое SSL и TLS, см. в следующих ресурсах:

• Краткий обзор функций: расшифровка SSL/TLS
• Не используйте TLS 1.3 Naked — риски и преимущества расшифровки трафика расшифрованы для вас
• TLS по номерам

Доступные данные

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

И пока он в пути, он уязвим .

Нельзя отрицать — преступники нацелены на данные, и у них на прицеле ваш бизнес. Это потому, что украденные данные ценны… и дороги . Исследования показывают, что средняя утечка данных обходится целевой компании в 3,92 миллиона долларов США. ¹

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

Вот где шифрование данных и
входит аутентификация.

Что такое шифрование данных и аутентификация?

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

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

Но, прежде чем ответить на вопросы «Что такое TLS?» и «Что такое SSL?» важно понимать, что такое HTTP и как он связан с TLS и SSL.

Что такое HTTPS?

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

И это подводит нас к HTTP.

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

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

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

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

Что такое SSL?

Чтобы узнать ответ на вопрос «Что такое SSL?», давайте взглянем на историю, связанную с этой технологией. SSL расшифровывается как Secure Sockets Layer и был впервые разработан компанией Netscape еще в 1994 году. Шифрование/дешифрование SSL — это метод, с помощью которого Интернет-соединения защищены, будь то клиент-клиент, сервер-сервер или (гораздо чаще ) клиент к серверу. Это предотвращает неавторизованные третьи лица от просмотра или изменения любых данных, которыми обмениваются через Интернет.

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

Этот обновленный протокол называется TLS.

Что такое TLS?

Часто SSL и TLS упоминаются как синонимы и взаимозаменяемы. Но между ними есть разница. Итак, что такое TLS?

TLS расшифровывается как Transport Layer Security и по сути является SSL, но более безопасным. Точнее, Internet Engineering Task Force отказалась от SSL в пользу TLS.

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

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

TLS также обеспечивают улучшенное управление ключами в форме генерации ключевого материала и используют улучшенные алгоритмы шифрования. TLS включает и поддерживает ключи эллиптической кривой, безопасные удаленные пароли, предварительно общие ключи и Kerberos, что отличает его от SSL и обеспечивает более безопасную линию передачи данных. TLS прошел через четыре типа версий, причем TLS 1.3 является самой новой и безопасной. Вы можете легко увидеть, подключен ли ваш браузер с помощью TLS; URL-адресу в вашем адресе будет предшествовать значок замка, и он будет включать https как часть URL-адреса.

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

HTTPS защищен SSL/TLS

SSL/TLS — это то, что переводит S в HTTPS. Чтобы сайт получил статус безопасный , ему необходим актуальный сертификат SSL/TLS. И пока
Сертификация SSL/TLS строго не требуется ,
это настоятельно рекомендуется всеми основными браузерами. Фактически, в июле 2018 г. Google
Chrome начал помечать сайты без сертификации SSL/TLS как «небезопасные».
предупреждая потенциальных посетителей сайта. Другие крупные браузеры последовали этому примеру.
В то же время Google награждает HTTPS-сайты лучшей поисковой системой.
рейтинги, предоставляя веб-мастерам больше стимулов для использования сертификатов SSL/TLS.

SSL/TLS в настоящее время почти повсеместно распространены в сети: 90 из 100 лучших в мире веб-сайтов (не принадлежащих Google) по умолчанию используют HTTPS. ⁴ Но как это работает?

Как работает расшифровка SSL/TLS?

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

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

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

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

Во время рукопожатия TLS происходит следующее:

1. Клиент связывается с сервером, инициируя связь с помощью сообщения «client hello». Это сообщение уведомляет сервер о версии TLS клиента и доступных наборах шифров. В это сообщение включена строка случайных байтов, называемая «client random».
2. Сервер отвечает клиенту сообщением «привет серверу». Это сообщение содержит сертификат SSL/TLS и выбранный сервером набор шифров. Сервер также отправляет строку случайных байтов, называемую «случайной выборкой сервера».
3. Сертификат SSL/TLS сервера проверен клиентом. Подтверждая сертификат в выдавшем его центре сертификации, клиент подтверждает подлинность сервера.
4. Клиент отправляет случайную строку зашифрованных информационных байтов, известную как «предварительный секрет». Это зашифровано с использованием открытого ключа.
5. Сервер использует закрытый ключ для расшифровки предварительного секрета.
6. Используя случайный клиент, случайный выбор сервера и предварительный секретный ключ, и клиент, и сервер генерируют сеансовые ключи. Используя одну и ту же информацию, клиент и сервер должны прийти к одному и тому же результату.
7. Клиент использует свой сеансовый ключ для отправки «завершенного» сообщения, указывающего, что клиентская часть подтверждения TLS завершена.
8. Сервер использует свой сеансовый ключ для отправки «завершенного» сообщения, указывающего, что он завершил серверную часть рукопожатия TLS.
9. Связь теперь может продолжаться с использованием сеансовых ключей. Эти ключи будут действовать до завершения сеанса.

3 уровня сертификации SSL/TLS

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

Сертификаты SSL/TLS поставляются в трех
уровни:

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

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

Векторы угроз SSL/TLS

Злоумышленники начали использовать сеансы TLS для внедрения вредоносного ПО, сокрытия трафика управления и контроля и кражи украденных данных. Чтобы защититься от этих угроз и обеспечить видимость и контроль над резко растущими объемами трафика TLS, сетевые администраторы должны рассмотреть возможность расшифровки входящего и бокового трафика. Но прежде чем перейти к расшифровке, вам нужно взвесить некоторые важные факторы. Итак, какие факторы SSL/TLS следует учитывать?

Первым из этих факторов является использование ресурсов . Расшифровка — это интенсивная функция, которая зависит от большого количества ресурсов процессора. И поскольку эти ресурсы конечны, это эффективно крадет доступные ресурсы у инструментов безопасности. Фактически, в недавнем исследовании NSS Labs было обнаружено, что расшифровка SSL/TLS может снизить производительность брандмауэра на целых 80 процентов и уменьшить число транзакций в секунду на целых 92 процента. ⁵

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

Gigamon предлагает решение в виде
Gigamon Visibility Fabric™.

С тканью видимости Gigamon,
организации могут получить оптимальную видимость трафика SSL/TLS, разгружая
потребности процессора расшифровки и высвобождение ресурсов для использования инструментами безопасности.
Gigamon Visibility Fabric расшифровывает правильный трафик и расшифровывает его один раз . Затем он делится релевантным трафиком
с правильными инструментами. Этот подход с однократным дешифрованием освобождает полосу пропускания сети,
и гарантирует, что в сеть входит только авторизованный трафик — эффективно
устранение SSL/TLS как вектора угрозы.

Часто задаваемые вопросы по SSL/TLS

• Совместим ли SSL/TLS со всеми браузерами?
  • Да, все основные браузеры поддерживают SSL/TLS.

• Совместим ли SSL/TLS со всеми устройствами и операционными системами?
  • Как правило, SSL/TLS должен быть совместим со всеми устройствами и операционными системами. Тем не менее, ваш центр сертификации должен быть в состоянии работать с вами, чтобы помочь вам достичь оптимальной конфигурации SSL/TLS.

• Совместим ли SSL/TLS с мобильными устройствами?
  • SSL/TLS должны быть совместимы со всеми современными мобильными устройствами, но некоторые старые устройства могут иметь проблемы совместимости при работе с новейшими протоколами. Ваш центр сертификации должен быть в состоянии помочь вам решить любые проблемы совместимости с мобильными устройствами.

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

Защитите своих пользователей, защитите
Ваш бизнес

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

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

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

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

Соответствующие термины:

• Асимметричная криптография
  • Шифры, которые создают математически связанные пары ключей (состоящие из одного открытого ключа и одного закрытого ключа) для использования в процессах шифрования и дешифрования. Эти ключи очень большие (с точки зрения битов) и не идентичны.

• Центр сертификации (ЦС)
  • Одна из нескольких групп, официально уполномоченных распространять, обновлять, приостанавливать или отзывать сертификаты SSL/TLS.

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

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

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

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

Дополнительная литература:

• «Gigamon ThreatINSIGHT 3.0»
• «Как всеобъемлющая видимость сокращает время простоя сети в новом завтрашнем дне»
• «Как ускорить работу криптографии и оставаться в безопасности, не спотыкаясь о хакеров?»

Ссылки

1. IBM. «Стоимость исследования утечки данных». IBM, 2019 г. https://www.ibm.com/security/data-breach.
2. ДОМО. «Данные никогда не спят 5.0». ДОМО, 2019. https://www.
   

   This entry was posted in Популярное