SSL

Модель TCP/IP (RFC 1122)
Прикладний рівень
BGP DHCP DNS FTP Gopher GTP HTTP HTTPS IMAP IRC LDAP MGCP MQTT NNTP NTP POP3 RIP RPC RTCP RTP RTSP SDP SIP SMTP SNMP SOAP SSH STUN Telnet TLS/SSL VNC XMPP докладніше
Транспортний рівень
TCP UDP DCCP SCTP RSVP ECN докладніше
Мережевий рівень
IP IPv4 IPv6 ICMP ICMPv6 IGMP IPsec докладніше
Канальний рівень
ARP RARP NDP MPLS OSPF Tunnels (L2TP) MAC-адреса Ethernet DSL ISDN FDDI Драйвер докладніше
Цей шаблон: переглянути обговорити редагувати

SSL (англ. Secure Sockets Layer — рівень захищених сокетів) — криптографічний протокол, який забезпечує встановлення безпечного з'єднання між клієнтом і сервером. SSL спочатку розроблений компанією Netscape Communications . Згодом на підставі протоколу SSL 3.0 був розроблений і прийнятий стандарт RFC, що отримав ім'я TLS.

Протокол забезпечує конфіденційність обміну даними між клієнтом і сервером, що використовують TCP / IP, причому для шифрування використовується асиметричний алгоритм з відкритим ключем. При шифруванні з відкритим ключем використовується два ключі, причому будь-який з них може використовуватися для шифрування повідомлення. Тим самим, якщо використовується один ключ для шифрування, то відповідно для розшифровки потрібно використовувати інший ключ. У такій ситуації можна отримувати захищені повідомлення, публікуючи відкритий ключ, і зберігаючи в таємниці секретний ключ.

Протокол SSL складається з двох підпротоколів: протокол SSL запису і рукостискання. Протокол SSL запису визначає формат, який використовується для передачі даних. Протокол SSL включає рукостискання з використанням протоколу SSL запису для обміну серіями повідомлень між сервером і клієнтом, під час встановлення першого з'єднання. Для роботи SSL потрібно, щоб на сервері був SSL- сертифікат.

SSL надає канал, що має три основні властивості:

• Аутентифікація. Сервер завжди автентифікований, в той час як клієнт автентифікований в залежності від алгоритму.
• Цілісність. Обмін повідомленнями включає в себе перевірку цілісності.
• Конфіденційність каналу. Шифрування використовується після встановлення з'єднання і використовується для всіх наступних повідомлень.

У протоколі SSL всі дані передаються у вигляді записів-об'єктів, що складаються із заголовка і переданих даних. Передача починається із заголовка. Заголовок містить або два, або три байти коду довжини. Причому, якщо старший біт в першому байті коду дорівнює одиниці, то запис не має заповнювача і повна довжина заголовка дорівнює двом байтам, інакше запис містить заповнювач і повна довжина заголовка дорівнює трьом байтам. Код довжини запису не включає в себе число байт заголовка. Довжина запису 2-х байтового заголовка:

RecLength = (byte [0] & 0x7F <<8) | byte [1];

Тут byte [0] і byte [1] перший і другий отримані байти.

Довжина запису 3-х байтового заголовка:

RecLength = (byte [0] & 0x3F <<8) | byte [1];

Escape = (byte [0] & 0x40)! = 0;

Padding = byte [2];

Тут 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 отримав широке застосування в електронній пошті.

