Криптографія і транспорт для QA

Чим хешування відрізняється від шифрування й кодування?

Сильна відповідь дає критерій, а не приклади: три операції розводять наявність ключа й можливість повернути дані назад. Хеш-функція ключа не бере й задумана однобічною — з дайджесту (digest) фіксованої довжини вхід відтворити має бути непрактично; звідси її ролі: підписи, MAC, зберігання паролів. Шифрування без ключа не існує, і зворотний шлях у ньому передбачений задумом: у симетричній схемі ключ той самий на обидві операції, в асиметричній — пара, де публічну половину можна роздавати, а приватну тримає лише власник. Кодування на кшталт Base64 не має ні ключа, ні секрету взагалі: це спосіб протягнути двійкові дані каналом, що приймає тільки ASCII, і розгорнути його може будь-хто. Практичний наслідок для тестувальника: фраза «дані зашифровані» без відповіді на питання «яким ключем і хто ним володіє» не гарантує нічого.

У відповіді API прилетів нечитабельний рядок. Як зрозуміти, шифр це чи кодування?

Перевірка займає кілька секунд і не потребує ні доступу до коду, ні знання криптографії: відкрийте консоль браузера й згодуйте рядок atob(). Якщо на виході зʼявився осмислений текст, ключа тут не було — отже, це кодування, а слово «зашифровано» в описі фічі помилкове. Непрямі ознаки Base64 видно ще до перевірки: алфавіт обмежений латиницею, цифрами, +, / і хвостовими =, а сам рядок приблизно на третину довший за вихідні дані; у URL-safe варіанті замість + і / стоятимуть - та _, а доповнення може бути відкинуте. Формулювання для тікета звучить так: дані передаються у відкритому вигляді, просто в іншому поданні. Це повноцінна знахідка, якщо йдеться про персональні дані, токен або внутрішній ідентифікатор.

Які властивості роблять хеш криптографічним і які алгоритми вже не можна брати?

Не будь-яка функція, що дає «рядок фіксованої довжини», годиться для безпеки. Криптографічний хеш має чотири властивості одночасно: рахуватися швидко, не піддаватися оберненню, змінювати вихід до невпізнання від найдрібнішої правки входу й не давати колізій — двох різних входів з одним дайджестом. Робоча родина сьогодні — SHA-2, де число в назві означає довжину дайджесту в бітах. SHA-1 із безпечних вибув, MD5 названо небезпечним. Практична деталь, на якій ловлять: браузерний SubtleCrypto.digest() спокійно порахує SHA-1 — API попереджає, але не забороняє, тож «у нас працює» тут не аргумент. І ще одна межа: сам по собі хеш авторства не доводить, для цього потрібен код автентифікації повідомлення (message authentication code, MAC) — окремий виклик SubtleCrypto.sign().

Що саме мають на увазі, коли кажуть «MD5 зламано»?

Дайджест-функції тримають три різні стійкості — до колізій, до прообразу й до другого прообразу, — і падають вони не разом. У MD5 упали колізії, причому не теоретично: пару різних входів з однаковим хешем знаходять приблизно за хвилину на звичайному ноутбуці, за іншим результатом — за секунди, і цей трюк уже застосовували до сертифікатів X.509. Стійкість до прообразу при цьому нікуди не поділася: RFC 6151 оцінює складність у 2^123.4 і називає її досі доволі високою. Тому відповідь «з MD5-хеша дістануть вихідний пароль» читається як нерозуміння: зламали здатність підібрати пару входів, а не здатність розгорнути хеш назад. Це питання-фільтр саме на точність формулювань, і бонусні бали дістає той, хто одразу проводить межу застосування.

У проєкті знайшли MD5. Це завжди дефект?

Ні, і саме тут відрізняють інженера від людини, яка читала заголовки новин. Якщо контрольна сума потрібна протоколу винятково для того, щоб зловити випадкове псування даних, MD5 у цій ролі лишається допустимою — RFC 6151 це прямо визнає. Якщо ж від хешу очікують стійкості до навмисно підібраної колізії — підпис, сертифікат, перевірка цілісності проти зловмисника, — це знахідка. Хеш файлу зі збірки я тікетом не оформлю; MD5 в алгоритмі підпису сертифіката оформлю негайно. Заміни джерело називає поіменно: HMAC-SHA256 або AES-CMAC. Окремий нюанс для точності: сам HMAC-MD5 практично вразливим не оголошували, тож із наявних протоколів його не виривають, але тягнути в нову схему не можна. І найкорисніше питання до архітектора: які саме властивості безпеки ви очікуєте від цього MD5 — воно змушує назвати вимогу вголос.

