Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

Цифровые сертификаты.

Рубрика: Безопасность -> Безопасность рабочей станции
Метки:
Пятница, 15 мая 2009 г.
Просмотров: 5506

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

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


     Цифровые сертификаты гарантируют, что и сервер, и клиент являются теми, кем они должны быть на самом деле. При использовании цифровых сертификатов сервер может быть уверен, что к нему подключился именно Иван Иванов, а не Вася Пупкин, а Иванов, в свою очередь, может быть уве­рен, что он подключился к серверу банка, а не к серверу Васи Пупкина, ко­торый расположен в соседней квартире.

     Любой пользователь может создать и подписать свой собственный сертифи­кат, но целостность так называемых «самоподписанных» сертификатов ог­раничена. Обычно надо, чтобы сертификат подписала какая-нибудь ува­жаемая и независимая третья сторона. В реальном мире все точно так же: вы можете показать чью-нибудь визитку (возможно, свою), но нет гарантии, что это именно ваша визитка. Если же вы предъявите паспорт, ситуация изме­нится: ведь паспорт подписан (выдан) третьей стороной (одним из РОВД). Правда, паспорт тоже можно подделать, но это уже совсем другая беседа.

     Большая часть современных браузеров, в т.ч. Netscape/Mozilla, содержат список организаций, которые могут подписать сертификат - Certifying Authorities (CA), то есть они имеют право выступать в роли третьей стороны.

     Если удаленная сторона предоставляет браузеру сертификат, подписанный одной из этих организаций, браузер может автоматически проверить подлинность сертификата. В Mozill'e настройки СА можно просмотреть, выполнив команду меню Edit > Preferences > Privacy and Security > Certificates.

     Без наличия цифрового сертификата HTTPS-соединение не быдет ус­тановлено, поэтому для сайта крайне важно иметь сертификат, даже самоподписанный. Когда браузер не может автоматически проверить целостность сертификата (например, если сертификат подписан самостоятельно или СА, подписавшего сертификат, нет в списке браузера), он спросит пользователя, желает ли тот продолжить соединение. Но безопасно ли принять сертификат, который не может быть аутентифицирован? Все зависит от сайта. Если вы вводите конфиденциальные данные, наверное, лучше ответить «нет» (по крайней мере, в первую очередь надо связаться с администрацией сайта и узнать, почему их сертификат не аутентифицируется). Если же сертификат нужен только для просмотра сайта, особой необходимости в нем нет и конфиденциальная информация не будет вводиться, то такой сертификат нужно принять.

     Способ сохранения информации в сертификатах определяется стандартом Х.509 (сейчас текущей представляется третья версия стандарта). Х.509 подразу­мевает следующую структуру сертификата:

  • Version (Версия) — версия Х.509-сертификата. Как уже говорилось, сейчас используется третья версия.
  • Serial number (Серийный номер) — уникальный номер сертификата, сгенерированный СА.
  • Signature Algorithm ID (ID алгоритма подписи) — метод шифрования, используемый для поля Signature (Подпись).
  • Certificate Issuer — СА, который подписал сертификат.
  • Validity Period (Срок действия) — дата, до которой сертификат считается действительным.
  • Subject's Name (Владелец) — кому принадлежит сертификат.
  • Subject's Public Key Information (PK владельца) — публичный ключ владельца сертификата.
  • Certification Authority's Signature (Подпись СА) — цифровая подпись СА, использует алгоритм, указанный в поле Signature Algorithm ID.

     Это основные поля, которые должны быть в каждом Х.509-сертификате (не все цифровые сертификаты соответствуют стандарту Х.509). В дополнение к этим полям допускаются некоторые необязательные поля, например Issuer ID, Subject ID, объяснения, как нужно использовать открытый ключ, и т.д.