Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции / Лекция 13 - Практические протоколы распределения ключей IKE, TLS.ppt
Скачиваний:
0
Добавлен:
04.06.2026
Размер:
2.38 Mб
Скачать

Зачем нужны промежуточные УЦ?

1.Если скомпрометирован промtжуточный Серт., то его можно отозвать, не отзывая корневой и все промежуточные, подписанные этим корневым. Поэтому область воздействия скомпрометированног Серт. сужается.

2. Многие Серт. выпускаются автоматически, Это означает, что закрытый ключ должен находиться на сервере, что создает риски его компрометации. Лучше подвергнуть риску промежуточный УЦ а не корневой. А закрытый ключ корневого УЦ хранить в надежном месте, не подключенном к сети, и использовать не часто, только для подписания Серт. промежуточных УЦ.

3.Списки отозванных сертификатов (CRL) могут быть очень велики. Имея несколько промежуточных Серт. УЦ может разделить свой пул выпущенных сертификатов между промежуточными УЦ и публиковать меньшие по размеру CRL по одному на каждый ПУЦ Всякий, кто может получить необходимые сертификаты и построить цепочку, может проверит сертификат.

Проверка сертификатов

Проверкой сертификатов занимается браузер или другой HTTP – клиент.

Браузер получает сертификат сервера во время процедуры квитирования TLS. Сертификат корневого УЦ находится в хранилище сертификатов в браузере или в ОС. (В большинстве ОС имеются общесистемные хранилища серт-в) Эти хранилища регулярно обновляются с помощью механизмов обновления ОС или браузера. Обслуживание хранилищ выполняет производитель ОС или браузера.

Хранилища подразделяются на хранилища надежных УЦ (это хранилища хорошо известных УЦ); хранилища ненадежных УЦ (промежуточные УЦ); хранилища серт. клиентов с закрытыми ключами.

Промежуточные сертификаты для проверки браузер обычно получает от веб-сервера вместе с сертификатом сайта.

Выпуск сертификатов.

1.Заявитель (будущий владелец сертификата) генерирует открытый и закрытый ключи сертификата; 2.Заявитель генерирует запрос на подписание сертификата

(СSR),который содержит наименование субъекта, открытый ключ, запрошенные расширения и подпись CSR. (подписывается закрытым ключем сертификата). 3.Заявитель отправляет CSR в УЦ для подписания.

4. УЦ проверяет личность заявителя.

5.УЦ изготавливает сертификат на основе информации, взятой из CSRи добавляетдругую информацию (наименование издателя, срок действия, расширения) и подписывает сертификат:

6. УЦ отправляет сертификат заявителю, который становится его владельцем или держателем..

Виды проверок заявителя

. Сертификат с подтвержденным доменом Domain-Validation-DV)

достоверяет, что браузер подключился к сайту с доменным именем, указанным в сертификате, например, www.openssl.org. V – сертификат не гарантирует, что сайт представляет какую-то онкретную организацию.

езопасно только подключение, сам сайт может быть не езопасным.

чем польза?

ащищают пользователей браузера от атак с отправлением DNS и человеком посередине. С высокой вероятностью пользователь может предполагать, что пользователь действительно подключился сайту указанному в адресной строке браузера.

8 $ в год).

2. Сертификаты с расширенным подтверждением (Extended

Validation (EV)

УЦ выполняет проверки: что CSR из организации, владеющей доменом; что название организации в поле Subject запроса совпадает с истинным названием; что организация зарегистрирована в государственном реестре организаций; что адрес и телефон реальны,что человек запросивщий сертификат, действует от имени организации.EV-сертификаты только

для юридических лиц. (90 $ в год).

3.Сертификаты с подтверждением юридического лица (Organization Validation OV)

4.Сертификаты с подтверждением физического лица (Individual Validation (IV)

Занимают промежуточное положение междуDV и EV.

В этих сертификатах проверяется подлинность юридического или физического лица. Выпущенный сертификат содержим имя влвдельца в поле Subject/

Протоколы защиты на различных уровнях протокола TCP/IP

2.Управление ключами в протоколе IPSec

Основные сведения о протоколе IPSec

IKE

Базы данных: SAD, SPD

Security Association (SA) Безопасная ассоциация Контекст безопасности

SA однонаправленное логическое соединение, создаваемое для обеспечения безопасности обмена информацией.

SA задается совокупностью параметров соединения.

SA однозначно определяется тройкой:

-Security Parameter Index (SPI);

-IP Destination Address (Адрес назначения); -Типом протокола безопасности: AH или ESP.

Установление безопасных ассоциации

Начальный обмен 1. Создание IKE SA

 

Согласование параметров:

 

(протокол, алгоритм, режим),выработка

 

шифрключей для алгоритмов,

 

аутентификация сторон

Хост 2

 

Хост 1

2. Создание дочерней SA (CREATE CHILD SA)

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

IP-пакет до и после применения протокола ESP