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

Posted:

Июл 22, 2023

Comments:

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

Содержание

Основы 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 соединение.

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

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 этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
Server Hello — сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.
Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
Certificate — сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.
Что представляет из себя сертификат? Сертификат — это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.
Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, — вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.
Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA — Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом — это цепочка подписания.
Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
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
Server Hello Done — сервер сообщает, что начальный этап установки соединения завершен
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. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.
Change Cipher Spec — клиент говорит серверу, что он готов перейти на защищенное соединение.
Finished — клиент зашифровывает симметричным ключом первое сообщение с MAC.
Change Cipher Spec — сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.
Finished — аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение
После этого соединение считается установленным, и происходит передача полезной информации
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. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!

Что такое сертификат SSL? – Описание сертификатов SSL/TLS – AWS

Что такое сертификат SSL/TLS?

Сертификат SSL/TLS — это цифровой объект, который позволяет системам проверять личность и впоследствии устанавливать зашифрованное сетевое соединение с другой системой с использованием протокола Secure Sockets Layer/Transport Layer Security (SSL/TLS). Сертификаты используются в рамках криптографической системы, известной как инфраструктура открытого ключа (PKI). PKI дает одной стороне возможность устанавливать подлинность другой стороны с помощью сертификатов (при условии, что обе стороны доверяют третьей стороне, известной как центр сертификации). Таким образом, сертификаты SSL/TLS действуют как цифровые удостоверения личности для защиты сетевых подключений и установления подлинности веб-сайтов в Интернете, а также ресурсов в частных сетях.

Почему сертификаты SSL/TLS важны?

Сертификаты SSL/TLS укрепляют доверие среди пользователей веб-сайта. Компании устанавливают сертификаты SSL/TLS на веб-серверы для создания веб-сайтов, защищенных SSL/TLS. Характеристики веб-страницы, защищенной SSL/TLS, следующие:

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

Ниже мы приводим некоторые преимущества сертификатов SSL/TLS.

Защищает личные данные

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

Укрепляйте доверие клиентов

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

Соответствие нормативным требованиям

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

Улучшить SEO

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

Каковы ключевые принципы технологии сертификации SSL/TLS?

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

Шифрование

Шифрование означает кодирование исходного сообщения таким образом, чтобы его мог расшифровать только предполагаемый получатель. Например, вы меняете слово cat на ecv, перемещая каждую букву алфавита вперед на два места. Получатель знает правило (или ключ) и меняет каждую букву на два места, чтобы прочитать фактическое слово. Шифрование SSL/TLS основано на этой концепции с использованием криптографии с открытым ключом с двумя разными ключами для шифрования и расшифровки сообщения. PKI дает одной стороне возможность устанавливать подлинность другой стороны с помощью сертификатов (при условии, что обе стороны доверяют третьей стороне, известной как центр сертификации). Центр сертификации проверяет сертификат и аутентифицирует обе стороны до начала связи.

Существуют два типа ключей:

Открытый ключ

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

Закрытый ключ

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

Аутентификация

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

Цифровая подпись

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

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

Центр сертификации (ЦС) – это организация, которая продает сертификаты SSL/TLS владельцам веб-сайтов, хостинговым компаниям или предприятиям. Центр сертификации проверяет сведения о домене и владельце перед выпуском сертификата SSL/TLS. Чтобы стать центром сертификации, организация должна соответствовать определенным требованиям, установленным компанией, выпускающей операционную систему, браузеры или мобильные устройства, и подать заявку на включение в список корневого центра сертификации. Это важно для завоевания доверия среди пользователей Интернета. Например, Amazon Trust Services является центром сертификации и может выдавать веб-сайтам сертификаты SSL/TLS.

Каков срок действия сертификата SSL/TLS?

Максимальный срок действия сертификата SSL/TLS составляет 13 месяцев. Срок действия сертификата SSL/TLS постепенно сокращался с годами. Цель состоит в том, чтобы снизить риски безопасности, влияющие на предприятия и пользователей Интернета. Например, ненадежные третьи стороны могут использовать действительный сертификат SSL/TLS из домена с истекшим сроком действия для создания незащищенного веб-сайта.

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

Что входит в сертификат SSL/TLS?

Сертификат SSL/TLS содержит следующую информацию.

