알려진 엔드포인트를 위한 사전 Basic 프록시 인증

챌린지를 먼저 기다리는 클라이언트는 프록시가 요청하기를 기다립니다. 사전 Basic 클라이언트는 선택된 엔드포인트를 이미 알고 있으며 첫 번째 해당 요청에 자격 증명을 보냅니다. 그 교환을 없애는 것이 유용할 수 있습니다. 그래도 비밀번호가 어디로 가는지에 대한 결정입니다.

최적화 전에 엔드포인트를 파악하세요

인증 정책이 알려진 고정 사설 프록시는 낯선 중개자를 선택할 수 있는 라우팅 계층보다 명확한 사례입니다. 계정을 예상되는 프록시 ID와 프로토콜에 연결하세요. 모든 챌린지에 하나의 회사 비밀번호로 응답하는 일반 콜백을 만들지 마세요.

Basic은 암호화된 증명이 아니라 계정의 base64 표현을 전달합니다. 프록시 리스너까지의 TLS는 사이트의 HTTPS 세션과 별개의 연결 선택입니다. 사이트의 HTTPS 터널은 암호화되지 않은 클라이언트-프록시 연결로 전송된 Basic 자격 증명을 소급해 보호하지 않습니다. 사설 LAN은 위치이지 암호화 속성이 아닙니다.

메커니즘을 구체적으로 유지하세요

사전 Basic은 Digest, NTLM, Negotiate의 범용 지름길이 아닙니다. 그 메커니즘에는 자체 교환 요구 사항이 있습니다. 지원되는 스킴을 발견한 클라이언트가 추가 트랜잭션을 수행하는 것은 정당합니다.

선택한 라이브러리의 프록시 인증 인터페이스를 사용한 다음 실제 스킴과 범위를 확인하세요. 대상 사전 인증 설정이 프록시 핸드셰이크를 제어하지 않을 수 있습니다. 기존 인증 연결이 있으면 새 연결이 챌린지를 수행할지도 가릴 수 있습니다.

전체 작업을 비교하세요. 교환 횟수, 완료 시간, 필요한 전송 보호, 프록시가 바뀔 때의 동작입니다. 로그가 더 깔끔한 것이 유용한 경우는 애플리케이션이 여전히 의도한 중개자에게 인증하고 그 구성이 확립될 수 없을 때 멈출 때뿐입니다.