Як правильно зберігати паролі й навіщо потрібна сіль?

Стартова умова однозначна: оборотне шифрування для паролів виключене — хто дістав ключ, той дістав усю базу; потрібна спеціалізована функція хешування паролів. Друга умова — сіль (salt): випадкові байти, які приклеюються до пароля до обчислення, тож у базу лягає дайджест від пари, а не від самого пароля. Роль у солі вузька й конкретна — вона знищує сенс наперед порахованих таблиць, зокрема райдужних, бо словник під кожну можливу сіль побудувати неможливо. Сіль має бути своя на кожен обліковий запис: рекомендують 16 байтів, 128 бітів вистачає для всіх застосувань, і лише за жорсткої економії місця беруть 64. Річ, яку постійно перевертають: сіль не є секретом і спокійно лежить у тому самому рядку бази поруч із солоним хешем — ховають ключі, а не сіль. Третя умова — фактор роботи: алгоритм має бути навмисно повільним і налаштовуваним.

Що таке memory-hard функція і який варіант Argon2 брати?

Класичний повільний хеш змушує атакувальника платити процесорним часом, а memory-hard — ще й памʼяттю, і саме це ламає економіку перебору на відеокартах та спеціалізованому залізі. Argon2 цілиться в максимальну швидкість заповнення памʼяті й одночасно закриває компроміс «час проти памʼяті»: докласти обчислювальних блоків, щоб памʼяті знадобилося менше, не вийде. Варіантів три. Argon2d ходить по памʼяті залежно від самих даних; Argon2i — незалежно, через що краще підходить паролям; Argon2id склеює обидва — першу половину першого проходу поводиться як Argon2i, далі як Argon2d. Нормативно реалізація зобовʼязана вміти Argon2id, а правило вибору сформульоване просто: не бачите різниці або вважаєте атаки по сторонніх каналах реальною загрозою — беріть Argon2id.

Які параметри Argon2 налаштовують і які числа називають джерела?

Важелів три: p — скільки потоків рахують паралельно, m — скільки кібібайтів памʼяті займе обчислення (не менше ніж 8*p), t — кількість проходів, якою час тягнуть угору окремо від памʼяті. Підбирають їх емпірично: беруть найбільше t, за якого відповідь ще вкладається в бюджет автентифікації. Далі починається місце, де кандидати гублять точність, бо канонічні числа різні. RFC 9106 першою рекомендацією дає Argon2id з t=1, p=4, m=2^21 — це 2 GiB памʼяті, — 128-бітною сіллю й 256-бітним тегом, а другою, для середовищ із дефіцитом памʼяті, — t=3, p=4, m=2^16 (64 MiB). Шпаргалка OWASP Password Storage вимагає іншого: щонайменше 19 MiB, дві ітерації й один ступінь паралелізму. Різниця на порядок не є суперечністю: RFC описує рівномірно безпечний дефолт під власне залізо, шпаргалка фіксує нижню планку прийнятного. Правильна відповідь називає обидва набори з атрибуцією, а не зводить їх в одне число.

Що QA перевірить у зберіганні паролів, не маючи доступу до криптографічного коду?

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

Які версії TLS сьогодні прийнятні і на якій підставі старі заборонили?

Дефолтом ставлять TLS 1.3, TLS 1.2 лишають лише заради сумісності, усе нижче вимкнене. Важливо, що це не «воно старе»: кожну заборону ухвалював окремий документ із названою причиною. RFC 8996 закриває TLS 1.0 і 1.1 — цілісність рукостискання й підписи автентифікації там тримаються на SHA-1, вартість атаки зниження (downgrade attack) оцінена в 2^77 операцій, що нижче за прийнятний сучасний запас, а вибрати сильніший хеш усередині цих версій неможливо, тож єдиний шлях — перейти на новішу; до TLS 1.2 не було ще й AEAD. RFC 7568 закриває SSL 3.0 через недетерміноване доповнення в конструкції CBC, яке дозволяє відновити відкритий текст, а єдиний поширений потоковий шифр там — RC4 із серйозними зміщеннями. RFC 6176 закриває SSL 2.0, де повідомлення рукостискання не захищені взагалі, тож посередник спокійно змушує сторони вибрати слабший набір. Якщо древній клієнт справді потрібен бізнесу, його виносять на окремий ендпоінт без чутливих даних, а основний не послаблюють.

