Когда дело доходит до аутентификации в Интернете, мы почти все знакомы с паролем — царь холма, печально известный как своими недостатками, а также его повсеместность. Вне пароля часто вы сталкиваются со схемами аутентификации, такими как совместное использование токенов (например, токены OAuth или RSA).

Еще один метод, который вы будете очень редко видеть, это низкая форма сертификата клиента проверки подлинности. Клиентские сертификаты связаны с гораздо более популярными серверным сертификатами и существуют в том же рукопожатии TLS. Другими словами, то же начальное соединение из веб-браузера, которое запрашивает у сервера сертификат SSL, также включает в себя сервер, спрашивая браузер, если он имеет сертификат SSL. Принятие первого было значительным в течение последнего десятилетия из-за его использования в HTTPS. Сертификаты клиентов полезны только для проверки подлинности, поэтому в сравнении их принятие было более ограниченным, чем серверные сертификаты.

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

Положить все это вместе

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

На рисунке выше вы можете видеть, что Firefox Сертификат менеджер имеет возможность хранить личные сертификаты. При использовании проверки подлинности клиента браузер пользователя будет иметь сертификат от доверенного Органа Сертификата. На фото, вы можете видеть, что у меня есть два, один из Comodo для моей электронной почты, и один самопиар сертификат для auth. Мы получим в самостоятельной подписью немного позже, но это не представляет такой же риск, как самостоятельно подписанные сертификаты сервера.

Предполагая, что у вас есть клиентский сертификат в вашем браузере (вы еще не сделали, но не волнуйтесь, мы будем круг обратно к этому), ваш браузер будет автоматически отправить его на сервер при выполнении же рукопожатие TLS используется для переговоров HTTPS. Это при условии, что сервер на самом деле запрашивает клиентский сертификат.

Выше конфигурация Nginx является выдержкой из конфигурации этого сайта. Линии 2-11 и 17 в значительной степени ваши основные конфигурации HTTPS. Я включаю те для полноты, так как отрицание HTTPS является необходимым условием для проверки подлинности сертификата клиента для работы; но, я искренне надеюсь, что вы уже делаете это.

Линии 13, 14 и 15 являются настоящим мясом и картофелем конфигурации сервера;

ssl_verify_client — это установлено к обязательному, намереваясь что мы просим браузер для сертификата клиента если он имеет одно, и проверяем его если поставлено, то но Nginx не потерпит неудачу рукопожатие TLS если браузер не обеспечивает одно.

ssl_client_certificate — эта конфигурация сообщает Nginx, кому сертификатные органы доверять. Многое, как веб-браузеры поддерживать список надежных CAs, это позволяет вашему серверу иметь аналогичный список. Nginx перечислит эти CAs по имени во время рукопожатия.

ssl_verify_depth — наконец, эта настройка позволяет Nginx знать, сколько промежуточных сертификатов, чтобы позволить. Сертификаты клиентов редко под подписывались непосредственно корневой сертификатом Сертификата Авторита; таким образом, установка этого до 2 вмещает 1 промежуточный подписавший в дополнение к корневой сертификат, который является довольно типичным.

Вышеуказанные три элемента конфигурации являются все, что требуется для включения клиентских сертификатов в Nginx. Есть два оставшихся рассмотрения; как мы генерируем эти сертификаты и как навязать значимую форму проверки подлинности? Давайте сначала обсудим последнее.

Проверка подлинности пользователей

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

Nginx предоставляет две переменные, которые полезны для утверждения аутентификации — ssl_client_verify and ssl_client_raw_cert.

Переменная ssl_client_verify в своей основной форме равна SUCCESS, когда был представлен клиентский сертификат, и соответствует доверенному списку CAs сервера (как набор с ssl_client_certificate). Вы можете сослаться на документацию Nginx для других значений, которые она содержит, но в большинстве случаев достаточно просто проверить равенство или неравенство на SUCCESS. Например;

Выше выдержки взяты из nginx конфигурации этого сайта. В этом примере вы можете увидеть, ssl_client_verify по сравнению с SUCCESS для тех, кто пытается получить доступ к странице входа WordPress этого сайта. Предоставление действительного сертификата клиента будет передавать запрос WordPress для регулярной проверки подлинности на основе пароля — так что никаких отклонений от стандартной установки там. Однако, для тех браузеров без действительного сертификата клиента, их соединение немедленно будет прекращено с ошибкой 404 — Доступ отказано.

