Протокол TLS. Введение

TLS – Transport Layer Security – протокол защиты транспортного уровня.

Назначение – обеспечить безопасную передачу данных в небезопасной сети. (в которой злоумышленники могут перехватить данные)

НТТРS, SMTPS, POP35, IMAPS

Место TLS в TCP/IP и в OSI:

Аспекты безопасной передачи данных:

1. Приватность. Метод защиты – шифрование

2. Целостность. Инструмент защиты – хэш-функции

3. Аутентификация инструмент защиты: ЭЦП, РКI (инфраструктура открытых ключей)

Шифрование

В современной версии TLS используется алгоритм обмена ключами. Диффи – Хеллмана.

Перед началом обмена К и С договоренность о двух числах. Числа передаются открыто. Затем К и С генерирует два случайных числа, которые нельзя передавать по открытым каналам.

(ключ) – разделяемый ключ, используемый К и С для симметричного шифрования.

* Условия работы алгоритма:

p – большое простое число (min 1024 бита)

q – первообразный корень по модулю р (небольшое целое число).

Невозможно вычислить ключ даже на современных cуперкомпьютерах.

Совершенная прямая секретность – невозможно расшифровать данные, даже если есть доступ к серверу.

Целостность.

Хэш-функция

– преобразование массива данных в строку фиксированной длины–хэш;

– по хэшу нельзя опр., на основе каких данных он был создан;

– Коллизия – одно и то же значение хэша для разных входных данных.

Криптографические хэш-функции: МD 5, SНА-1, SНА-224; SНА 256 SHA-384, SНА-512

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

Ограничение MAC

– нет возможности подтвердить подлинность сервера. При атаке «Man in the middle» на этапе обмена ключами (по алгоритму Диффи-Хеллмана) злоумышленник может перехватить процесс обмена и выслать клиенту свой ключ.

Метод защиты – PKI и ЭЦП.

Аутентификация. Инфраструктура открытых ключей.

ЭЦП использует асимметричное шифрование:

– сообщение шифруется закрытым ключом;

– расшифровка происходит с помощью открытого ключа.

Принцип подписывания сообщений:

Кому принадлежит открытый ключ?

В случае перехвата запроса на подключение «Man in the middle» злоумышленник может отправить свой открытый ключ и высылать сообщения, подписанные своим закрытым ключом.

=> Использование одной ЭЦП недостаточно. Нужна РКI

Механизм доверия:

– клиент и сервер не доверяют друг другу, а доверяют клиент удостоверяющему центру

– удостоверяющий центр выдает узлам сети сертификаты(файл специального вида в котором содержится открытый ключ, направление сервера)

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

– если клиент доверяет УЦ, то у него есть открытый ключ УЦ, которым он может расшифровать подписанное сообщение.

Google Chrome: (замок) –> Безопасное подключение –> Действительный сертификат

Инфраструктура:

Цепочка доверия:

1. Компьютер обращается за сертификатом в УЦ

2. УЦ выдаёт сертификатсо своей подписью

3. Сертификат УЦ подписывается корневой УЦ

Чтобы проверить подлинность сертификата, клиенту нужно пройти по всей цепочке.

Как узнать, что сертификат корневого УЦ принадлежит действительно ему самому?

Решение:

в ОС создаются хранилища сертификатов. Сертификаты корневых УЦ записывают в хранилище.

Chrome: Настройки –> Конфиденциальность и безопасность –> Безопасность –> Настроить сертификат.

Самоподписанные сертификаты:

1. Сертификат создает сервер и подписывает его своим закрытым ключом (Тез УЦ)

2. Все сертификаты корневых УЦ

Браузер выдает предупреждение о самоподписанном сертификате:

– если не доверяете, то не переходите.

– если доверяете, то можно добавить в хранилище.