Крім версії протоколу, що ще ви перевірите в транспорті?

Набір шифрів (cipher suite) — на одній і тій самій версії можна домовитися про дуже різний рівень захисту. Вмикають автентифіковані режими: у TLS 1.3 це стандартні AEAD-набори з AES-GCM або ChaCha20-Poly1305, у TLS 1.2 — теж AEAD і без CBC, з пріоритетом GCM та CCM; вони додають цілісність і автентичність поверх конфіденційності. На вимкнення джерело дає закритий перелік: TLS_*_anon_* (сервер узагалі не автентифікується), TLS_*_EXPORT_* (спадок навмисно ослабленої криптографії), null-шифри (шифрування немає як такого), а також TLS_RSA_*, TLS_DH_* і TLS_ECDH_* — ці три через відсутність прямої секретності (perfect forward secrecy). Дві заборони діють незалежно від версії й від будь-яких аргументів: RC4 і все, чия стійкість нижча за 112 бітів, не пропонують і не узгоджують. Окремо гасять стиснення TLS — через CRIME воно дозволяє відновити чутливу інформацію, включно з сесійними cookie. Перевіряють це інструментом, а не оком: SSL Labs онлайн або testssl.sh локально, і будь-який заборонений набір у виводі є знахідкою. Типова регресія приходить під приводом «підняли сумісність зі старим клієнтом».

У дампі ServerHello стоїть версія 1.2, а адміністратор клянеться, що це TLS 1.3. Хто помиляється?

Ніхто. У TLS 1.3 узгодження версії винесене з того поля, куди звикли дивитися: клієнт перелічує підтримувані версії в розширенні supported_versions, а сервер зобовʼязаний записати в ServerHello.legacy_version значення 0x0303, тобто «1.2». Механізм узгодження з TLS 1.2 при цьому оголошено застарілим: за наявності розширення сервер не має права брати версію з ClientHello.legacy_version і зобовʼязаний користуватися тільки supported_versions. Тому висновок «у нас TLS 1.2» з дампа робити не можна — дивитися треба саме на розширення, а не на legacy-поле. На практиці простіше не сперечатися над байтами, а прогнати testssl.sh чи Server Test і взяти узгоджену версію з їхнього звіту. Питання типове й перевіряє одну річ: людина розуміє формат чи впізнає числа.

Що таке атака зниження версії і як від неї захищається TLS 1.3?

Ідея атаки в тому, щоб посередник підмінив або обрізав список можливостей і змусив дві цілком сучасні сторони домовитися про старіший, слабший варіант — далі ламають уже його, а не актуальний протокол. TLS 1.3 вбудував проти цього маркер: сервер, який насправді вміє 1.3, але узгоджує нижчу версію, зобовʼязаний записати спеціальне значення в останні вісім байтів свого випадкового поля, а клієнт зобовʼязаний його перевірити й при збігу обірвати рукостискання алертом illegal_parameter. З боку конфігурації ту саму дірку закриває TLS_FALLBACK_SCSV. Розрізняти при цьому треба дві різні речі. Узгодити TLS 1.2 з клієнтом, який не вміє 1.3, — це штатне узгодження версії, і шпаргалка OWASP його прямо дозволяє заради сумісності. А от відкат — повторна спроба рукостискання на нижчій версії після невдалої першої — це вже поверхня для атаки: RFC 7568 забороняє відкат на SSLv3 окремою вимогою, решту закривають вимкнені старі версії й TLS_FALLBACK_SCSV. Знахідкою є саме відкат, а не сама наявність TLS 1.2 у переліку.

Що насправді означає «сертифікат валідний»?

Означає «прийнятий відносно конкретного набору якорів довіри», і без цього уточнення фраза неповна. Перевірка шляху сертифікації (certification path validation) доводить, що конкретне імʼя субʼєкта справді повʼязане з конкретним відкритим ключем; ланцюг узагалі існує тому, що клієнт початково довіряє лише невеликому переліку ключів центрів сертифікації, і дійсний шлях мусить дійти до сертифіката, виданого одним із них. Який саме перелік вважати довіреним — рішення політики, а не математики. Звідси береться найчастіше непорозуміння на стендах: браузер із системним сховищем відкриває сайт, а CI-агент у контейнері з мінімальним набором коренів на тому самому URL падає — і жоден із них не «глючить». Тому в баг-репорті коректно писати не «сертифікат невалідний», а «шлях до якоря довіри цього клієнта не будується».

