Міжнародная канферэнцыя распрацоўнікаў і карыстальнікаў свабодных праграм

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

Алексей Хлебников, Oslo, Norway

LVEE 2017

Browser makers spend a lot of effort for making SSL right and make PKI harder then ever, but pay too little attention to alternative methods of estimating the web site security. In this talk I will tell about such alternative methods and a little bit about using risk management for security level estimation.

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

На первых этапах внедрения 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
и борьбы со спамом.

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

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

Abstract licensed under Creative Commons Attribution-ShareAlike 3.0 license

Назад