Захищені протоколи. Протокол ssl.
Протокол SSL призначений для безпечного обліку інформацією. У1994р. він був вбудований в браузер Netscape Navigator для забезпечення безпечного зв’язку між клієнтами та сервером крізь відкриті канали зв’язку, такі як Інтернет. Першою комерційною версією був SSL 2.0 (версія 1.0 була тестовою і використовувалася лише у компанії Netscape).
Загальне описання протоколу SSL
Протокол реалізовано у вигляді багатошарової системи, що спеціально призначена для безпечного передавання секретної інформації відкритими каналами зв’язку. Як перший шар, у такому середовищі використовують традиційний протокол TCP. Другим шаром є SSL Record Protocol. Ці два шари формують ядро SSL. Це ядро є оболонкою для усіх протокольних інфраструктур. Наприклад, SSL Handshabe Protocol, що дозволяє серверу і клієнту аутентифікуватися, узгодити криптографічні алгоритми та ключі перед тим, як програми, що використовують SSL, почнуть передавання та приймання інформації, що захищається.
Архітектура SSL
SSL функціонує прозоро для користувача. SSL доповнює стандарт WinSock, працює на рівні сокетів, забезпечуючи безпеку інших протоколів, що використовують сокети.
У відповідності з протоколом SSL між двома точками мережі створюються захищені тунелі, як показано на pис.
SSL не може працювати на протоколі UDP оскільки він не гарантує доставку ІР-пакетів адресату. Зникнення пакетів може бути інтерпретоване як порушення секретності і зв'язок буде розірвано. Таким чином SSL не може захистити протоколи: SNMP(Simple Network Management Protocol), NFS(Network File System), DNS та інші.
Криптографічні алгоритми SSL
Протоколи, що захищаються SSL
HTTPS
SSMTP (Secure Simple Mail Transfer Protocol)
SNNTP (Secure Network News Protocol)
SSL-LDA (Lightweight Directory Access Protocol) SPOP3 (Secure POP3)
Служби безпеки SSL
SSL дозволяє розв’язувати задачі забезпечення конфіденційності та автентичності інформації. При цьому використовуються як симетричні, так і асиметричні криптоалгоритми: DES, RC4(40,128), DES(40,64), 3DES, IDEA, SKIPJACK Fortezza; RSA, Діффі-Хеллмана.
Обмін ключами: RSA, Діффі-Хеллмана, Fortezza; Цифровий підпис: RSA; DSA; DSS;
Хешування: MD5, SHA.
Аутентифікація. Аутентифікація використовує сертифікати за стандартом Х.509. Обмін сертифікатами виконується лише при встановленні зв’язку до обміну даними. Сервер може вимагати аутентифікації клієнта і розірвати зв'язок у випадку відсутності сертифіката клієнта.
Обмін ключами симетричного шифрування під час аутентифікації може виконуватися за допомогою алгоритмів RSA (ключ шифрується відкритим ключем RSA отримувача, взятим з сертифікату) або за алгоритмом Діффі-Хеллмана. У США може використовувати алгоритм обміну ключами Fortezza, що розроблені АНБ США.
У випадку RSA обмін виконується за один сеанс зв’язку, а Д.-Х. - за кілька.
Обмін за допомогою Fortezza включає обмін відкритими параметрами, які знаходяться у сертифікатах. На основі цих параметрів обчислюється ключ ТЕК (Token encryption key). Цей ТЕК використовується для шифрування як сеансовий ключ. Конфіденційність Конфіденційність повідомлень забезпечується симетричним шифруванням з використанням ключів від 40 до 128 біт.
Дані шифруються різними ключами в різних напрямках: клієнт шифрує свої дані за допомогою client write key, а сервер server write key.
Мала довжина ключа в 40 бітів для узгодження з обмеженням уряду США на експорт криптосистем.
Цілісність.
Цілісність
даних забезпечується хешуванням за
алгоритмами SHA або MD5. Для підвищення
криптостійкості згортка формується з
використанням операцій, що залежать
від секретного ключа; результат
називається кодом аутентифікації
повідомлень MAC. Ця процедура забезпечує
також аутентифікацію відправника
повідомлення, оскільки секретні дані
, що використовуються для формування
MAC, відомі лише учасникам
сеансу зв’язку.
Субпротоколи SSL
Handshake- відповідає за аутентифікацію сторін, за
встановлення параметрів та алгоритмів шифрування та хешування, також за обмін секретним ключем PreMasterSecret. Задача CCS- спостерігати за зміною параметрів під час обміну даними і сповіщати про це Record.
Протокол Alert - служба повідомлень про помилки.
Протокол Record - застосовує усі встановлені під час ініціалізації параметри безпеки для захисту даних. Крім того, він захищає повідомлення Handshake, CCS та Alert.
Обмін даних у SSL
Обмін виконується в 2 етапи:
1. на попередньому етапі виконується аутентифікація сторін, генерування та узгодження ключів.
2. при обміні даними безпека залежить від алгоритмів та параметрів, встановлених на 1-му етапі.
В будь-який момент зберігається можливість виникнення сигналу про вторгнення або помилку (протокол CCS).
Якщо клієнт приєднується до іншого сервера, то новий сеанс починається без розриву іншого. Якщо клієнт пізніше повертається до першого сервера і захоче щоби з’єднання поновилося з використанням старих параметрів, буде передано запит про відновлення старого сеансу замість ініціалізації нового. Т.ч. сеанс SSL - зв'язок між 2 об’єктами, який має певний набір параметрів та криптографічних атрибутів. Для обмеження ризику перехоплення повідомлень повторення специфікація SSL обмежує час дії ідентифікатора сеансу на протязі 24 годин, однак реальний час зв’язку визначається сервером.
Змінні стану сеансу SSL. Сеанс SSL однозначно ідентифікується таким набором змінних стану:
Session ID - випадкове число з 32 октетів для ідентифікації сеансу
Сертифікат вузла (peer certificate) - сертифікат Х.509 v.3. Значення може бути null, якщо сертифікату немає або використовується Fortezza.
Метод стискування - протокол SSL дозволяє встановити стискування інформації перед шифруванням.
Специфікація шифру (cipher spec) - визначає алгоритм шифрування та хешування
Головний ключ (PreMaster Secret) - ключ 48 байт, спільний для обох сторін. Використовується для генерування усіх інших ключів, діє увесь час сеансу.
Флаг поновлення (is resumable), що визначає можливість поновлення сеансу. Решта 5 елементів визначає набір та параметри криптоалгоритмів (Cipher Suite)
Тип шифрування - потоковий чи блочний алгоритм;
Алгоритм шифрування - алгоритм або не шифрувати обмін.
Алгоритм хешування - алгоритм хешування або без хешування.
Розмір хеш-образу.
IsExportable - двійкове значення, що визначає можливість експорту алгоритму замежі США. Змінні стану з’єднання SSL. Параметри які визначають стан з’єднання на протязі сеансу SSL. Вони можуть встановлюватися індивідуально для кожного нового з’єднання:
два випадкових числа (ID) server_random, client_random (по 32 байти). Ці числа генеруються сервером та клієнтом відповідно в момент встановлення сеансу і для кожного нового з’єднання. Ці числа використовуються для обчислення ключа шифрування і передаються у незашифрованому вигляді. При встановленні додаткового з’єднання вик. шифрування. Використання цих чисел захищає від атаки з повторним застосуванням повідомлень, перехоплених у іншому з’єднанні(атака перехоплення та повторення).
Два числа, server MaCurite Secret i client_Mac_write_secret. Вих. для обчислення коду аутентифікації.
- Секретні ключі симетричного шифрування даних (server_write_key i client_write_key). Довжина ключів залежить від алгоритму.
- Два вектори ініціалізації (initialige vector) для процедури симетричного шифрування у режимі СВС.
Порядкові номери довжиною 8 байтів. Вони формуються окремо для кожного зєднання і запобігають атаці перехоплення і повторення, оск. перешкоджає використання раніше відправлених повідомлень.
Принципи обчислення MasterSecret
Клієнт і сервер починають з вибору версії протоколу SSL, яка повинна бути однаковою. Після передачі ClientHello клієнт очікує на ServerHello. Воно визначає версію протоколу та ID сеансу, що вибрав сервер. Повід. також містить Server_random. Тоді можна сформувати ключі шифрування.
Повідомлення містить server_suite, який вибрав сервер з наданих клієнтом. Якщо нема можливості визначити спільний cipher_suite, зв’язок розривається. На другій стадії сервер відправляє клієнтові Certificate, що містить:
- сертифікат сервера х.509 v.3 з відкритим ключем або помилку, якщо сертифікату немає.
Сертифікат має такий вигляд:
Certificate=NameServer || NameCA || PKServer || PKCA {H[ NameServer || NameCA || PKServer ]}.
У випадку, коли вибрано метод обміну ключами не RSA, замість сертифікату передається повідомлення ServerKeyExсhange:
Fortezza;
Деффі-Хеллман.
Клієнт перевіряє сертифікат сервера за допомогою відкритого ключа СА
Повідомлення ServerKeyExсhange містить відкриті параметри алгоритму, що використовується для генерування ключа системи шифрування.
Сервер підписує ці параметри своїм електронним підписом. Прийнявши це повідомлення, клієнт перевіряє підпис за допомогою отриманого раніше відкритого ключа сервера і впевнюється в тому, що ключі відповідають один одному.
Після цього сервер може вимагати аутентифікації клієнта.
Обмін ключами. Якщо сервер запитує аутентифікацію клієнта, використовує
SertificateRequest, клієнт має відповісти відправкою свого сертифікату, якщо він є в повід. Certificate. Якщо нема - certificate -> розрив з’єднання. Після цього клієнт відправляє повідомлення. ClientKeyExchange, в якому є PreMasterSecret, за шифрування за доп. відпр. ключа сервера.
Якщо клієнта сертифіковано, він повинен відправити серверу підтверджуюче повідомлення CertificateVerity. Це повідомлення містить усіх попер. повід. Хеш-образу зашифровано приватним ключем клієнта. Мета цього повідомлення - дати можливість серверу перевірити підпис клієнта.
Далі для запуску процесу шифрування клієнт викликає протокол CCS з параметрами узгодженими на попередніх кроках. Таким чином протокол Record буде «знати», які параметри шифрування узгоджено. По закінченні клієнт передає серверу повідомлення Finished, яке є hash-ом усіх попередніх повідомлень клієнта.
Після отримання повідомлення Finished від клієнта, сервер хешує раніше отримані повідомлення та порівнює результат з отриманим мешем. Цей крок дозволяє зафіксувати факт перехоплення та зміни даних. Далі сервер також запускає CCS та формує своє повідомлення Finished.
Аж тепер починається передавання даних.
Атака. Man-in-Middle може перехопити та підмінити ClientHello або ServerHello на такі, які використовують слабкі алгоритми шифрування та обчислити PreMasterSecret. Частковим захистом є те, що необхідно обом сторонам дочекатись Finished у відповідь з обох сторін і лише потім починати передавання даних.
Інші субпротоколи
Протокол CCS(Change Cipher Spec). Протокол CCS складається з одного повідомлення, довжиною 1 байт. CCS дає вказівку протоколу Record, що може починатися шифрування з умовами, визначеними Handshake. До цього повідомлення шифрування є завданням Handshake. Після отримання цього повідомлення Record має змінити свої атрибути для запису (алгоритму тощо). На боці прийому Record змінює атрибути для читання, щоби бути в змозі розшифрувати отримані повідомлення.
Протокол Record. Стартує лише після повідомлення CCS. Під час встановлення зв’язку Record отримує дані від HandShake і передає їх без змін TCP. На етапі шифрування даних Record отримує дані від протоколів вищого рівня (HTTP,FTP тощо) і передає їх TCP після виконання таких дій:
1) Сегментація даних (макс.214 байта);
2) Стискування даних;
3) Формування хешу;
4) Шифрування.
Record додає заголовок у 5 байт до кожного повідомлення. Цей заголовок вказує на тип повідомлення, версію SSL та довжину блоку даних.
Протокол Alert. Формує повідомлення про помилки та сигналізує про зміну стану, н-д, про закриття зєднання. Record шифрує ці повідомлення з використанням обумовлених атрибутів шифрування.
Повідомлення можуть бути попередженнями або повідомленнями про фатальні помилки.
Повідомлення про фатальну помилку змушує одразу ж закрити з’єднання, не очікуючи підтвердження з іншого боку. Тому SSL вразливий до атак типу DOS, якщо супротивник може заміняти перехоплені повідомлення на повід. про фатальні помилки.
