Упреждающая Basic-аутентификация на прокси для известной конечной точки

Клиент, ожидающий вызова, ждёт, пока прокси спросит. Клиент с упреждающей Basic уже знает выбранную конечную точку и отправляет учётные данные в первом подходящем запросе. Убрать этот обмен может быть полезно. Но это всё равно решение о том, куда попадает пароль.

Знайте конечную точку до оптимизации

Фиксированный частный прокси с известной политикой аутентификации — более ясный случай, чем слой маршрутизации, который может выбрать незнакомого посредника. Привяжите учётную запись к ожидаемой идентичности прокси и протоколу. Не создавайте общий callback, отвечающий на каждый вызов одним корпоративным паролем.

Basic передаёт base64-представление учётной записи, а не зашифрованное доказательство. TLS до слушателя прокси — отдельный выбор соединения, отличный от HTTPS-сессии сайта. HTTPS-туннель сайта не защищает задним числом учётные данные Basic, отправленные по незашифрованному соединению клиент–прокси. Частная LAN — это место, а не свойство шифрования.

Держите механизм конкретным

Упреждающая Basic — не универсальный короткий путь для Digest, NTLM или Negotiate. У этих механизмов свои требования к обмену. Клиент, обнаруживающий поддерживаемые схемы, вправе выполнять дополнительные транзакции.

Используйте интерфейс аутентификации на прокси выбранной библиотеки, затем проверьте фактическую схему и область действия. Настройка предварительной аутентификации пункта назначения может не управлять рукопожатием с прокси. Существующее аутентифицированное соединение тоже может скрывать, выполнит ли новое соединение вызов.

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