SSL

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-сертифікатів

SSL-cертифікати розрізняють за центром сертифікації, типом захисту та рівнем перевірки.

За типом захисту SSL-сертифікати поділяють на:

1. Сертифікати із захистом доменів (звичайні сертифікати). Використовуються для шифрування інформації одного домену без піддоменів.
2. Сертифікати із захистом піддоменів (Wildcard-сертифікати). Використовуються для шифрування інформації всіх піддоменів одного домену.
3. Сертифікати із захистом кількох доменів (SAN-сертифікати). Використовуються для шифрування інформації одразу кількох доменів без піддоменів.
4. Сертифікати програмного коду (Code Signing). Використовуються для підпису програмного забезпечення.
5. Сертифікати з підтримкою IDN. Використовуються для шифрування інформації кириличних або інших доменів, які містять літери нелатинських алфавітів.
6. Сертифікати із захистом електронної пошти та документів. Використовуються для автентифікації відправника та запобігають змінам у документах з боку правопорушників (спам, фішинг, підроблені рахунки).

SSL-сертифікати за рівнем перевірки власника поділяються на:

1. DV-сертифікати (domain validation) – перевірка за доменом. Підтверджують факт володіння доменом. Використовуються для блогів, лендінгів, сайтів-візиток та портфоліо.
2. OV-сертифікати (organization validation) – перевірка організації. Підтверджують власника домену та компанію, яка за ним стоїть. Перевірка організації зазвичай використовується для бізнес-сайтів, які приймають платежі.
3. 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», тим самим сервер демонструє, що він знає приватний ключ відповідний сертифікату сервера.

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

Обмін ключами при використанні протоколу Діффі-Геллмана і автентифікація

Докладніше: Протокол Діффі-Геллмана

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

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

Протокол запису (Record Layer)

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

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

Протокол рукостискання (Handshake Protocol)

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

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

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

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

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

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

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

Протокол зміни параметрів шифрування (The Change Cipher Spec Protocol)

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

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

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

Протокол тривоги (Alert Protocol)

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

Протокол даних додатку (Application Data Protocol)

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

Помилки в протоколі 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, тому атака може бути виявлена.

Атаки на SSL 2.0

SSL 2.0 мав низку вразливостей:

• Використання одного ключа для автентифікації повідомлень та шифрування даних. (Протокол SSL 3.0, дозволяє MAC секретам бути довшими за ключі для шифрування, тому секрет може залишатись захищеним навіть якщо буде зламано ключ для шифрування.)
• SSL 2.0 має слабкий алгоритм обчислення MAC-підписів, що використовує хеш-функцію MD5 із таємним префіксом, що робить його вразливим до .
• SSL 2.0 не має захисту процесу рукостискання (відкриття сеансу обміну даними), що робить його вразливим до .
• SSL 2.0 використовує стандартні механізми протоколу транспортного рівня TCP закриття з'єднання для позначення кінця даних. Це робить його вразливим до атаки на передчасне завершення передачі даних. Зловмисник може примусово обірвати з'єднання підробивши команду TCP FIN, отримувач даних тоді може не дізнатись про отримання неповних даних (у SSL 3.0 цю проблему виправлено — завершення сеансу відбувається явно, за відповідним повідомленням).
• SSL 2.0 передбачає єдиний сертифікат для домену, що робить його несумісним з поширеною практикою віртуального хостингу веб серверів.

SSL 2.0 було вимкнено за замовченням починаючи з Internet Explorer 7,Mozilla Firefox 2,Opera 9.5, та Safari. Якщо після відправлення повідомлення TLS «ClientHello» Mozilla Firefox виявляє, що сервер не здатний завершити рукостискання, то браузер спробує повернутись до використання SSL 3.0 надіславши повідомлення SSL 3.0 «ClientHello» у форматі SSL 2.0 аби збільшити ймовірність успішного завершення рукостискання зі старішими серверами. Підтримка протоколу SSL 2.0 (та слабких 40- та 56- бітних шифрів) повністю прибрана з браузера Opera 10 версії.

Алгоритми, що використовуються в SSL

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

Вартість SSL

Вартість SSL-сертифікатів залежить від кількох факторів. Насамперед від типу перевірки та поширення. Найдешевшими є сертифікати з перевіркою тільки домену. Вони коштують від 15 доларів на рік. Далі йдуть сертифікати з перевіркою компанії. Їх вартість — від 45 доларів за один рік користування. Найдорожчі — SSL-сертифікати з розширеною перевіркою. За один рік користування ним потрібно заплатити від 140 доларів.

Як отримати SSL-сертифікат

Сертифікати довіри видаються багатьма центрами сертифікації. Серед них можна виділити Sectigo Limited, DigiCert Inc, Symantec, GeoTrust, RapidSSL, Thawte та інші. Але не обов'язково звертатись до них безпосередньо. Більшість провайдерів пропонують до хостингових тарифів цілий набір сертифікатів на вибір. Такий варіант навіть кращий, тому що провайдер має достатньо досвіду, щоб знайти надійний центр сертифікації та запропонувати найкраще рішення.

Див. також

• TLS
• JSSE
• OpenSSL
• SSH

Примітки

1. Honcharenko, Diana (17 квітня 2024). Які бувають SSL-сертифікати? Переваги й недоліки кожного типу • Блог Hostpro. Блог Hostpro (укр.). Процитовано 17 квітня 2024.
2. Joris Claessens; Valentin Dem; Danny De Cock; Bart Preneel; Joos Vandewalle (2002). . Computers & Security. 21 (3): 253—265. doi:10.1016/S0167-4048(02)00312-7. Архів оригіналу за 17 жовтня 2015. Процитовано 12 липня 2017.
3. RFC 6101
4. Lawrence, Eric (22 жовтня 2005). IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2. MSDN Blogs. Архів оригіналу за 17 квітня 2013. Процитовано 25 листопада 2007.
5. . Mozilla Corporation. Архів оригіналу за 14 лютого 2017. Процитовано 25 листопада 2007.
6. «Opera 9.5 for Windows Changelog» [ 26 червня 2009 у Wayback Machine.] at : «Disabled SSL v2 and weak ciphers.»
7. . 11 вересня 2008. Архів оригіналу за 14 лютого 2017. Процитовано 12 липня 2017.
8. «Opera 10 for Windows changelog» [ 26 березня 2013 у Wayback Machine.] at : «Removed support for SSL v2 and weak ciphers»
9. Pettersen, Yngve (30 квітня 2007). . Opera Software. Архів оригіналу за 12 жовтня 2007. Процитовано 25 листопада 2007.
10. . Просто о фрилансе, штатной работе и не только: блог Freelancehunt (рос.). 30 квітня 2021. Архів оригіналу за 21 липня 2021. Процитовано 21 липня 2021.
11. . cityhost.ua (укр.). Архів оригіналу за 8 грудня 2021. Процитовано 8 грудня 2021.

Посилання

• Mozilla.org [ 11 листопада 2011 у Wayback Machine.] — введення в SSL протокол