OHTTP: як знайти збій між клієнтом і сервером

Прямий запит працює, але це ще не відповідь

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

Причина не обов’язково в поганому моніторингу. Oblivious HTTP, або OHTTP, навмисно ділить відомості між двома проміжними вузлами. Ретранслятор (relay) бачить, звідки надійшло з’єднання, але не читає зашифрований вміст. Шлюз (gateway) розшифровує запит і передає його цільовому серверу (origin), але не отримує адресу початкового клієнта безпосередньо через це з’єднання.

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

Спочатку відновіть маршрут

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

Типовий тест проходить так:

1. Клієнт отримує або завантажує конфігурацію публічного ключа шлюзу.
2. Перетворює початкове HTTP-повідомлення на двійковий формат bHTTP.
3. Шифрує повідомлення для шлюзу.
4. Надсилає захищене повідомлення ретранслятору.
5. Ретранслятор передає його шлюзу.
6. Шлюз розшифровує повідомлення та формує запит до цільового сервера.
7. Захищена відповідь повертається тим самим маршрутом і розшифровується на клієнті.

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

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

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

Гілка 1: ретранслятор не бачить спроби

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

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

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

Гілка 2: ретранслятор прийняв запит, але шлюз не завершив обробку

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

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

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

Гілка 3: шлюз розшифрував запит, але цільовий сервер поводиться інакше

Після успішного розшифрування порівнюйте запит шлюзу з прямим тестом. Виклик через curl може мати інший шлях, метод, заголовок Host, тип вмісту, тіло або службові облікові дані. Фраза «прямий запит працює» корисна лише разом із переліком відомих відмінностей.

Перевірте, чи шлюз сформував очікуваний запит, установив з’єднання з цільовим сервером і отримав внутрішній HTTP-статус. У журналах цільового сервера використовуйте вузьке часове вікно або погоджений обмежений ідентифікатор. Не намагайтеся шукати адресу початкового клієнта: через цей маршрут сервер зазвичай бачить з’єднання від шлюзу.

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

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

Контрольована лабораторна сесія з pvcli

Cloudflare опублікувала вихідний код pvcli — інструмента, схожого на curl, для наскрізної роботи з OHTTP та іншими протоколами приватності. За описом Cloudflare, він прибирає потребу вручну складати bHTTP, шифрувати повідомлення та відтворювати багатокроковий обмін.

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

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

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

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

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

Джерела

• Cloudflare, We’re open-sourcing our privacy proxy CLI: https://blog.cloudflare.com/open-sourcing-our-privacy-proxy-cli/