Безопасноcть в браузерах: Альтернативы SSL

Ожидания и реальность

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

Однако, реальность оказалась сложнее. Например, пользоваться SSL стали
и компьютерные преступники.

Вот скриншот с форума, где DDOS-еры предлагают свои услуги:

Как видно, SSL-сертификат успешно проверен, замочек показан.
Пользователь может быть уверен, с сайтом “всё в порядке”.

А вот скриншот с сайта visa.com:

Видим, что сертификат браузеру определённо не нравится. Внимательный
читатель наверное уже догадался, что сертификат выписан на имя
“www.visa.com”, а введённый адрес – просто “visa.com”, без префикса
“www”. Но обычный пользователь вряд ли это поймёт, а вполне может
подумать, что его атакуют.

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

Заметим, что браузеры совсем не выдают таких предупреждений для
сайтов, которые предоставляются не по HTTPS, а по HTTP, то есть
вообще без сертификата. Таким образом, упрощённая модель
SSL-безопасности в Web выглядит скорее вот так:

, что не очень логично, так как “плохой” сертификат всё-таки лучше его
отсутствия.

Логичнее было бы вот так:

Взломы SSL

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

• 2001 – Атакующий прикинулся сотрудником Microsoft и получил у
  Verisign сертификат для Microsoft.
• 2008 – На сервисе live.com зарегистрирован бесплатный e-mail
  sslcertificates@live.com, затем у Thawte получен сертификат для
  login.live.com.
• 2008 – Взломы StartCom и Comodo, у Comodo получен сертификат для
  www.mozilla.com.
• 2009 – Взлом ipsCA через NULL prefix attack, получен сертификат для
  www.paypal.com.
• 2011 – Взломы Comodo, Diginotar и TurkTrust. Получены сертификаты
  для www.google.com, mail.google.com, addons.mozilla.org,
  login.live.com, login.yahoo.com, login.skype.com. Шуточная атака
  “Honest Achmed” на Mozilla.
• 2014 – Взлом NICCA, получены сертификаты для доменов Google и Yahoo.
• 2015 – Взломы CNNIC, WoSign, Let’s Encrypt и Symantec. Получены
  сертификаты для доменов Google, GitHub и других.
• 2016 – Найдены уязвимости в инфрастркутурах выдачи сертификатов у
  StartCom и Comodo. Были ли эти уязвимости использованы и как – пока
  неизвестно.

А также взломы разной степени эффективности самого протокола SSL/TLS:

• 2009 – Renegotiation attack, SSL stripping.
• 2011 – BEAST, StartTLS injection.
• 2012 – CRIME.
• 2013 – BREACH, TIME, Lucky13.
• 2014 – FREAK, POODLE, Triple Handshake.
• 2016 – DROWN.

А также не будем забывать о периодически находимых уязвимостях в
реализациях SSL, например Heartbleed в OpenSSL.

Система CA недостаточно надёжна

До сих пор никто так и смог дать убедительного ответа, почему сайты и
пользователи должны доверять тем самым CA, которых большинство
пользователей в глаза не видело. Ответ “по умолчанию” на этот вопрос -
потому что CA берут деньги за выдачу сертификата, и если они вдруг
выдадут неправильный сертификат или будут взломаны – сразу потеряют
доверие, клиентов и разорятся. Мне в этот аргумент почему-то не
очень-то верится. Особенно в свете известных вышеперечисленных
взломов. Кто из CA понёс серьёзное наказание в результате взлома и
прекратил выдачу сертификатов? Почти никто. Только маленький
Diginotar. А взлом Comodo в том же году, наделавший немало шума -
спустили на тормозах. Потому что Comodo – “too big to fail”. Работает
дальше и продолжает “радовать” нас периодическими уязвимости своей
инфраструктуры выдачи сертификатов. А сколько взломов не стало
достоянием общественности? А ведь CA довольно неохотно раскрывают
факты взломов своей инфраструктуры, и бывали уличены в сокрытии такой
информации.

А можем ли мы быть уверены, что если в офис CA придут
сотрудники местных спецслужб и попросят выдать им сертификат на не
принадлежащий им домен, то СА откажет им? Скорее, мы можем быть
уверены в обратном. А знает ли уважаемый читатель, что в США полицией
и спецслужбами уже несколько лет используются так называемые MITM
boxes? Это устройство, которое в реальном времени осуществляет
MITM-атаку и расшифровывает весь SSL-траффик, проходящий через
устройство. Причём, пользователь, которого прослушивают, не получает
никаких предупреждений от своего браузера, потому что MITM-box на лету
выдаёт “правильные” сертификаты для всех серверов, посещаемых
пользователем. Как устройчтво это делает? Очень просто – устройство
обладает intermediate-CA сертификатом, который любезно выдан крупным
американским CA, которому, конечно, доверяют все браузеры.

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

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

