#TLS

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

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

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

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

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

✉️📭💬 Продовжуючи серію про дивний протокол 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.

🔒✨🐇 Сьогодні увімкнули ще одну можливість 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 доменів безоплатно. Було б добре придумати якесь цікаве некомерційне застосування.

Сьогодні хочу розпочати серію постів про роботу 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.

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

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

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

• DNS перехоплюється дуже широко, з метою або додати власні ресурси, або заблокувати чужі. Та навіть мій домашній роутер перехоплює запити DNS, щоб блокувати рекламу — до якого б серверу не звертався пристрій, він все одно потрапить на DNS роутера. Щоб уникнути перехоплень, потроху приживається DNS поверх TLS.

• TLS взагалі є універсальним захистом від перехоплень. Але потребує додаткових дій, зокрема отримання сертифіката для сервера. Та, звісно, взаємодомовленості про підтримку, бо одна з класичних помилок — це “невірна версія TLS”, яка насправді свідчить, що друга сторона надіслала запит відкритим текстом.

• До речі, SMTP теж є поверх TLS, зазвичай за окремим портом - 465. Якщо хостинг перехоплює SMTP поверх TLS, то ми отримаємо помилку “розбіжність імені хоста”, бо перехопити легко, а вдати з себе вірний сервер — технічно неможливо. Про то в мене вже є ціла серія постів.

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

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

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

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

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

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

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

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

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

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

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

Минулий раз про Let’s Encrypt я писав три роки тому. Відтоді трохи ще довелося попрацювати з сертифікатами, тому розуміння додалося.

Цікаво, що разом з сервісом Let’s Encrypt - який, нагадаю, роздає сертифікати TLS для сайтів — зʼявився й протокол автоматизованої видачі сертифікатів ACME. Річ у тім, що сертифікати хороші, якщо термін придатності їх обмежений, а коли так, їх потрібно оновлювати… чого вручну ніхто раз на 1-3 місяці робити не буде. Зате якщо зробити автоматичний сервіс, то можна зробити щастя.

Це й була революція, яка дозволила всім, аж до домашніх сторінок переїхати на HTTPS. Наразі Let’s Encrypt видає понад 50% сертифікатів в інтернеті! Але чи знаєш ти, що практично всі інші провайдери також впровадили підтримку ACME, причому часто — теж безплатну? Є, наприклад, Google Trust Services. А взагалі ось список.

Тому зараз отримати сертифікат — це прямо дуже легко. Та для цього навіть не потрібно встановлювати certbot чи шукати інший клієнт ACME, бо можна цю підтримку додати прямо у свій код. Для підтвердження сертифіката достатньо правильно відповісти на спеціальний URL на обраному домені, тобто це повністю під силу будь-якому вебзастосунку. (Є ще підтвердження за DNS, його складніше зробити технічно, зате легше підтримувати, бо на кожне наступне оновлення буде однакова перевірка.)

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