Как цифровые сертификаты обеспечивают дополнительную безопасность поверх SSL

Мое устаревшее приложение находится на https (SSL). Кроме того, я вижу, что некоторые пользователи настроены на использование цифровых сертификатов, созданных моим собственным центром сертификации с использованием OpenSSL? При этом у меня есть CAcert.pem и CAkey.pem, которые используются для создания цифровых сертификатов для пользователя, который запрашивает его (через CSR).

Насколько я понимаю, всякий раз, когда пользователь (используя цифровые сертификаты) пытается подключиться к серверу, браузер автоматически отправляет установленный цифровой сертификат на сервер (Вопрос в том, как браузер узнает, что это пользователь с цифровым доступом, и ему нужно отправить сертификат? ) и проверяет сервер (Кто отвечает за проверку информации о сертификате на стороне сервера?)

Мой последний вопрос: как цифровые сертификаты обеспечивают дополнительную безопасность по сравнению с SSL?

ОБНОВЛЕНИЕ:-

Как вы сказали, цифровые сертификаты являются неотъемлемой частью ssl, не отличающейся от него (где цифровые сертификаты отправляются с сервера клиенту, содержащие открытый ключ и информацию о ЦС, которому доверяет браузер). Теперь браузер будет отправлять данные, зашифрованные с помощью открытого ключа, которые будут расшифрованы на стороне сервера с помощью закрытого ключа. Точно так же, когда сервер отправляет ответ, он будет обратным, то есть зашифрованным с помощью открытого ключа и расшифрованным с помощью открытого ключа на стороне браузера Правильно?

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

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

Я использую веб-сервер Tomcat. Вот фрагмент в server.xml, который я добавил

Шаг 1 :-

 <Connector 
      SSLEnabled="true" 
      acceptCount="100" 
      connectionTimeout="20000" 
      executor="tomcatThreadPool" 
      keystoreFile="c/.keystore" 
      keystorePass="changeme" 
      maxKeepAliveRequests="15" 
      port="443" 
      protocol="HTTP/1.1" 
      redirectPort="443" 
      scheme="https" 
      secure="true" 
/>

Шаг 2

Ниже добавлен фрагмент в файл tomcat-users.xml.

<role rolename="certrole"/>
<user username="ignoreAndCheckInWebApp" password="nopass" roles="certrole"/>

Шаг 3 Добавлен ниже sniipet в web.xml

 <security-constraint>
    <web-resource-collection>
      <web-resource-name>Client Certificate Auth</web-resource-name>
      <url-pattern>/MyClientAuthenticator.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>certrole</role-name>
    </auth-constraint>
  </security-constraint>
  <login-config>
    <auth-method>CLIENT-CERT</auth-method>
  </login-config>

поместил файл jar, содержащий MySSlAuthentication.java, в папку lib Tomcat.

Шаг 4 Затем добавлен ниже элемент клапана в tomcat\conf\context.xml

 <Valve className="MySSlAuthentication"/>

Так что это более или менее процедура, упомянутая в http://twoguysarguing.wordpress.com/2009/11/03/mutual-authentication-with-client-cert-tomcat-6-and-httpclient/, но я не могу понять шаги (почему и когда они необходимы) и как они связаны друг с другом?

Теперь мой вопрос: -

Я не могу связать шаги 2, 3 и 4. Я хочу понять, что происходит, когда браузер пытается подключиться к MyClientAuthenticator.jsp? Насколько я понимаю, когда браузер пытается вызвать MyClientAuthenticator.jsp, сервер запрашивает сертификат клиента из браузера. Но тогда как/когда появляются шаги 2 и 4?


java ssl digital-certificate
person user3198603    schedule 03.05.2014    source источник
comment
Re ваше редактирование, пожалуйста, смотрите мое обновление.   -  person user207421    schedule 04.05.2014

Ответы (2)


arrow_upward
2
arrow_downward

Как цифровые сертификаты обеспечивают дополнительную безопасность поверх SSL?

В общем, я бы не сказал, что цифровые сертификаты обеспечивают «дополнительную» безопасность поверх SSL/TLS. Наоборот, они его неотъемлемая часть. Хотя подробности PKI и способы проверки сертификатов не являются частью спецификации TLS (RFC 5246) (для этого есть несколько дополнительных спецификаций, таких как RFC 5280 и RFC 6125), в самой спецификации четко упоминаются сертификаты и то, как их следует использовать.

Кажется, вы говорите о сертификатах клиента, но вы, вероятно, уже знаете о сертификатах сервера, которые встречаются гораздо чаще.

В обоих случаях цель сертификатов в SSL/TLS — аутентифицировать взаимодействующие стороны, чтобы каждая сторона могла быть уверена, что разговаривает с ожидаемой удаленной стороной.

У вас всегда должен быть как минимум сертификат сервера (иначе соединение будет уязвимо для MITM-атак). Это подтверждает личность сервера для клиента.

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

