Ось готовий урок, створений за твоїм майстер-промптом.

🎓 CS50-style: TLS та захист з’єднань. Секрети в надійних руках

Привіт, друзі! 👋

Уявіть собі ситуацію. Ви сидите в улюбленій кав'ярні, підключилися до безкоштовного Wi-Fi й вирішили перевірити баланс на банківській карті або залогінитися у Facebook. Ви вводите пароль, натискаєте Enter... і дані полетіли через роутер кав'ярні десь в інтернет.

А тепер питання: Хлопець у худі за сусіднім столиком, який щось уважно друкує на ноутбуці, — він може побачити ваш пароль?

Якщо ви використовуєте HTTP — так, він бачить його як простий текст. Якщо ви використовуєте HTTPS (TLS) — він бачить лише безглуздий набір символів.

Сьогодні ми розберемося з магією, яка перетворює інтернет із «прохідного двору» на безпечний простір. Ми говоримо про TLS.

1. 🔥 Вступ: Чому не можна просто "передати дані"?

Давайте проведемо аналогію. Уявіть, що інтернет — це шкільний клас. Ви (клієнт) хочете передати записку (дані) своїй подрузі (серверу) на іншому кінці класу.

Сценарій 1: HTTP (без захисту) Ви пишете: "Мій пароль — 12345". Передаєте записку через однокласників. Кожен, хто бере записку в руки (роутери, провайдери), може її розгорнути, прочитати й передати далі. Це катастрофа.

Сценарій 2: Шифрування Ви пишете шифром. Але тут виникає проблема: як ваша подруга дізнається, як розшифрувати записку? Якщо ви передасте їй ключ ("зсунь кожну букву на 1 вправо") разом із запискою — той самий "однокласник-шпигун" перехопить і ключ, і записку.

Риторичне питання: Як передати секретний ключ так, щоб ніхто його не перехопив, якщо канал зв’язку прослуховується з самого початку?

Здається неможливим? А ось і ні. Саме це вирішує TLS.

2. 🧠 Теоретична база: Як це працює "під капотом"

TLS (Transport Layer Security) — це протокол, який забезпечує дві головні речі: 1. Конфіденційність: Ніхто не прочитає ваші дані. 2. Автентичність: Ви точно знаєте, що спілкуєтеся з банком, а не з шахраєм, який намалював логотип банку.

🔑 Два типи шифрування (Це треба зрозуміти інтуїтивно)

Щоб зрозуміти TLS, треба знати два механізми:

1. Симетричне шифрування (Швидке, як блискавка ⚡️):

   • У вас і у сервера є однаковий ключ. Ним закриваємо, ним і відкриваємо.
   • Аналогія: Ключ від вашої квартири. У кого є дублікат — той і заходить.
   • Проблема: Як безпечно передати цей ключ через інтернет?

2. Асиметричне шифрування (Розумне, але повільне 🐢):

   • Є два ключі: Публічний (Public) і Приватний (Private).
   • Те, що зашифровано Публічним, можна розшифрувати тільки Приватним.
   • Аналогія: Поштова скринька. Кинути листа у щілину може будь-хто (Публічний доступ), а дістати й прочитати — лише той, у кого є ключ від дверцят (Приватний ключ).

🤝 TLS Handshake (Рукостискання)

Ось де відбувається магія. Коли ви заходите на сайт https://google.com, відбувається "танець" (Handshake):

1. Привіт! Браузер каже: "Я хочу безпечного зв'язку".
2. Ось мій паспорт. Сервер відповідає: "Окей, ось мій Сертифікат (там лежить мій Публічний ключ). Дивись, я справді Google".
3. Перевірка. Браузер перевіряє сертифікат (чи не підроблений?).
4. Секрет. Браузер створює тимчасовий симетричний ключ, шифрує його Публічним ключем сервера і відправляє серверу.
5. Розшифровка. Сервер своїм Приватним ключем розшифровує повідомлення і дістає симетричний ключ.
6. Готово! Тепер у обох є однаковий симетричний ключ. Далі спілкуємося через швидке симетричне шифрування.

Запам’ятати обовʼязково: Асиметричне шифрування використовується лише на початку, щоб безпечно домовитися про спільний ключ. Далі використовується симетричне.

3. 🧪 Приклади: Від теорії до практики

Приклад 1: Що ми бачимо очима?

Зайдіть на будь-який сайт, наприклад wikipedia.org. Що ви очікуєте побачити зліва від адресного рядка?

Правильно, замочок 🔒.