1. Криптографічна безпека: SSL встановлює безпечне з'єднання між двома сторонами.
2. Відкритість: Програмісти, незалежно один від одного, можуть створювати додатки, що використовують SSL, які згодом будуть здатні успішно обмінюватися криптографічними параметрами без всякого знання коду чужих програм.
3. Розширюваність: SSL прагне забезпечити робочий простір, в якому нові відкриті ключі і трудомісткі методи шифрування можуть бути додані при необхідності.
4. Відносна ефективність: робота протоколу на основі SSL вимагає великих швидкостей від CPU, зокрема для роботи з відкритими ключами. Тому до SSL протоколу була включена необов'язкова схема кешування сесій для зменшення кількості з’єднань, які необхідно встановлювати з нуля. Крім того, велика увага приділяється тому, щоб зменшити мережеву активність.

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, повідомлення обміну підписуються server's RSA або сертифікат DSS. Сигнатура включає поточне значення повідомлення Client_Hello.random, таким чином старі сигнатури і старі тимчасові ключі не можуть повторюватися. Сервер може використовувати тимчасовий ключ RSA тільки одного разу для створення сесії. Після перевірки сертифіката сервера клієнт шифрує секрет (pre_master_secret) за допомогою відкритого ключа сервера. Після успішного декодування секрету (pre_master_secret) створюється повідомлення «finished», тим самим сервер демонструє, що він знає приватний ключ відповідний сертифікату сервера.

Коли RSA використовується для обміну ключами, для аутентифікації клієнта використовується повідомлення перевірки сертифіката клієнта. Клієнт підписується значенням, обчисленим з master_secret і всіх попередніх повідомлень протоколу рукостискання. Ці повідомлення рукостискання включають сертифікат сервера, який ставить у відповідність сигнатурі сервера, повідомлення Server_Hello.random, якому ставить у відповідність сигнатуру поточному повідомленням рукостискання.

У цьому випадку сервер може також підтримувати алгоритм Діффі-Хеллмана або може використовувати повідомлення обміну ключами від сервера для посилки набору часових параметрів, підписаних сертифікатами DSS або RSA. Тимчасові параметри хешують з повідомленням hello.random перед підписанням, для того щоб зловмисник не зміг вчинити повтор старих параметрів. У будь-якому випадку клієнт може перевірити сертифікат або сигнатуру, для впевненості, що параметри належать серверу.

Якщо клієнт має сертифікат, що містить параметри протоколу Діффі-Геллмана, то сертифікат також має інформацію необхідну для того, щоб завершити обмін ключами. Зауважимо, що в цьому випадку клієнт і сервер повинні будуть згенерувати ті ж результати алгоритму Діффі-Геллмана (pre_master_secret) щоразу, коли вони встановлюють з'єднання. Для запобігання перебування секрету (pre_master_secret) у пам'яті комп'ютера на час, довший за необхідний, секрет має бути переведений в загальний секрет (master_secret) настільки швидко, наскільки це можливо. Для роботи обміну ключами параметри клієнта повинні бути сумісні з тими, які підтримує сервер.

Протокол запису — це рівневий протокол. На кожному рівні повідомлення включають поля для довжини, опису і перевірки. Протокол запису приймає повідомлення, які потрібно передати, фрагментує дані в керовані блоки, розумно стискає дані, застосовуючи MAC (message authentication code), шифрує і передає результат. Отримані дані він розшифровує, перевіряє, розпаковує, збирає і доставляє верхнім рівням клієнта.

Існує чотири протоколи запису: протокол рукостискання (Handshake Protocol), протокол тривоги (Alert Protocol), протокол зміни шифру (The Change Cipher Spec Protocol), протокол даних додатку (Application Data Protocol). Якщо SSL реалізація отримує тип запису, який їй невідомий, то цей запис просто ігнорується.

SSL клієнт і сервер домовляються про встановлення зв'язку за допомогою процедури рукостискання. Під час рукостискання клієнт і сервер домовляються про різні параметри, які будуть використані, щоб забезпечити безпеку з'єднання.

• Рукостискання починається тоді, коли клієнт підключається до SSL сервера. Запит безпечного з'єднання являє собою список підтримуваних шифрів та хеш-функцій.

• З цього списку сервер вибирає найсильніший шифр та хеш-функцію, яку він також підтримує, і повідомляє клієнтів про прийняте рішення.

• Сервер відсилає це рішення у вигляді цифрового сертифікату. Сертифікат, звичайно, містить ім'я сервера, довірений Центр Сертифікації, і відкритий ключ шифрування сервера. Клієнт може зв'язатися з сервером, який видав сертифікат і переконатися, що сертифікат є справжнім, перш ніж продовжити.

