Как работает https шифрование

Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик

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

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

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

Трубопровод

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

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

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

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

• Для этого требуется больше вычислительных мощностей
• Передается больше данных
• Нельзя использовать кеширование

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

Transport Layer Security (TLS)

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

TLS — наследник SSL — это такой протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (так называемого HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI. Объясняя на пальцах, это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением.

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

1) Асиметричное шифрование (криптосистема с открытым ключом) для генерации общего секретного ключа и аутентификации (то есть удостоверения в том, что вы – тот за кого себя выдаете).
2) Симметричное шифрование, использующее секретный ключ для дальнейшего шифрования запросов и ответов.

Криптосистема с открытым ключом

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

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

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

Как это возможно? Математика!

Алгоритм Ди́ффи — Хе́ллмана

Одним из наиболее распространенных подходов является алгоритм обмена ключами Ди́ффи — Хе́ллмана (DH). Этот алгоритм позволяет клиенту и серверу договориться по поводу общего секретного ключа, без необходимости передачи секретного ключа по соединению. Таким образом, злоумышленники, прослушивающие канал, не смогу определить секретный ключ, даже если они будут перехватывать все пакеты данных без исключения.

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

Немного математики…

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

Пусть Алиса и Боб – две стороны, осуществляющие обмен ключами по DH-алгоритму. Сперва они договариваются о некотором основании root (обычно маленьком числе, таком как 2,3 или 5 ) и об очень большом простом числе prime (больше чем 300 цифр). Оба значения пересылаются в открытом виде по каналу связи, без угрозы компрометировать соединение.

Напомним, что и у Алисы, и у Боба есть собственные закрытые ключи (из более чем 100 цифр), которые никогда не передаются по каналам связи.

По каналу связи же передается смесь mixture, полученная из закрытых ключей, а также значений prime и root.

Таким образом:
Alice’s mixture = (root ^ Alice’s Secret) % prime
Bob’s mixture = (root ^ Bob’s Secret) % prime
где % — остаток от деления

Таким образом, Алиса создает свою смесь mixture на основе утвержденных значений констант (root и prime), Боб делает то же самое. Как только они получили значения mixture друг друга, они производят дополнительные математические операции для получения закрытого ключа сессии. А именно:

Вычисления Алисы
(Bob’s mixture ^ Alice’s Secret) % prime

Вычисления Боба
(Alice’s mixture ^ Bob’s Secret) % prime

Результатом этих операций является одно и то же число, как для Алисы, так и для Боба, и это число и становится закрытым ключом на данную сессию. Обратите внимание, что ни одна из сторон не должна была пересылать свой закрытый ключ по каналу связи, и полученный секретный ключ так же не передавался по открытому соединению. Великолепно!

Для тех, кто меньше подкован в математическом плане, Wikipedia дает прекрасную картинку, объясняющую данный процесс на примере смешивания цветов:

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

Симметричное шифрование

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

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

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

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

Что если я позвоню своему приятелю, мы осуществим DH-обмен ключами, но вдруг окажется, что мой звонок был перехвачен и на самом деле я общался с кем-то другим?! Я по прежнему смогу безопасно общаться с этим человеком – никто больше не сможет нас прослушать – но это будет совсем не тот, с кем я думаю, что общаюсь. Это не слишком безопасно!

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

Но, на самом деле, что это за сертификат, и как он предоставляет нам безопасность?

Сертификаты

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

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

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

Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (центром сертификации, Certificate Authority, CA). CA – это компании, выполняющие ручную проверку, того что лицо, пытающееся получить сертификат, удовлетворяет следующим двум условиям:

1. является реально существующим;
2. имеет доступ к домену, сертификат для которого оно пытается получить.

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

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

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

Прочие вещи которые нужно знать о сертификатах

Расширенная валидация

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

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

Обслуживание множества веб-сайтов на одном сервере

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

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

По этой теме много данных есть в википедии, есть курс на Coursera. Отдельное спасибо ребятам из чата на security.stackexchange.com, которые отвечали на мои вопросы сегодня утром.

Примечания переводчика:

1)Спасибо хабраюзеру wowkin за отличную ссылку по теме (видео переведено и озвученно хабраюзером freetonik):

2) По результатам развернувшейся в коменатариях дискуссии (спасибо за участие хабраюзерам a5b, Foggy4 и Allen) дополняю основную статью следующей информацией:

По данным netcraft на базе свежего SSL survey (2.4 млн SSL сайтов, июнь 2013), большинство SSL соединений не используют Perfect forward secrecy алгоритмы: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.

На Hacker News в обсуждении это тоже заметили.

