Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

Пости з тегом #TLS

23.09.2022

TLS сертифікати, де їх взяти, та проблеми з ними

🌎🔐💸 Продовжуючи тему проблемних вебтехнологій: TLS. Або ж SSL (чи знаєте ви, що TLS - це нова версія SSL, а SSL абсолютно застарілий та ненадійний та давно його ніхто не підтримує?)

Зараз такий час що всі користуються TLS, а все завдяки поширенню чудової ініціативи Let’s Encrypt. Тепер будь-хто може безплатно отримати сертифікат для сайту. Тепер і більшість хостингів безплатно створять його за вас, включаючи й AWS. Це дуже добре, що всі мають доступ до безпечного інтернету.

Де ж проблеми? Проблеми в тому, що не всюди ці сертифікати приймають. Якщо сертифікат вам потрібен для сайту на HTTPS - то, напевно, обійдетесь Let’s Encrypt. (Чи знаєте ви, що HTTPS - це звичайний HTTP, але комунікація відбувається через канал TLS?) Браузери з ними нормально працюють — і браузерів насправді не так багато.

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

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

28.09.2022

SMTP - діалоговий протокол. Шифрування SMTP

✉️📭💬 Продовжуючи серію про дивний протокол SMTP. Який ми всі використовуємо щодня, але ніхто не знає, як він працює.

Як вам така дивина: на відміну від HTTP, SMTP - протокол діалоговий. Тобто для того, щоб відправити одного листа, потрібно обмінятися з отримувачем не однією, а декількома командами. Спочатку HELO, потім MAIL FROM, потім RCPT TO, і нарешті DATA - зміст листа. Перед тим, як слати наступну команду, треба дочекатись відповіді до попередньої. Проблема в тому, що затримка підключення накладається на кожну з команд, тож з повільним звʼязком або на далекий сервер SMTP йде набагато довше, ніж HTTP. Це, до речі, одна з головних причин того, що сьогоденні поштові сервіси як то Mailtrap або SendGrid пропонують відправляти по HTTP API, а не по SMTP.

А ще через цю діалоговість SMTP має дуже дивну форму шифрування. (Бо, звісно, всі листи, як і вебсайти, варто відправляти тільки через зашифрований канал.) Так от, хоч і існує SMTP-аналог до HTTPS, тобто, коли спочатку встановлюється канал TLS, а потім вже через нього SMTP, але такий спосіб непопулярний. Натомість у протоколі SMTP є команда STARTTLS, після якої сервер має припинити комунікацію по відкритому каналу, та почати сеанс TLS на тому самому підключенні. І так роблять практично всі клієнти SMTP. Через STARTTLS всім серверам SMTP доводиться керувати власними TLS-сертифікатами, і не можна цю роботу делегувати балансиру, як це зазвичай трапляється з HTTP.

19.10.2022

Cloudflare for SaaS - генерація сертифікатів для користувацьких доменів

🔒✨🐇 Сьогодні увімкнули ще одну можливість Cloudflare - а саме, генерацію сертифікатів TLS для користувацьких доменів. Це у них загадково називається Cloudflare for SaaS.

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

Як це виглядає для нас: наш сервер має бути підключений через Cloudflare Proxy (як це нормально буває, якщо ви користуєтесь Cloudflare.) Потім, після реєстрації клієнтського домену ми по Cloudflare API додаємо його як Custom Hostname. По HTTP домен працює відразу, а з HTTPS через хвилину.

Як це працює: зрозуміло, що Cloudflare, по-перше, має підтвердити власність домену. Це можна зробити або доданням DNS запису, або відповіддю на HTTP запит за заданим шляхом. Так от, HTTP-випробування за нас пройде Cloudflare Proxy - бо домен клієнта вже направлений на нього через CNAME. До нашого додатка цей запит навіть не доходить. Отакою простою магією без жодних зайвих зусиль користувача він отримує TLS-сертифікат (тобто, сам сертифікат — ні, а підтримку HTTPS - так.) Радію від таких рішень.

Фіча доступна навіть на безплатних планах, а коштує $0.10 на домен на місяць, при чому перші 100 доменів безоплатно. Було б добре придумати якесь цікаве некомерційне застосування.

20.12.2022

Основи TLS - асиметричне шифрування

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

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

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

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

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

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

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

21.12.2022

Основи TLS - ключі та підписи

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

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

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

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

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

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

22.12.2022

Основи TLS - сертифікати та ланцюг довіри

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

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

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

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

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

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

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

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

23.12.2022

Основи TLS - чому необхідно шифрування в інтернеті

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

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

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

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

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

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

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

24.12.2022

Основи TLS - як працює HTTPS

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

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

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

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

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

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

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

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

25.12.2022

Основи TLS - типові помилки протоколу та що вони значать

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

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

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

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

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

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

26.12.2022

Основи TLS - VPN

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

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

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

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

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

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

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

17.10.2024

Перехоплення запитів в інтернеті третьою стороною

Сьогодні натрапив на цікавий випадок: в одного хостингу SMTP не заблокований зовсім, а перехоплюється їхнім внутрішнім сервісом; хочеш свій — доплачуй. Вихід з такої ситуації простий: використовувати натомість Email API.

Але це мене надихнуло написати про те, що, взагалі кажучи, кожна наша взаємодія з інтернетом може бути перехоплена по дорозі. В першу чергу це цікаво робити нашому провайдеру чи хостингу, але також, наприклад, державним установам.