Доменные имена
Центр сертификации
Цифровая подпись центра сертификации
Дата выпуска
Дата истечения срока действия
Открытый ключ
Версия SSL/TLS

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

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

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

Рукопожатие SSL/TLS

Рукопожатие SSL/TLS включает в себя следующие шаги:

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

Ключ сеанса

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

Что такое Менеджер сертификатов AWS?

Менеджер сертификатов AWS (ACM) – это сервис, позволяющий легко предоставлять и развертывать публичные и частные сертификаты SSL/TLS для использования вместе с сервисами AWS или внутренними подключенными ресурсами, а также помогающий управлять этими сертификатами. Этот сервис избавляет от необходимости тратить время на покупку, загрузку и обновление сертификатов SSL/TLS вручную. Вместо этого можно быстро запросить сертификат и выполнить его развертывание с помощью таких интегрированных с ACM ресурсов AWS, как эластичная балансировка нагрузки, Amazon CloudFront или в API шлюза Amazon. После этого можно поручить Менеджеру сертификатов AWS обновление сертификатов. Этот сервис позволяет также создавать частные сертификаты для внутренних ресурсов и централизованно управлять жизненным циклом сертификатов.

Организации используют ACM для упрощения применения, развертывания и обновления сертификатов SSL/TLS. Вместо обычного процесса создания и отправки запроса на подпись сертификата (CSR) в центр сертификации можно создать сертификат SSL/TLS, управляемый ACM, несколькими щелчками мыши.

Начните работу с Менеджером сертификатов AWS, зарегистрировав аккаунт AWS уже сегодня.

Какие существуют типы сертификатов SSL/TLS?

Сертификаты SSL/TLS различаются в зависимости от проверки и домена. Сертификаты с разными уровнями проверки классифицируются следующим образом:

Сертификаты расширенной проверки
Сертификаты, подтвержденные организацией
Сертификаты, подтвержденные доменом

Сертификаты SSL/TLS, поддерживающие различные типы доменов:

Сертификат на один домен
Подстановочный сертификат
Мультидоменный сертификат

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

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

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

Сертификаты проверки организации

Сертификаты проверки организации (OV SSL/TLS) занимают второе место после EV SSL/TLS с точки зрения уровня проверки и доверия. Как и EV SSL/TLS, компании должны пройти процесс проверки при подаче заявки на получение SSL/TLS OV. Хотя процесс проверки менее строгий, заявители должны доказать сертификационным органам право собственности на домен.

Сертификат OV SSL/TLS содержит проверенную деловую информацию и может быть проверен в браузере. Фронтальные и коммерческие компании используют сертификат OV SSL/TLS для укрепления доверия среди клиентов. OV SSL/TLS обеспечивает надежное шифрование для защиты конфиденциальности клиентов при просмотре веб-страниц.

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

Сертификаты проверки домена (DV SSL/TLS) – это цифровые сертификаты с самым низким уровнем проверки. Подача заявки на них также обходится дешевле всего. В отличие от SLL EV и OV SSL/TLS, кандидаты на получение сертификата DV проходят менее строгий процесс проверки. Заявитель подтверждает право собственности на домен, ответив на электронное письмо с подтверждением или телефонный звонок.

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

SSL/TLS сертификаты для одного домена

Сертификат SSL/TLS для одного домена – это сертификат SSL/TLS, который защищает только один домен или субдомен. Домен – это основной URL-адрес или адрес веб-сайта, такого как amazon.com. Субдомен – это веб-адрес с текстовым расширением, который предшествует основному домену, например aws.amazon.com.

Например, вы можете использовать сертификат SSL/TLS для одного домена на сайте http://example.com. Однако вы не можете использовать сертификат для http://example.com и sub.example.com одновременно.

Подстановочные сертификаты SSL/TLS

Подстановочный сертификат SSL/TLS – это сертификат SSL/TLS, который защищает домен и все его субдомены. Например, можно использовать подстановочный сертификат SSL/TLS для защиты веб-страниц http://example.com, blog.example.com и shop.example.com.

Мультидоменные сертификаты SSL/TLS

Мультидоменные сертификаты также называют сертификатами объединенных коммуникаций. Мультидоменный сертификат SSL/TLS обеспечивает защиту SSL/TLS для нескольких доменных имен, размещенных на одном или разных серверах с одинаковым владельцем. Например, вы покупаете мультидоменный сертификат для веб-страниц http://example1.com, domain2.co.uk, shop.business3.com и chat.message.au.

