Немногие обращают внимание на зелёную надпись «Надёжный» (надёжный сайт) слева от адресной строки в Chrome и на значок закрытого замка рядом, а между тем число сайтов с такой надписью в 2017 году перевалило за половину всех существующих. Что же это означает? Давайте разберёмся.
История протокола HTTPS
На самой заре Интернета перед пользователями сети встала проблема: некоторые веб-страницы хочется сделать приватными, доступными только ограниченному кругу людей. Очевидным решением было передавать серверу пароль и выдавать пользователю электронный пропуск (токен), который он должен предъявлять каждый раз, как заходит на закрытый ресурс. Но как сохранить токен и пароль в тайне? Как мы помним из прошлой статьи, HTTP — текстовый протокол. Он передаёт все данные в открытом виде, более того, в довольно понятной для человека форме, и никак не предотвращает перехват данных сторонним лицом.
В 1995 году компания Netscape Communications опубликовала стандарт SSL (Secure Sockets Layer, уровень защищённых сокетов), предназначенный для передачи данных через открытые каналы. Основанный на алгоритмах асимметричного шифрования, протокол подходил для использования не только в качестве слоя защиты для HTTP, но и в качестве контейнера для передачи голоса, видео и любой другой информации вне зависимости от канала. Уже в 1996 была выпущена версия SSL 3.0.
В 1999 году на основе SSL3.0 сообщество IETF разработало TLS — протокол защиты транспортного уровня. В нём были исправлены множественные недочёты и уязвимости SSL, и сегодня TLS стал рекомендованным стандартом шифрования сетевых соединений. На данный момент больше половины трафика сети использует SSL/TLS в качестве защищённого контейнера. По сути, обычный HTTP пропускается через «чёрный ящик» криптопротокола и посылается клиенту или серверу, где и расшифровывается. Чёткое разделение между слоем шифрования и слоем доступа к сетевым сервисам позволило программистам легко интегрировать HTTPS во многие проекты. Упомянутый выше значок «Надёжный сайт» рядом с адресной строкой браузера как раз сигнализирует о том, что ваше соединение с сайтом защищено одним из криптоалгоритмов.
Что же под капотом у современных средств шифрования?
Механизмы безопасности
Установление безопасного соединения состоит из нескольких этапов:
- клиент и сервер договариваются, какой протокол использовать для обмена ключами (RSA или протокол Диффи-Хеллмана, о них ниже);
- клиент и сервер обмениваются ключами;
- с этого момента все пакеты между Алисой (почему-то во всех учебниках по криптографии Алиса что-то шлёт Бобу или серверу) и сервером шифруются с помощью этого ключа обычным криптоалгоритмом (AES, Blowfish, ГОСТ 28147-89 и т.д.)
Почему бы не шифровать с помощью RSA или Диффи-Хеллмана (DH) весь поток данных между клиентом и сервером? Дело в том, что и RSA, и DH очень требовательны к ресурсам компьютера, и сильно бы замедлили отправку и приём информации, тогда как алгоритмы шифрования с симметричным ключом требуют гораздо меньше вычислительных мощностей и часто реализованы прямо «в железе».
Протокол Диффи-Хеллмана
Представим ситуацию: Алиса пишет Бобу, что она спрятала банку от Евы с печеньем на верхней полке бельевого шкафа, и при этом использует мессенджер, работающий поверх HTTP. Ага! — говорит Ева, вступившая неделей ранее в класс по компьютерным сетям. — Эти простаки шлют незащищённый текст. Все печеньки мои!
И как же Алиса может защитить своё печенье от Евы, которая слушает все её переговоры с Бобом? Ответ был дан американскими криптографами Диффи, Хеллманом и Мерклом ещё в 1976 году на Национальной Компьютерной Конференции. Выступая на ней, математики предложили протокол безопасной передачи сообщений по открытым каналам, позже названный протоколом Диффи-Хеллмана.
Идея протокола основана на том, что с помощью некоторой магии, которую волшебники математики называют коммутативностью операции возведения в степень. Разберёмся в концепции этого полезного протокола на простом примере: представьте, что Алиса хочет послать по почте Бобу немного вкусного печенья в контейнере. Однако хрустящее лакомство поджидает грозная опасность в виде голодной Евы, периодически заглядывающей в почтовый ящик Боба. Как же обезопасить подарок от загребущих лапок Евы? Можно закрыть контейнер на замок, но как быть с ключом? Послать по почте его нельзя, а встретиться с Бобом лично для обмена ключами не получится ввиду плотного графика.
Алгоритм безопасной пересылки существует, и он таков:
- Алиса закрывает ящик с печеньем на замок и посылает по почте. Ева не может добраться до печенья — ключа у неё нет.
- Боб получает закрытый ящик и вешает на него свой замок, после чего посылает по почте. У Евы опять же нет печенья — ящик закрыт на два замка!
- Алиса получает ящик обратно, снимает с него свой замок и отправляет его Бобу — но уже с его собственным замком.
- Боб получает ящик с печеньем и открывает его.
- Все довольны (кроме Евы).
Таким образом, несмотря на то, что Ева имеет доступ к ящику, а у Евы и Боба нет общего ключа, посылка доходит в сохранности. Казалось бы — вот они, счастье и гарантия тайны личной переписки! Однако не всё так просто. При всей простоте и стойкости к перехвату протокол Диффи-Хеллмана обладает весомым недостатком: двойная пересылка сообщений. Только вдумайтесь: каждый раз, когда вы бы смотрели фильм или слушали музыку по защищённому каналу, вашему телефону приходилось бы посылать на сервер то же количество трафика, что он бы получал, а потом получать его снова. Нагрузка на сеть и процессор возросла бы минимум втрое! И хотя в некоторых особо критичных случаях перерасход ресурсов в обмен на безопасность представляется выгодной сделкой, для большинства ситуаций использование чистого протокола Диффи-Хеллмана — непозволительная роскошь. Как же тогда нам добиться безопасной передачи данных?
Асимметричное шифрование
Идея асимметричного шифрования состоит в следующем: существуют алгоритмы, которые позволяют шифровать сообщение одним ключом (публичным), а расшифровывать с помощью другого (приватного). Таким образом, узнав публичный ключ адресата, вы сможете посылать ему зашифрованные письма, расшифровать которые сможет только владелец приватного ключа.
Самый известный и популярный алгоритм асимметричного шифрования называется RSA — по именам трёх создателей (Rivest, Shamir и Adleman). Опубликованный ещё в 1987 году, он до сих пор является криптографическим стандартом.
Криптографические сертификаты
Помимо безопасной пересылки сообщений, асимметричное шифрование позволяет провернуть ещё один весьма полезный трюк — создание электронной подписи.
Используя хэш-функцию (это такая полезная функция, которая может превращать текст любой длины в число меньше определённой величины) и RSA, мы можем защитить важные документы от подделки.
Всё очень просто:
- сначала сгенерируем пару приватный-публичный ключ;
- после этого возьмём хэш от данных, которые нужно защитить от фальсификации;
- теперь зашифруем хэш-сумму нашим приватным ключом (обратите внимание, при использовании RSA для шифрования сообщений данные шифруются публичным ключом!) и прикрепим получившиеся байты к нашему файлу;
- Вуаля! Теперь любой, кто имеет публичный ключ, может взять контрольную сумму от документа и сравнить с расшифрованным хэшем. Если обе цифры совпадают, то документ подлинный.
Так как же электронная подпись относится к безопасному интернету? Ответ прост: она решает проблему доверия к ключу, полученному клиенту от сервера. Действительно, откуда мы знаем, что соединились с сервером vk.com, а не с хакерской ловушкой, установленной на вашем роутере? Существует ряд так называемых центров сертификации, один из которых подписывает файл с именем сайта, данными о владельце и открытым ключом. После выдачи такого «удостоверения» сервер использует этот файл на этапе установления соединения. Дело в том, что на вашем компьютере (а также на планшете и телефоне) хранится набор открытых ключей стандарта X.509, выпущенных этими самыми сертификационными центрами, поэтому браузер имеет возможность проверить сертификат сайта и в случае проблем просигнализировать о проблеме пользователю:
Так в чём подвох?
Казалось бы, методы шифрования отточены за долгие годы, и большая часть атак на криптоалгоритмы носит скорее теоретический характер, так что нам не о чем волноваться. Так ли оно на самом деле?
К сожалению, TLS защищает ваши данные только на пути от браузера до сервера. На самом деле, никакие технические методы не решат проблем социальных. Мошенникам не составит труда получить домен, похожий на известный сайт, и TLS сертификат, таким образом мимикрируя под безопасный сервис. Сертификаты на вашем компьютере можно подменить (так делают даже некоторые антивирусы, якобы с целью проверки трафика, но кто знает наверняка?), да и люди никогда не страдали избытком бдительности, с радостью открывая файлы Word от незнакомых людей и доверяя доступ к аккаунтам мошенническим приложениям.
Несмотря на то, что браузеры полны уязвимостей, большая часть взломов происходит по вине пользователей или ленивых владельцев сайтов. Как шутят программисты, самая уязвимая часть системы — это прокладка между креслом и экраном. Так что даже бродя по сайтам с «замком» — не теряйте бдительности.