Also (and I made the same mistake in my talk. ), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don’t work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server’s public key. (RFC 5246: 7.4.7.1, 8.1.1)

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

• https
• tls
• шифрование
• алогритм Диффи-Хеллмана
• цифровой сертификат

• Информационная безопасность
• Веб-разработка
• Алгоритмы

Как работает HTTPS простыми словами

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

Стандартный протокол HTTP передаёт данные в открытом виде. Злоумышленники могут “вклиниться” в передачу — изменить или перехватить данные. В HTTPS для передачи данных создаётся защищённый канал. Вот как это происходит:

Вася хочет перейти на сайт FirstSSL, защищённый SSL-сертификатом

→ Васин браузер посылает запрос к сайту

→ сайт отправляет в ответ копию сертификата

→ браузер проверяет подлинность сертификата — узнаёт у центра сертификации, который его выдал

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

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

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

HTTPS используется там, где защита данных важнее всего — в платёжных системах и формах обратной связи. С начала 2017 Google Chrome и Mozilla Firefox помечают HTTP-сайты с формами ввода данных как ненадёжные. К концу года браузеры будут отмечать так все HTTP-страницы независимо от назначения.

Установите на сайт SSL-сертификат — подключите HTTPS. Так вы повысите доверие пользователей и избежите проблем в будущем.

В чем разница протоколов HTTP и HTTPS

Объясняем, как работают протоколы HTTP и HTTPS и в чем их ключевая разница.

Эта инструкция — часть курса «Как работают сетевые протоколы».

Смотреть весь курс

Визуально различие очевидно: оно в букве S, которая означает «Secure» — безопасность. Это небольшое, но ключевое отличие может сохранить компьютер от заражения вирусами, а бизнес — от потери денег и клиентов. Рассмотрим подробнее, что такое протоколы HTTP и HTTPS и как они отличаются друг от друга.

Что такое HTTP: принцип действия

Протокол HTTP описан в официальной спецификации RFC 2616:

«HTTP, или Hyper Text Transfer Protocol, — это протокол передачи гипертекстовой разметки, которая используется для передачи данных в интернете».

Как это работает? Например, мы хотим прочитать статью о доменах в блоге Selectel. Если в его поисковой строке мы наберем «домены», то в ответ получим страницу с набором статей, которые связаны с этим понятием.

Когда мы набрали запрос и нажали ввод, браузер отправил этот запрос на веб-сервер Selectel.

На веб-сервере хранятся статьи в виде картинок, HTML-документов, файлов с CSS-стилями и JavaScript-файлами. Также на веб-сервере установлено ПО, которое понимает HTTP-протокол.

Веб-сервер принимает запрос, обрабатывает, определяет, какие файлы отправить, и отдает их в ответ. Браузер принимает эти данные, интерпретирует и показывает нам в «человеческом» виде.

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

GET / HTTP/1.1 Host: selectel.ru User-Agent: Mozilla/5.0 Accept: text/html Connection: close

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

За последнее отвечает метод. Приведенном примере метод GET, который указывает, что браузер хочет прочитать страницу с сервера. Есть еще методы HEAD, PUT, PATCH, POST и другие. С их помощью можно отправить серверу команды удалить страницы, добавить на них новые данные или что-то скачать. Но эти методы встречаются гораздо реже.

HTTP-ответ выглядит примерно так:

HTTP/1.1 200 OK Date: Tue, 05 Aug 2021 09:50:20 GMT Server: Apache/1.3.26 X-Powered-By: PHP/4.1.2. Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 18 Connection: close

В ответе содержится:

• версия протокола — HTTP/1.0 — и ответ: в примере это «200» — страница доступна;
• время и дата ответа;
• информация о сервере — в примере Apache-сервер;
• инструкция, как браузеру отобразить страницу (content-type) — в примере это необходимо сделать в кодировке UTF-8.

В ответе мы также получаем HTML с данными страницы — ту самую гипертекстовую разметку из определения HTTP. Гипертекстовая разметка, например, для статьи про управление доменами в блоге Selectel будет выглядеть примерно так:

Браузер помогает собирать из разметки страницы.

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

Что такое HTTPS: принцип действия

HTTPS — это не совсем протокол. Это расширение HTTP-протокола — объединение двух протоколов: HTTP и SSL или HTTP и TLS.

Протоколы TLS (Transport Layer Security) и SSL (Secure Socket Layer) — криптографические. Это значит, что они позволяют шифровать данные, в нашем случае те, что передаются между браузером и сервером. Расшифровать эти данные могут только сервер и браузер, для всех остальных это будет набор нечитаемых символов.

