Безопасные сайты в интернете можно распознать по аббревиатуре HTTPS (Hypertext Transport Protocol Secure) и зелёной маркировке защиты в левой части адресной строки браузера – так обозначается шифрование обмена данными между сайтом со всеми модулями и браузером. Кроме того, перед началом передачи данных сервер предъявляет действительный сертификат. Так пользователи могут быть уверены, что открывают «правильный» сайт, а не подложенный злоумышленниками.
Впрочем, это подход в духе «всё или ничего»: сервер передает данные или полностью в зашифрованном виде по протоколу HTTPS, или полностью в незашифрованном по HTTP. Но часто бывают случаи, когда шифруется только часть сайта, например, если он содержит рекламу, которая передается по HTTP, или использует скрипты, которые опять-таки обращаются к HTTP-ресурсам. Это приводит к проблемам в HTTPS: браузеры выводят предупреждения, блокируют или неправильно отображают сайты. В таких случаях выход предлагает оппортунистическое шифрование (OE, Opportunistic Encryption).
Оппортунистическое шифрование
Оппортунистическое шифрование (OE) является важным промежуточным решением между HTTP и HTTPS. Этот метод при необходимости позволяет шифровать передачу данных сайта по HTTP. Побочный эффект использования OE – данные сайта могут передаваться по HTTP/2 на более высоких скоростях.
Увеличение доли безопасных соединений
Согласно регулярным оценкам Google, пользователи Chrome все чаще обмениваются данными по HTTPS-соединению
OE – это метод, в настоящее время установленный в рамках проекта Инженерного совета Интернета (Internet Engineering Task Force). Суть заключается в следующем: для передачи данных HTTP-сайтов применяется криптографический протокол TLS (Transport Layer Security). Похоже на HTTPS только на первый взгляд, поэтому при использовании OE в адресной строке не видно пометки «HTTPS».
Для того, чтобы уловить разницу, нужно сравнить установление соединения браузера и сервера по HTTPS и OE и проанализировать поведение браузера. На правой странице предлагаем схематическое описание принципа работы обоих методов. HTTPS рассчитан на обеспечение безопасности с самого начала и срабатывает сразу вместе с конкретным запросом браузера об установлении зашифрованного соединения.
Если сервер не может его установить, обмен данными завершается уведомлением об ошибке, не успев действительно начаться. С точки зрения безопасности это правильное решение, поскольку по HTTPS передача данных в незашифрованном виде не может осуществляться.
OE работает по-другому. Браузер запрашивает у сервера незащищенный HTTP-сайт через порт 80. Через так называемую альтернативную службу, простой дополнительный заголовок, сервер в ответ сообщает браузеру, что данные аналогичного сайта он может передавать не только через порт 80, но и через порт 443 с использованием TLS. Если браузер поддерживает OE (в настоящее время только Firefox), следующие запросы могут происходить по TLS.
Как и в случае с HTTPS, сначала браузер проверяет сертификат сервера, затем происходит обмен ключом шифрования, и только потом устанавливается защищенное соединение между браузером и сервером. Но, в отличие от HTTPS, если шифрование не удается, передача данных не прерывается – происходит переход к незашифрованной связи, как изначально браузер запрашивал у сервера.
Технически отличие между HTTP с TLS и HTTPS, что касается запросов, заключается не в мощности шифрования, а только в букве S в адресной строке. Разница заключается в установлении соединения с сайтом и в том, что браузеры по-разному осуществляют соединения HTTP и HTTPS: при зашифрованном HTTP-соединении, в отличие от HTTPS, может быть сомнительный смешанный контент, например, ссылки на HTTP-ресурсы или реклама, которая передается только в открытом виде.
Сравнение скорости: обращение к сайту по HTTP и HTTP/2
Скорость протокола HTTP/2 намного выше, как показывают тесты, но каналы передачи данных по-прежнему защищаются HTTPS. HTTP-соединения по протоколу HTTP/2 позволяет только OE.
Оппортунистическое шифрование можно спокойно воспринимать как инструмент для заполнения пробелов, пока все сайты не перешли на HTTPS – а этот процесс займет не один год. Между тем OE можно использовать для увеличения скорости обмена данными. Для HTTP/2, второй версии протокола HTTP, шифрование обязательно. По HTTP/2 передаются данные защищенных сайтов, причем скорость сайтов возрастает (см. справа), но только тех из них, которые поддерживают HTTPS. Поскольку OE работает как раз на HTTP-сайтах, данные таких сайтов тоже могут передаваться по более быстрому протоколу HTTP/2.
Пока не все сайты перешли на HTTPS, оппортунистическое шифрование является практическим временным решением
Что касается безопасности, OE выполняет не всю работу. Этим методом можно защититься от пассивного прослушивания, например, спецслужбами, которые следят за сетевым трафиком в целом. Активной же атаке достаточно перехватить только первый заголовок, в котором сервер предлагает альтернативную службу. Как только удаляется это указание, процесс установления шифрования прерывается и появляется возможность прослушивать незащищенный канал.
OE не представляет собой альтернативу HTTPS – на этом его сторонники даже не настаивают. Скептики также указывают на то, что OE – это отличный повод для администраторов сайтов не переходить на HTTPS. Но в действительности получается не совсем так: нередко перечисленные технические причины переходу препятствуют.
В дискуссию о шифровании в интернете включился даже изобретатель Всемирной паутины Тим Бернерс-Ли. Он выступил за то, чтобы совсем уйти от HTTPS – не в смысле положить конец шифрованию, а наоборот: он предложил для всего сетевого трафика использовать криптографию TLS в режиме реального времени – тогда разводить HTTP и HTTPS не было бы необходимости.
Заезд Браузер и веб-сайт обмениваются данными или по незашифрованному каналу по протоколу HTTP, или по зашифрованному каналу по HTTPS, или при помощи нового метода шифрования Opportunistic Encryption по HTTP.
При стандартном запросе по HTTP браузер обращается к серверу и отправляет запрос по незашифрованному каналу, на который сервер отвечает без аутентификации также в открытом виде.
Перед тем, как отправить хотя бы бит полезных данных, по протоколу HTTPS между браузером и сервером устанавливается зашифрованное соединение. Этот метод подразумевает в том числе аутентификацию.
Новинка: Оппортунистическое шифрованиеОппортунистическое шифрование начинается с незашифрованного запроса. Шифрование устанавливается только тогда, когда сервер отправляет альтернативный заголовок с предложением зашифровать канал.
Здесь угрожает опасность: при помощи атаки посредника злоумышленник может перехватить альтернативный заголовок (см. основной текст)
Фото: компании-производители
SSH (secure shell) – это безопасный протокол и наиболее распространенный способ защищенного управления удаленными серверами. Используя ряд технологий шифрования, SSH обеспечивает механизм для установления криптографически защищенного соединения между двумя сторонами, аутентификации каждой стороны, обмена командами и выходными данными.
Читайте также :
В данной статье мы рассмотрим основные методы шифрования и установления защищенных соединений, которые использует SSH. Эта информация может быть полезна для понимания различных уровней шифрования и этапов формирования соединения и аутентификации.
Для обеспечения передачи информации SSH использует несколько различных методов управления данными в разных точках транзакции. К ним относится симметричное шифрование, асимметричное шифрование и хеширование.
Способ шифрования определяется связью компонентов, которые шифруют и дешифруют данные.
Симметричное шифрование – это способ шифрования, при котором для шифрования и дешифровки данных между сторонами используется один и тот же ключ. Это означает, что любой, у кого есть ключ, может шифровать и дешифровать сообщения других пользователей, у которых есть этот же ключ.
Такой тип также называется шифрованием с общим секретным ключом. Обычно при этом для всех операций используется только один ключ, или пара простых ключей.
Симметричные ключи используются в SSH для шифрования всего соединения. В свою очередь асимметричные пары ключей используются только для аутентификации, а не для шифрования соединения. Симметричное шифрование позволяет защитить парольную аутентификацию от отслеживания.
Клиент и сервер устанавливают этот секретный ключ, который не должен быть известен посторонним. Секретный ключ создается посредством так называемого алгоритма обмена ключами. Этот обмен приводит к тому, что сервер и клиент одновременно используют один и тот же ключ независимо друг от друга.
Ключ для симметричного шифрования зависит от сессии и обеспечивает шифрование данных, передаваемых между сервером и клиентом. Как только соединение установлено, ключ шифрует все данные между сервером и клиентом. Это делается до аутентификации клиента.
Протокол SSH может использовать различные системы симметричного шифрования, включая AES, Blowfish, 3DES, CAST128 и Arcfour. Сервер и клиент могут определить список поддерживаемых шифров и упорядочить его в зависимости от своих предпочтений. Первый шифр из списка клиента, который поддерживается сервером, используется в качестве алгоритма шифрования в обоих направлениях.
В Ubuntu 14.04 клиенты и серверы по умолчанию используют aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, [email protected], [email protected], [email protected], aes128-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour.
То есть если две машины Ubuntu 14.04 пытаются установить соединение, не переопределяя стандартных параметров, они всегда будут использовать aes128-ctr для шифрования их соединения.
Асимметричное шифрование отличается от симметричного тем, что для передачи данных в одном направлении необходимы два связанных ключа. Один из них называется закрытым (или секретным) ключом, а второй – открытым ключом.
Открытый ключ можно свободно распространять. Он связан с закрытым ключом, но закрытый ключ нельзя вычислить из открытого ключа. Математическая взаимосвязь между этими ключами позволяет открытому ключу шифровать сообщения, которые могут быть дешифрованы только закрытым ключом. Это одностороннее шифрование: открытый ключ не может расшифровывать зашифрованные им данные и все, что отправляет его закрытый ключ.
Закрытый ключ нужно хранить в секрете и никому не передавать. Это базовое правило асимметричного шифрования. Закрытый ключ является единственным компонентом, способным расшифровывать данные, которые были зашифрованы с помощью связанного с ним открытого ключа.
SSH использует асимметричное шифрование в нескольких разных задачах. Во время начального процесса обмена ключами для настройки симметричного шифрования сессии используется асимметричное шифрование. На данном этапе обе стороны генерируют временные пары ключей и обмениваются открытыми ключами, чтобы создать общий секретный ключ для симметричного шифрования.
Более широко асимметричное шифрование SSH используется для беспарольной аутентификации на основе ключей. Пары ключей SSH могут использоваться для аутентификации клиента на сервере. Клиент создает пару ключей и подгружает открытый ключ на удаленный сервер в файл authorized_keys в каталоге ~/.ssh.
После установки симметричного шифрования между сервером и клиентом клиент должен пройти аутентификацию для разрешения доступа. Сервер может использовать открытый ключ шифрования сообщения о вызове клиенту. Если клиент может расшифровать это сообщение, он подтверждает, что ему принадлежит связанный закрытый ключ. Затем сервер может настроить среду для клиента.
Еще одна форма обработки данных, которую использует SSH, — это криптографическое хеширование.
Криптографическое хеширование – это совокупность методов создания краткой «подписи» или сводки набора информации. Главными отличительными признаками методов хеширования являются их необратимость, непредсказуемость и уникальность.
Шифруя одно и то же сообщение с помощью одной и той же функции хэширования, вы получите один и тот же хэш. Изменится любая часть данных – получите совершенно другой хэш. Пользователь не должен иметь возможность воссоздавать исходное сообщение из хэша, но должен иметь возможность определить, выдало ли данное сообщение заданный хэш.
Учитывая эти свойства, хеши в основном используются для подтверждения целостности данных и проверки подлинности связи. Основное использование хэширования в SSH – это HMAC или хэш-коды аутентификации сообщений. Они позволяют подтвердить, что текст принятого сообщения не был изменен или поврежден.
В рамках согласования симметричного шифрования выбирается алгоритм кода аутентификации сообщения (MAC). Алгоритм выбирается путем обработки списка доступных MAC-адресов клиента. В результате будет использоваться первый алгоритм из этого списка, который поддерживает сервер.
Впоследствии каждое отправленное сообщение должно содержать MAC, чтобы другая сторона могла проверить целостность пакета. MAC вычисляется из симметричного общего секретного ключа, последовательности пакетов сообщения и фактического содержимого сообщения.
Сам MAC отправляется за пределы области симметричного шифрования в качестве конечной части пакета. Обычно рекомендуют зашифровать данные, а затем вычислить MAC.
Теперь у вас есть базовое понимание того, как работает SSH. В протоколе SSH используется модель клиент-сервер для аутентификации двух сторон и шифрования данных между ними.
Серверный компонент прослушивает соединения по указанному порту. Он отвечает за ведение переговоров о безопасном подключении, аутентификацию подключаемой стороны и создание правильной среды для клиента в случае, если он предоставил валидные учетные данные.
Клиент отвечает за рукопожатие TCP с сервером, согласование безопасного соединения, проверку соответствия сервера ранее записанной информации и за предоставление учетных данных для аутентификации.
Сессия SSH устанавливается в два этапа. Первый этап – согласование и установка шифрования для защиты будущего взаимодействия. Второй этап – аутентификация пользователя и принятие решения о том, должен ли клиент получить доступ к серверу.
Когда клиент инициирует TCP-соединение, сервер отвечает версиями протокола, которые он поддерживает. Если клиент тоже поддерживает одну из версий протокола, соединение продолжается. Сервер также предоставляет свой открытый ключ хоста, с помощью которого клиент может подтвердить, что подключается к нужному хосту.
На этом этапе обе стороны обсуждают ключ сеанса с помощью алгоритма Диффи-Хеллмана. Этот алгоритм (и его варианты) позволяет каждой стороне объединить свои личные данные с общедоступными данными другой системы, чтобы получить одинаковый секретный ключ для сессии.
Ключ сессии будет использоваться для шифрования всей сессии. Открытый и закрытый ключ, который используется на этом этапе, не совпадают с парой ключей SSH, используемой для аутентификации клиента на сервере.
Базовый алгоритм Диффи-Хеллмана работает так:
Симметричное шифрование, которое используется для такого соединения, называется бинарным протоколом пакетов. Вышеупомянутый процесс позволяет каждой стороне одинаково участвовать в создании общего ключа, благодаря чему ни одна из сторон не может полностью контролировать этот ключ. Кроме того, когда обе стороны получают одинаковый ключ, нет необходимости отправлять эту информацию по небезопасным каналам.
Сгенерированный ключ – это симметричный ключ, который используется для шифрования и расшифровки сообщений. Цель этого ключа – заключить всю дальнейшую связь в зашифрованный туннель, который не сможет расшифровать злоумышленник.
После этого этапа начинается аутентификация клиента.
Следующий этап подразумевает аутентификацию пользователя и определение доступа. Существует несколько различных методов, которые могут использоваться для аутентификации на основе того, какие данные принимает сервер.
Простейшим методом является парольная аутентификация, при которой сервер просто запрашивает у клиента пароль учетной записи. Пароль отправляется через шифрованное соединение, поэтому он защищен от посторонних.
Несмотря на то, что пароль шифруется при передаче, этот метод обычно не рекомендуется использовать из-за ограничений сложности пароля. Автоматизированные сценарии очень легко подбирают пароли обычной длины и могут навредить серверу.
Самой популярной и рекомендуемой альтернативой парольной аутентификации является аутентификация на основе ключей SSH. Пары SSH-ключей являются асимметричными ключами, что означает, что два связанных ключа служат для разных функций.
Открытый ключ используется для шифрования данных, которые могут быть дешифрованы только с помощью закрытого ключа. Открытый ключ можно свободно передавать, потому что вычислить закрытый ключ из открытого ключа невозможно.
Аутентификация на основе ключей SSH начинается после того, как установлено симметричное шифрование. Процедура выполняется следующим образом:
Как видите, асимметрия ключей позволяет серверу шифровать сообщения клиенту с помощью открытого ключа. Затем клиент может доказать, что он имеет закрытый ключ, для чего ему нужно дешифровать полученное сообщение.
Теперь у вас есть представление о взаимоотношениях между различными компонентами и алгоритмами. Знакомство с основами SSH может помочь вам лучше понять, что происходит при входе на удаленный сервер.
Tags:Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL /TSL -соединения перехватить обычными средствами невозможно. Но так ли это?
На самом деле - не совсем так. Да, зашифрованный трафик теоретически невозможно расшифровать, хотя опять таки теоретически при очень большой необходимости и желании, и такой трафик можно расшифровать, подобрав ключ. Однако для этого нужны такие затраты ресурсов, что актуальность взлома сохраняется только, наверное, на правительственном или военном уровне:)
При работе по защищенному соединению (самый просто пример - HTTPS) весь трафик между взаимодействующими точками в сети шифруется на стороне отправителя и дешифруется на стороне получателя. Шифруется трафик, идущий в обоих направлениях. Для того, чтобы его зашифровать и расшифровать нужна пара ключей (ассиметричное шифрование). Публичный ключ служит для зашифрования и передается получателю данных, а приватный - для дешифрования, он остается у отправителя. Таким образом, узлы, между которыми устанавливается SSL-соединение, обмениваются публичными ключами. Далее, для повышения производительности формируется единый ключ, который пересылается уже в зашифрованном виде и используется как для шифрации, так и для дешифрации на обеих сторонах (симметричное шифрование).
А как они это делают? Обычно - по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).
Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.
Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:
клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения
Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.
В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере - ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.
Стоит отметить, что уже давно продаются так называемые «решения по информационной безопасности предприятия», которые перехватывают весь трафик, проходящий через офисный прокси-сервер, и «читают» его. Программы ищут наличие определенных фраз или информации определенного вида в потоке данных от браузеров, почтовых программ, ftp-клиентов, мессенджеров сотрудников офиса. Причем, эти программы умеют различать и обрабатывать правильно самые разные виды информационного взаимодействия с серверами. В том числе, они проверяют и защищенный SSL-трафик путем подмены сертификатов. С разработкой одной из таких систем я сталкивался почти непосредственно.
Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:
<== SSH-соединение ==> сервер <=> целевой сервер
Другой способ защиты трафика - VPN -канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.
На практике есть два варианта работы. Первый - покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP.
Второй вариант - покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. VDS может быть российским или американским (только не забывайте про заокеанские пинги), дешевым (от $5) и слабым или дорогим и помощнее. На VDS ставят OpenVPN -сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента .
Если вы решите использовать вариант с OpenVPN, то есть например эта простая пошаговая инструкция по поднятию сервера (Debian). Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).
Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.
Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, - это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.
Теги: Добавить метки
Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.
Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.
Как данные защищаются? Как клиент и сервер могут установить безопасное соединение, если кто-то уже прослушивает их канал? Что такое сертификат безопасности и почему я должен кому-то платить, чтобы получить его?
Когда браузер делает запрос к Вашему любимому веб-сайту, этот запрос должен пройти через множество различных сетей, любая из которых может быть потенциально использована для прослушивания или для вмешательства в установленное соединение.
С вашего собственного компьютера на другие компьютеры вашей локальной сети, через роутеры и свитчи, через вашего провайдера и через множество других промежуточных провайдеров – огромное количество организаций ретранслирует ваши данные. Если злоумышленник окажется хотя бы в одной из них - у него есть возможность посмотреть, какие данные передаются.
Как правило, запросы передаются посредством обычного HTTP, в котором и запрос клиента, и ответ сервера передаются в открытом виде. И есть множество весомых аргументов, почему HTTP не использует шифрование по умолчанию:
Для этого требуется больше вычислительных мощностей
Передается больше данных
Нельзя использовать кеширование
Но в некоторых случаях, когда по каналу связи передается исключительно важная информация (такая как, пароли или данные кредитных карт), необходимо обеспечить дополнительные меры, предотвращающие прослушивание таких соединений.
TLS - наследник SSL - это такой протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (так называемого HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI . Объясняя на пальцах, это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением.
TLS – гибридная криптографическая система. Это означает, что она использует несколько криптографических подходов, которые мы и рассмотрим далее:
1) Асиметричное шифрование (криптосистема с открытым ключом) для генерации общего секретного ключа и аутентификации (то есть удостоверения в том, что вы – тот за кого себя выдаете).
2) Симметричное шифрование , использующее секретный ключ для дальнейшего шифрования запросов и ответов.
С тех пор как сообщение было зашифровано с помощью открытого ключа, оно может быть расшифровано только соответствующим ему закрытым ключом. Ни один из ключей не может выполнять обе функции. Открытый ключ публикуется в открытом доступе без риска подвергнуть систему угрозам, но закрытый ключ не должен попасть к кому-либо, не имеющему прав на дешифровку данных. Итак, мы имеем ключи – открытый и закрытый. Одним из наиболее впечатляющих достоинств ассиметричного шифрования является то, что две стороны, ранее совершенно не знающие друг друга, могут установить защищенное соединение, изначально обмениваясь данными по открытому, незащищенному соединению.
Клиент и сервер используют свои собственные закрытые ключи (каждый – свой) и опубликованный открытый ключ для создания общего секретного ключа на сессию.
Это означает, что если кто-нибудь находится между клиентом и сервером и наблюдает за соединением – он все равно не сможет узнать ни закрытый ключ клиента, ни закрытый ключ сервера, ни секретный ключ сессии.
Как это возможно? Математика!
Как только произошел обмен ключами по 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.
При получение такого сертификата, браузер отображает в адресной строке зеленую плашку, в дополнение к обычной иконке с замочком.