В этом случае проверка подлинности сертификата клиента обеспечивает только дополнительный уровень безопасности. Очень нужен один, учитывая безудержное число автоматизированных попыток взлома осуществляется против WordPress сайтов. Эта мера безопасности также предполагает, что простой проверки сертификата достаточно, чтобы отфильтровать рифф-рафф. Это работает, потому что Nginx настроен только доверять сет-лист сертификат органов (см. ssl_client_certificate обсуждения выше) — в моем случае мой собственный CA.

Для более мелкозернистого контроля, ssl_client_raw_cert переменная позволяет для проверки самого сертификата клиента. Эта переменная кодируется PEM и поэтому требует дополнительной обработки, чтобы сделать ее полезной. По этой причине лучше всего передать эту переменную серверу для проверки уровня приложения. Другими словами, мы набит эту переменную заголовком HTTP и позволим Ruby, Node.js, .NET, Java и т.д. обрабатывать форматированный сертификат PEM в слое приложения, а также разрешать или отклонять запрос.

Выше фрагмент иллюстрирует, как такая переменная может быть направлена на сервер вверх по течению. По конвенции HTTP заголовок, начиная с «X» являются обычай, и там один раз бесплатно выбирать, какое имя мы хотим, только до тех пор, как Nginx и вверх по течению приложение договориться о названии конвенции.

Выше приведен пример того, как будет выглядеть содержимое этого заголовка — сертификат, закодированный PEM.

Это полностью зависит от приложения клиента о том, как обрабатывать вещи с этого момента. Для сравнения, однако, это концептуально не так сильно отличается от обработки проверки подлинности на основе паролей. Слой приложения должен иметь логику для проверки предоставленного имени пользователя и пароля, а также для ответа соответствующим образом. Аналогичным образом, приложение, используя проверку подлинности сертификата клиента, должно иметь логику для обработки закодированного сертификата PEM, извлечения любых полей, которые оно сочтет актуальными (скорее всего, Общее имя) и ответа соответствующим образом. Приложение не нуждается в проверке сертификата, так как проверка была обработана Nginx перед переаймированием запроса.

Гадкие детали

Ключи и сертификаты — говорят эти слова большинству разработчиков, и они будут съеживаться. По праву, мало на пути пользователей без друзей — действительно продукт функции над формой. Любить их, или ненавидеть их, они необходимость в нашем современном мире. Выстояв на протяжении десятилетий криптоанализа, они являются приоритетом номер один, чтобы обеспечить цифровую помощь, не обязательно делая жизнь разработчика проще. Именно по этим причинам, что я решил охватить эту тему в последнюю минуту.

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

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

При правильном распределении, само подписали сертификаты могут быть так же безопасны, как коммерческие сертификаты — но это большой, если для сервера сертификаты. Для клиентских сертификатов риски практически утехались. Браузерам все равно, кто выдает сертификаты клиентов, так как они сохраняют как государственный, так и частный ключ. Сервер, предположительно управляемый одним и тем же человеком или организацией, которая является само подписи сертификаты могут по своей сути доверять себе — я надеюсь.

Достаточно срыва с моей стороны, давайте посмотрим, как мы генерируем эти сертификаты.

Первый шаг заключается в том, что мы должны стать Сертификат органа. Использование OpenSSL это относительно легко.

Во-первых, проверьте настройки dir в разделе ca_default в конфигурации OpenSSL — вы, как правило, найдете это в /etc/ssl. Параметр dir должен указывать на ca, делая полный путь /etc/ssl/ca — это путь, который будут использовать эти примеры. Если ваш путь не соответствует, либо обновить OpenSSL config или следующие сценарии, чтобы соответствовать друг другу.

После проверки пришло время создать наше Управление по сертификатам.

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

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

Когда сценарий создания пользователя завершится, у вас будет пароль, защитяемый PKCS, #12 отформатированный клиентский сертификат, готовый к импорту в ваш браузер. Вы сделали — идти вперед и импортировать его. Пути расположения Nginx, защищенные в более ранних разделах, теперь должны быть доступны.

В заключение

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