Помилка сертифіката прилетіла в тест. На які причини її розкладають?

Розкладати обовʼязково, бо за одним червоним екраном стоять різні поламки з різними лагодженнями. Кожна ланка ланцюга мусить пройти чотири перевірки: підпис звіряється відкритим ключем видавця, поточний час потрапляє в період дії (межі якого включні), сертифікат не значиться відкликаним, імʼя видавця збігається з очікуваним. Пʼятою перевіркою поверх ланцюга йде звірка ідентифікатора: клієнт має очікуваний ідентифікатор (reference identifier), сервер показує свій (presented identifier), і вони мають зійтися. Є ще жорсткий відсікач: критичне розширення, якого клієнт не розуміє, зобовʼязує його відхилити сертифікат — це відмова, а не попередження. Практичний висновок: у тікеті пишуть, яка саме з пʼяти умов не виконалася, бо прострочений сертифікат, невідомий корінь і невірне імʼя лікуються трьома різними діями. Окрема деталь для повноти: відкликаний сертифікат ще якийсь час приймається, бо роздільність відкликання обмежена періодом випуску списку відкликаних сертифікатів (certificate revocation list, CRL).

Що покриває сертифікат на *.staging.example.com і чому wildcard не безкоштовний?

Підстановка діє рівно на один лейбл, тож api.staging.example.com покривається, а a.b.staging.example.com — ні. Правило суворе й складається з двох частин: символ підстановки в імені може бути тільки один, і він мусить займати найлівіший лейбл повністю. Порівняння імен нечутливе до регістру, але всі лейбли повинні збігтися — «майже те саме імʼя» не працює. Дивитися при цьому треба в розширення subjectAltName, поле dNSName: рядки, схожі на доменні імена, у Common Name не включають і не перевіряють, а сучасні версії Chrome це поле просто ігнорують, тож «у CN же написано правильно» — не аргумент. Ціна wildcard у тому, що один сертифікат і один приватний ключ автоматично ручаються за будь-який однолейбловий хост усередині домену, включно з тим, який завтра підніме інша команда, — прямий конфлікт із принципом найменших привілеїв.

Чому не можна просто ввімкнути «ігнорувати помилки сертифіката» в автотестах?

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

Чим задача «дані в спокої» відрізняється від «даних у русі» і чому «ми ввімкнули HTTPS» не закриває питання?

Це два різні набори алгоритмів під дві різні задачі: надійно зберігати й надійно передавати. HTTPS відповідає лише за другу, шифрування диска — лише за першу, і жодне з двох не покриває обидві. Починають не з алгоритму, а з моделі загроз: шифрування на рівні заліза рятує від виносу сервера з дата-центру й нічого не дає проти зловмисника, який отримав віддалений доступ до працюючої системи. Найдешевший захист узагалі не криптографічний — не зберігати те, чого зберігати не обовʼязково. Числа для спокою: AES із ключем від 128 бітів (в ідеалі 256) у безпечному режимі, криві на кшталт Curve25519 для асиметрики, RSA не коротше за 2048 бітів і обовʼязково з випадковим доповненням OAEP. Для руху окремо памʼятають, що TLS має стояти на всіх сторінках, а суто API-ендпоінт мусить нешифрований HTTP відхиляти, а не перенаправляти: до моменту редиректу запит із токеном уже пролетів відкритим каналом.

Де не можна зберігати ключ шифрування?

