Комментарии 17
НЛО прилетело и опубликовало эту надпись здесь
Ответ на ваш вопрос: Github Gist
Такой задачи не было, поэтому не занимался данным вопросом
Я тоже планирую реализовать подобную аутентификацию.
Хочу заметить, что метод автора для генерации *.p12 файла включает в результирующий файл самоподписанный CA сертификат. По хорошему, клиентам нет необходимости устанавливать (а иногда и нет возможности) «левый» CA в систему, который для нужд аутентификации не требуется.
Чтобы сгенерировать файл для передачи клиенту не содержащий информацию о родительском самоподписанном сертификате, нужно выполнить следующую команду:
В результате получаем файлик, который клиент/пользователь может установить сам. Для винды достаточно дважды кликнуть и далее-далее-далее-готово.
UPD:
Так же хочу дополнить что данная команда выдаст хоть и зашифрованный .p12 файл, но этот файл будет зашифрован слабыми алгоритмами вроде 40-битного RC2 и 3DES(для приватного ключа). Такой файл нельзя передавать по открытым каналам.
Я не являюсь спецом в ИБ, но как мне кажется, лучше явно указать чтобы приватный ключ был зашифрован другим алгоритмом, например, AES256. Сделать это можно с помощью параметра командной строки -aes256
Хочу заметить, что метод автора для генерации *.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. Но винда данные файлы поддерживать не будет, увы :(
НЛО прилетело и опубликовало эту надпись здесь
Я так понимаю на location авторизацию повесить нельзя?
Создание клиентского закрытого ключа и запроса на сертификат (CSR):
Почему из мануала в мануал тянется генерация закрытого ключа клиента? Этот ключ должен быть только у клиента и никого более.
Смотря какова цель данного действия. Выше в комментариях автор пишет, что сертификаты используются лишь для предварительной авторизации. То есть, чтобы back end сервер не сканировали все боты мира, его закрыли за прокси-сервером с пре-авторизацией.
Создание ключа на клиентском компьютере даёт следующие выгоды:
Пункт №2 автору не нужен.
Вместо пункта №1 можно обезопасить канал передачи ключа. Во многих случаях это достаточно просто: можно передать ключ непосредственно пользователю при визите в офис. Есть ещё вариант с пересылкой запароленного ключа по e-mail, а (сложный) пароль передать, например, по телефону. Конечно, есть теоретическая вероятность перехвата обоих каналов, но что получит атакующий — возможность просканировать back end сервер?
Всегда полезно делать анализ угроз и понимать, как и для чего мы собираемся использовать некий инструмент, и что нам грозит в случае взлома. Выдать пользователю инструкцию по генерации ключа и отсылке вам запроса не всегда возможно — слишком сложные действия на которые у пользователя может не быть прав. Установить готовый ключ — несколько кликов.
Создание ключа на клиентском компьютере даёт следующие выгоды:
- Нет необходимости передавать ключ по безопасному каналу
- Есть возможность аутентификации пользователя по сертификату
Пункт №2 автору не нужен.
Вместо пункта №1 можно обезопасить канал передачи ключа. Во многих случаях это достаточно просто: можно передать ключ непосредственно пользователю при визите в офис. Есть ещё вариант с пересылкой запароленного ключа по e-mail, а (сложный) пароль передать, например, по телефону. Конечно, есть теоретическая вероятность перехвата обоих каналов, но что получит атакующий — возможность просканировать back end сервер?
Всегда полезно делать анализ угроз и понимать, как и для чего мы собираемся использовать некий инструмент, и что нам грозит в случае взлома. Выдать пользователю инструкцию по генерации ключа и отсылке вам запроса не всегда возможно — слишком сложные действия на которые у пользователя может не быть прав. Установить готовый ключ — несколько кликов.
появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.),
Если у клиента такая политика безопасности, то маловероятно, что им подойдет вариант, когда их ключ у кого-то еще есть.
Мне самому в свое время пришлось разбираться с похожей схемой с авторизацией по ключам. И junior-админу предыдущими админами просто была вручена инструкция «генеришь ключ, отдаешь клиенту». И тут вдруг банк сказал «ключ генерим мы сами», и у этого junior'а внезапно все встало.
Ну и еще если вдруг что-то сломается, клиент всегда может сказать «ну и что что моя запись в логах, ключ-то у вас, вы сами все и сломали».
Выдать пользователю инструкцию по генерации ключа и отсылке вам запроса не всегда возможно — слишком сложные действия на которые у пользователя может не быть прав.Если нет прав, значит у пользователя есть админы. Раз есть админы, значит они должны знать, что у пользователя есть какая-то кастомная схема с авторизацией по ключам. Потому что когда у пользователя что-то сломается, он пойдет к своим админам в первую очередь, а тем придется ковыряться по всей цепочке.
Вы предполагаете, что у автора статьи ничего не работает, и он всё выдумал? Таких «их ключей» от вашего самоподписанного центра вы и без ведома клиента можете сгенерировать миллионы. Если клиенты довольны и угрозы безопасности нет, то в чём дело?
Ещё раз: аутентификация по ключу не производится, только пре-авторизация. Задача обеспечить plausible deniability по ключу у автора статьи не стоит. Если нужна p.d. — автоматическая смена пароля при первом заходе снимет вопрос (насколько вообще можно снять этот вопрос в условиях наличия контроля над серверной инфраструктурой).
Типовая ситуация в крупных компаниях: у пользователя нет и не может быть прав администратора. Скорее всего, скрипт, присланный по e-mail, запустить тоже не удастся. То есть ни mmc.exe не запустить, ни с certreq автоматически никаких манипуляций не сделать. А дабл-клик на .pfx никаких прав не требует и обрабатывается rundll32.exe, которая даже при наличии белого списка, скорее всего, в нём будет.
В компании из 100 человек можно «пойти к админам». В крупном банке на любые операции с правами администратора будете год получать разрешение от всех отделов безопасности по цепочке.
Ещё раз: аутентификация по ключу не производится, только пре-авторизация. Задача обеспечить plausible deniability по ключу у автора статьи не стоит. Если нужна p.d. — автоматическая смена пароля при первом заходе снимет вопрос (насколько вообще можно снять этот вопрос в условиях наличия контроля над серверной инфраструктурой).
Типовая ситуация в крупных компаниях: у пользователя нет и не может быть прав администратора. Скорее всего, скрипт, присланный по e-mail, запустить тоже не удастся. То есть ни mmc.exe не запустить, ни с certreq автоматически никаких манипуляций не сделать. А дабл-клик на .pfx никаких прав не требует и обрабатывается rundll32.exe, которая даже при наличии белого списка, скорее всего, в нём будет.
В компании из 100 человек можно «пойти к админам». В крупном банке на любые операции с правами администратора будете год получать разрешение от всех отделов безопасности по цепочке.
Я добавлю один момент, почему ключи делаем сами. У большинства клиентов, которым выдаем ключи, договор без пролонгации, а порой и вообще сроком на 2-3 мес. Менеджеры часто забивают забывают об этом, но когда доступ у клиента резко обрывается им напоминают)) При запросе ключа, обязательно запрашиваем на какой срок необходим сертификат.
Если клиенты довольны и угрозы безопасности нет, то в чём дело?Клиент не понимает, что он делает/получает, поэтому он и доволен.
В крупном банке на любые операции с правами администратора будете год получать разрешение от всех отделов безопасности по цепочке.А если не пошли и не получили разрешения, то получать по шапке позже, когда все эти отделы выяснят, что что-то тут сделано без их разрешения.
Да и не нужны админские права для генерации ключа в большинстве случаев.
Еще раз — есть корректный способ (генерация ключа у клиента); есть не очень корректный (генерим сами). Тот, кто будет читать эту статью должен сам решать, как же ему делать. И это стоило отобразить в статье
Можно ссылку на авторитетный источник, где один из двух способов обозначен как единственно «корректный», а другой, как, соответственно «некорректный»?
Я вам пояснил, почему нет разницы с точки зрения безопасности в заданных условиях между этими двумя способами. Вы вчистую проигнорировали всё обсуждение по сути, настаиваете на надуманной «корректности» одного из них.
Если вы знаете способ, как без прав администратора, запуска присланных по e-mail скриптов, сторонних программ и набирания команд в консоли сгенерировать запрос к стороннему удостоверяющему центру, стоит написать об этом статью на Хабр, многим будет полезно.
Я вам пояснил, почему нет разницы с точки зрения безопасности в заданных условиях между этими двумя способами. Вы вчистую проигнорировали всё обсуждение по сути, настаиваете на надуманной «корректности» одного из них.
Да и не нужны админские права для генерации ключа в большинстве случаев.
Если вы знаете способ, как без прав администратора, запуска присланных по e-mail скриптов, сторонних программ и набирания команд в консоли сгенерировать запрос к стороннему удостоверяющему центру, стоит написать об этом статью на Хабр, многим будет полезно.
Спасибо, что затронули эту тему. Конечно, до двухфакторной аутентификации такой схеме ещё далеко, но, насколько я сталкивался, многие вообще не в курсе возможности всем браузерам прозрачно и просто аутентифицироваться/авторизоваться по сертификату.
И что вы предлагаете клиентам делать с вашим корневым сертификатом — ставить его в Trusted Root, чтоб вы могли подменять собой любые сайты?
Как раз потому и есть смысл использования серверного сертификата от доверенного центра (Let's Encrypt в данном случае), чтобы не надо было отсылать пользователю ca.crt, а тому его ставить в систему. Для того, чтобы использовать клиентский сертификат, доверять центру, его выдавшему, не обязательно.
Отдельно хочу порекомендовать добавить в конфигурацию настройки Extended Key Usage — нет необходимости раздавать всем сертификаты, доступные для любых типов использования (например, подпись кода). Вкупе с установкой ca.crt в Trusted Root это может потенциально создать проблемы. Подробнее можно поискать по:
Для того чтобы клиент смог подключиться по сертификату ему необходимо отправить файл 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 файл без встроенного корневого сертификата.
Меня тоже смутило что необходимо добавлять «левый» CA сертификат в систему. Поэтому я нашел и описал в соседнем комменте способ как создать клиентский *.p12 файл без встроенного корневого сертификата.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Авторизация с помощью сертификата ssl на nginx + Let's Encrypt