HTTPS (HTTP Secure) защищенный протокол прикладного уровня. Защищенный протокол передачи данных: что это такое

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

HTTPS (Hypertext Transport Protocol Secure) - это протокол, который обеспечивает конфиденциальность обмена данными между сайтом и пользовательским устройством. Безопасность информации обеспечивается за счет использования криптографических протоколов SSL/TLS, имеющих 3 уровня защиты:

1. Шифрование данных . Позволяет избежать их перехвата.
2. Сохранность данных . Любое изменение данных фиксируется.
3. Аутентификация . Защищает от перенаправления пользователя.

В каких случаях необходим сертификат HTTPS?

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

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

Что нужно для перехода сайта на HTTPS?

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

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

• Лицо, которому он выдан, действительно существует,
• Оно является владельцем сервера (сайта), который указан в сертификате.

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

Сертификатов существует несколько видов в зависимости от:

• того, какой уровень безопасности вам необходим,
• количества доменных имен и поддоменов,
• количества владельцев.

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

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

HTTP - это протокол прикладного уровня передачи данных, как вы уже, наверное, знаете. Именно поэтому мы набираем HTTP:// и затем переходим на , и по этому адресу мы попадем на HTTP-версию этого веб-сайта.

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

Когда вы заходите на веб-сайт при помощи HTTPS, веб-сервер запускает задачу по вызову SSL и защите обмена данными. Сервер отправляет сообщение обратно клиенту с указанием, что должен быть установлен защищенный сеанс, и клиент, в ответ, отправляет ему свои параметры безопасности. Это значит, что клиент скажет: "Я готов использовать такую-то цифровую подпись, я готов использовать такой-то метод обмена ключами, алгоритм, я готов использовать такой-то симметричный ключ", а сервер сравнивает эти параметры безопасности со своими собственными до тех пор, пока не находит соответствие, и это называется фазой “рукопожатия” или handshake.

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

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

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

Так и устанавливается защищенный канал обмена данными.

Для работы TLS нужен сервер и браузер с поддержкой TLS, а все современные браузеры поддерживают TLS, как мы убедились в статье на Википедии. И во всех браузерах вы увидите HTTPS, что будет указывать на то, что используется TLS, и кроме того, вы часто встречаете замок, все браузеры имеют нечто подобное с целью держать вас в курсе, используете ли вы HTTPS или HTTP с TLS.

Если мы посмотрим на замок здесь, то увидим технические детали, какие алгоритмы шифрования используются. В данном случае, используется TLS. Эллиптические кривые с Диффи-Хеллманом, RSA. AES со 128-битным ключом, режим шифрования GCM, и SHA256 для целостности данных. Все это будет согласовываться между клиентом и сервером.

А если мы посмотрим в Wireshark, Wireshark - это анализатор протоколов, то увидим, как трафик принимается и отправляется. Мы видим здесь, что произошел диалог, в котором мой клиент, то есть браузер, сказал: "Вот вещи, которые я поддерживаю". А сервер ответил ему и сказал: "Что ж, вот то, что я, собственно, хотел бы использовать". Затем сервер предоставил сертификат с цифровой подписью и открытый ключ к нему.

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

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

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

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

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

Адрес веб-сайта был верифицирован.

Соединение между Firefox и веб-сайтом зашифровано для предотвращения прослушивания.
Зеленый замок:
Адрес веб-сайта был верифицирован при помощи сертификата расширенной проверки (EV). Это означает, что владельцу веб-сайта требуется предоставить гораздо больше информации, гораздо больше достоверной информации, чтобы доказать, что он именно тот, за кого себя выдает. Так что если вы видите EV и зеленый замок, то это означает, что была проведена расширенная проверка владельцев сайта.
Соединение между Firefox и веб-сайтом зашифровано для предотвращения прослушивания. Такие дела.

Представим такую ситуацию. У вас есть сайт, расположенный на внешнем сервере. Вы, как администратор, выполняете на нем определенные действия, подключаясь под определенным логином и паролем. Вторая ситуация. Вы являетесь пользователем системы Web Money или аналогичной. Для выполнения действий с вашими кошельками вам необходимо подключиться к системе. Что может произойти во время таких подключений? Если кто-либо окажется между вашим компьютером и сервером, он сможет перехватить (sniffer) передаваемые вами и вам данные, выделить из них информацию, которая может дать доступ к вашему серверу или кошельку и выполнить действия, которые нанесут вам вред.

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

Для создания защищенных соединений разработано несколько протоколов

