#ОсновиІнтернетБезпеки

Сьогодні хочу розпочати серію постів про роботу TLS та HTTPS. Нехай то буде моїм “простим розʼясненням теорії категорій”. Мені доводилося багато стикатися з TLS, колись навіть робив MITM Proxy для підміни сертифікатів, та — уявіть собі! - для порядного клієнта з гарними намірами.

Щоб зрозуміти TLS, спочатку треба розуміти асиметричне шифрування.

Шифрування — то, сподіваюсь, широко відоме поняття. Але ми звикли до того, що для розшифрування потрібен пароль (ключ), та шпигуни ганяються за паролем чи там кодовим диском, щоб розкрити таємницю.

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

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

Вся система довіри сучасного інтернету будується на цієї властивості.

Зазначу, що все шифрування на компʼютері працює з числами, бо будь-яка інформація зберігається у вигляді цифр, на то й цифрові технології. До того ж ніяких складних операцій там немає — тільки арифметика та бітова логіка, бо шифрування має працювати дуже швидко, на обсязі в гігабайти даних. Асиметричний алгоритм RSA складається з досить зрозумілої та цікавої арифметики простих чисел, я навіть колись робив його реалізацію. В чому ж тоді його безпечність? Прості числа, які використовуються як ключі в справжньому шифруванні, дуже великі, довжиною близько 600 цифр. Чим більше ключ — тим складніше підібрати до нього пару. На цей час компʼютери на це не спроможні. Настане день, коли це стане технічно можливим — тоді ми зробимо ключі ще довшими.

Отже, вчора розібралися з тим, що таке асиметрична криптографія та яке значення вона має для довіри в інтернеті. Тепер про ключі та підписи.

Про ключі я вже трохи говорив. Додам, що, на відміну від паролів, які можуть бути випадковими, ключі для асиметричного шифрування повʼязані математичною залежністю, тому ніхто їх ніколи не вигадує, а натомість генерує, наприклад, командою ssh-keygen.

Цікаво, що з одного боку, ключі уможливлюють автентифікацію: якщо я передам тобі свій публічний ключ, то потім ти можеш перевірити, що я — це я, тримач приватного ключа. Але з іншого — не містять визначної інформації: тобто хто я такий, по ключу зрозуміти не можна. Для цього нам потрібні сертифікати, та щоб дістатись до сертифікатів, треба спочатку зрозуміти підписи.

Що ж таке цифровий підпис? Насправді він робиться дуже просто — беремо документ для підпису, та шифруємо його приватним ключем. Це і є підпис. Тепер передаємо підпис отримувачу разом з оригінальним документом. Отримувач документа може розшифрувати підпис публічним ключем, порівняти з оригінальним документом, та зробити висновок про його дійсність.

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

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

На цей час в уважного читача має виникнути питання — а як публічні ключі розповсюджуються? Та де взяти той самий публічний ключ, що відповідає серверу чи особі, та підтвердить їх автентичність?

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

Відповідь контрінтуїтивна: публічний ключ нам передає його власник. Наприклад, у випадку підпису документа, публічний ключ прикладається до нього так само як і підпис. А у випадку вебсерверів, то сервер пришле нам свій ключ на початку сеансу. Оце так! Ми ж йому ще не довіряємо?

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

Криптографічний сертифікат — то документ, що містить публічний ключ та додаткову інформацію — таку, як імʼя особи або сервера, контактні дані, та інше. Але головне, що будь-який сертифікат має підпис, наданий іншим сертифікатом. Найчастіше цей сертифікат належить центру сертифікації. А далі — як можна здогадатись — сертифікат цього центру також має підпис… Така послідовність підписів називається ланцюгом довіри. Закінчується ланцюг кореневим сертифікатом, який підписаний сам собою.

Кореневому сертифікату ми довіряємо тому, що він у нас є заздалегідь. Якщо на macOS відкрити програму Keychain Access, то ми зможемо побачити перелік кореневих сертифікатів. Кожного разу, коли ваша система перевіряє підпис, вона завжди проходить по ланцюгу довіри, поки не знайде відомий їй кореневий сертифікат.

У “Дії”, до речі, свій набір кореневих сертифікатів, а точніше, він належить державі Україні. Власне, для будь-якої потреби можна визначити кореневі сертифікати, яким ви довірятимете.

Якщо цікаво пороздивлятися сертифікати, раджу програму Keystore Explorer.

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

Сучасні комп’ютери та смартфони вдало приховують той факт, що між нами та нашими співбесідниками, соціальними мережами, відео, банками та новинами стоїть мережа серверів розміром з цілий світ — Інтернет.

Легко помітити, що у твого компʼютера немає прямого дроту, що веде, наприклад, на сервер Телеграму. Замість того компʼютер звернеться до роутера, той — до провайдера, провайдер — на магістральний вузол, і так далі до дата-центрів Телеграму і до конкретної машини, що обробить запит. Все, що ми відправляємо чи отримуємо з Інтернету, проходить через десятки вузлів.