В этом случае дополнительная безопасность заключается в том, что клиент подвергается той же строгости аутентификации от сервера, что и сервер от клиента. В частности, поскольку закрытый ключ никогда не покидает удаленную сторону в этом процессе, это помогает предотвратить олицетворение путем кражи пароля (поскольку пароль не передается). Дополнительные сведения см. в этом вопросе на Security.SE.

Запрос сертификата клиента может быть выполнен только сервером. Если ваш сервер настроен на это, он отправит сообщение клиенту (вашему браузеру) во время рукопожатия SSL/TLS, и это сообщение обычно будет содержать список сертификатов ЦС, которым он доверяет, чтобы указать, какие клиентские сертификаты оно готово принять. (В этом конкретном случае ваш сервер, скорее всего, будет настроен на запрос клиентских сертификатов, выданных вашим ЦС.) Ваш сервер будет закодирован и настроен для этого (из вашего вопроса я не уверен, используете ли вы Контейнер Java Servlet или специальный Java-сервер).

Проверка сертификата выполняется диспетчером доверия в Java. Это часто инициализируется прозрачно, предоставляя приложению доверенное хранилище и полагаясь на поведение по умолчанию SSLContext (затем используется по умолчанию SSLSocket или SSLEngine в зависимости от того, как закодировано ваше приложение). Предполагая, что ваш сервер использует диспетчер доверия по умолчанию и настроен на хранилище доверенных сертификатов, содержащее ваш сертификат ЦС (а также настроен на запрос сертификата), он отправит имя этого ЦС в браузеры, а не подключится к нему, и он будет также используйте этот ЦС для проверки сертификата, отправленного браузером. (Некоторые приложения также могут иметь настроенный диспетчер доверия, но тогда его поведение полностью зависит от того, для чего оно было написано.)

Java предоставляет два способа запроса сертификата: «нужен» или «хочу» (см. SSLSocket.setNeedClientAuth(...)). Разница в том, что при «необходимости» соединение прекратится, если клиент не предъявил сертификат пользователя, тогда как в этом случае оно продолжится при «хочу».

После этого серверное приложение может проверить статус аутентификации пользователя, проверив одноранговый сертификат из файла SSLSession. (Он не получит никакого однорангового сертификата, если клиент не отправил его, а сервер использовал режим «требования». Это может подойти для анонимного доступа.) На этом этапе (при условии, что серверное приложение было закодировано с правильным доверием менеджер, т.е. не фиктивный), код сервера будет гарантировать, что удаленный пользователь действительно является держателем закрытого ключа, соответствующего этому сертификату. Затем отличительное имя субъекта сертификата можно использовать в качестве идентификатора удаленной стороны. (Некоторые серверы позволяют при необходимости сопоставить это с другим набором имен пользователей. Это будет зависеть от того, какой именно сервер вы используете и как он настроен.)

Как вы сказали, цифровые сертификаты являются неотъемлемой частью ssl, не отличающейся от него (где цифровые сертификаты отправляются с сервера клиенту, содержащие открытый ключ и информацию о ЦС, которому доверяет браузер). Теперь браузер будет отправлять данные, зашифрованные с помощью открытого ключа, которые будут расшифрованы на стороне сервера с помощью закрытого ключа. Точно так же, когда сервер отправляет ответ, он будет обратным, то есть зашифрованным с помощью открытого ключа и расшифрованным с помощью открытого ключа на стороне браузера. Верно?

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

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

Во-первых, ваш Connector не имеет атрибута clientAuth (поэтому его значение по умолчанию равно false). Это означает, что сертификат клиента не будет получен во время первоначального рукопожатия, а будет инициирован вторым рукопожатием, когда вы попытаетесь получить доступ к защищенному ресурсу (в соответствии с вашей security-constraint конфигурацией). Это называется повторными переговорами, и в этом нет ничего необычного.

(Я также заметил, что у него нет настроек, связанных с хранилищем доверенных сертификатов, что означает, что он использует хранилище доверенных сертификатов JRE по умолчанию, что также подразумевает, что ваш собственный сертификат ЦС должен быть явно импортирован в это хранилище доверенных сертификатов (в общем случае cacerts). Сохраните это. иметь в виду, если вы обновите свою JRE, так как вам, вероятно, придется снова импортировать этот сертификат вручную.)

Ваша конфигурация tomcat-users.xml — это то, о чем я говорил ранее (о сопоставлении DN субъектов с именами пользователей или ролями). Это, в сочетании с вашим нестандартным клапаном, является тем, что необычно в ваших настройках.

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

В более традиционном случае имена пользователей в tomcat-users.xml будут DN субъектов ваших сертификатов, и таким образом вы сопоставите их с ролями. Здесь кажется, что ваше развертывание не заботится об этом сопоставлении в этот момент, но оно предназначено для проверки этого в вашем приложении позже. Вероятно, это означает, что ваше приложение должно напрямую полагаться на HttpServletRequest.getRemoteUser() (если только оно не будет настроено фильтром позже), но должно считывать сертификат, используя атрибут "javax.servlet.request.X509Certificate" из запроса.