Список коротких «ні» такий: не в коді репозиторію — це, до речі, найпростіша перевірка з усіх, робиться грепом; не у змінних оточення, бо їх видає назовні і phpinfo(), і читання /proc/self/environ; ніколи у відкритому вигляді; і не поруч із даними, які цей ключ захищає — якщо дані в базі, ключам місце у файловій системі. Правильне місце — криптографічне сховище: апаратний модуль або ізольований криптографічний сервіс. Звідси конвертна схема: ключ шифрування даних (DEK) шифрує самі дані, ключ шифрування ключів (KEK) шифрує DEK і зберігається окремо, тож зашифрований DEK можна тримати поряд із даними — без KEK з іншої системи він марний. Загальні правила поруч: ключ шифрують не слабшим ключем, і кожен ключ має рівно одне призначення, бо це обмежує шкоду від компрометації. Тут же межа, на якій валяться відповіді: «поклали в секрети CI» — це гігієна секретів, а вимоги до криптографічного ключа суворіші, і змінна оточення сховищем для нього не рахується. Останнє, що дивляться в ревʼю: ротація готується до інциденту, а не після нього, план відновлення має бути записаний, а самі ключі, вектори ініціалізації, ідентифікатори сесій, CSRF-токени й токени скидання пароля мусять походити з CSPRNG.

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

Кейс 1. «У нас це поле зашифроване» — перевірка за пʼять хвилин

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

{
  "userId": 8412,
  "contactRef": "b2xla3NhbmRyLmtAZXhhbXBsZS5jb206KzM4MDY3MTIzNDU2Nw=="
}

Хвіст із ==, алфавіт лише з латиниці й цифр, довжина помітно більша за очікуваний вміст — усе це вже підозріле. Далі один рядок у консолі браузера:

atob('b2xla3NhbmRyLmtAZXhhbXBsZS5jb206KzM4MDY3MTIzNDU2Nw==');
// 'oleksandr.k@example.com:+380671234567'

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

Помічник, який ту саму перевірку робить прямо в API-тесті — щоб контракт не поповз мовчки після наступного релізу:

import { test, expect } from '@playwright/test';

// осмислений ASCII після Base64-декоду = дані відкриті, ключа не було
function decodesToPlainText(value: string): boolean {
  if (!/^[A-Za-z0-9+/_-]+={0,2}$/.test(value)) return false;
  const decoded = Buffer.from(value, 'base64').toString('utf8');
  return decoded.length > 0 && /^[\x20-\x7E\s]+$/.test(decoded);
}

test('чутливе поле не їде у відповіді у відкритому вигляді', async ({ request }) => {
  const res = await request.get('https://api.example.com/v1/profile/8412');
  const body = await res.json();

  expect(
    decodesToPlainText(body.contactRef),
    'contactRef розкодовується без ключа — це кодування, а не шифрування',
  ).toBe(false);
});

Що дивитися і чому:

• Base64 — це транспорт, а не захист. Тест вище не намагається зламати шифр: він перевіряє рівно те, що можна перевірити збоку — чи розгортаються дані без жодного ключа. Пройшов — питання до архітектури лишається відкритим; не пройшов — знахідка доведена одним рядком.
• Дайджест від кодування відрізняє довжина. Хеш видає фіксовану довжину на будь-якому вході, Base64 — довжину, пропорційну вхідним даним. Якщо в базі паролів усі рядки однакової довжини — це хеш, і наступне питання вже про сіль і фактор роботи.
• Однакові рядки на однакових паролях — окрема знахідка. Заведіть двох тестових користувачів з одним і тим самим паролем і порівняйте значення в дампі: збіг означає, що солі немає, і райдужна таблиця розкриє всю базу разом.
• crypto.subtle на http не існує. Якщо фронтенд щось «шифрує на клієнті», а стенд піднятий без TLS, код мовчки не працюватиме: Web Crypto доступний лише в захищеному контексті, і typeof crypto.subtle поверне 'undefined'.

Кейс 2. Аудит транспорту перед релізом: читаємо звіт сканера

Задача перед релізом звучить як «перевірити, що HTTPS налаштований правильно». Вручну це не перевіряється — беруть testssl.sh або Server Test і читають вивід по трьох осях: які версії пропонуються, які набори шифрів увімкнені, які відомі вразливості спрацювали. Нижче — скорочений і причесаний вигляд такого звіту: точні формулювання рядків залежать від інструмента та його версії, важить не текст рядка, а вердикт, який з нього випливає.

 Testing protocols

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final

 Testing cipher categories

 NULL ciphers (no encryption)                    not offered (OK)
 Anonymous NULL ciphers (no authentication)      not offered (OK)
 Export ciphers                                  not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)         offered (NOT ok)
 Obsoleted CBC ciphers                           offered
 Forward Secrecy strong encryption (AEAD)        offered (OK)

 Testing vulnerabilities

 CRIME, TLS                                      VULNERABLE (NOT ok)

