х. Коли клієнт або сервер генерує ключ сесії, вони насправді формують два ключа, SERVER-READ-KEY (відомий також як CLIENT-WRITE-KEY) і SERVER-WRITE-KEY (відомий також як CLIENT-READ-KEY). Мастерний ключ використовується клієнтом і сервером для генерації різних ключів сесій.
Нарешті, після того як мастерний ключ визначений, сервер посилає клієнтові повідомлення SERVER-VERIFY.
Цей заключний крок аутентифікує сервер, так як тільки сервер, який має відповідний загальнодоступний ключ, може знати мастерний ключ.
Фаза 2
Друга фаза є фазою аутентифікації. Сервер вже аутентифікований клієнтом на першій фазі, з цієї причини тут здійснюється аутентифікація клієнта. При типовому сценарії, серверу необхідно отримати щось від клієнта, і він надсилає запит. Клієнт надішле позитивний відгук, якщо має необхідною інформацією, або надішле повідомлення про помилку, якщо немає. Ця специфікація протоколу не визначає семантику повідомлення ERROR, що посилається у відповідь на запит сервера (наприклад, конкретна реалізація може ігнорувати помилку, закрити з'єднання, і т.д. і, тим не менш, відповідати даній специфікації). Коли один партнер виконав аутентифікацію іншого партнера, він посилає повідомлення «finished». У разі клієнта повідомлення CLIENT-FINISHED містить зашифровану форму ідентифікатора CONNECTION-ID, яку повинен верифікувати сервер. Якщо верифікація зазнає невдачі, сервер посилає повідомлення ERROR.
Раз партнер послав повідомлення «finished» він повинен продовжити сприймати повідомлення доти, поки не отримає повідомлення finished від партнера. Як тільки обидва партнера послали і отримали повідомлення «finished», протокол діалогу SSL закінчив свою роботу. З цього моменту починає працювати прикладної протокол.
На малюнку представлений SSL діалог.
Рис. 5 - Алгоритм роботи SSL
Нижче представлено кілька варіантів обміну повідомленнями в рамках протоколу діалогу SSL. У цих прикладах представлені два учасники діалогу: клієнт (С) і сервер (S). Якщо щось поміщено у фігурні дужки, наприклад, «{щось} key», це означає, що щось зашифровано за допомогою ключа «key».
Таблиця 1 - За відсутності ідентифікатора сесії
Client-helloC S: challenge, cipher_specsserver-helloS C: connection-id, server_certificate, cipher_specsclient-master-keyC S: {master_key} server_public_keyclient-finishC S: {connection-id} client_write_keyserver-verifyS C : {challenge} server_write_keyserver-finishS C: {new_session_id} server_write_key
Тепер розглянемо практично наш діалог. Ми будемо виступати в якості клієнта з ip адресою 10.10.3.166, а Сервер як видно з малюнка має адресу 93.186.227.126.
Рис. 6 - Діалог клієнта з сервером
Перші 6 повідомлень діалогу, схожі на діалог з таблиці 1 і це значить, що у нас відсутній ідентифікатор сесії.
Праворуч вид повідомлення в шістнадцятковому вигляді. Повідомлення можна змінювати і перевозяться транзитом.
Цифрові сертифікати
Це підводить нас до обговорення цифрових сертифікатів, що грають важливу роль в SSL. Цифрові сертифікати в основному служать двом цілям:
...