Якщо натиснути на нього, ви побачите напис "Connection is secure" (З'єднання безпечне). Це означає, що ваші дані шифруються, а сертифікат сайту перевірено і він дійсний.

Приклад 2: Що бачить хакер? (Wireshark)

Уявімо, ми перехопили пакет даних.

Без TLS (HTTP):

POST /login HTTP/1.1
Host: example.com
User: admin
Password: super_secret_password

Жах, правда? Все як на долоні.

З TLS (HTTPS):

17 03 03 00 28 c9 3a 4f 1b d0... (набір байтів)

Хакер бачить сміття. Він знає, що ви щось відправили на example.com, але не знає, ЩО саме.

Приклад 3: Перевірка сертифіката через термінал

Ми можемо самі "помацати" це рукостискання. Відкрийте термінал. Що станеться, якщо ми попросимо показати весь ланцюжок з'єднання?

Команда: curl -v https://www.google.com

Результат (спрощено):

*   Trying 142.250.xxx.xxx...
* Connected to www.google.com
* ALPN: offers h2, http/1.1  <-- Домовляються про протокол
* TLSv1.3 (OUT), TLS handshake, Client hello (1): <-- Браузер каже "Привіт"
* TLSv1.3 (IN), TLS handshake, Server hello (2): <-- Сервер відповідає
* Server certificate:
*  subject: CN=www.google.com  <-- Сервер показує "паспорт"
*  SSL certificate verify ok.    <-- Перевірка пройшла успішно
> GET / HTTP/1.1
...

Бачите? Ви тільки що побачили "рукостискання" в реальному часі!

4. 🛠 Практична частина

Час закачати рукави! Спробуйте виконати ці завдання.

Завдання 1: Детектив сертифікатів 🕵️‍♂️ 1. Відкрийте браузер. 2. Зайдіть на сайт вашого банку. 3. Натисніть на замочок -> "Connection is secure" -> "Certificate is valid". 4. Знайдіть поле "Validity Period" (Термін дії). До якої дати дійсний сертифікат? 5. Знайдіть "Issuer" (Хто видав). Це організація, яка ручається за банк.

Завдання 2: "А що, якщо..." (Небезпечний експеримент) ⚠️ Знайдіть в інтернеті сайт, який досі використовує HTTP (наприклад, старі університетські сайти або тестові сторінки, наприклад http://neverssl.com). 1. Зайдіть на нього. 2. Що каже браузер? (Зазвичай пише "Not Secure"). 3. Чому сучасні браузери так агресивно попереджають про це, навіть якщо там немає форми входу?

Завдання 3: Роль CA (Certificate Authority) Уявіть, що ви створили свій сайт і самі виписали собі сертифікат ("Мамой клянусь, я Google"). 1. Це називається Self-signed certificate. 2. Як відреагує браузер користувача, якщо ви встановите такий сертифікат? 3. Чому він покаже червоний екран смерті, хоча шифрування технічно працює? (Підказка: згадайте аналогію з паспортом. Чи повірять вам на кордоні, якщо ви намалюєте паспорт самі собі фломастерами?)

Завдання 4: Міні-кейс Ви розробляєте інтернет-магазин. Ваш замовник каже: "Ой, сертифікати коштують грошей, давай на сторінці оплати буде HTTPS, а на головній і в каталозі товарів — звичайний HTTP, щоб не морочитися". Поясніть замовнику, чому це погана ідея (згадайте про підміну контенту або крадіжку cookies).

5. 💡 Мислення як у розробника

Як думає новачок:

"Я налаштував HTTPS, замочок зелений — значить, мене неможливо зламати".

Як думає досвідчений інженер:

"HTTPS захищає лише трубу (канал передачі). Якщо я передаю вірус по захищеній трубі — він все одно дійде. Якщо у мене пароль '12345' — HTTPS не врятує від підбору".

Типові помилки:

1. Mixed Content: Ви налаштували HTTPS, але картинки на сайті завантажуються через http://. Браузер заблокує їх або прибере зелений замочок.
2. Забув оновити сертифікат: Це класика. Навіть великі корпорації (як Microsoft чи Spotify) іноді забували це зробити, і їхні сервіси падали на кілька годин.
3. Hardcoding: Зберігати приватні ключі в коді на GitHub. Ніколи. Так. Не. Робіть.

Порада з практики:

Раніше сертифікати коштували дорого і їх треба було налаштовувати вручну. Зараз існує Let's Encrypt. Це безкоштовно, автоматизовано і стало стандартом індустрії. Немає жодної причини не мати HTTPS сьогодні.

6. 🧩 Підсумок

Отже, що ми сьогодні розібрали: 1. Інтернет — це небезпечне місце, де всі підслуховують. 2. TLS створює захищений тунель навіть у незахищеній мережі. 3. Ми використовуємо асиметричне шифрування для знайомства і симетричне для довгої розмови. 4. Сертифікат — це паспорт сайту, який гарантує, що ви не віддаєте гроші шахраям.

Тепер ви вмієте: * Розуміти різницю між HTTP та HTTPS. * Перевіряти валідність сертифікатів. * Пояснити, чому "саморобний" сертифікат викликає помилку в браузері.

Тизер наступного уроку: Окей, ми захистили канал зв'язку. Ніхто не вкраде ваш пароль по дорозі. Але... як сервер розуміє, що ви — це саме ви, коли ви переходите зі сторінки на сторінку? Не вводити ж пароль кожен клік? Наступного разу говоримо про Cookies, Sessions та JWT токени.

Це був CS50. До зустрічі! 🚀