HTTPS. Как это работает
01.10.2018
Теги: HTTP • HTTPS • SSL • Web-разработка • Ключ
Когда браузер делает запрос к у веб-сайту, этот запрос должен пройти через множество промежуточных узлов, любой из которых может быть использован для прослушивания или для вмешательства в передачу данных. Запросы и ответы передаются посредством протокола HTTP, в котором и запрос клиента, и ответ сервера передаются в открытом виде. Для безопасной передачи данных используется протокол HTTPS с поддержкой шифрования.
Защиту данных в HTTPS обеспечивает криптографический протокол SSL/TLS, который шифрует передаваемую информацию. По сути, этот протокол является обёрткой для протокола HTTP. Он обеспечивает шифрование данных и делает их недоступными для просмотра посторонними. Протокол SSL/TLS хорош тем, что позволяет двум незнакомым между собой участникам сети установить защищённое соединение через незащищённый канал.
Transport Layer Security (TLS)
TLS (наследник SSL) — протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (то есть HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI. Это означает, что в процессе выполнения запроса сперва происходят всё, связанные с TLS-соединением и уже потом — все что связано с HTTP-соединением.
TLS — гибридная криптографическая система. Это означает, что она использует два метода криптографии — асимметричное шифрование и симметричное шифрование.
- Асимметричное шифрование (криптосистема с открытым и закрытым ключом) предназначено для генерации общего секретного ключа и аутентификации
- Симметричное шифрование использует полученный общий для клиента и сервера секретный ключ для дальнейшего шифрования запросов и ответов
Асимметричное шифрование
Криптосистема с открытым ключом – это разновидность криптографической системы, когда у каждой стороны есть и открытый, и закрытый ключ, математически связанные между собой. Открытый ключ используется для шифрования текста сообщения, в то время как закрытый ключ используется для дешифрования и получения исходного текста.
С тех пор как сообщение было зашифровано с помощью открытого ключа, оно может быть расшифровано только соответствующим ему закрытым ключом. Ни один из ключей не может выполнять обе функции. Открытый ключ публикуется в открытом доступе без риска подвергнуть систему угрозам, но закрытый ключ не должен попасть к кому-либо, не имеющему прав на дешифровку данных.
Две стороны, ранее совершенно не знающие друг друга, могут установить защищенное соединение, изначально обмениваясь данными по открытому, незащищенному соединению. Клиент и сервер используют свои собственные закрытые ключи (каждый — свой) и опубликованный открытый ключ для создания общего секретного ключа на сессию.
Это означает, что если кто-нибудь находится между клиентом и сервером и наблюдает за соединением — он все равно не сможет узнать ни закрытый ключ клиента, ни закрытый ключ сервера, ни секретный ключ сессии.
Как это возможно? Алгоритм Диффи-Хеллмана!
Алгоритм Диффи-Хеллмана
Алгоритм позволяет клиенту и серверу договориться по поводу общего секретного ключа, без необходимости передачи секретного ключа по соединению. Таким образом, злоумышленник, прослушивающие канал, не сможет определить секретный ключ, даже если он будет перехватывать все пакеты данных без исключения.
Математические функции, лежащие в основе этого алгоритма, имею важную отличительную особенность — они относительно просто вычисляются в прямом направлении, но практически не вычисляются в обратном. Это именно та область, где в игру вступают очень большие простые числа.
Симметричное шифрование
Обмен ключами происходит всего один раз за сессию, во время установления соединения. Когда стороны уже договорились о секретном ключе, взаимодействие клиент-сервер происходит с помощью симметричного шифрования, которое намного эффективнее для передачи информации.
Используя секретный ключ, полученный ранее, а также договорившись по поводу режима шифрования, клиент и сервер могут безопасно обмениваться данными, шифруя и дешифруя сообщения, полученные друг от друга с использованием секретного ключа.
Аутентификация
Алгоритм Диффи-Хеллмана позволяет двум сторонам получить закрытый секретный ключ. Но откуда обе стороны могут уверены, что разговаривают действительно друг с другом? Мы еще не говорили об аутентификации, которая должна быть в самом начале.
В криптосистемах с открытым ключом существует такое понятие, как доверие. Оно означает, что пользователи доверяют группе сертификатов, которые называются корневыми и при помощи которых подписываются другие сертификаты иерархией ниже.
Для этого нужна Инфраструктура открытых ключей, позволяющая быть уверенным, что субъекты являются теми, за кого себя выдают. Эта инфраструктура создана для создания, управления, распространения и отзыва цифровых сертификатов.
Сертификаты
В самом грубом приближении, цифровой сертификат — это файл, использующий электронно-цифровую подпись и связывающий открытый (публичный) ключ с его принадлежностью. Цифровая подпись на сертификате означает, что некто удостоверяет тот факт, что данный открытый ключ принадлежит определенному лицу или организации.
По сути, сертификаты связывают доменные имена с определенным публичным ключом. Это предотвращает возможность того, что злоумышленник предоставит свой публичный ключ, выдавая себя за сервер, к которому обращается клиент.
Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (Центром Сертификации, Certificate Authority, CA). Центры сертификации — это компании, выполняющие проверку того, что лицо, пытающееся получить сертификат — реально существует и является владельцем домена.
Как только CA удостоверяется в том, что заявитель — реальный и он контролирует домен, CA подписывает сертификат для этого сайта, по сути, устанавливая штамп подтверждения на том факте, что публичный ключ сайта действительно принадлежит ему и ему можно доверять.
Во все браузеры уже изначально предзагружены список аккредитованных CA. Если сервер возвращает сертификат, не подписанный аккредитованным CA, то появится большое красное предупреждение. В противном случае, каждый мог бы подписывать фиктивные сертификаты.
Расширенная валидация
В дополнение к обычным сертификатам, существуют Extended validation сертификаты, обеспечивающие более высокий уровень доверия. Выдавая такой сертификат, CA совершает еще больше проверок в отношении лица, получающего сертификат (обычно используя паспортные данные или счета).
Server Name Indication (SNI)
Поскольку обмен данными по протоколу TLS происходит еще до начала HTTP соединения, то возникает проблема в случае, если несколько веб-сайтов расположены на одном и том же веб-сервере, по тому же ip-адресу. Server Name Indication (SNI) — расширение протокола TLS, которое позволяет браузерам сообщить желаемое имя сайта до получения и проверки SSL сертификата от сервера.
В ходе создания TLS-подключения клиент запрашивает цифровой сертификат у web-сервера. После того, как сервер отправляет сертификат, клиент проверяет его действительность и сравнивает имя хоста, с которым он желает подключиться к серверу, с именем в сертификате.
Поиск: HTTP • HTTPS • HandShake • SSL • TLS • Web-разработка • Безопасность • Браузер • Клиент • Ключ • Протокол • Сервер • Сертификат • Шифрование