Взгляд на безопасность веб-сайтов постоянно меняется. Яркий тому пример — метод хранения паролей. В былые времена хеш с функцией MD5 был вполне приемлемым вариантом. Вскоре, однако, стала очевидной его недостаточность, поэтому мы пошли дальше и стали добавлять более мощные функции хеширования, такие как SHA1. Теперь и этот вариант представляется практически бесполезным, а целевые ориентиры вновь сместились. Если вы впервые об этом слышите, предлагаю ознакомиться с памяткой по хранению паролей от OWASP (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

Особенность механизмов хранения паролей заключается в том, что они практически скрыты от пользователя. С первого взгляда не поймешь, какую концепцию защиты учетных данных использует веб-сайт, тогда как информация о реализации протокола SSL лежит на поверхности. Независимым индикатором безопасности веб-сайта является содержимое публикуемого браузером отчета о реализации SSL. Уже давно конечным пользователям настоятельно рекомендуется «искать значок замка рядом с адресной строкой», поскольку таким образом браузер дает понять, что трафик между клиентом и сервером будет защищен (по крайней мере, до момента прерывания канала SSL где-то возле сервера). В этом и состояла основная схема оценки безопасности сайта (по наличию или отсутствию сертификата SSL), но теперь браузеры, такие как Chrome, выходят на качественно иной уровень. Отличной иллюстрацией может служить информация о сертификате моего сайта по адресу https://haveibeenpwned.com/ (см. экран 1). Здесь, в частности, говорится об «устаревшем шифровании», что обусловлено моей зависимостью от службы веб-сайтов Microsoft Azure, которая на момент написания этой статьи все еще поддерживает криптографический шифр RC4 (http://www.troyhunt.com/2015/06/its-time-for-grade-ssl-on-azure-websites.html).

 

Информация о сертификате сайта
Экран 1. Информация о сертификате сайта

То, что Chrome сообщает не просто о наличии сертификата SSL, но и о степени его надежности, без сомнения, очень хорошо. Если вспомнить проблемы безопасности, с которыми мы сталкивались в недавнем прошлом (POODLE, FREAK, Logjam и т. д.), становится очевидным, что просто наличия SSL недостаточно. SSL должен быть надежным, а браузер обязан дать вам знать, если это не так. Однако сегодня целевые ориентиры смещаются, что я отметил при работе с банком Absa в Южной Африке (см. экран 2).

 

Слабый вариант SSL
Экран 2. Слабый вариант SSL

Здесь мы имеем дело с ситуацией, когда банк использует слабый SSL (посмотрите мою сводку банков с указанием уровня их защищенности, http://windowsitpro.com/troy-hunts-security-sense/security-sense-why-are-our-banks-doing-bank-grade-security-so-poorly), о чем браузер вполне обоснованно предупреждает пользователей. В буквальном смысле браузер возлагает на сайт ответственность и предлагает пользователям соблюдать осторожность, устанавливая соединение. На мой взгляд, совет хорош, и за него следует выразить благодарность Chrome. Плохим советчиком я бы назвал банк, который в такой ситуации рекомендует своим клиентам игнорировать предупреждения браузера. Конечно, банки применяют множество других механизмов для защиты своих клиентов, но при пересылке данных единственное, что защищает их конфиденциальность и обеспечивает сохранность, — это реализация SSL.

Конечно, мы знаем об этом уже с сентября прошлого года (http://googleonlinesecurity.blogspot.com.au/2014/09/gradually-sunsetting-sha-1.html), когда компания Google сообщила, что о сертификатах, которые используют SHA1 и у которых срок действия истекает после 2016 года, будут выдаваться предупреждения. Существует также стабильный бета-канал Chrome, где в случае обнаружения шифра RC4 из адресной строки изымается значок замка и не применяется схема HTTPS. Как и в отношении поддержки SHA1, это означает, что больше нет необходимости изучать сертификат, чтобы узнать о недостатках шифра, так как эта информация выведена на первый план. Все это не новость для операторов веб-сайтов: мы давно знаем, что существуют определенные реализации SSL, которые просто не должны больше использоваться.

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