Чем отвечает индустрия

Как видно, в проблем в концепции SSL и CA хватает. Чем же отвечает
индустрия? Правильно, индустрия отвечает закручиванием гаек. “PKI them
harder”. В частности, предлагались или предлагаются следующие решения:

• Короткоживущие сертификаты
• Публичные списки выдаваемых сертификатов
• Обязательное OCSP
• HTTP Strict Transport Security (HSTS)
• HTTP Public Key Pinning (HPKP) и TACK
• Convergence и Mutually Endorsing CA Infrastructure
• The Monkeysphere Project и Web of Trust

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

Диверсификация защиты и управление рисками

PKI – не серебрянная пуля. И не священная корова. Нужна диверсификация
средств безопасности. Не стоит складывать все яйца в одну корзину,
полагаясь лишь на PKI.

Диверсификация защиты применяется в реальном мире с начала времён. Её
преимущество очевидно – нет единой точки отказа. Если механизм защиты
вдруг отказал, то

• без диверсификации – отказала вся система,
• с диверсификацией – возрос риск, но не отказала вся система.

Принципы безопасности с помощью диверсифицированной защиты и управления рисками:

• Применяется комплекс защитных мер.
• Ни одна из мер сама по себе не даёт сильной защиты.
• Комбинация защитных мер даёт сильную защиту.
• Возможна детальная оценка безопасности и “обратная связь”.

Оценка уровня безопасности сайта

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

Прежде всего, несколько предложений относительно самого SSL.

Так повелось, что SSL применяют как абсолютно “беcпамятную”
технологию. В отличие от, например, SSH. Каждое общение с сайтом – как
в первый раз. Сменился сертификат у сервера – никакой реакции у
браузера на это. Сменился CA – тоже никакой реакции.

Следующие факторы должны понижать оценку безопасности сайта:

• У сайта другой сертификат
  • И срок действия предыдущего не вышел
• У сертификата другой ключ
  • И предыдущий сертификат не отозван
• Внезапная смена CA
  • Французский CA, бразильский сайт?
• Смена EV на DV

“Память” неплохо бы использовать не только для SSL, но и для IP:

• Кардинально сменился IP
  • Совсем другая подсеть?
  • Совсем другая страна?
• Traceroute стал гораздо короче (MITM?)

Браузер должен помнить о ранее посещённых сайтах, когда сайт просит
пароль:

• Сайт посещался много раз, и много раз пароль здесь уже вводился -
  риск меньше.
• Сайт посещается в первый раз и уже просит пароль – риск больше.

Хостинг. Стоит проверить whois и AS (autonomous system) info.

Пример: банк Societe Generale.

• Хостится на AS.
• Имя AS: SOCIETE-GENERALE.
• Подключена к французскому бэкбону.
• Работает с 1995 года.

Такой хостинг заслуживает доверия.

По части DNS можно проверить следующее:

• Reverse lookup: client321.adsl-pool.isp.com
• Маленький TTL
• Комбинация записей A, MX, NS
• Регистратор DNS и IP:
  • RIPE: риск меньше
  • GoDaddy: риск больше

Можно проверить и TCP/IP stack fingerprint сервера:

• E-commerce сайт хостится на Windows Home Premium?
• Открыт порт, по которому слушает “популярный” троян?

Проверка URL:

• Смешанный алфавит в именах популярных сайтов.
• Spell-check: panascanic.com, bankoffireland.ie.
• Подстроки: “members”, “adsl-pool”, etc.

Мы видим ту же веб-страницу, что и остальные Интернет-пользователи,
или нам её подменили?

• Сравнение с веб-архивом.
• Сравнение с кэшем Google.
• Сравнение с User Agent = Googlebot.

Проверка содержания самой веб-страницы:

• Страница пытается задействовать известные уязвимости?
• HTML тэги в “неправильных” местах?
• Несколько тэгов html, head, title, body?
• Много объектов подгружается из других доменов?

Проверка Javascript на странице:

• Длинные строки и их энтропия.
• Вызовы eval(), большое количество substring(), concat(), fromCharCode().

Для оценки безопасности страницы наверняка можно использовать и
байесовский фильтр, широко применяемый для оценки безопасности e-mail
и борьбы со спамом.

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

После всех проверок, оценка безопасности сайта может выглядеть,
например, вот так: