Модуль 16

HTTPS та SSL/TLS сертифікати

Ось урок, створений у дусі CS50 та стилі Девіда Малана: енергійно, з живими аналогіями та фокусом на розуміння суті.


🎓 CS50: HTTPS та SSL/TLS сертифікати

(Або: Чому ми не пишемо паролі на поштових листівках)


1. 🔥 Вступ: проблема та мотивація

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

Уявіть ситуацію. Ви сидите в улюбленій кав’ярні, підключилися до публічного Wi-Fi й вирішили купити квитки на концерт. Ви вводите номер своєї кредитної картки, натискаєте "Оплатити" і...

Стоп! 🛑

Чи замислювалися ви, як саме ці цифри летять повітрям від вашого ноутбука до роутера кав'ярні, а потім через інтернет до банку?

Якщо ви використовуєте старий протокол HTTP, то ваші дані летять у вигляді поштової листівки. Будь-хто, хто сидить за сусіднім столиком і запустив програму-сканер (сніфер), може "перехопити" цю листівку і прочитати: "Номер картки: 1234...". Ніякого конверта, ніякого захисту. Прозорий текст.

Питання до вас: Ви б відправили пароль від свого банківського акаунту на поштовій листівці, яку по дорозі читає кожен поштар? Звісно, ні.

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

Без HTTPS сучасний інтернет перетворився б на хаос крадіжок особистих даних. Сьогодні ми розберемося, як працює ця магія.


2. 🧠 Теоретична база (без сухої академічності)

Давайте заглянемо під капот.

Що таке HTTPS?

Це HyperText Transfer Protocol Secure. По суті, це звичайний HTTP, який "загорнули" в захисну оболонку — SSL/TLS.

💡 Довідка: SSL (Secure Sockets Layer) — це старіша назва. Зараз ми використовуємо новішу версію — TLS (Transport Layer Security). Але за звичкою всі кажуть "SSL-сертифікат".

Як це працює? (Аналогія з валізою)

Щоб зрозуміти шифрування, уявіть два типи ключів:

  1. Симетричне шифрування (Швидке): У вас і у сервера є однакові ключі від однієї валізи. Ви закрили — сервер відкрив.

    • Проблема: Як безпечно передати ключ серверу через небезпечний інтернет? Якщо хакер перехопить ключ — все пропало.
  2. Асиметричне шифрування (Публічний та Приватний ключі):

    • У сервера є Публічний ключ (роздає всім) і Приватний ключ (тримає в таємниці).
    • Магія: Те, що зашифровано Публічним ключем, можна розшифрувати ТІЛЬКИ Приватним.

Процес "Рукостискання" (TLS Handshake) — крок за кроком:

Коли ви заходите на google.com, відбувається діалог за мілісекунди:

  1. Клієнт (Ви): "Привіт! Я хочу захищене з'єднання."
  2. Сервер (Google): "Привіт! Ось мій Паспорт (Сертифікат) і мій Публічний ключ."
  3. Клієнт: Перевіряє паспорт. "Хм, паспорт виданий перевіреною організацією? Не прострочений? Ок, вірю."
  4. Клієнт: Створює тимчасовий "сесійний ключ" (швидкий), шифрує його Публічним ключем сервера і відправляє.
  5. Сервер: Отримує повідомлення, розшифровує його своїм Приватним ключем і дістає "сесійний ключ".

💥 Бум! Тепер у вас обох є однаковий секретний ключ. Далі спілкування йде через швидке (симетричне) шифрування.

Що запам’ятати:

  • HTTPS захищає дані від прослуховування.
  • Сертифікат підтверджує, що сайт — це дійсно той, за кого себе видає (що ви на apple.com, а не на aple-fake.com).
  • Замочок у браузері означає, що перевірка пройшла успішно.

3. 🧪 Приклади (від простого до реального)

Приклад 1: Браузерна магія

Як користувач, ви бачите лише замочок 🔒.

  • Очікування: Якщо натиснути на замок, що ми побачимо?
  • Реальність: Браузер покаже: "Connection is secure" (З'єднання безпечне), "Certificate is valid" (Сертифікат дійсний). Там буде написано, хто видав сертифікат (наприклад, Let's Encrypt або DigiCert).

Приклад 2: Налаштування сервера (Nginx)

Уявіть, що ви системний адміністратор. Ось як виглядає конфігурація звичайного сайту на HTTP (порт 80):

server {
    listen 80;
    server_name mysite.com;
    # ... інший код
}

А ось так виглядає HTTPS (порт 443). Зверніть увагу на шляхи до ключів:

server {
    listen 443 ssl; # Слухаємо захищений порт
    server_name mysite.com;

    # Шлях до Публічного ключа (Паспорта)
    ssl_certificate /etc/letsencrypt/live/mysite.com/fullchain.pem;

    # Шлях до Приватного ключа (Секрет!)
    ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;

    # ... інший код
}

Чому так? Сервер повинен знати, де лежить його "посвідчення особи" (certificate) і "секретний підпис" (key), щоб довести браузеру, що він справжній.


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

Час попрацювати руками! Відкрийте браузер (Chrome/Safari/Edge).

Завдання 1: Інспектор 🕵️‍♂️

  1. Зайдіть на сайт вашого банку або google.com.
  2. Натисніть на 🔒 ліворуч від адреси.
  3. Натисніть "Connection is secure" -> "Certificate is valid".
  4. Знайдіть:
  5. Дата закінчення дії (Expires on).
  6. Хто видав сертифікат (Issuer).

Завдання 2: "Небезпечний" світ ⚠️

Спробуйте знайти сайт, який використовує старий HTTP (зараз це складно, бо браузери їх блокують або попереджають). * Спробуйте зайти на http://neverssl.com (це безпечний сайт, створений спеціально, щоб бути БЕЗ шифрування). * Подивіться, як браузер позначає його ("Not Secure"). Що це означає для ваших даних?

Завдання 3: Аналіз конфігу 📝

У коді нижче допущено критичну помилку, через яку HTTPS не запрацює. Знайдіть її.

server {
    listen 443 ssl;
    server_name my-shop.com;

    ssl_certificate /etc/ssl/public.pem;
    # (Тут був рядок, який адмін забув дописати)
}

(Підказка: Ми показали паспорт, але чим ми доведемо, що він наш? Чого не вистачає?)

Завдання 4: Міні-кейс 🤔

Ви розробляєте сайт. Ви купили сертифікат, налаштували його. Сайт відкривається через https://. Але картинки на сайті не вантажаться, а браузер пише "Mixed Content Error". * Чому? (Ви намагаєтеся завантажити картинку через http:// на захищеному https:// сайті). * Як виправити? (Змінити посилання картинок на https).


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

Як думають профі, коли працюють з SSL?

  1. "HTTPS — це стандарт, а не розкіш". Раніше сертифікати коштували дорого. Зараз існує Let's Encrypt — безкоштовний центр сертифікації. Немає жодної причини робити сайт на HTTP. Навіть якщо це блог про котиків. Google песимізує (опускає в пошуку) сайти без HTTPS.

  2. "Автоматизуй це". Сертифікати мають термін дії (наприклад, 90 днів).

    • Помилка новачка: Забути оновити сертифікат. Сайт "падає", клієнти бачать страшне попередження "DANGER".
    • Дії профі: Використати Certbot. Це програма, яка сама раз на місяць стукає до центру сертифікації, оновлює ключі та перезавантажує сервер.
  3. "Self-signed (самопідписані) сертифікати — тільки для тестів". Ви можете самі згенерувати сертифікат на своєму комп'ютері. Але браузери інших людей йому не повірять (червоний екран), бо вони не знають "хто ви такий". Це як намалювати паспорт фломастерами. Працює тільки вдома для розробки (localhost).


6. 🧩 Підсумок

Отже, що ми сьогодні розібрали:

  • HTTP — це прозорий тунель (всі все бачать).
  • HTTPS — це броньований тунель (дані зашифровані).
  • SSL/TLS — технологія шифрування, що працює на основі пари ключів (публічний/приватний).
  • Сертифікат — це цифровий паспорт сайту.

Тепер ви вмієте: ✅ Розуміти різницю між безпечним і небезпечним з'єднанням. ✅ Перевіряти дійсність сертифікатів у браузері. ✅ Розуміти, з яких компонентів складається захист на сервері (ключ + сертифікат).


👀 Тизер наступного уроку: Ок, ми захистили канал зв'язку. Хакери не бачать наш пароль. Але... як сервер розуміє, що я — це я, коли я вже ввів пароль і перейшов на іншу сторінку? Не вводити ж пароль при кожному кліку? Наступного разу ми поговоримо про Аутентифікацію, Cookies та Сесії.

Це був CS50. Побачимось! 👋