Сертификация SSL на AWS: следующие шаги

Зарегистрировать бесплатный аккаунт

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

Регистрация

Начало разработки в консоли

Начните разработку с использованием гибридного облака AWS в Консоли управления AWS.

Вход

Стандарт только для HTTPS. Технические рекомендации

На этой странице рассматриваются некоторые важные технические концепции, относящиеся к прочности и качеству конфигурации HTTPS сервера.

SSL и TLS
Секретность пересылки
Алгоритмы подписи, такие как SHA-1 и SHA-2
Сильные наборы шифров
Полная цепочка сертификатов

SSL и TLS

HTTPS сегодня использует Transport Layer Security или TLS . TLS — это сетевой протокол, который устанавливает зашифрованное соединение с аутентифицированным узлом через ненадежную сеть.

Ранее менее безопасные версии этого протокола назывались Secure Sockets Layer или SSL) .

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

В настоящее время используются следующие основные версии SSL/TLS:

SSLv3: Выпущен в 1996 г. Считается небезопасным после публикации атаки POODLE в 2014 г. Отключение SSLv3 эффективно удаляет поддержку Internet Explorer 6
TLSv1.0: — выпущен в 1999 году. Сегодня широко используется для поддержки некоторых старых клиентов, таких как IE8 и Android 4. 3 и ниже. Специальная публикация NIST 800-52 запрещает TLSv1.0 для государственных систем.
TLSv1.1: — выпущен в 2006 г. Улучшение по сравнению с TLSv1.0, но его быстро заменил TLSv1.2.
TLSv1.2: — выпущен в 2008 году. На сегодняшний день это самая надежная форма TLS, которая широко поддерживается современными браузерами.

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

Злоумышленник может вмешаться в процесс согласования и попытаться «понизить» соединения до самой старой взаимно поддерживаемой версии.

Атаку понижения версии можно предотвратить, используя TLS Fallback SCSV — расширение TLS, предложенное в 2014 году и включенное по умолчанию в новых версиях OpenSSL.

Дополнительные сведения о рекомендациях NIST см. в специальной публикации NIST 800-52.

На панели мониторинга Pulse HTTPS для доменов . gov будет указано, когда домен все еще предлагает небезопасный SSLv3 или когда домен еще не предлагает TLSv1.2.
https.cio.gov настроен для поддержки TLSv1.0, TLSv1.1 и TLSv1.2, а также включен резервный SCSV TLS.

Секретность пересылки

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

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

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

В TLS прямая секретность обеспечивается путем выбора наборов шифров, включающих обмен ключами DHE и ECDHE.

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

На панели инструментов Pulse HTTPS для доменов .gov будет отмечено, когда домен предлагает мало или вообще не обеспечивает секретность пересылки.
https.cio.gov настроен для обеспечения надежной секретности пересылки.

Алгоритмы подписи

Модель безопасности HTTPS/TLS использует «сертификаты» для гарантии подлинности. Эти сертификаты криптографически «подписаны» доверенным центром сертификации.

Доверенный корневой сертификат центра сертификации (который включен в вашу ОС или браузер) используется для подписи промежуточного сертификата, который используется для подписи сертификата вашего веб-сайта. В цепочке может быть более одного промежуточного сертификата. Частью процесса подписи является вычисление «хэша» данных, включенных в сертификат. Это можно сделать с помощью стандартного алгоритма хеширования, такого как SHA-1 или SHA-2.

SHA-1 имеет серьезные недостатки, поэтому поставщики браузеров и операционных систем, такие как Google, Microsoft и Mozilla, объявили о сроках отказа от SHA-1 в пользу семейства алгоритмов SHA-2.

NIST запретил SHA-1 для создания цифровых подписей после 2013 года.

По состоянию на январь 2016 года большинство корневых программ запрещают коммерческим центрам сертификации выдавать сертификат SHA-1. Таким образом, получение публично доверенного сертификата SHA-1 больше невозможно. Кроме того, владельцы сайтов с существующим сертификатом SHA-1 должны знать, что многие браузеры и ОС отключат поддержку SHA-1 в начале 2017 года9.0005

Надежные наборы шифров

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

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

