1. 1. Введення
2. 2. Методи криптографії
3. алгоритми шифрування
4. Однонаправлені Хеш-функції
5. цифрові підписи
6. 3. Сертифікати
7. вміст сертифіката
8. центри сертифікації
9. ланцюжки сертифікації
10. Створення кореневого центру сертифікації
11. управління сертифікатами
12. 4. SSL
13. огляд протоколу
14. установка сеансу
15. Передача даних
16. Використання SSL
17. 5. Реалізація SSL
18. Література для подальшого вивчення
19. Koops
20. сертифікати

Переклад А. В. Южанинова [email protected] . Оригінал статті був опублікований на http://www.pseudonym.org/ssl/ssl_intro.html

Ця стаття була написана в кінці 1990-х або на початку 2000-х років. І хоча базові принципи викладені в даній статті досі застосовні, я рекомендую звернутися до більш сучасним статтями на цю тему.

1. Введення

Протокол SSL (Secure Sockets Layer protocol, протокол захищених сокетів) [ SSL3 ] Надає спосіб для аутентифікації, контролю цілісності, і конфіденційності при використанні Web.

Даний документ містить вступ в концепцію SSL для тих, хто знайомий з роботою Web, HTTP, Web серверів, але не є фахівцем з інформаційної безпеки. Він не призначений бути вичерпним посібником з протоколу SSL, в ньому так само немає опису певних серверів або технік управління сертифікатами. У ньому так само не розглянуті правові аспекти: патенти і експортні та імпортні обмеження 1) . Мета цього документа і статті OpenSSL Certificate Cookbook дати початкову точку для подальшого вивчення тем, хто хоче зрозуміти, як працює підтримка SSL на серверах.

2. Методи криптографії

Для розуміння SSL необхідно розуміти, що таке алгоритми шифрування, хеш-функції і цифрові підписи. Ці питання добре розкриті в книзі «Прикладна криптографія» [ Schneier ], І є основою для забезпечення конфіденційності, контролю цілісності і аутентифікації.

алгоритми шифрування

Припустимо, що Аліса хоче відправити повідомлення банку про перерахування певної суми грошей, що включає інформацію, яку вона хоче приховати від інших, таку як номер рахунку і сума. Аліса хоче, щоб повідомлення було секретним. Криптографічні алгоритми можуть бути використані для перетворення її повідомлення в зашифрований вид. Як тільки повідомлення стало нечитабельним, воно може стати зрозумілим тільки за допомогою секретного ключа. Без секретного ключа повідомлення марно, тому що потрібно занадто багато часу, щоб розшифрувати його. Існують два основних типи алгоритмів заснованих на ключах: симетричні і з відкритим ключем.

Симетричні алгоритми, часто звані традиційними, вимагають, щоб у відправника і одержувача був однаковий ключ, секретна інформація, яка використовується для шифрування і дешифрування повідомлення. Тільки ті, хто мають ключ (відправник і одержувач) можуть прочитати повідомлення. Якщо Аліса і банк знають секретний ключ, вони можуть надсилати один одному приватні повідомлення. Проблема в тому, що Аліса і банк повинні вибрати ключ до того почнуть обмінюватися повідомленнями.

Дрого підхід використовувати криптографію з відкритим ключем. Алгоритми з відкритим ключем (звані асиметричними алгоритмами) вирішують проблему обміну ключами, вони розроблені таким чином, що ключ, який використовується для дешифрування відрізняється від ключа використовується для шифрування. Це дозволяє обмінюватися секретними повідомленнями без визначення загального ключа: відкритий ключ можна опублікувати, а другий потрібно зберегти в секреті (закритий ключ). Будь-хто може зашифрувати повідомлення, використовуючи відкритий ключ, але тільки володар закритого ключа зможе прочитати його. Таким чином, будь-хто може послати зашифроване повідомлення тому, хто згенерував пару ключів і зробив відомим відкритий ключ (залишивши закритий ключ у себе). Якщо у Алісі є відкритий ключ банку, вона зможе послати йому зашифроване повідомлення. Тільки банк зможе дешифрувати його.

Однонаправлені Хеш-функції

Хоча Аліса може зашифрувати своє повідомлення, щоб зробити його секретним, вона може так само турбуватися про те, що хтось змінить її повідомлення або замінить іншим, наприклад для того, щоб перерахувати гроші собі. Алісі потрібна гарантія цілісності повідомлення. Один із способів - обчислити коротку контрольну суму повідомлення і так же переслати її банку. Коли банк отримає повідомлення, він так само вважатиме контрольну суму і порівняє її з отриманою від Аліси. Якщо вони збігаються, то повідомлення не було змінено.

Такі суми називаються односпрямованим хеш-функціями, або характерними ознакою повідомлення (message digest). Хеш-функції використовуються для створення короткого, з фіксованою довжиною уявлення довгого повідомлення зі змінною довгою. Алгоритми хеш-функцій розроблені так, щоб для різних повідомлень мати різні значення, і так що було вкрай складно за значенням хеш-функції відновити вихідне повідомлення. Вони так само зроблені так, щоб було практично неможливо створити два повідомлення, які мають однакове значення хеш-функцію (щоб виключити можливість заміни одного повідомлення на інше з таким же значенням хеш-функцією).

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

цифрові підписи

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

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

3. Сертифікати

Хоча Аліса може послати банку секретне повідомлення, підписати його, і бути впевненою, що воно не буде змінено, їй потрібно бути впевненою, що відкритий ключ насправді належить банку. Банк теж повинен бути впевненим в тому, що цифровий підпис дійсно належить Алісі. Якщо кожен має сертифікат, в якому сказано хто його власник, міститься відкритий ключ і все це підписано довіреною організацією, то вони можуть вважати, що вони зв'язуються дійсно з тими, з ким передбачалося. Така довірена організація називається центром сертифікації (Certificate Authority, CA), і сертифікати використовуються для аутентифікації.

вміст сертифіката

Вміст сертифіката:

Суб'єкт: відмітна ім'я, відкритий ключ Ким видано: відмітна ім'я, підпис Терміни дії: дата початку дії, дата закінчення дії Службова інформація: версія, порядковий номер Розширення:

Відмітна ім'я використовується для ідентифікації в певному контексті (наприклад, людина може мати особистий сертифікат і сертифікат як співробітник фірми). Відмінні імена визначені в стандарті X.509 [ Kaufman ], В якому визначені імена, їх абревіатури та вимоги до змісту. Центр сертифікації може визначити правила, в яких визначено, які поля обов'язкові, а які ні. Можуть так само визначатися вимоги до вмісту полів. Наприклад, браузер Netscape вимагає, щоб в поле Common Name сертифіката сервера було регулярне вираз для його доменного імені (наприклад * .opengroup.org).

Відмітна ім'я:

загальне ім'я (CN) Ім'я суб'єкта, наприклад CN = Frederick Hirsch Організація або компанія (O) Ім'я цієї організації, наприклад O = The Open Group Організаційна одиниця (OU) Ім'я організаційної одиниці, відділу, підрозділу і т. п., наприклад, OU = Research Institute Місто / Розташування (L) Місто, в якому розташований суб'єкт, наприклад Cambridge Область / Район (SP) Область / Район, наприклад Massachusetts Країна (C) Країна ( код ISO ), Наприклад US

Двійковий формат сертифіката визначається за допомогою нотації ASN.1 [ ASN.1 ]. Ця нотація визначає, як вміст сертифікату перетворюється в двійковий вигляд. Двійковий формат сертифіката визначений з використанням правил DER, які засновані на більш загальних правила BER. Двійкова форма може бути перетворена з використанням кодування base64 в текст (ASCII) для тих випадків, коли не можна використовувати двійковий формат. Такий вид називається PEM (Privacy Enhanced Mail) і сертифікат поміщається між лініями:

----- BEGIN CERTIFICATE ----- ----- END CERTIFICATE -----

центри сертифікації

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

ланцюжки сертифікації

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

Створення кореневого центру сертифікації

Одна з проблем при використанні сертифікатів - кожен повинен бути ким небудь підписаний, якщо це не кореневий сертифікат. Т. к. Це сертифікат верхнього рівня, він не може бути виданий кимось іншим. У цьому випадку сертифікат є «самоподпісанного» (self-signed), оскільки суб'єкт сертифікації це орган, який його видав. Тому, довіряючи самоподпісанного сертифікатом потрібно бути особливо обережним. Ми можемо довіряти їм зазвичай тому, що відкриті ключі кореневих центрів широко відомі. Клієнти і сервери налаштовані довіряти їм за замовчуванням.

Є ряд компаній, таких як VeriSign [ VeriSign ] Які грають роль кореневих центрів сертифікації. Вони надають методики для запиту сертифікатів, мають правила для перевірки інформації, видачі сертифікатів і управління ними. Хоча це небезпечно в Інтернеті, в інтранеті може бути корисно, коли організації мають простий спосіб для аутентифікації серверів і користувачів.

управління сертифікатами

Організація центру сертифікації це відповідальність, що вимагає об'єднання адміністративних, управлінських і технічних систем. Центр сертифікації не тільки видає сертифікати, а й керує ними. Це означає, він повинен визначати терміни дії сертифікатів, продовжувати їх і підтримувати списки виданих сертифікатів, які є недійсними (certificate revocation lists, CRL). Якщо Аліса працює в компанії і має сертифікат як співробітник, то коли вона звільняється, сертифікат повинен бути відкликаний. Сертифікат може бути широко поширений, і не можна в ньому самому вказати, що він був відкликаний. При перевірці дійсності сертифіката необхідно зв'язатися з центром сертифікації, який видав цей сертифікат для того, щоб перевірити, чи не було відкликано, але часто цю частину процесу потрібно виконувати вручну. В системах, де відгуки сертифікатів мають значення, необхідно переконатися, що список відкликаних сертифікатів перевіряється.

Коли використовується центр сертифікації, який за замовчуванням не відомий браузеру, необхідно встановити сертифікат центру сертифікації, щоб було можна перевіряти сертифікати серверів, видані цим центром. Це може бути небезпечно, оскільки, встановивши один раз такий сертифікат, браузер буде приймати будь-які сертифікати видані цим центром. Ланцюжки сертифікатів дозволяють надавати сертифікати разом з сертифікатами тих, хто їх видав, щоб можна було перевірити сертифікат, навіть якщо сертифікати проміжних центрів сертифікації були встановлені в браузері (або на сервері).

4. SSL

Протокол SSL (Secure Sockets Layer protocol, протокол захищених сокетів) - протокол, який може бути поміщений в багаторівневої моделі протоколів між протоколом забезпечує надійне з'єднання (наприклад, TCP) і прикладним рівнем (наприклад, HTTP). Він надає безпечний канал між клієнтам і сервером, надаючи можливість взаємної аутентифікації, використання цифрових підписів для забезпечення цілісності та шифрування для конфіденційності.

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

Існує кілька версій протоколу SSL.

Версія Джерело Опис Підтримка в браузерах SSL 2.0 опубліковано Netscape вихідний протокол Netscape 3.0, Internet Explorer 3.0 SSL 3.0 застарілий Internet Draft версія, що запобігає деякі атаки, додані нові алгоритми і підтримка ланцюжків сертифікатів Netscape 3.0, Internet Explorer 3.0 TLS 2.0 IETF draft переглянутий SSL 3.0 none

Проблемна група проектування Internet ( Internet Engineering Task Force, IETF ) Працює над стандартом TLS (Transaction Layer Security - протокол захисту транспортного рівня).

огляд протоколу

Одного разу встановлений сеанс може бути використано повторно, щоб уникнути втрат продуктивності через багатокрокової процедури встановлення з'єднання.

установка сеансу

Установка сеансу починається з роботи протоколу квітірованія (handshake sequence) між клієнтом і сервером. Ця послідовність може залежати від того, чи налаштований сервер надавати сертифікат, і чи потребує він наявність сертифіката у клієнта. Можливо так само, для узгодження параметрів алгоритму шифрування будуть потрібні додаткові кроки. У цьому документі описується типовий сценарій, а решта можливості SSL не розглядаються.

Протокол квітірованія використовується клієнтом і сервером для:

1. Узгодження параметрів шифрування (Cipher Suite), які будуть використаний при передачі даних

2. Вироблення і передачі сеансового ключа між клієнтом і сервером

3. Необов'язковою аутентифікації сервера клієнтом.

4. Необов'язковою аутентифікації клієнта сервером.

Мал. 1. Спрощений порядок квітірованія (Handshake)

Узгодження набору параметрів шифрування дозволяє вибрати клієнту і серверу такі параметри, які вони обидва підтримують. Специфікація SSL 3.0 визначає 31 набору параметрів. Набір параметрів шифрування складається з:

1. Методу обміну ключами

2. Симетричного алгоритму шифрування для передачі даних

3. Функції хешування для створення MAC (Message Authentication Code - код автентичності повідомлення).

Метод обміну ключами визначає, як клієнт і сервер узгодять загальний ключ для симетричного алгоритму шифрування. The key exchange method defines how the shared secret symmetric cryptography В SSL 2.0 для обміну ключів використовується RSA. В SSL 3.0 можливий вибір між RSA, при використанні сертифікатів, і шляхом обміну ключами по Діффі-Хеллману (Diffie-Hellman) для обміну ключами без сертифікатів і без попередньої зв'язку між клієнтом і сервером [ Kaufman ].

Вибір методу обміну ключами включає рішення використовувати або не використовувати цифрові підписи при обміні ключами, і який спосіб цифрового підпису використовувати. Підпис закритим ключем захищає від атак людина по середині (man-in-the-middle-attack) під час обміну інформацією, яка використовується для вироблення спільного ключа.

В SSL використовуються симетричні алгоритми шифрування для шифрування даних протягом сеансу. Можливі 9 варіантів, включаючи відмову від шифрування:

1. немає шифрування

2. потокове шифрування

   1. RC4 з ключем 40 біт

   2. RC4 з ключем 128 біт

3. Алгоритми використовуються в режимі CBC

   1. RC2 з ключем 40 біт

   2. DES40, DES, 3DES_EDE.

   3. Idea

   4. Fortezza

Режим CBC (Cipher Block Chaining - зчеплення блоків шифру), попередній зашифрований блок використовується при шифруванні поточного блоку. DES - Data Encryption Standard [ Schneier, ch12 ], Має безліч варіантів (включаючи DES40 and 3DES_EDE). Idea (один з найбільш стійких алгоритмів) і RC2 є власністю компанії RSA [ Schneier, ch13 ].

Вибір функції хешування визначає, як буде створюватися хеш блоку даних. SSL підтримує:

1. без хеширования

2. MD5, хеш 128 довжиною біт

3. Secure Hash Algorithm (SHA), хеш 160 біт

SHA був розроблений для використання спільно з DSS (Digital Signature Standard - стандарт цифрового підпису).

Протокол квітірованія надає безліч можливостей, але найбільш поширена послідовність включає обмін сертифікатами і обмін ключами за методом Деффи-Хеллмана. В інших випадках порядок квітірованія відрізняється, як описано в специфікації SSL. Послідовність квітірованія використовує три протоколи, протокол квітірованія SSL (SSL Handshake Protocol), щоб відкрити потрібну між клієнтом і сервером, протокол узгодження параметрів шифрування (SSL Change Cipher Spec protocol) для узгодження набору криптоалгоритмів і їх параметрів і протокол сповіщення (SSL Alert Protocol) для обміну повідомленнями про помилки між клієнтом і сервером. Ці протоколи вміщені в протокол записи SSL (SSL Record Protocol) як дані прикладного рівня. Інкапсульований протокол передається як дані нижчого протоколом, які не аналізує ці дані. Інкапсульований протокол нічого не знає про нижніх протоколах.

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

Мал. 2. Стек протоколів SSL

Передача даних

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

Мал. 3. Протокол запису SSL

SSL використовує хеш-функції повідомлення і порядкові номери для обчислення кодів автентичності повідомлення (MAC, Message Authentication Code), які шифруються, що запобігає атаки повтору. Блоки протоколу записи, стислі блоки і зашифровані блоки містять ідентифікатор вихідного протоколу, довжину повідомлення та дані.

Використання SSL

Одне з поширених застосувань SSL - захист даних переданих по HTTP між клієнтом і веб-сервером. Безпечний варіант URL починається з «https», замість «http», і використовується інший порт (за замовчуванням 443) / Браузер зберігає клієнтські сертифікати і закриті ключі, і показує індикатор захищеного з'єднання, коли воно використовується.

5. Реалізація SSL

оча можливо написати реалізацію SSL «з нуля» за специфікацією, значно простіше взяти один з готових пакетів. Додатково, через патенти необхідно ліцензувати деякі криптографічні бібліотеки, по крайней мере, в США. Бібліотеки SSL містять функції для шифрування, обчислення хеш-функцій, і кошти для роботи з сертифікатами. Кожен пакет так же повинен містити ліцензований модуль для роботи з відкритими ключами в США, оскільки існує патент на використання криптографії з відкритим ключем.

Є два відомих пакета для роботи з несиметричним алгоритмом RSA:

• RSARef Зразок реалізації RSA, підтримуваний вихідний код бібліотеки, може бути використаний в безкоштовних і некомерційних додатках. Компанія Consensus Development Corp. продавала ліцензії на комерційне використання, але зараз це вже не так.
• BSAFE 3.0 Комерційна реалізація RSARef.

Ці пакети для роботи з відкритими ключами включають повний набір несиметричних алгоритмів (включаючи RSA і метод обміну ключами Деффи-Хеллмана), симетричні алгоритми, хеш-функції. Вони можуть бути використані в реалізаціях SSL. Найбільш відомі бібліотеки для роботи з SSL:

• SSLRef зразок реалізації SSL 3.0 від Netscape Communications Corp.
• SSLPlus Комерційний пакет з вихідним пакетом від Consensus Development Corp., покращену SSLRef 3.0. Для використання потрібен BSAFE 3.0 (from RSA).
• SSLava Реалізація SSL 3.0 на мові Java від Phaos Technology.
• OpenSSL OpenSSL-0.9.4 (OpenSSL-0.9.4.tar.gz) вільна, не комерційна реалізація SSL 2.0 і SSL 3.0 і TLS 2.0. Включає реалізацію несиметричних алгоритмів, яка може бути використана за межами США. У Штатах через патентні обмежень необхідно використовувати RSARef або BSAFE3.0. SSLeay надає недорогу можливість для використання SSL. [ OpenSSL FAQ ]

Література для подальшого вивчення

Загальні питання

Elgamal

Kaliski

Kaufman

Charlie Kaufman, Radia Perlman, Mike Speciner, Network Security: PRIVATE Communication in a PUBLIC world, Prentice Hall, 1995.

Koops

Phaos

Schneier

Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See http://www.counterpane.com/ for various materials by Bruce Schneier.

сертифікати

Kaliski

security / ssl_intro.txt · Останні зміни: 2017-09-19 21:07 UTC - citrin