• Для того, щоб згенерувати ключі сеансу, використовується безпечне з'єднання. Клієнт шифрує випадкове число за допомогою відкритого ключа (ВК) сервера і відправляє результат на сервер. Тільки сервер в змозі розшифрувати його (з його закритим ключем (ЗК)), і тільки цей факт робить ключі прихованими від третьої сторони, так як тільки сервер і клієнт мали доступ до цих даних. Клієнт знає відкритий ключ і випадкове число, а сервер знає закритий ключ і (після розшифровки повідомлення клієнта) випадкове число. Третя сторона, можливо, знає тільки відкритий ключ, якщо закритий ключ не був зламаний.

• З випадкового числа обидві сторони створюють ключові дані для шифрування та розшифрування.

На цьому рукостискання завершується, і починається захищене з'єднання, яке зашифровується і розшифровується за допомогою ключових даних. Якщо будь-що з перерахованих вище дій не вдається, то рукостискання SSL не вдалося, і з'єднання не створюється.

Він існує для сигналізації переходу в режим шифрування. Протокол містить єдине повідомлення, яке зашифроване і стиснуте при поточному встановленому з'єднанні. Повідомлення складається тільки з одного біта зі значенням 1.

struct { enum {change_cipher_spec (1), (255)} type; } ChangeCipherSpec;

Повідомлення зміни шифру посилається і клієнтом і сервером для сповіщення приймаючої сторони, що наступні записи будуть захищені відповідно до нових домовленостей про CipherSpec і ключі. Прийняття цього повідомлення змушує одержувача віддати наказ рівня запису негайно копіювати стан відкладеного читання у стан поточного читання. Відразу після послання цього повідомлення, той хто послав повинен віддати наказ рівня запису перевести режим відкладеної запису в режим поточного запису. Повідомлення зміни шифру надсилається під час рукостискання, після того як параметри захисту були передані, але перед тим як буде надіслано повідомлення 'finished'.

Один з типів перевірки, які підтримуються в протоколі SSL запису, — це протокол тривоги. Повідомлення тривоги передає труднощі, які виникли у повідомленні, та опис тривоги. Повідомлення тривоги з критичним рівнем негайно перериває з'єднання. У цьому випадку інші з'єднання, відповідної сесії, можуть бути продовжені, але ідентифікатор сесії повинен бути визнаний недійсним. Як і інші повідомлення, повідомлення тривоги зашифровано і стиснуто, як тільки вказано поточний стан з'єднання.

Повідомлення з даними додатка опрацьовуються на рівні запису. Вони фрагментуються, стискаються і шифруються на основі поточного стану з'єднання. Повідомлення вважаються прозорими для рівня запису.

У протоколі SSL обробка помилок дуже проста. Коли помилка виявлена​​, той, хто її виявив, посилає про це повідомлення своєму партнерові. Непереборні помилки вимагають від сервера і клієнта розриву з'єднання. Протокол SSL визначає наступні помилки:

1. Unsupported_Certificate_Type_Error: така помилка виникає, коли клієнт / сервер отримує тип сертифіката, який не підтримується. Помилка переборна (тільки для аутентифікації клієнта).
2. No_Cipher_Error: помилка виникає, коли сервер не може знайти розмір ключа або шифр, який підтримується також і клієнтом. Помилка непереборна.
3. Bad_Certificate_Error: така помилка виникає, коли сертифікат вважається приймаючою стороною поганим. Це означає, що або некоректний підпис сертифіката, або він має некоректне значення. Помилка переборна (тільки для аутентифікації клієнта).
4. No_Certificate_Error: якщо надіслано повідомлення Request_Certificate, то ця помилка може бути надіслана через те, що клієнт не має сертифіката. Помилка переборна.

Опишемо ряд атак, які можуть бути проведені проти протоколу SSL. Однак, SSL стійкий до цих атак за умови використання довірених центрів сертифікації.

Як відомо, SSL залежить від різних криптографічних параметрів. Шифрування з відкритим ключем RSA необхідно для пересилки ключів і аутентифікації сервера / клієнта. Для шифрування використовуються різні криптографічні алгоритми. Таким чином, якщо здійснити успішну атаку на ці алгоритми, то SSL не може вже вважатися безпечним. Атака проводиться записом сесії, і потім, протягом довгого часу підбирається ключ сесії або ключ RSA. Використання SSL робить таку атаку невигідною, так як витрачається велика кількість часу і грошей.

Також відома як MitM (Man-in-the-Middle) атака. Передбачає участь трьох сторін: сервера, клієнта і зловмисника, що знаходиться між ними. У даній ситуації зловмисник може перехоплювати всі повідомлення, які слідують в обох напрямках, і підміняти їх. Зловмисник представляється сервером для клієнта і клієнтом для сервера. У разі обміну ключами по алгоритму Діффі-Хелмана дана атака є ефективною, оскільки цілісність прийнятої інформації і її джерело перевірити неможливо. Однак така атака неможлива при використанні протоколу SSL, так як для перевірки автентичності джерела (зазвичай сервера) використовуються сертифікати, завірені центром сертифікації.

Атака буде успішною, якщо:

• Сервер не має підписаного сертифіката.
• Клієнт не перевіряє сертифікат сервера.
• Користувач ігнорує повідомлення про відсутність підпису сертифіката центром сертифікації або про розбіжності сертифіката з кешованою копією.

Зауваження. Робота HTTPS-фільтра (який встановлює тунель в обидві сторони і віддає свій сертифікат клієнту) в MS Forefront TGM, що працює за цією схемою, не є атакою, але є засобом захисту та контролю.

Зловмисник записує комунікаційну сесію між сервером і клієнтом. Пізніше, він намагається встановити з'єднання з сервером, відтворюючи записані повідомлення клієнта. Але SSL відбиває цю атаку за допомогою особливого унікального ідентифікатора з'єднання (ІЗ). Звичайно, теоретично третя сторона не в силах передбачити ІЗ, тому що він заснований на наборі випадкових подій. Однак, зловмисник з великими ресурсами може записати велику кількість сесій і спробувати підібрати «правильну» сесію, ґрунтуючись на коді nonce, який послав сервер в повідомлення Server_Hello. Але коди nonce SSL мають, щонайменше, довжину 128 біт, а значить, зловмисникові необхідно записати ${\displaystyle 2^{64}}$ кодів nonce, щоб отримати ймовірність вгадування 50%. Але ${\displaystyle 2^{64}}$ досить велике число, що робить ці атаки безглуздими.

Зловмисник може спробувати вплинути на обмін рукостисканнями для того, щоб сторони обрали різні алгоритми шифрування, а не ті, що вони обирають зазвичай. Через те, що багато реалізацій підтримують 40-бітове експортне шифрування, а деякі навіть 0-шифрування або MAC-алгоритм, ці атаки представляють великий інтерес.

Для такої атаки зловмисникові необхідно швидко підмінити одне або більше повідомлень рукостискання. Якщо це відбувається, то клієнт і сервер обчислять різні значення хеш повідомлення рукостискання. У результаті чого сторони не приймуть один від одного повідомлення Finished. Без знання секрету зловмисник не зможе виправити повідомлення Finished, тому атака може бути виявлена.

• Для обміну ключами та перевірки їх достовірності застосовуються: RSA, Diffie-Hellman, ECDH, SRP, PSK.
• Для аутентифікації: RSA, DSA, ECDSA.
• Для симетричного шифрування: RC2, RC4, IDEA, DES, Triple DES або AES, Camellia.
• Для хеш-функцій: SHA, MD5, MD4 і MD2.

SSL у сестринських Вікіпроєктах

• TLS
• JSSE
• OpenSSL
• SSH
• SSLeay

• Mozilla.org — введення в SSL протокол
• inSSL — ресурс про SSL

Це незавершена стаття про Інтернет. Ви можете допомогти проєкту, виправивши або дописавши її.