Примечание: TLS основан на SSL, но второй уже устарел, и вместо него используют TLS.

Как работает шифрование

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

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

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

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

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

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

Ограничения и недостатки протоколов HTTP и HTTPS

У HTTP есть следующие достоинства:

• использовать протокол можно в локальных сетях;
• страницы HTTP хранятся в кэше компьютера и они быстрее открываются;
• страницы HTTP открываются во всех браузерах;
• страницы HTTP мало весят.

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

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

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

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

Ключевая разница HTTP и HTTPS

Без сертификата безопасности и шифрования данных у HTTP нет преимуществ.

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

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

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

В шифровании — ключевое различие между HTTP и HTTPS.

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

Почему стоит установить SSL/TLS-сертификат

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

По статистике центра сертификации Let’s Encrypt, основанной на данных Firefox, больше 80% страниц в мире загружаются по HTTPS.

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

Сейчас в браузерах работает HSTS — HTTP Strict Transport Security. Это защитный механизм браузера, который принудительно переводит соединение из HTTP в HTTPS или обрывает HTTP-соединение.

• Не получится открыть ресурс из закладок, если он работает на HTTP. HSTS переводит все запросы в HTTPS.
• Если ресурс открывает по HTTPS, но где-то в нем остались HTTP-ссылки, то HSTS переводит их в HTTPS-запросы. Если не открываются, то браузеры просто блокируют ресурс. Так решается вопрос смешанного контента, когда в на HTTPS-ресурс подмешиваются HTTP-ссылки.
• HSTS блокирует все попытки зайти на ресурс с поддельным сертификатом, как на скрине ниже. Это сразу прерывает атаки с перехватом HTTP-запросов.

Чаще всего ресурс на HTTP браузер просто не откроет, а выведет предупреждение. Например, в браузере Google Chrome незащищенные ресурсы блокируются еще с 2020 года.

Типы SSL/TLS-сертификатов и кто их выдает

Сертификаты бывают разные: групповые, многодоменные, подтверждающие организацию. Рассмотрим самые популярные, расположив их от небезопасных к безопасным.

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

Групповые сертификаты. На CloudFlare или Let’s Encrypt выдают бесплатные сертификаты. Но их нужно продлевать несколько раз в год . Также такие сертификаты выдаются на группу сайтов. Wildcard-сертификаты выдаются на доменное имя уровня выше, чем предполагается использовать: то есть сертификат на CN *.test.ru будет валидным для всех доменных имен с доменом .test.ru. Для некоторых компаний такой сертификат — возможность закрыть большое количество доменов одним сертификатом.

Подписанные доверенным центром сертификации. Такие сертификаты выдают центры сертификации или удостоверяющие центры (УЦ). Например, для блога Selectel выбрал УЦ GeoTrust. Лучше выбирать крупные и надежные центры, к которым есть доверие у браузеров. Они подтверждают подлинность ключей шифрования своей электронной подписью.

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

Domain Validation — сертификат, который подтверждает домен. УЦ проверяет право собственности на домен. Обычно через электронную почту. Подойдут для простых сайтов — например, личных блогов, новостных сайтов и других, на которых не собираются персональные данные и не проводятся платежи.

Organization Validation — сертификат, который подтверждает организацию. Здесь УЦ проверяет, существует ли организация юридически: идентифицирует владельца домена, его личность, просит предоставить документы. Подойдут для магазинов и других ресурсов, где можно проводить платежи.

Extended Validation — сертификаты с расширенной проверкой. Сайты с таким сертификатом имеют зеленый замочек и выдают всю информацию о ресурсе при нажатии на него.

Как подключить SSL/TLS-сертификат

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

Краткий перечень шагов по подключению:

1. Выбрать тип и вид сертификата.
2. Настроить запись WHOIS, чтобы в ней были верные данные.
3. Создать запрос на сервере на подпись SSL-сертификата — CSR.
4. Отправить запроса в УЦ для проверки ваших данных, в зависимости от того, какой тип проверки выбрали.
5. Добавить сертификат с секретным ключом на сервер: как файл .crt (есть еще форматы .pfx, .cer, .crt, .pem, которые можно конвертировать друг в друга).

Сертификат может выглядеть так:

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

Облачное хранилище Selectel

Подойдет для хранения самых разных данных: архивов, логов, документов, фото- и видеоконтента.

Подведем итог

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

Отличия TCP- и UDP-протоколов — определяем разницу на примерах

FTP-протокол: что это такое и для чего он служит

Зарегистрируйтесь в панели управления

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

HTTP и HTTPS — в чем разница?

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

Что такое HTTP и HTTPS

И то, и другое является протоколами, с помощью которых происходит взаимодействие пользователей с сайтами в интернете. Сама аббревиатура HTTP обозначает Hyper Text Transfer Protocol то есть протокол передачи гипертекста. Та самая буква, которая отличает термины между собой – S – означает Security (Безопасность).

Каждый раз, когда вы попадаете на сайт и смотрите в адресную строку, то первым в URL-адресе идёт именно http:// или https:/. Они сообщают браузеру о подключении через тот или иной протокол.

HTTP

При отправлении и получении пакетов данных по сети интернет через HTTP используется протокол управления передачей (TCP). Соединение при этом происходит через порт 80. Клиент отправляет запрос на HTTP-сервер, где располагается сайт, после чего сервер посылает ответ. Этот ответ содержит информацию о состоянии завершения. Выглядит это примерно так: HTTP/1.1 200 OK.

За прошедшие годы протокол TCP был некоторым образом усовершенствован, но по большей части остается таким же, каким был в 1974 году. HTTP также применяет UDP (протокол пользовательских дейтаграмм), который был разработан Дэвидом Ридом ещё в 1980-м. Это менее надёжный протокол, однако его активно применяются в видеоконференциях, играх и потоковой передаче. Благодаря этому можно отбрасывать и принимать отдельные пакеты в произвольном порядке для увеличения производительности.

Автором термина «гипертекст» был Тед Нельсон (1965 год). Оригинальный HTTP предложил и разработал Тим Бернерс-Ли, директор консорциума World Wide Web (W3C), чьей миссией было раскрытие потенциала интернета через разработку протоколов и руководств, обеспечивающих долгосрочный рост всемирной сети.

Первую документацию по HTTP опубликовали в 1991 году. Она состояла лишь из одного метода HTTP-запроса GET(данные запрашивались из указанного ресурса). В 1996 году был разработан HTTP 1.0, он уже состоял из трех методов HTTP-запроса: GET, HEAD и POST (данные отправлялись для обработки на указанный ресурс). В 1997 году появился протокол HTTP/1.1, который до сих пор используется для всех HTTP-запросов.

В HTTP/0.9 и 1.0 соединение закрывалось после единственного запроса. В HTTP/1.1 уже появились постоянные соединения (более одного запроса/ответа на единственное HTTP-соединение), благодаря этому удалось уменьшить задержку. Также появились и другие улучшения, например, кэширование, улучшенная поддержка сжатия и совместное использование ресурсов между источниками.

При наличии сложностей с HTTP-запросом, присутствует список кодов состояния, которые информируют браузер, что позволяет эту проблему обнаружить. Пользовательский агент обрабатывает ответ в зависимости от кода и полей заголовка ответа. Например, ошибка 404 означает, что содержимое либо не существует, либо было перемещено. Ошибка 502 Bad Gateway сообщает, доменное имя не разрешается в правильный IP-адрес или не разрешается ни в один IP-адрес.

Получить консультацию об облачных сервисахЗаказать звонок

HTTPS

HTTPS означает безопасный протокол передачи гипертекста (или HTTP через TLS или SSL). Когда вы вводите https:// в адресную строку перед доменом, вы передаёте браузеру информацию о подключении через HTTPS. Сайты, работающие по протоколу HTTPS, обычно имеют перенаправление, то есть даже при вводе обычного http:// происходит переадресация для доставки по защищенному соединению. HTTPS также использует TCP (протокол управления передачей) для отправки и получения пакетов данных. Это делается через порт 443 соединением, зашифрованным TSL.

Автором HTTPS являлся Netscape Communications, он появился в 1994 году и применялся в браузере Netscape Navigator. Сначала HTTPS работал с протоколом SSL, но позднее он трансформировался в TLS.

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

В чем разница между HTTP и HTTPS

Кратко перечислим основные различия протоколов:

• По-разному записывается URL-адрес. Для HTTP — http://, а для HTTPS — https://.
• HTTP является не защищенным, а HTTPS защищенным.
• HTTP посылает данные через порт 80, а HTTPS использует порт 443.
• HTTP работает на уровне приложений, а HTTPS — на транспортном уровне.
• Для HTTP не нужны SSL-сертификаты; для HTTPS нужен SSL-сертификат, подписанный центром сертификации.
• HTTP не требует проверки домена, тогда как HTTPS требует хотя бы проверки домена, а для некоторых сертификатов даже проверки юридического документа.
• В HTTP нет шифрования, HTTPS шифрует данные перед отправкой.

Заключение

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