І друге, про що варто подумати — у цифрових даних немає ніякого вбудованого механізму приховування. Сама по собі передача даних відбувається у повністю відкритому вигляді. Всі наші дані може прочитати будь-хто з доступом до одного з цих вузлів. Та й більше того - проміжні сервери постійно читають їх та передають далі. А ось чи зберігають вони нашу інформацію - ми не маємо можливості дізнатись.

Отже, коли ти переписуєшся з кимось в Телеграмі, то це зовсім не приватна розмова. Навпаки — ваші повідомлення передаються з уст в уста через весь світ! До деякого моменту інтернет тримався на засадах довіри. Це не дивно для мережі, що виросла з університетських лабораторій. Все ж таки мережеві оператори — люди серйозні, та підглядати не будуть… то й можна їм довіряти. Зараз це так дико звучить, але ж не так давно ще ніхто не переймався.

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

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

Отже, ми зʼясували потребу шифрувати обмін даними в інтернеті. Розглянемо, як це працює, на прикладі HTTPS - шифрованого протоколу перегляду вебсайтів.

Архітектура інтернету така, що кожний протокол розв’язує задачі конкретного рівня абстракції, та спирається на інші протоколи для більш базових потреб. HTTP займається вебсторінками. Для того, щоб відправити запит HTTP та отримати назад сторінку, необхідна наявність сталого каналу комунікації. Тож HTTP побудований на базі протоколу TCP, який і створює такий канал між клієнтом та сервером. (Без зайвих деталей скажу, що існують і інші режими комунікації, залежно від потреб.)

Чого протокол TCP не дає, так це жодних гарантій безпеки. Дані пересилаються у відкритому вигляді; крім того, автентичність сервера не перевіряється.

Для надання цих двох гарантій існує протокол TLS. Він ніби “апгрейдить” підключення TCP - функціонально це той самий сталий канал, але тепер вже зашифрований. Так от, HTTPS - це абсолютно той же самий HTTP - єдина різниця в тому, що запити проходять по зашифрованому каналу TLS. Та це гарний приклад: так само працюють й інші протоколи, якім потрібне шифрування, наприклад, SMTP, про який я вже писав.

Щоб зробити з підключення TCP підключення TLS, потрібна процедура рукостискання. Перше, що присилає сервер клієнту після підʼєднання — це свій сертифікат. Клієнт аутентифікує сертифікат за допомогою своїх кореневих сертифікатів, як я писав раніше. Головне, що у сертифікаті сервера зазначено його доменне імʼя, та воно обовʼязково має збігатися з тим, куди відбувається підключення.

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

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

Отак, в дуже загальних термінах, воно все і працює. Наступного разу поговоримо про поширені проблеми та ризики цієї системи, з якими ми всі час від часу стикаємося.

Напевно, всі ми більше за все стикаємся з TLS, коли він не працює. Розʼяснимо найчастіші випадки, коли це трапляється.

Найпоширеніша проблема - у сертифіката сервера сплив термін дії. Так, у всіх сертифікатів в принципі є термін дії. Чому? Головна причина в тому, що зі зростанням обчислювальної можливості безпека потребує довших ключів, тож старі сертифікати рано чи пізно стають небезпечними. Щоб уникнути цього, та інших можливих вразливостей, сертифікати необхідно примусово оновлювати, зазвичай раз на рік. 😅 Якщо адміністратор цього не зробить - клієнти побачать помилку “сплив термін дії сертифікату”. 👹 АБО зловмисник підібрав ключа до старого сертифікату, чи просто його вкрав.

Далі - трапляється що імʼя домену в сертифікаті не співпадає з адресою сервера. 😅 Це зазвичай проблема налаштувань DNS, а не сертифікату; а саме, домен спрямований на неправильний або не налаштований сервер. Так може статись на “спильному” хостингу, такому як Heroku, якщо не повідомити сервісу, що у вас є власний домен. Або сайт переїхав на інший домен, а сертифікат не поміняли. Або на сервері декілька доменів, та для деяких забули купити сертифікат. 👹 АБО хтось видає свій сервер за інший, може, з дуже схожим імʼям.

Інколи клієнт не може перевірити сертифікат, тому що в системі не вистачає кореневих сертифікатів. З сучасним та оновленим компʼютером чи телефоном такого ніколи не трапиться. 😅 Але на сервері трапляється, особливо в докері (де часто за замовчування ніякі сертифікати не встановлені), або зі старою версією ОС. Кращим рішенням буде встановити або оновити сертифікати. Гіршим - відключити аутентифікацію HTTPS, що вдасться зробити тільки з власним кодом. 👹 Ніколи не можна встановлювати додаткові кореневі сертифікати від особ, яким не довіряєш абсолютно - бо ця особа отримає можливість фальсифікувати для вашої системи будь-який сертифікат.

Якщо вже заговорили про відключення автентифікації - то є ще сценарій, коли беруть “власноруч підписаний” сертифікат. Такий сертифікат неможливо аутентифікувати, в принципі - тільки приняти на віру. Але навіть такий сертифікат дозволить шифрувати сесію. Та його можно згенерувати на своїй машині та безплатно. Тому часто такі сертифікати вживають у внутрішніх мережах. Але я б радив натомість брати mkcert.