Это может иметь смысл, если приложение делает все это правильно. То, что я здесь говорю, на самом деле является предположением, поскольку оно полностью зависит от того, как реализован клапан Tomcat. Это, безусловно, повлияет на имя удаленного пользователя и принципалы пользователей, которые вы получите.

Что касается ваших комментариев об ActiveX и IE, аутентификация с помощью клиентского сертификата также должна нормально работать с Firefox или Chrome. На ум приходят две вещи:

  • Этот код ActiveX может просто не иметь ничего общего с клиентскими сертификатами, но может быть частью того, для чего предназначено приложение.
  • Этот код ActiveX является частью вашего собственного ЦС и позволяет вашим пользователям подавать заявки на сертификаты из своих браузеров (если у них их еще нет). Возможно, это было реализовано только для IE, хотя это можно сделать и для Firefox или других браузеров.
person Bruno    schedule 03.05.2014
comment
Спасибо. Пожалуйста, смотрите мое обновление. - person user3198603; 04.05.2014
comment
Мое приложение использует IE для клиентских сертификатов, так как оно имеет активный контроль X и не работает в IE/FF. Это то, что я прочитал в одном из документов проекта. Но я не уверен, почему клиентские сертификаты работают только в IE (может быть, он имеет активный контроль x). Но почему для клиентского сертификата требуется активный контроль x? - person user3198603; 04.05.2014

arrow_upward
1
arrow_downward

Вопрос в том, как браузер узнает, что это пользователь с цифровым доступом, и ему нужно отправить сертификат? )

Браузер отправляет его, потому что сервер запросил его, потому что сервер настроен на это.

Кто отвечает за проверку информации о сертификате на стороне сервера?

Ответственность за реализацию SSL.

Как цифровые сертификаты обеспечивают дополнительную безопасность поверх SSL?

Как часть SSL, вы имеете в виду. Они надежно идентифицируют владельца, что дает приложению возможность решить, авторизован ли этот пользователь для использования этой части приложения.

Ваше ОБНОВЛЕНИЕ:

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

Неправильный. Процессы шифрования и дешифрования не отличаются только потому, что клиент предоставил сертификат. На самом деле происходит то, что клиент и сервер согласовывают симметричный сеансовый ключ. Шифрование с открытым и закрытым ключом не используется.

1) Как браузер узнает, когда он должен отправить сертификат клиента (поскольку EJP указал, что сервер запрашивает его, но я не уверен, где он запрашивает его в приведенной выше конфигурации).

Он просит об этом из-за этого:

<auth-method>CLIENT-CERT</auth-method>

2) Кто проверяет сертификат клиента на стороне сервера? Это MySSlAuthentication?

Реализация SSL, связанная с соединителем, проверяет сертификат клиента. Вы не сказали нам, что такое MySSlAuthentication, поэтому я не могу вам сказать, что он делает.

person user207421    schedule 03.05.2014
comment
я не могу связать шаги 2, 3 и 4. Я хочу понять, что происходит, когда браузер пытается подключиться к MyClientAuthenticator.jsp? Насколько я понимаю, когда браузер пытается вызвать MyClientAuthenticator.jsp, сервер запрашивает сертификат клиента из браузера. Но тогда как/когда появляются шаги 2 и 4? - person user3198603; 04.05.2014
comment
Контейнер видит, что вы запрашиваете MyClientAuthenticator.jsp,, у которого есть security-constraint,, в котором говорится, что вы должны быть в login-role, чтобы получить к нему доступ, и он также видит, что auth-method это CLIENT-CERT, поэтому он запрашивает сертификат клиента. Затем ваш Valve творит чудеса и решает, соответствует ли представленный сертификат пользователю этой роли. Затем, если все это работает, пользователю предоставляется доступ к JSP. - person user207421; 04.05.2014
comment
Я думаю, вы имели в виду certrole вместо логина-роли. Но зачем нам две записи ‹role rolename=certrole/› ‹user username=ignoreAndCheckInWebApp password=nopass roles=certrole/› в tomcat-users.xml? - person user3198603; 04.05.2014
comment
Вы, вероятно, нет, в зависимости от того, что делает ваш Valve. - person user207421; 04.05.2014
comment
@ Спасибо, EJP. Еще один вопрос. Мое приложение использует IE для клиентских сертификатов, так как оно имеет активный контроль X и не работает в IE/FF. Это то, что я прочитал в одном из документов проекта. Но я не уверен, почему клиентские сертификаты работают только в IE (может быть, он имеет активный контроль x). Но почему для клиентского сертификата требуется активный контроль x? - person user3198603; 04.05.2014
comment
Это не требуется. Это ваше приложение. Почему ты спрашиваешь меня, как это работает? И почему вы колеблетесь между «у него есть управление ActiveX» и «может быть у него есть управление ActiveX»? - person user207421; 05.05.2014
comment
я знаю, что это мое приложение. Но я не был уверен, почему для сертификата клиента требуется активный контроль x, и сделал google, но не помог. - person user3198603; 11.05.2014