Допустимо ли промежуточному прокси добавлять куки во время аутентификации прокси?
Недавно я столкнулся с определенным устройством безопасности (BlueCoat), которое требует, чтобы через него были проксированы все соединения с Интернетом (привет, человек посередине), и, соответственно, использует специальный сертификат SSL для перехвата всего трафика.
Это помешало нормальной работе Git, хотя соответствующие http.proxy а также http.sslCAInfo свойства были установлены, чтобы убедиться, что само соединение SSL работает.
Использование переменной среды GIT_CURL_VERBOSE=1мы обнаружили, что при использовании git clone, HTTP 407 (требуется проверка подлинности прокси). Git выполняет эту аутентификацию правильно, и в конце этого, устройство возвращает HTTP 200 с заголовком cookie Set-Cookie,
Затем Git подключится к целевому серверу, но без файла cookie, что приведет к HTTP 401.
Решением для этого является установка опции конфигурации git http.saveCookies=true
Вопрос: разрешено ли стандартами RFC, что промежуточный прокси-сервер добавляет файлы cookie?
Энтони Рич задал тот же вопрос списку рассылки http-state, но без ответа. Он отметил, что в
Механизм управления состоянием HTTP RFC 2965, 3.5. Кэширование прокси-роли. В нем говорится: Прокси НЕ ДОЛЖНЫ вводить собственные заголовки Set-Cookie2 (Cookie) в ответах (запросах) прокси.
Однако, заменяющий RFC 6265 больше не упоминает об этом.
1 ответ
HTTP-куки - это горячий беспорядок. Там нет реального стандарта; RFC, для чего это стоит, просто пытается документировать, что делают реальные пользовательские агенты.
В любом случае RFC, который вы, вероятно, хотите прочитать, это RFC 7235, который указывает, что прокси-серверы должны отправлять заголовок Proxy-Authenticate с ошибкой 401 для запроса информации аутентификации, а пользовательские агенты, получающие это, должны повторить запрос с Заголовок прокси-авторизации, содержащий информацию для аутентификации прокси.
Для предоставления этой информации может быть использован ряд методов запроса / ответа; наиболее широко используемым является "базовый" ( RFC 7617), поскольку практически все, что говорит по HTTP, реализует его.
IANA поддерживает реестр известных схем проверки подлинности HTTP. Как правило, они используют заголовки HTTP, названные ранее, или они отмечены как несовместимые. Никто не использует куки для аутентификации.
Я не могу сказать, разрешено ли для прокси-сервера добавлять или изменять файлы cookie. RFC на самом деле не совсем ясны в этом вопросе. Это, конечно, неожиданное поведение, особенно для аутентификации. И BlueCoat имеет долгую историю посредственного качества...