Cloudflare

Вчера Cloudflare анонсировала замену Капчи с помощью FIDO аттестации. Вы можете почитать об этом в их блоге https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/, и попробовать само решения(если у вас есть FIDO сертифицированный ключ безопасности, как например Yubikey) https://cloudflarechallenge.com/

Также можно прочитать новость от @maybe_elfhttp://personeltest.ru/aways/habr.com/ru/news/t/557776/

Для тех кому интересно больше узнать о FIDO2 советую почитать эту статью http://personeltest.ru/aways/habr.com/ru/post/354638/

Как работает "FIDO Капча" у Cloudflare:

1. Пользователя отправляют на Капча страницу

   

2. Пользователь нажимает "I am human" (Я человек)

3. Ключ безопасности загорается и пользователь дотрагивается до ключа

4. Браузер запрашивает разрешение на получение аттестации устройства. После соглашения пользователем, аттестация отправляется Cloudflare.

1. Cloudflare имея корневой сертификат полученный от производителя, подтверждает валидность аттестационного сертификата.

2. PROFFIT!!!!

Прежде чем понять почему это все плохо, давайте разъясним два главных концепта Аттестация и Капча.

Что такое FIDO аттестация?

Аттестация это механизм протоколов FIDO для получения информации о модели устройства и его производителе. Когда вы регистрируете FIDO устройство в своем аккаунте, вебсайт может запросить вас предоставить аттестацию. По умолчанию же браузер её вырезает(почему обсудим позже).

Аттестация это такая криптографическая обертка. Во время производства, производитель зашивает в устройство партийный сертификат и партийный приватный ключ, a так же устанавливает идентификатор модели устройства. Для FIDO2 это GUID/UUID, для U2F это SKID(Subject Key Identifier). Вебсайт получая аттестацию, использует идентификатор модели чтобы найти корневой сертификат, и с помощью него валидирует путь сертификатов. Никакой магии, обычный PKI.

Что такое Капча?

Капча^[1](отCAPTCHAангл.CompletelyAutomatedPublicTuring test to tellComputers andHumansApart полностью автоматизированный публичныйтест Тьюрингадля различения компьютеров и людей) компьютерный тест, используемый для того, чтобы определить, кем является пользователь системы: человеком или компьютером.

Ист. https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D1%87%D0%B0

То есть, весь смысл капчи это то что есть некие вещи которые тяжелые для компьютера: машинное зрение, анализ текста, логические пазлы и т.д., но легкие для человека.

Так почему же FIDO аттестация это плохая замена Капчи?

Первое: Автоматизация FIDO устройств это достаточно тривиальная задача

Весь смысл капчи это то что автоматизировать процесс решения задачи очень сложно. Но вот что не учли в Cloudflare это то что автоматизация FIDO ключей безопасности это очень просто. Во время аутентификации с помощью FIDO аутентификатор требует доказательства присутствия. Это делается за счет нажатия на кнопку или считыватель отпечатков. Соответсвенно, имея базовые знания электроники и умение писать под 5$ ардуинки, можно существенно автоматизировать процесс получения доказательства присутствия:

Второе: Хакерам разрешения не нужны

Аттестация по умолчанию вырезается браузером, и вебсайту возвращается пустая аттестация, или как её называют в WebAuthn API - NONE. Если вебсайт хочет получить аттестацию, то он должен установить attestation: "direct" в запросе к API. Когда этот флаг установлен, пользователь должен дать согласие для передачи аттестации. Это сделано из-за проблем приватности у аттестации, об это мы поговорим ниже.

Как мы знаем исходный код у Chromium полностью открытый и вы можете или полностью убрать плашку разрешения, или же модифицировать функцию EraseAttestationStatement и добавить JS инжектор который заменит "direct" на "none" но из-за модифицированного исходного кода полная аттестация все равно вернется, и таким образом Cloudflare ничего не поймет.

Так же у Google Enterprise есть возможность настройки политик чтобы аттестация всегда возвращалась для определенных доменов https://chromeenterprise.google/policies/#SecurityKeyPermitAttestation

Третье: FIDO ключи безопасности достаточно быстры

По моему личному опыту, на низком уровне, для генерацию аттестации ключи расходуют от 700мс до 1700мс. Это достаточно грубая оценка ибо я не пишу супер быстрый код, но с более тонкой оптимизацией HID запросов можно запросто это все держать в пределах 500-1000мс. То есть мы смотрим в самом худшем случае, когда HID код пишет аспирант с зарплатой в 25к рублей, мы может собирать порядка 30 аттестаций в минуту, что дает нам возможность собрать крутую HID клик ферму!

Рецепт таков: берем пару машин с двенадцатью ядрами, как например Ryzen 3900, пару очень хороших PCI-USB плат, пару очень больших USB хабов, и собираем кластер USB ключей безопасности . Покупаем 1000 Feitian U2F, или Yubico Security Key по 15-20$ за единицу. Дальше пишем виртуальный HID адаптер который будет прикидываться USB устройством но на самом деле он будет перехватывать запросы и отправлять их на кластер, а ответ будет приходить от любого свободного ключа. Виртуальный HID адаптер ставится на виртуальные машины на которых открыты браузеры и скрипты автоматизации. Пара 5$ ардуинок чтобы имитировать нажатие и мы таким методом можем генерировать 30,000 - 40,000 аттестаций в минуту, что соразмерно с большой бот конторой в Индии, при несчастных 25,000$ затрат.

И чтобы вы не думали что я тут просто чешу языком:

• Виртуальное HID устройство на линуксе - https://github.com/djpnewton/vmulti

• HID на Python - https://pypi.org/project/hid/

В конце концов если вам лень то можно всегда купить кучку ACS122U NFC считывателей и кучку NFC ключей и тогда даже без ардуинки можно с помощью волшебными командами: SCARD_UNPOWER_CARD/SCARD_POWER_CARD перезагрузить NFC устройство для получения аттестации. Быстро и надежно в малом масштабе.

Четвертое и самое важное: Аттестация плохая замена CAPTCHA

Аттестация это очень специфичный механизм который который имеет слишком много проблем в большинстве случаев. Причины почему Cloudflare не стоит использовать аттестацию вместо капчи таковы:

• 1. Аттестация ничего не предоставляет кроме информации о модели устройства - Аттестация это не серебряная пуля, кровь единорога или философский камень. Аттестация не предоставляет доказательство присутствия пользователя, потому что Cloudflare просто проверяет есть ли у вас FIDO сертифицированное устройство. FIDO протоколы отличные стандарты, которые решают проблемы фишинга. Это возможно потому что вы сами добавляете свой ключ в свой аккаунт, и за счет этого, любая атака становится направленной, личной, что напрочь убивает ботов. Cloudflare же просто проверяет или у вас есть сертифицированное устройство. И все.

• 2. У аттестации есть проблемы с приватность - У каждого ключа безопасности есть партийный билет сертификат и партийный приватный ключ. Эта пара генерируется каждые сто-тысяч устройств. Это дает возможность раскрывать модель устройства и одновременно не создавая уникальный идентификатор с помощью которого за вами можно следить. Пример: вы регистрируетесь на сайте под другим именем, и сайт запрашивает аттестацию вашего устройство. Для сайта вероятность того что вы Вася Пупкин также являетесь Никитой Петровым является 1/100,000. Это дает некую надежду на приватность, но когда мы обсуждаем сценарий Cloudflare, который на данный момент покрывает более трети интернета, 1/100,000 это еще один ваш уникальный признак который очень полезен для слежки за вами. Cloudflare говорит что они не будут использовать аттестацию для слежки, но мы все знаем что большие компании думают о вашей приватности когда на них начинают давить инвесторы.

• 3. Пользовательский опыт у аттестации хромает - Я думаю мы все устали от постоянных всплывающих окон, и тот факт что вам каждый раз подтверждать то что вы хотите дать свое согласие на предоставление информации о своем устройстве не сильно улучшает пользовательский опыт по отношению к капче.

• 4. Аттестацией в целом тяжело управлять - Вопрос на засыпку: как достать все корневые сертификаты сертифицированных устройств? Можно воспользоваться БД FIDO, aka Metadata Service - MDS, но на данный момент она не достаточно активно используется компаниями, хотя FIDO начинает это активно решать. Соответственно Cloudflare нужно писать всем и всям компаниям чтобы получить от них корневые сертификаты, долго ждать ответов, иногда еще и общаться с юр-отделом. Либо же забить, и разрешить только пару тройку популярных компаний. Так как мы все знаем что Cloudflare не будет делать все правильно, мы будем дальше наблюдать монополизацию решений FIDO в руках одной двух компаний.

В заключении

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

Я не пишу эту статью чтобы просто облить грязью Cloudflare. Cloudflare в целом крутые ребята и я сам читаю их блоги, и использую их решения для себя и для своих клиентов. Я действительно думаю что они пытались сделать что-то хорошее, но как бывает у многих компаний, они не достаточно задумались о том действительно ли оно решает их проблему, и были слишком "застенчивы" чтобы спросить кого-то из экспертов FIDO о последствиях такого решения. Давайте не будет использовать микроскопы для забивания гвоздей, и оставим Капчу делать то для чего она была создана: делать тупые нейросети умнее, пока Скайнет нас всех не уничтожит.

И не забываем самое важное: FIDO это аутентификационые протоколы. Давай помнить об этом прежде чем их куда-то зачем-то пихать.

Q&A

- Почему нельзя просто использовать виртуальные/программные/самодельные аутентификаторы?

Потому что Cloudflare только поддерживает сертифицированные устройства, чья аттестация строго контролируется производителем. Самопал и программные аутентификаторы просто не пройдут.

Привет! Меня зовут Дима, я техлид SysOps-команды в Wrike. В этой статье я расскажу, как за 10 минут и 5 долларов в месяц сделать максимально близкий к пользователю сайт и автоматизировать его деплой. Статья почти не имеет отношения к тем проблемам, которые мы решаем внутри нашей команды. Это, скорее, мой личный опыт и впечатления от знакомства с новой для меня технологией. Я постарался описать шаги максимально подробно, чтобы инструкция оказалась полезной для людей с разным опытом. Надеюсь, вам понравится. Поехали!

Итак, возможно, вы уже нашли для себя простой и дешевый способ хостинга сайта. Может быть, даже бесплатный, как описано в этой прекрасной статье.

Но вдруг вам все равно скучно и хочется прикоснуться к дивному новому миру технологий? Скажем, вы думаете об автоматизации развертывания и хотели бы по максимуму ускорить сайт? В этой статье мы будем использовать Hugo, но это не обязательно.

Для автоматизации мы используем Gitlab CI/CD, но что делать с ускорением? Давайте развернем сайт напрямую в Cloudflare с помощью Worker Sites.

Что требуется для старта:

• Gitlab (ваш собственный или облачный)

• Аккаунт на Cloudflare

• Установленный nodejs/npm

Часть 1: Установка Hugo

Если у вас уже установлен Hugo или если вы предпочитаете другой генератор статических сайтов (или вообще не пользуетесь ими), то эту часть можно пропустить.

1. Скачиваем Hugo с https://github.com/gohugoio/hugo/releases

2. Помещаем исполняемый файл Hugo по одному из определенных в PATH путей

3. Создаем новый сайт: hugo new site blog.example.com

4. Меняем текущую директорию на только что созданную: cd blog.example.com

5. Выбираем тему оформления (https://github.com/budparr/gohugo-theme-ananke/releases или что угодно)

6. Создаем первый пост: hugo new posts/my-amazing-post.md

7. Добавляем контент в созданный файл: content/posts/my-amazing-post.md.
   Когда все сделано, меняем значение draft на false

8. Генерируем статические файлы: hugo -D

Теперь наш статический сайт находится внутри директории ./public и готов к первому ручному развертыванию.

Часть 2: Настраиваем Cloudflare

Теперь разберемся с первоначальной настройкой Cloudflare. Предположим, что домен для сайта у нас уже есть. В качестве примера возьмем blog.example.com.

Шаг 1: Создаем запись DNS

Сначала выбираем наш домен, а затем пункт меню DNS. Создаем A-запись blog и указываем для нее какой-нибудь фиктивный IP (это официальная рекомендация, но они могли бы сделать как-то посимпатичней).

Шаг 2: Токен Cloudflare

1. My Profile -> API tokens tab-> Create Token -> Create Custom Token

Здесь вам нужно будет ограничить токен учетными записями и зонами, но оставить возможность Edit для перечисленных на картинке разрешений.

Сохраните токен на будущее, он понадобится нам в третьей части.

Шаг 3: Получаем accountid и zoneid

Domain -> Overview -> [правая боковая панель]

Сохраните их рядом с токеном, они тоже понадобятся нам в третьей части.

Шаг 4: Активация Workers

Domain-> Workers -> Manage Workers

Выбираем уникальное имя и тариф Workers - > Unlimited ($5 в месяц на сегодняшний день). При желании позже вы сможете перейти на бесплатную версию.

Часть 3: Первый деплой (ручное развертывание)

Я сделал первое развертывание вручную, чтобы выяснить, что же там происходит на самом деле. Хотя всё это можно сделать и проще:

1. Устанавливаем wrangler: npm i @cloudflare/wrangler -g

2. Переходим в директорию нашего блога: cd blog.example.com

3. Запускаем wrangler: wrangler init site hugo-worker

4. Создаем конфиг для wrangler (введите токен, когда его спросят): wrangler config

Теперь попробуем внести изменения в только что созданный файл wrangler.toml (здесь полный список возможных настроек):

1. Указываем accountid и zoneid

2. Меняем route на что-нибудь вроде *blog.example.com/*

3. Указываем false для workersdev

4. Меняем bucket на ./public (или где находится ваш статический сайт)

5. Если у вас больше одного домена в пути, то вам следует исправить путь в рабочем скрипте: workers-site/index.js (см. функцию handleEvent)

Отлично, пора развертывать сайт с помощью команды wrangler publish.

Часть 4: Автоматизация деплоя

Эта инструкция составлена для Gitlab, но она передает суть и простоту автоматизированного развертывания в целом.

Шаг 1: Создаем и настраиваем наш проект

1. Создаем новый проект GitLab и загружаем сайт: директория blog.example.com со всем содержимым должна находиться в корневом каталоге проекта

2. Задаем переменную CFAPITOKEN здесь: Settings -> CI/CD -> Variables

Шаг 2: Создаем файл .gitlab-ci.yml и запускаем первое развертывание

Создаем файл .gitlab-ci.yml в корне со следующим содержимым:

stages:  - build  - deploybuild:  image: monachus/hugo  stage: build  variables:    GIT_SUBMODULE_STRATEGY: recursive  script:    - cd blog.example.com/    - hugo  artifacts:    paths:      - blog.example.com/public  only:    - master # this job will affect only the 'master' branch  tags:    - gitlab-org-docker #deploy:  image: timbru31/ruby-node:2.3  stage: deploy  script:    - wget https://github.com/cloudflare/wrangler/releases/download/v1.8.4/wrangler-v1.8.4-x86_64-unknown-linux-musl.tar.gz    - tar xvzf wrangler-v1.8.4-x86_64-unknown-linux-musl.tar.gz    - cd blog.example.com/    - ../dist/wrangler publish  artifacts:    paths:      - blog.example.com/public  only:    - master # this job will affect only the 'master' branch  tags:    - gitlab-org-docker #

Запускаем первое развертывание вручную (CI / CD -> Pipelines -> Run Pipeline) или отправляя commit в ветку master. Вуаля!

Заключение

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

Cloudflare WorkersHugoGitLab Ci