Федеральные агентства не контролируют примитивы, поддерживаемые основными клиентами, используемыми общественностью (такими как веб-браузеры, cURL и другие распространенные HTTP-клиенты). Однако агентства могут контролировать шифры и алгоритмы, поддерживаемые их серверами (которые также могут включать прокси-серверы, балансировщики нагрузки или сети доставки контента).

При настройке серверов:

Избегайте SHA-1 в рукопожатии TLS. Хотя не существует известной конкретной уязвимости в использовании SHA-1 как части рукопожатия TLS, уже было показано, что SHA-1 неприемлемо слаб для использования в качестве алгоритма подписи для выданных сертификатов. Начиная с TLS 1.2, серверы могут и должны согласовывать использование алгоритма подписи, отличного от SHA-1, для рукопожатия TLS.
Избегайте RC4. RC4 когда-то был популярным шифром, но в 2013 году был обнаружен критический недостаток. Современные браузеры больше не поддерживают наборы шифров на основе RC4, и серверы больше не нужно настраивать для поддержки RC4.

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

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

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

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

В общем:

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

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

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

Стандарт только для HTTPS. Технические рекомендации

SSL и TLS
Секретность пересылки
Алгоритмы подписи, такие как SHA-1 и SHA-2
Сильные наборы шифров
Полная цепочка сертификатов

SSL и TLS

Ранее менее безопасные версии этого протокола назывались Secure Sockets Layer 9.0004 или SSL) .

В настоящее время используются следующие основные версии SSL/TLS:

SSLv3: Выпущен в 1996 г. Считается небезопасным после публикации атаки POODLE в 2014 г. Отключение SSLv3 эффективно удаляет поддержку Internet Explorer 6
TLSv1.0: — выпущен в 1999 году. Сегодня широко используется для поддержки некоторых старых клиентов, таких как IE8 и Android 4.3 и ниже. Специальная публикация NIST 800-52 запрещает TLSv1.0 для государственных систем.
TLSv1.1: — выпущен в 2006 г. Улучшение по сравнению с TLSv1.0, но его быстро заменил TLSv1.2.
TLSv1.2: — выпущен в 2008 году. На сегодняшний день это самая надежная форма TLS, которая широко поддерживается современными браузерами.

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

Атаку на более раннюю версию можно предотвратить, используя TLS Fallback SCSV — расширение TLS, предложенное в 2014 году и включенное по умолчанию в новых версиях OpenSSL.

Дополнительные сведения о рекомендациях NIST см. в специальной публикации NIST 800-52.

На панели мониторинга Pulse HTTPS для доменов .gov будет указано, когда домен все еще предлагает небезопасный SSLv3 или когда домен еще не предлагает TLSv1.2.
https.cio.gov настроен для поддержки TLSv1.0, TLSv1.1 и TLSv1.2, а также включен резервный SCSV TLS.

Секретность пересылки

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

В TLS прямая секретность обеспечивается путем выбора наборов шифров, включающих обмен ключами DHE и ECDHE.

На панели инструментов Pulse HTTPS для доменов .gov будет указано, когда домен предлагает мало или вообще не обеспечивает секретность пересылки.
https.cio.gov настроен для обеспечения надежной секретности пересылки.

Алгоритмы подписи

NIST запретил SHA-1 для создания цифровых подписей после 2013 года.

Надежные наборы шифров

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

При настройке серверов:

Избегайте SHA-1 в рукопожатии TLS. Хотя не существует известной конкретной уязвимости в использовании SHA-1 как части рукопожатия TLS, уже было показано, что SHA-1 неприемлемо слаб для использования в качестве алгоритма подписи для выданных сертификатов. Начиная с TLS 1.2, серверы могут и должны согласовывать использование алгоритма подписи, отличного от SHA-1, для рукопожатия TLS.
Избегайте RC4. RC4 когда-то был популярным шифром, но в 2013 году был обнаружен критический недостаток. Современные браузеры больше не поддерживают наборы шифров на основе RC4, и серверы больше не нужно настраивать для поддержки RC4.

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

В общем:

Вам не нужно обслуживать доверенный корень, к которому привязан сертификат. Клиент сравнивает цепочку с локальным корневым хранилищем, поэтому обслуживание корня приведет только к потере байтов и замедлению соединения.
This entry was posted in Популярное

Posted:

Comments: