HTTPS в принудительном порядке

[temmokan]

Несложно найти публикации в Сети, в которых критикуется политика Google по принудительному обозначению сайтов, не использующих HTTPS, как небезопасных. То есть буквально и всех: если используется HTTP, пользователей браузера, в рамках плана Moving towards more secureu Web будут предупреждать, что сайт небезопасен.

По сути, это выкручивание рук: доля браузера Google Chrome давно уже больше 50%, и те, кто не торопятся переносить сайты на HTTP, вскоре ощутят отток пользователей и, несомненно, санкции поисковой машины Империи Добра.

Вроде бы, всё очевидно: при передаче данных по незащищённому протоколу

• кто угодно может их перехватить по дороге - нельзя передавать тайные данные (такие как имена/пароли)
• нехороший человек сможет подменить данные по дороге - а это совсем плохо (MITM, "атака посредника")

Казалось бы, ставь HTTPS - тем более, что нужные для этого сертификаты открытого ключа за просто так выдаются тем же Let's Encrypt. Но не всё так просто.

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

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

Всё. Только это. Да, с таким сертификатом переданные данные действительно фактически нереально перехватить (дешифровать, точнее) третьей стороне, а значит - и подменить. Но на этом всё и заканчивается. Наличие годного HTTPS-канала передачи данных между вашим браузером и Web-сервером с другой стороны не гарантирует безопасность ваших данных, не гарантирует, что с той стороны нет злоумышленника. Кто угодно может получить упомянутый бесплатный сертификат.

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

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

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

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

А пока что, если ваш сайт всё ещё на HTTP - начинайте ставить тот же сертификат от Let's Encrypt уже сейчас. И да, геморроя с принудительным переходом только на HTTPS может оказаться более чем достаточно.

Зато Google будет доволен.

Comments

[brmail]

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

Вторая фигня, которая реально происходит. Это доступ наружу из корпоративных систем. Через разный проверяющий софт. И при этом вы получаете комп, на котором уже установлены поддельные сертификаты. MIM в чистом виде, при этом законный

[temmokan]

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

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