Друга половина аудиту стосується не шифрів, а того, чи взагалі можна дістатися до сервісу відкритим каналом. Для API правило суворіше, ніж «поставте редирект»:

import { test, expect } from '@playwright/test';

test('API-ендпоінт по http відмовляє, а не веде редиректом на https', async ({ request }) => {
  const res = await request.get('http://api.example.com/orders', { maxRedirects: 0 });

  // редирект тут не рішення: запит із токеном уже пройшов відкритим каналом
  expect([301, 302, 307, 308]).not.toContain(res.status());
});

Що дивитися і чому:

• Версія — лише третина відповіді. «Увімкнули TLS» не каже нічого ні про набори шифрів, ні про сертифікат. Три питання аудиту: що узгоджується як версія, що узгоджується як набір, що показує сертифікат.
• Дамп рукостискання про версію бреше. Якщо ви дивитеся не звіт сканера, а байти, памʼятайте: сервер, що узгодив TLS 1.3, зобовʼязаний виставити в ServerHello.legacy_version значення 0x0303. Реальну версію шукайте в розширенні supported_versions.
• Регресія приходить під приводом сумісності. Формулювання «нам треба підтримати старий клієнт» повертає слабкі набори тихо й без окремого тікета. Правильний хід — окремий ендпоінт для такого клієнта, без доступу до чутливих даних, а основний не чіпають.
• Редирект з HTTP на HTTPS рятує пізно. Браузерну сторінку він ще виправдовує, API — ні: перший запит із заголовком Authorization уже пішов відкритим каналом, і перенаправлення відбувається після витоку, а не замість нього.
• Звіт сканера кладіть у тікет цілим блоком. Рядок offered (NOT ok) — це відтворюваний доказ, з яким не сперечаються, на відміну від переказу «сканер щось знайшов».

Кейс 3. У CI ERR_CERT_AUTHORITY_INVALID, у браузері все зелено

Класика стенду: тестувальник відкриває https://staging.example.com у себе — замок на місці, помилок немає. Та сама адреса в контейнері CI валить усю сюїту на першому ж goto. Перше, що хочеться зробити, — виставити ignoreHTTPSErrors: true у конфізі. Це і є хибний хід, бо він не лагодить причину, а прибирає перевірку разом із цілим класом майбутніх регресій.

Причину дістають однією командою, а не здогадами:

openssl s_client -connect staging.example.com:443 \
  -servername staging.example.com -showcerts </dev/null

depth=0 CN = staging.example.com
verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
...
Verify return code: 21 (unable to verify the first certificate)

Це не «сертифікат зламаний» — це «клієнт не може добудувати шлях до жодного зі своїх якорів довіри». Браузер його добудовує, бо системне сховище на робочій машині містить внутрішній корінь компанії; мінімальний образ CI цього кореня не має. Розкладка помилки на пʼять причин, кожна зі своїм лагодженням:

Правильне лагодження для нашого випадку — не прапорець, а корінь у сховищі образу; для Node-частини (request-фікстура Playwright, API-тести) той самий корінь підключається змінною NODE_EXTRA_CA_CERTS:

# CI: внутрішній корінь потрапляє і в системне сховище, і в Node
- run: |
    cp ./ci/certs/internal-root.crt /usr/local/share/ca-certificates/
    update-ca-certificates
- run: npx playwright test
  env:
    NODE_EXTRA_CA_CERTS: /usr/local/share/ca-certificates/internal-root.crt

Що дивитися і чому:

• Прапорець «ігнорувати помилки» дозволено мати, але не за замовчуванням. Стандарт вимагає, щоб автоматичний клієнт при розбіжності рвав звʼязок і писав у лог; вимикач цієї поведінки — свідомий тимчасовий виняток на конкретний прогін, а не рядок у базовому конфізі, який ніхто ніколи не прибере.
• Різниця «браузер бачить, CI не бачить» — не флак. Валідність рахується щодо набору якорів довіри конкретного клієнта, тож два різні вердикти на одному URL є нормальною поведінкою двох різних сховищ. Питання не «чому CI глючить», а «якого кореня йому бракує».
• Wildcard часто буває справжньою причиною. Сертифікат на *.staging.example.com покриває api.staging.example.com і не покриває a.b.staging.example.com: підстановка бере рівно один лейбл. Якщо тест переїхав на глибший піддомен, помилка імені виглядатиме як «сертифікат раптом зламався».
• Common Name не аргумент. Перевіряють subjectAltName, поле dNSName; сучасний Chrome CN узагалі ігнорує, тож «але в CN правильне імʼя» пояснює рівно нічого.
• У тікеті називайте конкретну умову. «Сертифікат невалідний» — це п'ять різних дефектів в одному реченні; «на стенді не віддається проміжний сертифікат, ланцюг обривається на глибині 1» — це задача, яку адміністратор закриє за десять хвилин.

Хешування, шифрування, кодування

• Знаю критерій, який розводить три операції — ключ і оборотність, — і замість суперечок про «нечитабельний рядок» доводжу кодування через atob() у консолі.
• Знаю чотири властивості криптографічного хешу, статус SHA-2, SHA-1 і MD5, те, що голий хеш не заміняє MAC, і що Web Crypto API живе лише в захищеному контексті.

«MD5 зламано» — про що це насправді

• Розрізняю три стійкості дайджеста й памʼятаю, що в MD5 упали колізії, а не прообраз.
• Знаю межу застосування: контрольна сума проти випадкового псування прийнятна, MD5 у підписі чи сертифікаті — знахідка; заміни називаються HMAC-SHA256 та AES-CMAC.

Зберігання паролів

• Знаю, що пароль хешують спеціалізованою функцією з фактором роботи, а не шифрують оборотно.
• Можу пояснити роль солі, її унікальність на кожен пароль і те, що секретом вона не є.
• Розумію, що таке memory-hard, чим різняться Argon2d, Argon2i та Argon2id і чому за замовчуванням беруть саме Argon2id.
• Знаю три важелі конфігурації (m, t, p) і не зводжу в одне число дефолти RFC 9106 та мінімум OWASP.
• Знаю, що видно збоку без доступу до коду: однакові хеші на однакових паролях означають відсутність солі, а миттєвий логін при заявленому Argon2id з 2 GiB означає, що щось одне з двох неправда — або конфігурація, або заявлене.

Версії TLS і набори шифрів

• Можу назвати заборонені версії з документом і підставою: TLS 1.0/1.1 (RFC 8996, SHA-1 та 2^77), SSL 3.0 (RFC 7568, доповнення CBC), SSL 2.0 (RFC 6176, незахищене рукостискання).
• Памʼятаю дві особливості TLS 1.3: у ServerHello.legacy_version стоїть 0x0303, а справжня версія живе в розширенні supported_versions; від зниження боронить маркер в останніх восьми байтах випадкового значення, алерт illegal_parameter і TLS_FALLBACK_SCSV з боку конфігурації.
• Знаю, що вмикають (AEAD: AES-GCM, ChaCha20-Poly1305) і що гасять поіменно: null-шифри, анонімні, експортні, TLS_RSA_*, статичні TLS_DH_*/TLS_ECDH_*, RC4, усе слабше за 112 бітів і стиснення TLS через CRIME.

Сертифікати

• Можу розкласти помилку сертифіката на пʼять причин: підпис, строк, відкликання, видавець, імʼя — і знаю, що лагодяться вони по-різному.
• Розумію, що «валідний» рахується щодо набору якорів довіри конкретного клієнта, тож розбіжність браузера й CI-агента буває цілком законною.
• Знаю правила wildcard (один символ підстановки, крайній лівий лейбл цілком, покриття рівно на один лейбл) і те, що імʼя звіряють у subjectAltName, а не в Common Name.
• Розумію, чому «ігнорувати помилки сертифіката» — тимчасовий свідомий виняток, а самопідписаний сертифікат на стенді лікується внутрішнім коренем у сховищі довіри агента.

Дані в спокої, дані в русі та ключі

• Розводжу дві задачі: HTTPS закриває лише рух, шифрування диска — лише спокій, і залізне шифрування нічого не дає проти віддаленої компрометації.
• Можу пояснити, чому суто API-ендпоінт має нешифрований HTTP відхиляти, а не перенаправляти: до моменту редиректу запит із токеном уже пролетів відкритим каналом.
• Знаю конвертну схему DEK/KEK і перелік місць, де ключам не місце: код, змінні оточення, відкритий вигляд, сусідство з даними, які вони захищають.
• Памʼятаю, що ключі, вектори ініціалізації, ідентифікатори сесій і токени скидання пароля беруть із CSPRNG, а UUID надійним джерелом випадковості не вважають.