← Privacy Proxy / privacy-proxy / concepts

Аутентификация

Для проксирования трафика через Privacy Proxy клиенты должны пройти аутентификацию. На этой странице описаны поддерживаемые методы аутентификации и случаи их применения.

Методы аутентификации

Privacy Proxy поддерживает три метода аутентификации:

Метод	Сценарий использования	Уровень конфиденциальности
Pre-shared key (PSK)	Проверка концепции, тестирование	Ниже
Токены Privacy Pass	От клиента к серверу	High
mTLS	От сервера к серверу	Выше

Pre-shared key (PSK)

Предварительно распределенные ключи предоставляют простой способ аутентификации на этапе разработки и тестирования концепции. Cloudflare выдает секретный ключ, который клиенты включают в каждый запрос.

Как это работает

Укажите PSK в Proxy-Authorization заголовок:

CONNECT example.com:443 HTTP/2
Host: example.com
Proxy-Authorization: Preshared <YOUR_PSK>

Прокси проверяет ключ и разрешает соединение, если он совпадает.

Ограничения

Аутентификация PSK имеет ограничения, из-за которых она не подходит для использования в производственной среде.

Shared secret: все клиенты используют один и тот же ключ, поэтому вы не можете отозвать доступ для отдельных пользователей.
Без ограничения скорости на пользователя: вы не можете применять квоты или ограничения для отдельных пользователей.
Связываемость: прокси может связывать все запросы, использующие один и тот же PSK, что снижает конфиденциальность пользователя.

Используйте PSK только для тестирования. Для производственных развертываний используйте Токены Privacy Pass.

Токены Privacy Pass

Privacy Pass ↗ это протокол, который позволяет клиентам проходить аутентификацию, не раскрывая свою личность. Токены криптографически несвязываемы, поэтому прокси не может сопоставить разные запросы от одного и того же пользователя.

Как это работает

Privacy Pass использует архитектуру с тремя участниками:

Attester: проверяет, что Client является легитимным пользователем (например, имеет действующий аккаунт), и пересылает запросы на токены Issuer.
Издатель: подписывает слепые токены, не узнавая, какой Client их запросил.
Источник (Privacy Proxy): принимает токены в качестве подтверждения авторизации.

Выдача токена

┌──────────┐    1. Attestation request   ┌──────────┐
│          │ ──────────────────────────▶ │          │
│  Client  │                             │ Attester │
│          │ ◀────────────────────────── │          │
└──────────┘    2. Attestation OK        └──────────┘
     │
     │ 3. Blinded token request
     ▼
┌──────────┐    4. Forward request       ┌──────────┐
│          │ ──────────────────────────▶ │          │
│ Attester │                             │  Issuer  │
│          │ ◀────────────────────────── │          │
└──────────┘    5. Signed blinded token  └──────────┘
     │
     │ 6. Return to Client
     ▼
┌──────────┐
│  Client  │  (unblinds and stores token)
└──────────┘

Client отправляет запрос токена через Attester, чтобы сохранить невозможность связывания запросов. Это гарантирует, что Issuer не может сопоставить запросы токенов с конкретными событиями аттестации или личностью Client.

Погашение токена

┌──────────┐    1. Present token         ┌──────────┐
│          │ ──────────────────────────▶ │          │
│  Client  │                             │  Privacy │
│          │ ◀────────────────────────── │  Proxy   │
└──────────┘    2. Connection OK         └──────────┘

Privacy Proxy проверяет токен с помощью открытого ключа Issuer. Прокси узнает только то, что токен действителен, но не то, кому он был выдан.

Процесс выдачи токена:

Клиент подтверждает свою личность аттестатору (например, выполнив вход в систему с учетной записью).
Аттестатор подтверждает, что клиент действителен.
Клиент генерирует блиндированные токены и отправляет их эмитенту.
Эмитент подписывает блиндированные токены и возвращает их.
Клиент снимает блиндирование с токенов и сохраняет их.

При выполнении запроса:

Клиент передает токен в заголовке Proxy-Authorization заголовок.
Прокси проверяет подпись токена с помощью открытого ключа эмитента.
Прокси разрешает соединение, если токен действителен.

Поскольку токены подвергаются блайндингу при выдаче, эмитент не может связать токен с конкретным запросом на выдачу. Прокси видит только то, что токен действителен, но не то, кому именно он был выдан.

Token format

Токены Privacy Pass включаются в Proxy-Authorization заголовок с помощью PrivateToken схема:

CONNECT example.com:443 HTTP/2
Host: example.com
Proxy-Authorization: PrivateToken token=<base64-encoded-token>

Настройте Privacy Pass

Для рабочих развертываний с использованием Privacy Pass:

Выберите эмитента токенов. Cloudflare может выступать эмитентом, либо вы можете интегрироваться со сторонним эмитентом.
Настройте аттестацию, чтобы определить, как клиенты подтверждают свою личность перед получением токенов.
Распространите конфигурацию эмитента. Клиентам нужны публичный ключ эмитента и конечная точка для запроса токенов.

Свяжитесь с нами ↗ для настройки Privacy Pass в вашем развёртывании.

Взаимный TLS (mTLS)

Аутентификация с использованием взаимного TLS (mTLS) ↗ обеспечивает защищённость и доверие трафика в обоих направлениях. Клиент предъявляет прокси сертификат, и прокси проверяет его перед тем, как разрешить соединение.

Как это работает

Клиент передает клиентский сертификат TLS во время TLS-рукопожатия. Прокси проверяет сертификат по настроенному центру сертификации (CA) и разрешает соединение, если сертификату доверяют.

Ограничения

Вам придется выпускать сертификаты для каждого клиента или сервиса и управлять ими. mTLS предназначен для взаимодействия между серверами, а не для аутентификации отдельных пользователей. По сертификату прокси может определить клиента, что снижает уровень конфиденциальности по сравнению с Privacy Pass.

Используйте mTLS для интеграций между серверами, где обе стороны являются доверенными сервисами.