Защищенная связь в Интернете может быть реализована с помощью ряда протоколов, таких, как Secure Socket Layer (SSL), Secure HTTP (SHTTP) и Private Communications Technology (PCT) . Они обеспечивают защищенность каналов связи между Web-сервером и браузером и осуществляют идентификацию либо браузера, либо сервера. Реализаций защищенных протоколов несколько, но для того чтобы подавляющее число Web-браузеров могли работать с вашей системой, она все же должна поддерживать протокол SSL, как наиболее на сегодняшний день распространенный. Часто для его обозначения и выделения среди других используется аббревиатура HTTPS . Именно эта латинская буква «s» превращает обычный, не защищенный канал передачи данных в Интернете по протоколу HTTP, в засекреченный или защищенный.

Протокол SSL был представлен компанией Netscape Communications Corporation в 1994 году. Тогда была представлена вторая версия, в которой защищенность канала обеспечивалась поверх уровня транспортного протокола (например, TCP), а прикладные программы работали через SSL. Протокол SSL обеспечивает защиту данных посредством шифрования своих сообщений, а также проверку целостности сообщений и аутентификацию со стороны сервера и выборочно — со стороны клиента. Двумя годами позже была представлена третья версия этого протокола, в которой была расширена поддержка алгоритмов шифрования и обмена ключами.

Протокол SSL предоставляет "безопасный канал", который имеет три основных свойства:

• Защищенность связи. После первоначального квитирования связи применяются средства шифрования и определяется секретный ключ. Для шифрования данных используются средства симметричной криптографии (например, DES, RC4 и т.д.).
• Участник сеанса связи может быть идентифицирован и с помощью общих ключей, то есть средствами асимметричной криптографии (например, RSA, DSS и т.д.).
• Надежность связи. Транспортные средства проводят проверку целостности сообщений с помощью зашифрованного кода целостности (MAC). Для вычисления кодов МАС используются безопасные хэш-функции (например, безопасный хэш-алгоритм (SHA), MD5 и т.д.).

Цель протокола SSL — обеспечение защищенности и надежности связи

Основная цель протокола SSL состоит в том, чтобы обеспечить защищенность и надежность связи между двумя подключенными друг к другу приложениями. Этот протокол состоит из двух уровней. Нижний уровень, который располагается поверх транспортного протокола (например, TCP), называется SSL Record Protocol . SSL Record Protocol используется для встраивания различных протоколов высокого уровня и обеспечивает базовый набор средств защиты и поддержку двух следующих сервисов для соединений SSL: конфиденциальность и целостность сообщений. Один из таких встроенных протоколов, SSL Handshake Protocol , позволяет серверу и клиенту идентифицировать друг друга и согласовывать алгоритм шифрования и криптографические ключи, прежде чем протокол приложения произведет обмен первыми битами данных. Одно из преимуществ SSL заключается в том, что он независим от протоколов приложений. Протокол высокого уровня может совершенно прозрачно располагаться поверх протокола SSL.

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

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

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

Процесс "узнавания" состоит из нескольких фаз, что замедляет работу сервера

При установлении связи процесс инициализации начинает клиент, который отправляет серверу сообщение ClientHello , содержащее версию протокола, идентификатор сеанса, комплект шифров (cipher suite), метод сжатия и исходные случайные числа. Затем клиент ожидает от сервера сообщения ServerHello , которое содержит те же параметры, что и сообщение ClientHello, и Certificate , в котором передаётся открытый ECDH ключ сервера, подписанный цифровой подписью по алгоритму ECDSA. При необходимости может быть отправлено сообщение ServerKeyExchange (обмен ключами сервера) и CertificateRequest (запрос сертификата). Сообщением ServerDone сервер извещает о завершении фазы приветствия. После аутентификации сервера клиент вычисляет секретный ключ. Если сервер запросил сертификат, клиент отправляет сообщение Certificate или уведомление NoCertificate , если подходящий сертификат отсутствует. Затем он передаёт свой открытый ключ в сообщении ClientKeyExchange . В завершение данного этапа клиент может отправить сообщение CertificateVerify , чтобы обеспечить средства прямой верификации сертификата клиента.

После этого, производится еще ряд промежуточных обменных операций, в процессе которых, производится окончательное уточнение выбранного алгоритма шифрования, ключей и секретов, и далее, сервер посылает клиенту некое финальное сообщение. Только после того, как сервер идентифицирует пользователя, он предоставляет клиенту доступ к ресурсу, заданному соответствующим универсальным идентификатором (Uniform Resource Locator, URL). Аутентификация с применением сертификата клиента позволяет серверу идентифицировать индивидуальных пользователей и предоставлять им заданные администратором права доступа. Так, Internet Information Server поддерживает аутентификацию клиентов в сеансе защищенного канала посредством сертификатов с открытым ключом.

Для того, чтобы можно было работать в браузере через защищенное соединение, нужно, чтобы он поддерживал протоколы SSL и был открыт доступ к Интернету по порту 443. Для нормальной работы с протоколами нужно использовать один из следующих браузеров:

• Internet Explorer 5.01 и выше
• Opera от 5.0 и выше
• Netscape Navigator от 4.6 и выше

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

Где можно увидеть применение протоколов SSL? Наверняка, многие из вас пользуются теми или иными системами электронных денег — Яндекс.Деньги, Web Money, иные. При подключении к серверам выполняется проверка вашего сертификата, после чего устанавливается (если сертификат действителен) защищенное соединение. Аналогично выполняется подключение к серверам электронных бирж, брокерских площадок, ряда других сервисов.

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

Разработка веб-сайтов ,

Алгоритмы

• Перевод

Как же все-таки работает 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-соединение возникает еще раньше. Единый сертификат на весь сервер будет использоваться при запросе к любому сайту, расположенному на сервере, что может вызвать

Аббревиатура HTTPS расшифровывается как Hypertext Transfer Protocol Secure, а переводится примерно следующим образом: «безопасный гипертекстовый протокол передачи данных». HTTPS появился в 2000-м году благодаря стараниям компании Netscape Communications и стал применяться во всемирной паутине очень широко. Следовательно, мы просто обязаны уделить ему внимание.

Суть простыми словами

На самом деле HTTPS является не отдельным, совершенно новым протоколом, а всего лишь расширенным HTTP. То есть, парни из Netscape Communications взяли уже существующий протокол HTTP и прикрутили к нему технологию шифрования данных SSL (Secure Sockets Layer) . Ну и к названию одну букву добавили, а также назначили для установки соединений вместо 80-го программного порта по умолчанию 443-й.

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

Встречаются и самодельные сертификаты (для серверов под управлением Unix-подобных ОС), «самоподписанные», созданные с помощью софта gensslcert от компании SuSE или ssl-ca от проекта OpenSSL. Защищённое соединение устанавливается, но надёжных гарантий подлинности нет.

Есть также разновидность сертификатов, которые выдаются сервером и хранятся в браузерах на компьютерах пользователей, дабы при подключении к веб-ресурсу автоматически устанавливать защищённое соединение и авторизоваться. Так действует, к примеру, сервис платёжной системы Webmoney под названием WM Keeper Light.

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

Вы можете открыть Менеджер сертификатов в настройках, допустим, Mozilla Firefox, отыскать список регистраторов, отредактировать его, посмотреть контрольные суммы. А также импортировать файл с сертификатом, который вам выдан (тем же Webmoney Keeper Light) или экспортировать уже присутствующий, создав резервную копию.

Однако вернёмся к нашим серверам. «Ух ты!» - радостно говорит браузер, - «доступно защищённое соединение! И сертификат подлинный!» На что сервер отвечает: «А ты как думал! Это же сайт солидной конторы. Добро пожаловать! Сейчас назначу надёжный 128-битный ключ шифрования - и начинаем обмениваться данными!»

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

Зачем это нужно

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

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

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

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

Практика

Касаемо электронной почты, к Gmail и Hotmail наконец-то присоединился Яндекс , включив в своём веб-интерфейсе протокол HTTPS по умолчанию. Настраивать вручную ничего не нужно.

В Gmail следует зайти в настройки и отметить опцию «Использовать только HTTPS». На всякий случай.

С Hotmail не всё так просто, доведётся залезть в дебри.

1. Жмём «Параметры» справа вверху, рядом с именем пользователя.
2. Выбираем «Другие параметры»
3. Движемся в раздел «Дополнительные параметры конфиденциальности»
4. «Перейти к параметрам HTTPS»
5. Выбираем «Использовать протокол HTTPS автоматически»
6. Ну и кнопку сохранения изменений не игнорируем, естественно.

При установке зашифрованного соединения адрес веб-страницы начинается не с «http://» а с «https://». Адресная строка может окрашиваться в иной цвет (например, в браузере SeaMonkey - в бледно-жёлтый). Или рядом с ней будет нарисован какой-нибудь символ вроде крохотного навесного замка. В общем, в разных браузерах индикация реализована по-разному. (В Firefox 9 с настройками по умолчанию - почему-то вообще никак.)

Заключение

Защищённый протокол HTTPS используется в таких социальных сетях и сервисах как Twitter, Blogger, Google+, Сайты Google, Wordpress.com, и это очень хорошо, потому что значительно снижает вероятность взлома учётной записи и рассылки спама от имени пользователя. Для банков и платёжных систем просто не может не быть зашифрованного соединения, иначе это никакой не банк и не система. Да и просто личная переписка останется приватной, если выбрать хорошую почтовую службу.

Предыдущие публикации: