RFC 2617¶

RFC 2617 — это документ, опубликованный Инженерным советом Интернета (IETF) в июне 1999 года, который определяет расширенную схему аутентификации доступа для протокола передачи гипертекста (HTTP). Он заменяет собой более ранний стандарт RFC 2616 (который описывал HTTP/1.1) и вводит механизм «дайджест-аутентификации» (Digest Access Authentication) как более безопасную альтернативу базовой аутентификации (Basic Authentication). RFC 2617 является частью серии стандартов, регулирующих взаимодействие веб-клиентов и серверов, и широко используется в современных веб-приложениях для защиты доступа к ресурсам.

¶История и развитие

Протокол HTTP изначально не имел встроенных механизмов аутентификации. Первые версии (HTTP/0.9 и HTTP/1.0) использовали базовую аутентификацию, описанную в RFC 1945 (1996 год). Она передавала имя пользователя и пароль в открытом виде (Base64-кодирование, которое легко декодируется), что делало её уязвимой для перехвата. В 1997 году в RFC 2068 была предложена дайджест-аутентификация, но она не получила широкого распространения из-за сложности реализации.

RFC 2617 был разработан рабочей группой IETF HTTP Authentication Working Group и опубликован в 1999 году как часть пакета документов, обновляющих HTTP/1.1 (RFC 2616). Он ввёл два основных механизма:

Базовая аутентификация (Basic) — унаследована из более ранних стандартов, но с уточнёнными правилами.
Дайджест-аутентификация (Digest) — новый механизм, использующий хеширование для защиты паролей.

В 2015 году RFC 2617 был заменён на RFC 7235 («Hypertext Transfer Protocol (HTTP/1.1): Authentication»), который унифицировал и упростил описание аутентификации. Однако RFC 2617 остаётся исторически важным и до сих пор используется в старых системах.

¶Основные механизмы аутентификации

RFC 2617 описывает два типа аутентификации: Basic и Digest. Оба работают по схеме «запрос-ответ» (challenge-response), где сервер отправляет клиенту запрос аутентификации (заголовок WWW-Authenticate), а клиент отвечает с учётными данными (заголовок Authorization).

¶Базовая аутентификация (Basic)

Базовая аутентификация — это простейший механизм. Сервер отправляет клиенту строку вида WWW-Authenticate: Basic realm="Имя_домена". Клиент кодирует имя пользователя и пароль в формате username:password с помощью Base64 и отправляет в заголовке Authorization: Basic <закодированная_строка>.

Недостатки:

Пароль передаётся в открытом виде (Base64 не является шифрованием).
Уязвимость к атакам «человек посередине» (MITM).
Отсутствие защиты целостности сообщения.

Применение: В современных системах базовая аутентификация используется редко, обычно в сочетании с HTTPS (для шифрования канала) или в устаревших API.

¶Дайджест-аутентификация (Digest)

Дайджест-аутентификация — это более безопасный механизм, который не передаёт пароль в открытом виде. Вместо этого клиент вычисляет хеш (дайджест) от комбинации пароля, случайного числа (nonce), метода HTTP, URI и других параметров.

Процесс работы:

Сервер отправляет клиенту заголовок WWW-Authenticate: Digest realm="Имя_домена", nonce="случайное_число", algorithm=MD5, qop="auth".
Клиент вычисляет дайджест по формуле: HA1 = MD5(username:realm:password), HA2 = MD5(method:uri), response = MD5(HA1:nonce:nonce_count:cnonce:qop:HA2).
Клиент отправляет заголовок Authorization: Digest username="имя", realm="домен", nonce="число", uri="путь", response="хеш", qop=auth, nc=00000001, cnonce="клиентское_число".
Сервер проверяет дайджест и либо предоставляет доступ, либо возвращает ошибку 401.

Преимущества:

Пароль не передаётся в открытом виде.
Защита от повторной атаки (replay attack) за счёт использования nonce и счётчика nonce count (nc).
Поддержка проверки целостности сообщения (qop=auth-int).

Недостатки:

Хеш пароля хранится на сервере (если не используется дополнительное хеширование).
Уязвимость к атакам по словарю (если nonce предсказуем).
Сложность реализации по сравнению с Basic.

¶Структура заголовков

RFC 2617 определяет формат заголовков WWW-Authenticate и Authorization для обоих типов аутентификации.

¶Заголовок WWW-Authenticate (сервер → клиент)

`` WWW-Authenticate: <тип> realm="<строка>", [параметры] ``

Для Basic: WWW-Authenticate: Basic realm="Example" Для Digest: WWW-Authenticate: Digest realm="Example", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41", qop="auth,auth-int", algorithm=MD5

Параметры Digest:

realm — строка, идентифицирующая защищённую область (например, имя домена).
nonce — случайное число, генерируемое сервером для предотвращения повторных атак.
opaque — строка, которую сервер отправляет и ожидает обратно (может использоваться для сохранения состояния).
qop — качество защиты: auth (только аутентификация) или auth-int (аутентификация с проверкой целостности).
algorithm — алгоритм хеширования: MD5 (по умолчанию) или MD5-sess (сессионный вариант).
stale — флаг, указывающий, что nonce устарел и клиент должен повторить запрос с новым nonce.

¶Заголовок Authorization (клиент → сервер)

`` Authorization: <тип> <параметры> ``

Для Basic: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Для Digest: Authorization: Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", response="e966c932a9242554e42c8eeaccef7d1f", opaque="5ccc069c403ebaf9f0171e9517f40e41", qop=auth, nc=00000001, cnonce="0a4f113b"

Параметры Digest:

username — имя пользователя.
realm — область, полученная от сервера.
nonce — то же число, что и от сервера.
uri — путь запрашиваемого ресурса.
response — вычисленный дайджест.
opaque — строка, полученная от сервера.
qop — качество защиты, выбранное клиентом.
nc — счётчик nonce (шестнадцатеричное число, увеличивается с каждым запросом).
cnonce — случайное число, сгенерированное клиентом.

¶Коды состояния HTTP

RFC 2617 использует два основных кода состояния HTTP:

401 Unauthorized — сервер требует аутентификации. В ответе обязательно присутствует заголовок WWW-Authenticate.
403 Forbidden — аутентификация прошла успешно, но доступ запрещён (например, недостаточно прав).

¶Применение

RFC 2617 широко применяется в веб-разработке, особенно в устаревших системах и API, где требуется простая аутентификация без использования токенов (например, OAuth 2.0). Примеры:

Веб-серверы (Apache, Nginx) — поддержка Basic и Digest для защиты директорий.
Прокси-серверы — аутентификация для доступа к прокси (заголовок Proxy-Authenticate).
Встроенные системы — маршрутизаторы, принтеры, IP-камеры (часто используют Basic с HTTPS).
API — некоторые старые REST API используют Digest для аутентификации (например, в системах управления контентом).

¶Критика и ограничения

RFC 2617 подвергается критике за несколько недостатков:

Хранение паролей — сервер должен хранить пароль в виде, позволяющем вычислять HA1 (хеш пароля), что делает его уязвимым к атакам на базу данных.
Отсутствие защиты канала — Digest не шифрует данные, поэтому при использовании HTTP без HTTPS аутентификация остаётся уязвимой для MITM-атак (злоумышленник может подменить nonce или ответ).
Сложность реализации — правильное вычисление дайджеста требует точного соблюдения алгоритма, что может привести к ошибкам.
Устаревшие алгоритмы — использование MD5 (который считается небезопасным для криптографических целей) снижает надёжность.

В современных системах предпочтение отдаётся более безопасным методам, таким как OAuth 2.0, OpenID Connect или аутентификация на основе токенов (JWT), которые работают поверх HTTPS.

¶Интересные факты

RFC 2617 был одним из первых стандартов, предложивших механизм защиты от повторных атак (replay protection) в веб-аутентификации.
В некоторых реализациях Digest используется модифицированный алгоритм MD5-sess, который вычисляет HA1 один раз за сессию, что снижает нагрузку на сервер.
RFC 2617 не поддерживает многофакторную аутентификацию, что ограничивает его применение в современных системах безопасности.

¶Источники

RFC 2617 — «HTTP Authentication: Basic and Digest Access Authentication» (1999).
RFC 7235 — «Hypertext Transfer Protocol (HTTP/1.1): Authentication» (2015).
RFC 1945 — «Hypertext Transfer Protocol — HTTP/1.0» (1996).
RFC 2068 — «Hypertext Transfer Protocol — HTTP/1.1» (1997).
Книга: «HTTP: The Definitive Guide» (David Gourley, Brian Totty, 2002).
Документация Apache HTTP Server — модуль mod_auth_digest.

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru