Pull to refresh

Comments 17

UFO just landed and posted this here
Такой задачи не было, поэтому не занимался данным вопросом
Я тоже планирую реализовать подобную аутентификацию.
Хочу заметить, что метод автора для генерации *.p12 файла включает в результирующий файл самоподписанный CA сертификат. По хорошему, клиентам нет необходимости устанавливать (а иногда и нет возможности) «левый» CA в систему, который для нужд аутентификации не требуется.

Чтобы сгенерировать файл для передачи клиенту не содержащий информацию о родительском самоподписанном сертификате, нужно выполнить следующую команду:
openssl pkcs12 -export -in client01.crt -inkey client01.key -clcerts \
-out client01.p12 -passout pass:PASSWORD_HERE

В результате получаем файлик, который клиент/пользователь может установить сам. Для винды достаточно дважды кликнуть и далее-далее-далее-готово.

UPD:
Так же хочу дополнить что данная команда выдаст хоть и зашифрованный .p12 файл, но этот файл будет зашифрован слабыми алгоритмами вроде 40-битного RC2 и 3DES(для приватного ключа). Такой файл нельзя передавать по открытым каналам.
Я не являюсь спецом в ИБ, но как мне кажется, лучше явно указать чтобы приватный ключ был зашифрован другим алгоритмом, например, AES256. Сделать это можно с помощью параметра командной строки -aes256

UPD2: Ключ -aes256 не даст желаемого результата.
Помимо этого, в формате PKCS#12 ограниченная поддержка алгоритмов шифрования: вики.
Теоретически, через флаги -certpbe aes-256-cbc -keypbe aes-256-cbc можно заставить openssl шифровать сертификат и ключ с помощью aes. Но винда данные файлы поддерживать не будет, увы :(

UFO just landed and posted this here
Я так понимаю на location авторизацию повесить нельзя?
Да, нельзя. В документации nginx указан контекст: http, server. location нету.
Создание клиентского закрытого ключа и запроса на сертификат (CSR):

Почему из мануала в мануал тянется генерация закрытого ключа клиента? Этот ключ должен быть только у клиента и никого более.
Смотря какова цель данного действия. Выше в комментариях автор пишет, что сертификаты используются лишь для предварительной авторизации. То есть, чтобы back end сервер не сканировали все боты мира, его закрыли за прокси-сервером с пре-авторизацией.

Создание ключа на клиентском компьютере даёт следующие выгоды:
  1. Нет необходимости передавать ключ по безопасному каналу
  2. Есть возможность аутентификации пользователя по сертификату

Пункт №2 автору не нужен.
Вместо пункта №1 можно обезопасить канал передачи ключа. Во многих случаях это достаточно просто: можно передать ключ непосредственно пользователю при визите в офис. Есть ещё вариант с пересылкой запароленного ключа по e-mail, а (сложный) пароль передать, например, по телефону. Конечно, есть теоретическая вероятность перехвата обоих каналов, но что получит атакующий — возможность просканировать back end сервер?

Всегда полезно делать анализ угроз и понимать, как и для чего мы собираемся использовать некий инструмент, и что нам грозит в случае взлома. Выдать пользователю инструкцию по генерации ключа и отсылке вам запроса не всегда возможно — слишком сложные действия на которые у пользователя может не быть прав. Установить готовый ключ — несколько кликов.
появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.),

Если у клиента такая политика безопасности, то маловероятно, что им подойдет вариант, когда их ключ у кого-то еще есть.
Мне самому в свое время пришлось разбираться с похожей схемой с авторизацией по ключам. И junior-админу предыдущими админами просто была вручена инструкция «генеришь ключ, отдаешь клиенту». И тут вдруг банк сказал «ключ генерим мы сами», и у этого junior'а внезапно все встало.
Ну и еще если вдруг что-то сломается, клиент всегда может сказать «ну и что что моя запись в логах, ключ-то у вас, вы сами все и сломали».
Выдать пользователю инструкцию по генерации ключа и отсылке вам запроса не всегда возможно — слишком сложные действия на которые у пользователя может не быть прав.
Если нет прав, значит у пользователя есть админы. Раз есть админы, значит они должны знать, что у пользователя есть какая-то кастомная схема с авторизацией по ключам. Потому что когда у пользователя что-то сломается, он пойдет к своим админам в первую очередь, а тем придется ковыряться по всей цепочке.
Вы предполагаете, что у автора статьи ничего не работает, и он всё выдумал? Таких «их ключей» от вашего самоподписанного центра вы и без ведома клиента можете сгенерировать миллионы. Если клиенты довольны и угрозы безопасности нет, то в чём дело?

Ещё раз: аутентификация по ключу не производится, только пре-авторизация. Задача обеспечить plausible deniability по ключу у автора статьи не стоит. Если нужна p.d. — автоматическая смена пароля при первом заходе снимет вопрос (насколько вообще можно снять этот вопрос в условиях наличия контроля над серверной инфраструктурой).

Типовая ситуация в крупных компаниях: у пользователя нет и не может быть прав администратора. Скорее всего, скрипт, присланный по e-mail, запустить тоже не удастся. То есть ни mmc.exe не запустить, ни с certreq автоматически никаких манипуляций не сделать. А дабл-клик на .pfx никаких прав не требует и обрабатывается rundll32.exe, которая даже при наличии белого списка, скорее всего, в нём будет.

В компании из 100 человек можно «пойти к админам». В крупном банке на любые операции с правами администратора будете год получать разрешение от всех отделов безопасности по цепочке.
Я добавлю один момент, почему ключи делаем сами. У большинства клиентов, которым выдаем ключи, договор без пролонгации, а порой и вообще сроком на 2-3 мес. Менеджеры часто забивают забывают об этом, но когда доступ у клиента резко обрывается им напоминают)) При запросе ключа, обязательно запрашиваем на какой срок необходим сертификат.
Если клиенты довольны и угрозы безопасности нет, то в чём дело?
Клиент не понимает, что он делает/получает, поэтому он и доволен.
В крупном банке на любые операции с правами администратора будете год получать разрешение от всех отделов безопасности по цепочке.
А если не пошли и не получили разрешения, то получать по шапке позже, когда все эти отделы выяснят, что что-то тут сделано без их разрешения.
Да и не нужны админские права для генерации ключа в большинстве случаев.

Еще раз — есть корректный способ (генерация ключа у клиента); есть не очень корректный (генерим сами). Тот, кто будет читать эту статью должен сам решать, как же ему делать. И это стоило отобразить в статье
Можно ссылку на авторитетный источник, где один из двух способов обозначен как единственно «корректный», а другой, как, соответственно «некорректный»?

Я вам пояснил, почему нет разницы с точки зрения безопасности в заданных условиях между этими двумя способами. Вы вчистую проигнорировали всё обсуждение по сути, настаиваете на надуманной «корректности» одного из них.

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

Если вы знаете способ, как без прав администратора, запуска присланных по e-mail скриптов, сторонних программ и набирания команд в консоли сгенерировать запрос к стороннему удостоверяющему центру, стоит написать об этом статью на Хабр, многим будет полезно.
Спасибо, что затронули эту тему. Конечно, до двухфакторной аутентификации такой схеме ещё далеко, но, насколько я сталкивался, многие вообще не в курсе возможности всем браузерам прозрачно и просто аутентифицироваться/авторизоваться по сертификату.

Для того чтобы клиент смог подключиться по сертификату ему необходимо отправить файл client01.p12 и ca.crt, а так же сообщить пароль для установки сертификата. ca.crt необходим, так как мы не используем его для сертификации сервера, для этомо используеться Let's Encrypt.

И что вы предлагаете клиентам делать с вашим корневым сертификатом — ставить его в Trusted Root, чтоб вы могли подменять собой любые сайты?
Как раз потому и есть смысл использования серверного сертификата от доверенного центра (Let's Encrypt в данном случае), чтобы не надо было отсылать пользователю ca.crt, а тому его ставить в систему. Для того, чтобы использовать клиентский сертификат, доверять центру, его выдавшему, не обязательно.

Отдельно хочу порекомендовать добавить в конфигурацию настройки Extended Key Usage — нет необходимости раздавать всем сертификаты, доступные для любых типов использования (например, подпись кода). Вкупе с установкой ca.crt в Trusted Root это может потенциально создать проблемы. Подробнее можно поискать по:
extendedKeyUsage = clientAuth
Спасибо большое за полезный комментарий! Надо будет добавить Extended Key Usage в свой конфиг.

Меня тоже смутило что необходимо добавлять «левый» CA сертификат в систему. Поэтому я нашел и описал в соседнем комменте способ как создать клиентский *.p12 файл без встроенного корневого сертификата.
Sign up to leave a comment.

Articles