Мало хто звертає увагу на зелену напис «Надійний» (надійний сайт) зліва від адресного рядка в Chrome і на значок закритого замка поруч, а між тим число сайтів з таким написом в 2017 році перевалила за половину всіх існуючих. Що ж це означає? Давайте розберемося.

Історія протоколу HTTPS

На самій зорі Інтернету перед користувачами мережі постала проблема: деякі веб-сторінки хочеться зробити приватними, доступними тільки обмеженому колу людей. Очевидним рішенням було передавати серверу пароль і видавати користувачу електронний пропуск (токен), який він повинен пред'являти кожен раз, як заходить на закритий ресурс. Але як зберегти токен і пароль в таємниці? Як ми пам'ятаємо з минулого статті , HTTP - текстовий протокол. Він передає всі дані у відкритому вигляді, більш того, в досить зрозумілою для людини формі, і ніяк не запобігає перехоплення даних сторонньою особою.

У 1995 році компанія Netscape Communications опублікувала стандарт SSL (Secure Sockets Layer, рівень захищених сокетів), призначений для передачі даних через відкриті канали. Заснований на алгоритмах асиметричного шифрування, протокол підходив для використання не тільки в якості захисного шару для HTTP, але і в якості контейнера для передачі голосу, відео і будь-який інший інформації незалежно від каналу. Вже в 1996 була випущена версія SSL 3.0.

У 1999 році на основі SSL3.0 співтовариство IETF розробило TLS - протокол захисту транспортного рівня. У ньому були виправлені множинні недоліки і уразливості SSL, і сьогодні TLS став рекомендованим стандартом шифрування мережевих з'єднань. На даний момент більше половини трафіку мережі використовує SSL / TLS в якості захищеного контейнера. По суті, звичайний HTTP пропускається через «чорний ящик» криптопротоколів і надсилається клієнту або сервера, де і розшифровується. Чіткий поділ між шаром шифрування і шаром доступу до мережевих сервісів дозволило програмістам легко інтегрувати HTTPS у багато проектів. Згаданий вище значок «Надійний сайт» поруч з адресним рядком браузера якраз сигналізує про те, що ваше з'єднання з сайтом захищено одним з криптоалгоритмів.

Що ж під капотом у сучасних засобів шифрування?

механізми безпеки

Встановлення безпечного з'єднання складається з декількох етапів:

• клієнт і сервер домовляються, який протокол використовувати для обміну ключами (RSA або протокол Діффі-Хеллмана, про них нижче);
• клієнт і сервер обмінюються ключами;
• з цього моменту все пакети між Алісою (чомусь у всіх підручниках по криптографії Аліса щось шле Бобу або сервера) і сервером шифруються за допомогою цього ключа звичайним криптоалгоритмом (AES, Blowfish, ГОСТ 28147-89 і т.д.)

Чому б не шифрувати за допомогою RSA або Діффі-Хеллмана (DH) весь потік даних між клієнтом і сервером? Справа в тому, що і RSA, і DH дуже вимогливі до ресурсів комп'ютера, і сильно б забарилися відправку і прийом інформації, тоді як алгоритми шифрування з симетричним ключем вимагають набагато менше обчислювальних потужностей і часто реалізовані прямо «в залізі».

Протокол Діффі-Хеллмана

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

І як же Аліса може захистити своє печиво від Єви, яка слухає все її переговори з Бобом? Відповідь була дана американськими криптографами Діффі, Хеллманом і Меркле ще в 1976 році на Національній комп'ютерної конференції. Виступаючи на ній, математики запропонували протокол безпечної передачі повідомлень по відкритих каналах, пізніше названий протоколом Діффі-Хеллмана.

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

Алгоритм безпечного пересилання існує, і він такий:

1. Аліса закриває ящик з печивом на замок і надсилає поштою. Єва не може дістатися до печива - ключа у неї немає.
2. Боб отримує закритий ящик і вішає на нього свій замок, після чого надсилає поштою. У Єви знову ж немає печива - ящик закритий на два замки!
3. Аліса отримує ящик назад, знімає з нього свій замок і відправляє його Бобу - але вже з його власним замком.
4. Боб отримує ящик з печивом і відкриває його.
5. Всі задоволені (крім Єви).

Таким чином, незважаючи на те, що Єва має доступ до ящика, а у Єви і Боба немає загального ключа, посилка доходить в цілості. Здавалося б - ось вони, щастя і гарантія таємниці особистого листування! Однак не все так просто. При всій простоті і стійкості до перехоплення протокол Діффі-Хеллмана володіє вагомим недоліком: подвійна пересилання повідомлень. Тільки вдумайтеся: кожен раз, коли ви б дивилися фільм або слухали музику по захищеному каналу, вашого телефону доводилося б посилати на сервер то ж кількість трафіку, що він би отримував, а потім отримувати його знову. Навантаження на мережу і процесор зросла б мінімум втричі! І хоча в деяких особливо критичних випадках перевитрата ресурсів в обмін на безпеку представляється вигідною операцією, для більшості ситуацій використання чистого протоколу Діффі-Хеллмана - недозволена розкіш. Як же тоді нам домогтися безпечної передачі даних?

асиметричне шифрування

Ідея асиметричного шифрування полягає в наступному: існують алгоритми, які дозволяють шифрувати повідомлення одним ключем (публічним), а розшифровувати за допомогою іншого (приватного). Таким чином, дізнавшись публічний ключ адресата, ви зможете посилати йому зашифровані листи, розшифрувати які зможе тільки власник приватного ключа.

Найвідоміший і популярний алгоритм асиметричного шифрування називається RSA - за іменами трьох творців (Rivest, Shamir і Adleman). Опублікований ще в 1987 році, він до цих пір є криптографічним стандартом.

криптографічні сертифікати

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

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

Все дуже просто:

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

Так як же електронний підпис ставиться до безпечного інтернету? Відповідь проста: вона вирішує проблему довіри до ключу, отриманого клієнту від сервера. Дійсно, звідки ми знаємо, що з'єдналися з сервером vk.com, а не з хакерською пасткою, встановленої на вашому роутере? Існує ряд так званих центрів сертифікації, один з яких підписує файл з ім'ям сайту, даними про власника і відкритим ключем. Після видачі такого «посвідчення» сервер використовує цей файл на етапі встановлення з'єднання. Справа в тому, що на вашому комп'ютері (а також на планшеті і телефоні) зберігається набір відкритих ключів стандарту X.509, випущених цими самими сертифікаційними центрами, тому браузер має можливість перевірити сертифікат сайту і в разі проблем просигналізувати про проблему користувачеві:

Так в чому підступ?

Здавалося б, методи шифрування відточені за довгі роки, і велика частина атак на криптоалгоритми носить скоріше теоретичний характер, так що нам нема про що хвилюватися. Так воно насправді?

На жаль, TLS захищає ваші дані тільки на шляху від браузера до сервера. Насправді, ніякі технічні методи не вирішать проблем соціальних. Шахраям не важко отримати домен, схожий на відомий сайт, і TLS сертифікат, таким чином мімікріруя під безпечний сервіс. Сертифікати на вашому комп'ютері можна підмінити (так роблять навіть деякі антивіруси, нібито з метою перевірки трафіку, але хто знає напевно?), Та й люди ніколи не страждали надлишком пильності, з радістю відкриваючи файли Word від незнайомих людей і довіряючи доступ до акаунтів шахрайським додаткам .

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