HTTPS (HyperText Transfer Protocol Secure)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 14:19, 3 декабря 2016.

HTTPS (англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443[1].

История

Netscape Communications создали HTTPS в 1994 году для своего браузера Netscape Navigator . Первоначально, HTTPS был использован с SSL-протоколом. Поскольку SSL превратилась в TLS (Transport Layer Security), текущая версия HTTPS была формально определено стандартном RFC 2818 в мае 2000 года[2].

Принцип работы

Собственно говоря, HTTPS это не отдельный протокол, а обычный HTTP работающий через SSL[3] или TLS. Чтобы подготовить веб-сервер для принятия https-транзакций администратор должен создать сертификат с открытым ключом для веб-сервера. Эти сертификаты могут быть созданы на UNIX-сервере такими программами, как например OpenSSL.

О преимуществах и технологиях применяемых в HTTPS

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

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

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

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

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

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

TLS (Transport Layer Security)

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

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

Secure Socket Layer

SSL — это сокращение от Secure Socket Layer — это стандартная интернет технология безопасности, которая используется, чтобы обеспечить зашифрованное соединение между веб-сервером (сайтом) и браузером. SSL сертификат позволяет нам использовать https протокол. Это безопасное соединение, которое гарантирует, что информация которая передается от вашего браузера на сервер остается приватной; то есть защищенной от хакеров или любого, кто хочет украсть информацию. Один из самых распространенных примеров использования SSL — это защита клиента во время онлайн транзакции (покупки товара, оплаты). TLS – гибридная криптографическая система. Это означает, что она использует несколько криптографических подходов:

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

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

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

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

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

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

Клиент и сервер используют свои собственные закрытые ключи (каждый – свой) и опубликованный открытый ключ для создания общего секретного ключа на сессию.

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

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

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

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

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

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

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

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

Сертификаты

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

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

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

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

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

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

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

Фактическая защита

Уровень защиты зависит от корректности введения браузерного и серверного программного обеспечения и поддержки криптографических алгоритмов. Среди пользователей кредитных карт в Интернете существует ошибочное мнение, что HTTPS полностью защищает номер их карты от воров. Фактически шифрованное подключение к веб-серверу только защищает номер кредитной карты при передаче между компьютером пользователя и сервером напрямую. Это не гарантирует что сервер непосредственно защищен - он даже может быть сломанным[6].

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

Примечания

  1. wiki HTTPS [Электронный ресурс] / Дата обращения: 31.10.2016. — Режим доступа: https://uk.wikipedia.org/wiki/HTTPS
  2. RFC 2818 [Электронный ресурс] / Дата обращения: 31.10.2016. — Режим доступа: http://tools.ietf.org/html/rfc2818
  3. SSL info [Электронный ресурс] / Дата обращения: 31.10.2016. — Режим доступа: https://habrahabr.ru/company/tuthost/blog/150433/
  4. About HTTPS [Электронный ресурс] / Дата обращения: 31.10.2016. — Режим доступа: https://en.wikipedia.org/wiki/HTTPS
  5. Принцип работы HTTPS-протокола [Электронный ресурс] / Дата обращения: 31.10.2016. — Режим доступа: https://habrahabr.ru/post/188042/
  6. HTTP [Электронный ресурс] / Дата обращения: 31.10.2016. — Режим доступа: https://habrahabr.ru/post/215117/