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-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-сайтів^[1].

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

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

• Використання одного ключа для автентифікації повідомлень та шифрування даних. (Протокол SSL 3.0, дозволяє MAC секретам бути довшими за ключі для шифрування, тому секрет може залишатись захищеним навіть якщо буде зламано ключ для шифрування.^[3])
• 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,^[4] Mozilla Firefox 2,^[5] Opera 9.5,^[6] та Safari. Якщо після відправлення повідомлення TLS «ClientHello» Mozilla Firefox виявляє, що сервер не здатний завершити рукостискання, то браузер спробує повернутись до використання SSL 3.0 надіславши повідомлення SSL 3.0 «ClientHello» у форматі SSL 2.0 аби збільшити ймовірність успішного завершення рукостискання зі старішими серверами.^[7] Підтримка протоколу SSL 2.0 (та слабких 40- та 56- бітних шифрів) повністю прибрана з браузера Opera 10 версії.^[8][9]

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

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

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

• TLS
• JSSE
• OpenSSL
• SSH
• SSLeay

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

Ця стаття потребує додаткових посилань на джерела для поліпшення її перевірності. Будь ласка, допоможіть удосконалити цю статтю, додавши посилання на надійні (авторитетні) джерела. Зверніться на сторінку обговорення за поясненнями та допоможіть виправити недоліки. Матеріал без джерел може бути піддано сумніву та вилучено. (березень 2017)

Ця стаття не містить посилань на джерела. Ви можете допомогти поліпшити цю статтю, додавши посилання на надійні (авторитетні) джерела. Матеріал без джерел може бути піддано сумніву та вилучено. (березень 2017)

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

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