Коли побачите Помилку протоколу TLS або Несумісну версію TLS, то (з мого досвіду) це не буде викликано справжніми багами клієнта чи сервера. Скоріш за все, така помилка викликана тим, що сервер віддав HTTP замість HTTPS, а клієнт намагається трактувати документ HTTP як рукостискання TLS. 😅 Може, адміністратор переплутав порти, чи не увімкнув HTTPS. 👹 Але ще це улюблений метод третіх особ блокувати доступ. Наприклад, провайдера, якщо ти не заплатив за інтернет. Або деяка система безпеки заблокувала сайт. Оскільки ніхто не може підмінити HTTPS (та й добре!), то замість нього такі добродії дають браузеру сторінку HTTP. Щоб перевірити, треба замість https://mysite.com написати http://mysite.com:443 - це може показати справжню сторінку блокування.

Хочу закінчити серію постів про шифрування розповіддю про VPN, бо це типу теж шифрування, тож, наприклад, чи можна вважати, що якщо ти увімкнеш VPN, то вже не потрібно турбуватись про HTTPS? (Забігаючи наперед — НІ!)

VPN перпендикулярна технологія до TLS/HTTPS. Це категорія протоколів, що створюють безпечний канал між двома вузлами в Інтернеті. Але! Безпека VPN простягається тільки від твого компʼютера до сервісу VPN.

Бо насправді VPN - засіб для віддаленого підключення до приватної мережі. Наприклад, корпоративної. При цьому віддалений компʼютер потрапляє нібито всередину мережі. Ми на роботі користуємося внутрішнім VPN для обмеження доступу до ресурсів — дуже зручно, коли команда розповсюджена бозна-де.

🦺 Проте зараз VPN в першу чергу знають як засіб безпеки. Від чого VPN дійсно врятує: від хакерів на відкритому Wi-Fi; від регіональних блокувань; від стеження з боку провайдера.

⛵ Далі, треба розуміти, що кінець шляху від сервісу VPN до сайтів підключення проходить через звичайний, відкритий Інтернет. Тому ігнорувати помилки HTTPS так само небезпечно.

🏴‍☠️ І головне, що абсолютно всі твої дані проходитимуть через сам сервіс VPN, тож у його власників є ідеальна можливість стежити за тобою та подекуди красти дані. Тому дуже важливо обрати такий сервіс, якому можна довіряти, особливо застерігаю проти безплатних.

Щодо надійних сервісів, я можу порадити Private Internet Access.

Майже 10 років тому я написав пост про те, як легко впровадити OAuth2 без жодних бібліотек: OAuth2 is easy. Сьогодні — трохи продовження.

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

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

Проблемою OAuth2 було те, що він був настільки простим, що кожний провайдер робив щось своє (про що я згадую у статті.) Тому писати загальну авторизацію було складно чи навіть неможливо. Зараз з цим стало краще, бо є протокол OpenID Connect, який стандартизує поведінку провайдерів. (Та OpenID Connect нічого спільного не має з тим OpenID, який я колись тримав на своєму сервері з phpMyID)

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

🔐 Я в цьому каналі багато писав про безпеку, та конкретно в цьому пості — про ланцюг довіри. Але за що той ланцюг закріплений? Це фундаментальне питання безпеки. Якорем ланцюга є корінь авторитету — набір сертифікатів, якому ми довіряємо як аксіомі.

З одного боку, вкрай необхідно, щоб в наш корінь авторитету не потрапили зловмисні сертифікати. Причому на них не буде написано, що вони зловмисницькі! За означенням в нас немає можливості перевірити, чи є кореневий сертифікат “чесним” - тому вони повинні братися з надійного джерела.

З іншого, у світі кілька десятків агенцій, яким довірено видавати сертифікати, а також їхні кореневі сертифікати час від часу оновлюються. Отже, важливо, щоб корінь авторитету був повним та свіжим, інакше ми не будемо довіряти новим сертифікатам — це дуже реальна проблема старих систем.

Але не таких вже й старих! От я дізнався, що в стабільному Debian Bookworm корінь, який міститься в пакеті ca-certificates, від березня 2023!

В мене відразу зʼявилося питання — як же ж з ним люди в інтернет ходять? Виявилося, що як Chrome, так і Firefox використовують власні корені авторитету, а не системні. Тому проблеми через системні сертифікати відразу меншають — а для простих користувачів, певно, взагалі зникають.

Якщо копнути далі, то існує проєкт CCADB, в якому головні інтернет-оператори тримають каталог кореневих сертифікатів відповідно до суворих (та головне, задокументованих) вимог. Сертифікати цього проєкту можна завантажити та використати замість застарілих. Звісно, стає питання довіри, але якщо ще копнути, то той же ж пакет ca-certificates бере дані саме з бази Mozilla, так що на чомусь ця глобальна порука повинна замикатися.

Що найгірше може статися, якщо хтось підсуне вам власний кореневий сертифікат? Все залежить від того, хто саме.

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

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

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

Це поширена практика для внутрішніх ресурсів, не доступних для публіки, бо для них технічно неможливо отримати підписаний сертифікат, але мати TLS все ж хочеться.