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

Ця експлуатаційна затримка виникає через автоматичні системи захисту від зловживань на прикордонних вузлах мереж доставки контенту (CDN). Алгоритми репутації аналізують частоту надходження запитів із діапазонів IPv4 та підмереж IPv6. Коли сотні клієнтів використовують спільні вихідні шлюзи, системи моніторингу фіксують тисячі одночасних з'єднань з однієї адреси. Алгоритм фіксує аномалію та автоматично вимагає проходження інтерактивної перевірки.

Тривалий час адміністраторам доводилося обирати між розв'язанням графічних загадок і виділенням статичних IP (що знижує конфіденційність через деанонімізацію). Стандартизація IETF RFC 9505 (Privacy Pass Architecture), разом із RFC 9506 та RFC 9578, запропонувала надійне математичне рішення: сліпі цифрові підписи та токени приватного доступу (Private Access Tokens, PAT).

+--------------------------------------------------------------------------+
|                 ЧОТИРИСТОРОННЯ АРХІТЕКТУРА RFC 9505                      |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+     1. Атестація пристрою       +-------------+        |
|    |            | ------------------------------> | Атестатор   |        |
|    |   Клієнт   | <------------------------------ | (OS / TPM)  |        |
|    | (Браузер / |      Підтвердження валідності   +-------------+        |
|    | WireGuard) |                                        |               |
|    |            |      3. Запит засліпленого токена      | 2. Передача   |
|    |            | ------------------------------> +-------------+ доказів|
|    |            | <------------------------------ |  Емітент    |        |
|    +------------+      4. Підписаний токен        | (Blind RSA/ |        |
|          |                                        |   VOPRF)    |        |
|          | 5. Зняття засліплення (Unblind)        +-------------+        |
|          |    та надсилання Authorization: PrivateToken                  |
|          v                                                               |
|    +------------+                                                        |
|    |   Сервер   |  Перевірка підпису відкритим ключем Емітента           |
|    |  ресурсу   |  Миттєвий доступ БЕЗ БУДЬ-ЯКИХ ПЕРЕВІРОК КАПЧІ         |
|    | (CDN Edge) |  (Сервер НЕ знає IP-адресу чи особу клієнта)           |
|    +------------+                                                        |
+--------------------------------------------------------------------------+

Математичні засади: сліпі підписи та криптографія VOPRF

Ключовий криптографічний прорив RFC 9505 полягає в цілковитому розмежуванні процедури випуску токена та процедури його пред'явлення. У класичних схемах ідентифікації (як-от OAuth чи сертифікати x509) центр сертифікації точно знає, хто запитав підтвердження і якому серверу воно призначене. Якщо емітент та цільовий ресурс зіставлять свої журнали, мережевий маршрут користувача відновлюється безпомилково.

Privacy Pass усуває цей ризик за допомогою сліпих підписів (RFC 9506) та верифікованих псевдовипадкових функцій без відома (VOPRF, RFC 9578). Робочий процес поділяється на п'ять кроків:

1. Етап засліплення (Blinding)

Коли клієнт отримує відповідь HTTP 401 Unauthorized із заголовком WWW-Authenticate: PrivateToken, він генерує випадкове криптографічне число $x$ (контекст запиту) та маскувальний скаляр $r$.

На еліптичній кривій (NIST P-256 чи Curve25519) із базовою точкою $G$ клієнт перетворює значення $x$ у точку кривої $M = H_{1}(x)$ за стандартом RFC 9380. Засліплена точка $B$ обчислюється скалярним множенням:

$$B = r \cdot M$$

Через складність задачі дискретного логарифмування на еліптичних кривих жоден сторонній спостерігач, який перехопить $B$, не зможе відновити ні вихідне значення $M$, ні скаляр $r$.

2. Етап емісії (Issuance)

Точка $B$ надсилається Емітенту (Issuer). Щоб запобігти неконтрольованій генерації токенів автоматизованими ботами, Емітент вимагає підтвердження від Атестатора (Attester). У сучасних операційних системах Атестатор (модуль Apple Secure Enclave або апаратний TPM) підтверджує:

  • Запит походить від справжнього фізичного пристрою, а не віртуальної машини;
  • Цілісність ядра операційної системи збережена;
  • Частота генерації запитів перебуває в межах дозволеного ліміту.

Атестатор перевіряє суто фізичну справжність обладнання: він не має доступу до засліплених даних $B$ і не знає кінцевого веб-ресурсу. Після підтвердження Емітент підписує засліплену точку закритим ключем $k$:

$$C = k \cdot B = k \cdot (r \cdot M)$$

Емітент також створює доказ рівності дискретних логарифмів (DLEQ), який підтверджує відповідність обчислень відкритому ключу $K = k \cdot G$.

3. Етап зняття засліплення та верифікації (Unblinding & Verification)

Отримавши значення $C$ та доказ DLEQ, клієнт перевіряє їхню коректність із відкритим ключем Емітента. Потім клієнт усуває маскувальний фактор $r$, множачи $C$ на зворотне за модулем число до $r$:

$$S = r^{-1} \cdot C = r^{-1} \cdot (k \cdot r \cdot M) = k \cdot M$$

Отримана точка $S$ є валідним цифровим підписом на вихідне повідомлення $M = H_{1}(x)$. Клієнт запаковує її в бінарний токен RFC 9505 і повторює HTTP-запит до веб-сайту через заголовок Authorization: PrivateToken token="...".

Сервер призначеного ресурсу:

  1. Обчислює $M = H_{1}(x)$;
  2. Перевіряє рівність на еліптичній кривій із відкритим ключем $K$;
  3. Фіксує значення $x$ у кеші використаних токенів (replay cache) для захисту від повторного надсилання.

Запит схвалюється миттєво. Сервер бачить лише факт наявності підтвердженого токена, не знаючи реальної IP-адреси пристрою. Водночас Емітент бачив лише засліплену точку $B$ і не може визначити, який сайт відкрив користувач.

+--------------------------------------------------------------------------+
|                     РОЗПОДІЛ ДОСТУПНИХ ДАНИХ                             |
+--------------------------------------------------------------------------+
| Сторона     | Бачить реальну IP? | Бачить цільовий сайт? | Бачить тип ОС?|
+-------------+--------------------+-----------------------+---------------+
| Атестатор   | Так (або IP VPN)   | НІ                    | ТАК (апаратна)|
| Емітент     | НІ                 | НІ                    | НІ            |
| Сервер CDN  | Так (IP виходу VPN)| ТАК (власний ресурс)  | НІ            |
| Шлюз VPN    | Так (вхідна IP)    | ТАК (IP сервера CDN)  | НІ            |
+--------------------------------------------------------------------------+

Використання Private Access Tokens (PAT) у браузерах та ОС

У прикладних веб-технологіях стандарт RFC 9505 втілено у вигляді токенів Private Access Tokens (PAT). Вони інтегровані в iOS 16, macOS 13, сучасні версії Android та системні модулі Linux, а також підтримуються мережами Cloudflare, Fastly та Akamai.

Стандартний обмін повідомленнями за протоколом HTTP виглядає так:

GET /api/v1/telemetry HTTP/1.1
Host: api.example.com
User-Agent: SecureClient/2.4

HTTP/1.1 401 Unauthorized
Date: Fri, 13 Nov 2026 02:14:00 GMT
WWW-Authenticate: PrivateToken challenge="AQAB...", token-key="BLz..."

Заголовок WWW-Authenticate передає два необхідні параметри:

  • challenge: двійкова структура base64url, що визначає тип токена (0x0002 для Blind RSA або 0x0001 для VOPRF), контекст та ідентифікатор ресурсу.
  • token-key: хеш SHA-256 відкритого ключа Емітента.

Браузер обробляє код 401 у внутрішньому циклі без зупинки рендерингу сторінки. Модуль безпеки операційної системи проходить атестацію, отримує підписаний токен і автоматично повторює запит:

GET /api/v1/telemetry HTTP/1.1
Host: api.example.com
Authorization: PrivateToken token="AQIDBA..."

Прикордонний проксі перевіряє цифровий підпис менш ніж за 1 мілісекунду, скидає підозрілий рейтинг до нуля та повертає статус HTTP 200 OK.

Взаємодія з мережевою архітектурою RiceGuard

Хоча протокол Privacy Pass працює на прикладному рівні (L7), його поєднання з тунелями третього рівня (L3) створює помітні переваги:

  1. Розділення маршрутів автентифікації: Під час передавання трафіку через VPNRice та протокол RiceGuard сесія зв'язку з Атестатором надійно захищена від витоків DNS. IP-адреса, зафіксована Атестатором, відрізняється від адреси вихідного шлюзу, що унеможливлює зіставлення сесій операторами зв'язку.
  2. Зняття репутаційного навантаження: Спільні вихідні сервери VPN отримують математичне підтвердження легітимності трафіку. Інженерам не потрібно постійно змінювати пули IP-адрес для запобігання хибним спрацьовуванням CDN.
  3. Захист від цифрових відбитків (Fingerprinting): Звичайні візуальні перевірки капчі змушують браузер завантажувати важкі скрипти JavaScript для аналізу параметрів Canvas, WebGL та системних таймерів. Використання токенів PAT унеможливлює виконання такого діагностичного коду.

Практична реалізація: перевірка токенів на шлюзі (Go)

Для інженерів, які налаштовують API-шлюзи або зворотні проксі, перевірка токенів RFC 9505 потребує мінімуму процесорного часу. Нижче наведено приклад обробника на мові Go:

package main

import (
	"crypto"
	"crypto/rsa"
	"crypto/sha256"
	"encoding/base64"
	"errors"
	"fmt"
	"net/http"
	"strings"
	"sync"
)

type TokenValidator struct {
	issuerPublicKey *rsa.PublicKey
	spentTokens     map[string]bool
	mu              sync.Mutex
}

func NewTokenValidator(pubKey *rsa.PublicKey) *TokenValidator {
	return &TokenValidator{
		issuerPublicKey: pubKey,
		spentTokens:     make(map[string]bool),
	}
}

// VerifyPrivateToken перевіряє структуру двійкового токена RFC 9505
func (v *TokenValidator) VerifyPrivateToken(rawHeader string) error {
	if !strings.HasPrefix(rawHeader, "PrivateToken token=") {
		return errors.New("некоректний заголовок PrivateToken")
	}

	tokenData := strings.TrimPrefix(rawHeader, "PrivateToken token=")
	tokenData = strings.Trim(tokenData, """)
	decoded, err := base64.RawURLEncoding.DecodeString(tokenData)
	if err != nil {
		return fmt.Errorf("помилка декодування base64: %w", err)
	}

	// Структура токена (тип 0x0002):
	// [2 байти тип] [32 байти контекст] [32 байти nonce] [256 байтів підпис]
	if len(decoded) < 2+32+32+256 {
		return errors.New("довжина токена менша за допустимий мінімум")
	}

	tokenType := uint16(decoded[0])<<8 | uint16(decoded[1])
	if tokenType != 0x0002 {
		return fmt.Errorf("непідтримуваний тип токена: 0x%04x", tokenType)
	}

	context := decoded[2:34]
	nonce := decoded[34:66]
	signature := decoded[66 : 66+256]

	nonceKey := fmt.Sprintf("%x", nonce)

	// Захист від повторного використання
	v.mu.Lock()
	if v.spentTokens[nonceKey] {
		v.mu.Unlock()
		return errors.New("токен уже використано")
	}
	v.spentTokens[nonceKey] = true
	v.mu.Unlock()

	// Обчислення дайджесту повідомлення
	h := sha256.New()
	h.Write(context)
	h.Write(nonce)
	digest := h.Sum(nil)

	// Перевірка підпису RSA-PSS відкритим ключем Емітента
	err = rsa.VerifyPSS(v.issuerPublicKey, crypto.SHA256, digest, signature, &rsa.PSSOptions{
		SaltLength: rsa.PSSSaltLengthEqualsHash,
	})
	if err != nil {
		return fmt.Errorf("помилка криптографічної верифікації: %w", err)
	}

	return nil
}

func (v *TokenValidator) Middleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		authHeader := r.Header.Get("Authorization")
		if authHeader == "" || v.VerifyPrivateToken(authHeader) != nil {
			w.Header().Set("WWW-Authenticate", `PrivateToken challenge="AQAC...", token-key="pub-sha256"`)
			w.WriteHeader(http.StatusUnauthorized)
			w.Write([]byte("401 Unauthorized: потрібен дійсний токен RFC 9505\n"))
			return
		}
		next.ServeHTTP(w, r)
	})
}

Інженерні виклики та подальший розвиток

Впровадження стандарту RFC 9505 започатковує нову модель безпеки веб-ресурсів: довіра базується на апаратних вимірюваннях і математичному засліпленні замість нав'язливого стеження за поведінкою користувача. Під час проектування мереж слід ураховувати такі фактори:

  • Централізація атестації: Більшість наявних сервісів атестації прив'язані до розробників операційних систем (Apple, Google). Для підтримки дистрибутивів Linux та відкритого ПЗ необхідно розширювати відкриті протоколи на базі модулів TPM 2.0 і WebAuthn.
  • Контроль частоти запитів: Щоб запобігти масовій генерації токенів зі зламаного фізичного пристрою, емітенти використовують алгоритми обмеження трафіку (token bucket). Грамотна конфігурація квот є критичною для корпоративних шлюзів VPN.
  • Суворе розмежування повноважень: Незалежність Атестатора, Емітента та Сервера ресурсу є головною вимогою. Вони мають функціонувати в автономних інфраструктурах із прозорим аудитом.

Поєднання RFC 9505 і токенів PAT доводить, що захист мережевої інфраструктури та повага до приватності успішно досягаються сучасними криптографічними засобами.