SSL ( — рівень захищених сокетів) — криптографічний протокол, який забезпечує встановлення безпечного з'єднання між клієнтом і сервером. SSL спочатку розроблений компанією Netscape Communications . Згодом на підставі протоколу SSL 3.0 був розроблений і прийнятий стандарт RFC, що отримав ім'я TLS.
Протокол забезпечує конфіденційність обміну даними між клієнтом і сервером, що використовують TCP/IP, причому для шифрування використовується асиметричний алгоритм з відкритим ключем. При шифруванні з відкритим ключем використовується два ключі, причому будь-який з них може використовуватися для шифрування повідомлення. Тим самим, якщо використовується один ключ для шифрування, то відповідно для розшифрування потрібно використовувати інший ключ. У такій ситуації можна отримувати захищені повідомлення, публікуючи відкритий ключ, і зберігаючи в таємниці секретний ключ.
Опис Протокол SSL складається з двох підпротоколів: протокол SSL запису і рукостискання. Протокол SSL запису визначає формат, який використовується для передачі даних. Протокол SSL включає рукостискання з використанням протоколу SSL запису для обміну серіями повідомлень між сервером і клієнтом, під час встановлення першого з'єднання. Для роботи SSL потрібно, щоб на сервері був SSL-сертифікат.
SSL надає канал, що має три основні властивості:
Автентифікація. Сервер завжди автентифікований, в той час як клієнт автентифікований в залежності від алгоритму. Цілісність. Обмін повідомленнями містить у собі перевірку цілісності. Конфіденційність каналу. Шифрування використовується після встановлення з'єднання і використовується для всіх наступних повідомлень.
У протоколі SSL всі дані передаються у вигляді записів-об'єктів, що складаються із заголовка і переданих даних. Передача починається із заголовка. Заголовок містить або два, або три байти коду довжини. Причому, якщо старший біт в першому байті коду дорівнює одиниці, то запис не має заповнювача і повна довжина заголовка дорівнює двом байтам, інакше запис містить заповнювач і повна довжина заголовка дорівнює трьом байтам. Код довжини запису не містить у собі число байт заголовка. Довжина запису 2-х байтового заголовка:
RecLength = (byte & 0x7F <<8) | byte ;
Тут byte і byte перший і другий отримані байти.
Довжина запису 3-х байтового заголовка:
RecLength = (byte & 0x3F <<8) | byte ;
Escape = (byte & 0x40)! = 0;
Padding = byte ;
Тут Padding визначає число байтів доданих відправником до початкового тексту, для того щоб зробити довжину запису кратною розміру блока шифру, при використанні блокового шифру. Тепер відправник «заповненого» запису додає заповнювач до наявних даних, і шифрує все це. Причому вміст заповнювача ніякої ролі не має. Через те, що обсяг переданих даних відомий, то заголовок може бути сформований з урахуванням Padding. У свою чергу одержувач запису дешифрує все поле даних і отримує повну вихідну інформацію. Потім обчислюється значення RecLength за відомим Padding, і заповнювач з поля даних видаляється. Дані запису SSL складаються з трьох компонент:
MAC_Data [Mac_Size] — (Message Authentication Code) — код аутентифікації повідомлення Padding_Data [Padding] — дані заповнювача Actual_Data [N] — реальні дані
Коли записи надсилаються відкритим текстом, очевидно, що ніякі шифри не використовуються. Тоді довжина Padding_Data і MAC_Data дорівнюють нулю. При використанні шифрування, Padding_Data залежить від розміру блоку шифру, а MAC_Data залежить від вибору шифру. Приклад обчислення MAC_Data:
MacData = Hash (Secret, Actual_Data, Padding_Data, Sequence_Number);
Значення Secret залежить від того, хто (клієнт або сервер) посилає повідомлення. Sequence_Number — лічильник, який інкрементується як сервером, так і клієнтом. Тут Sequence_Number є 32-х бітовий код, який передається хеш-функції у вигляді 4-х байт, причому першим передається старший байт. Для MD2, MD5 MAC_Size дорівнює 16 байтам (128 бітам). Для 2-х байтового заголовка максимальна довжина запису дорівнює 32767 байтам, а для 3-х байтового заголовка 16383 байти.
Історія та розвиток Протокол SSL був спочатку розроблений компанією Netscape. Версія протоколу 1.0 публічно не випускалася. Версія 2.0 була випущена в лютому 1995 року, але «містила багато недоліків з безпеки, які, в кінцевому рахунку, привели до створення версії 3.0», яка була випущена в 1996 році. Тим самим версія SSL 3.0 послужила основою для створення протоколу TLS 1.0, стандарт протоколу Internet Engineering Task Force (IETF) вперше був визначений в RFC 2246 в січні 1999 року. Visa, Master Card, American Express і багато інших організацій, що працюють з інтернет грошима, мають ліцензію на використання протоколу SSL, для комерційних цілей в мережі Інтернет.
SSL працює модульним способом. Тим самим SSL розширюваність згідно з проектом про підтримку передньої і зворотної сумісності та переговорів між сполуками в однорангової мережі.
Застосування Значне використання протоколу SSL призвело до формування протоколу HTTPS (Hypertext Transfer Protocol Secure), що підтримує шифрування. Дані, які передаються по протоколу HTTPS, «упаковуються» в криптографічний протокол SSL або TLS, тим самим забезпечуючи захист цих даних. Такий спосіб захисту широко використовується у світі Веб для додатків, в яких важлива безпека з'єднання, наприклад у платіжних системах. HTTPS підтримується всіма браузерами. На відміну від HTTP, для HTTPS за замовчуванням використовується TCP-порт 443.
Спочатку віртуальні приватні мережі (VPN) на основі SSL розроблялися як додаткова і альтернативна технологія віддаленого доступу на основі IPsec VPN. Однак, такі фактори як достатня надійність і дешевизна зробили цю технологію привабливою для організації VPN. Також SSL отримав широке застосування в електронній пошті. Основні цілі протоколу в порядку пріоритетності Криптографічна безпека: SSL встановлює безпечне з'єднання між двома сторонами. Відкритість: Програмісти, незалежно один від одного, можуть створювати додатки, що використовують SSL, які згодом будуть здатні успішно обмінюватися криптографічними параметрами без всякого знання коду чужих програм. Розширюваність: SSL прагне забезпечити робочий простір, в якому нові відкриті ключі і трудомісткі методи шифрування можуть бути додані при необхідності. Відносна ефективність: робота протоколу на основі SSL вимагає великих швидкостей від CPU, зокрема для роботи з відкритими ключами. Тому до SSL протоколу була включена необов'язкова схема кешування сесій для зменшення кількості з’єднань, які необхідно встановлювати з нуля. Крім того, велика увага приділяється тому, щоб зменшити мережеву активність.
Типи SSL-сертифікатів SSL-сертифікати розрізняють за центром сертифікації, типом захисту та рівнем перевірки.
За типом захисту SSL-сертифікати поділяють на:
Сертифікати із захистом доменів (звичайні сертифікати). Використовуються для шифрування інформації одного домену без піддоменів. Сертифікати із захистом піддоменів (Wildcard-сертифікати). Використовуються для шифрування інформації всіх піддоменів одного домену. Сертифікати із захистом кількох доменів (SAN-сертифікати). Використовуються для шифрування інформації одразу кількох доменів без піддоменів. Сертифікати програмного коду (Code Signing). Використовуються для підпису програмного забезпечення. Сертифікати з підтримкою IDN. Використовуються для шифрування інформації кириличних або інших доменів, які містять літери нелатинських алфавітів. Сертифікати із захистом електронної пошти та документів. Використовуються для автентифікації відправника та запобігають змінам у документах з боку правопорушників (спам, фішинг, підроблені рахунки).
SSL-сертифікати за рівнем перевірки власника поділяються на:
DV-сертифікати (domain validation) – перевірка за доменом. Підтверджують факт володіння доменом. Використовуються для блогів, лендінгів, сайтів-візиток та портфоліо. OV-сертифікати (organization validation) – перевірка організації. Підтверджують власника домену та компанію, яка за ним стоїть. Перевірка організації зазвичай використовується для бізнес-сайтів, які приймають платежі. EV-сертифікати (extended validation) – розширена перевірка організації. Крім перевірки домену та організації, перевіряється, чи має компанія право на володіння своєю назвою. Використовуються для фінансових, урядових, банківських, страхових та ecommerce-сайтів.
SSL-сертифікати різних типів захисту та рівнів перевірки можна отримати в центрах сертифікації, зокрема Certum, Comodo (після ребрендингу Sectigo), RapidSSL, GeoTrust і Thawte.
Автентифікація і обмін ключами SSL підтримує 3 типи аутентифікації: Автентифікація обох сторін (клієнт — сервер), Автентифікація сервера з нерозпізнаних клієнтом Повна анонімність. Кожного разу, коли сервер автентифіковані, канал безпечний проти спроби перехоплення даних між вебсервером і браузером, але повністю анонімна сесія за своєю суттю вразлива до такої атаки. Анонімний сервер не може автентифікувати клієнта. Якщо сервер аутентифікований, то його повідомлення сертифікації має забезпечити вірний сертифікаційний ланцюжок, що веде до прийнятного центру сертифікації. Простіше кажучи, аутентифікований клієнт повинен надати допустимий сертифікат сервера. Кожна сторона відповідає за перевірку того, що сертифікат іншого боку ще не закінчився і не був скасований.
Головна мета процесу обміну ключами — це створення секрету клієнта (pre_master_secret), відомого тільки клієнту і серверу. Секрет (pre_master_secret) використовується для створення спільної таємниці (master_secret). Загальний секрет необхідний для того щоб створити повідомлення для перевірки сертифіката, ключів шифрування, секрету MAC (message authentication code) і повідомлення «finished». При посилці вірного повідомлення «finished», тим самим сторони доведуть що вони знають вірний секрет (pre_master_secret).
Анонімний обмін ключами Повністю анонімна сесія може бути встановлена при використанні алгоритму RSA або Діффі-Хеллмана для створення ключів обміну. У разі використання RSA клієнт шифрує секрет (pre_master_secret) за допомогою відкритого ключа несертифікованого сервера. Відкритий ключ клієнт дізнається з повідомлення обміну ключами від сервера. Результат надсилається в повідомленні обміну ключами від клієнта. Оскільки перехоплювач не знає закритого ключа сервера, то йому буде неможливо розшифрувати секрет (pre_master_secret). При використанні алгоритму Діффі-Хеллмана відкриті параметри сервера містяться в повідомленні обміну ключами від сервера, і клієнтові посилають в повідомленні обміну ключами. Перехоплювач, який не знає приватних значень, не зможе знайти секрет (pre_master_secret).
Обмін ключами при використанні RSA і автентифікація У цьому випадку обмін ключами та автентифікація сервера може бути скомбінована. Відкритий ключ також може міститися в сертифікаті сервера або може бути використаний тимчасовий ключ RSA, який посилається в повідомленні обміну ключами від сервера. Коли використовується тимчасовий ключ RSA, повідомлення обміну підписуються server's RSA або сертифікат DSS. Сигнатура включає поточне значення повідомлення Client_Hello.random, таким чином старі сигнатури і старі тимчасові ключі не можуть повторюватися. Сервер може використовувати тимчасовий ключ RSA тільки одного разу для створення сесії. Після перевірки сертифіката сервера клієнт шифрує секрет (pre_master_secret) за допомогою відкритого ключа сервера. Після успішного декодування секрету (pre_master_secret) створюється повідомлення «finished», тим самим сервер демонструє, що він знає приватний ключ відповідний сертифікату сервера.