요약

  • HTTP 511은 클라이언트에게 더 넓은 연결을 얻기 전에 접속 네트워크의 요구를 충족해야 한다고 알려 줍니다. 이 코드는 요청에 명시된 원 서버가 아니라, 경로에 놓인 가로채기 프록시를 위한 것입니다.
  • 511 응답은 원 서버의 신원 아래에서 인증 요구를 제시하기보다 별도의 로그인 리소스를 가리켜야 합니다. 이 코드는 혼란을 줄여 주지만, 가로채기를 신뢰할 수 있게 만들거나 TLS 인증서 실패를 해결하지는 못합니다.

답은 잘못된 권위에서 왔다

날씨 애플리케이션이 새 네트워크에 접속하는 상상을 해 보십시오. 이 앱은 신뢰하는 날씨 서비스에 작은 문서를 요청합니다. 예보 데이터 대신 호텔 로그인 페이지를 받습니다. 바이트는 앱의 HTTP 연결을 통해 도착했지만, 호텔은 날씨 원 서버가 아니며 그 페이지도 요청된 작업에 대한 답이 아닙니다.

브라우저는 페이지를 표시하고 사용자에게 그것을 판단하도록 요청할 수 있습니다. 그러나 캘린더 동기화 프로세스, 패키지 업데이터, API 클라이언트는 접근을 협상할 사람 없이 그것을 원 서버 응답으로 해석하고, 캐시하고, 손상을 보고하거나 리디렉션을 따라갈 수 있습니다. 네트워크는 한 권위의 메시지를 자신의 요구로 대체한 것입니다.

RFC 6585는 2012년511 Network Authentication Required를 도입해 이 개입의 모호성을 줄였습니다. 이 상태 코드는 클라이언트가 네트워크 접근을 얻으려면 인증이 필요하다고 말합니다. 더 중요한 것은 누가 그것을 발행해야 하는지입니다. 요청된 원 서버가 아니라, 연결을 제어하기 위해 경로에 놓인 가로채기 프록시여야 합니다.

네트워크 접속 허가는 원 서버 인증이 아니다

“인증”이라는 단어는 서로 다른 두 관계를 감출 수 있습니다. 원 서버는 애플리케이션 리소스에 대한 접근을 위해 클라이언트에게 인증을 요구할 수 있습니다. 네트워크는 트래픽을 전달하기 전에 결제, 약관 동의 또는 다른 상호작용을 요구할 수 있습니다. 이 두 권위는 서로 바꿔 쓸 수 없습니다.

RFC 6585는 원 서버가 511을 생성해서는 안 된다고 말합니다. 애플리케이션 자격 증명이 필요한 원 서버에는 일반적인 HTTP 인증·권한 부여 의미 체계가 있습니다. 511은 대신 접속 경로가 부과한 전제 조건을 식별합니다.

이 구분은 양쪽을 보호합니다. 포털은 패킷을 차단할 수 있다는 이유만으로 날씨 서비스를 사칭할 권리를 얻지 않습니다. 원 서버도 포털의 계약에 대한 책임을 지지 않습니다. 클라이언트는 애플리케이션 자격 증명을 고쳐도 현재 상황이 해결되지 않을 가능성이 높다는 것을 알게 됩니다.

이 상태 코드는 근거의 한계 안에 있습니다. 접속 네트워크의 조건을 보고할 수는 있지만, 기기를 사용하는 실제 사람, 그 장소의 약관의 정당성, 응답에 명시된 포털의 안전성을 증명할 수는 없습니다.

응답에는 로그인이 아니라 링크가 담겨야 하는 이유

RFC 6585는 511 표현이 사용자가 자격 증명을 제출할 수 있는 리소스로 연결되는 링크를 담을 것을 권고합니다. 또한 응답에는 인증 챌린지나 로그인 인터페이스 자체가 담겨서는 안 된다고 말합니다.

이 절제는 원 서버 혼란에 관한 것입니다. 브라우저는 사용자가 방문하려 한 URL의 맥락 안에 콘텐츠를 표시합니다. 가로채기 프록시가 비밀번호 양식을 그 응답에 직접 넣으면, 그 인터페이스가 요청된 사이트에 속하는 것처럼 보일 수 있습니다. 챌린지 역시 원 서버가 비밀을 요구하는 것으로 오인될 수 있습니다.

링크는 상호작용을 자체 이름을 가진 다른 리소스로 옮깁니다. 그것은 더 나은 경계이지만 자동적인 신뢰의 증서는 아닙니다. 클라이언트는 여전히 그것을 열지 결정하고, 호스트명을 명확히 표시하고, TLS 인증서를 검증해야 합니다. 포털은 자신이 받을 권한이 있는 자격 증명만을 요구해야 합니다.

따라서 511은 인계를 완성하는 것이 아니라 그것을 알리는 역할을 합니다. 원래 요청은 성공하지 않았습니다. 사용자는 별도로 식별된 포털을 방문하고, 조건을 충족한 뒤, 원 서버에 대해 의도한 작업을 반복할 수 있습니다.

브라우저가 아닌 클라이언트는 가로채기의 실제 비용을 드러냈다

RFC 6585는 511을 캡티브 포털에 대한 피해 통제로 명시적으로 규정하며, 특히 브라우저가 아닌 소프트웨어를 염두에 둡니다. 이것은 가로채기를 승인하지 않습니다.

자동화된 클라이언트는 요청에 명시된 서버가 응답을 제어한다고 기대합니다. 소프트웨어 업데이트 매니페스트를 HTML로 대체하면 형식이 잘못된 메타데이터처럼 보일 수 있습니다. WebDAV 응답을 대체하면 허위 동기화 오류를 만들 수 있습니다. 리디렉션도 권위 문제를 해결하지 못합니다. 소프트웨어는 그것을 따라가 포털 출력을 마치 원래 워크플로우에 속한 것처럼 계속 처리할 수 있기 때문입니다.

프로토콜이 HTTP를 기반으로 사용할수록, 무차별적 치환의 비용은 커집니다. 하나의 가로채기 정책은 접속 운영자가 이해하지 못하는 애플리케이션 경계를 가로지릅니다. 뚜렷한 상태 코드는 강건한 클라이언트에게 원 서버 작업을 무심코 수정·캐시·재시도하는 대신 중단할 이유를 줍니다.

캐시는 구속 상태를 원 서버 상태로 만들어서는 안 된다

RFC 6585는 캐시가 511 응답을 저장하는 것을 금지합니다. 이 조건은 연결된 네트워크, 접속 허가 상태, 특정 순간에 속합니다. 저장된다면 접근이 허가된 뒤나 클라이언트가 다른 네트워크로 옮긴 뒤에도 클라이언트를 따라다닐 수 있습니다. 더 나쁘게는 마치 요청된 원 서버를 기술하는 것처럼 재사용될 수 있습니다.

포털은 현재의 강제 상태로부터 새로운 접속 결정을 만들어 낼 수 있습니다. 캐시는 그 가로채기를 보존할 권위가 없습니다.

TLS는 HTTP가 복구할 수 없는 치환을 드러낸다

평문 HTTP에서는 중간자가 응답을 대체하고 511을 붙일 수 있습니다. HTTPS에서는 클라이언트가 먼저 TLS를 통해 서버 이름을 인증합니다. 캡티브 포털은 요청된 원 서버의 인증서를 가지고 있지 않습니다. RFC 6585는 따라서 가로채기가 인증서 오류를 일으킨다고 언급합니다.

포털이 정직하게 완료할 수 없는 TLS 핸드셰이크 뒤에 511을 반환하는 것은 불가능합니다. 인증서 경고를 억제하면 네트워크에 원 서버의 신원을 부여하게 되는데, 이것이 바로 이 코드가 봉쇄하려는 권위 혼란 그 자체입니다.

보안 문제는 상태 코드보다 넓습니다. 중간자는 HTTP 인증 자료를 관찰하거나 원 서버 이름공간의 쿠키를 조작할 수 있습니다. RFC 6585는 캡티브 포털이 511을 사용하든 아니든 이러한 위험을 가져온다고 강조합니다. 더 명확한 오류가 불안전한 경로를 정화해 주지는 않습니다.

갑작스러운 가로채기에서 사전 준비된 상태로

이후의 캡티브 포털 아키텍처인 RFC 8952는 시스템을 역할별로 분리합니다. 프로비저닝은 사용자 장비에게 Captive Portal API의 위치를 알려 주고, API는 상태를 보고하며, 사용자 포털이 상호작용을 처리하고, 강제 장치가 트래픽을 차단하거나 허용합니다. RFC 8908은 HTTPS API 교환을 정의합니다.

이것은 발견 메커니즘을 바꿉니다. 무관한 원 서버에 평문 카나리아를 보내고 변조를 관찰하는 대신, 클라이언트는 네트워크에 접속할 때 API URI를 학습합니다. API 서버의 TLS 인증서를 인증하고, 자신의 캡티브 상태를 문의하며, 필수 불리언 값과 관련 시에는 TLS 사용자 포털 URL을 받습니다.

사용자가 조건을 충족한 뒤 클라이언트는 다시 질의하여 구속이 끝났음을 확인합니다. 포털 완료는 단순히 양식 제출이 성공했거나 리디렉션이 일어났다는 이유만으로 추정되지 않습니다. 상태 권위는 같은 사용자 장비 인스턴스에 대해 API와 강제 시스템에 속합니다.

이 설계는 레거시 포털을 폐지하지 않으며, API와 강제 장치 사이의 신중한 신원 결합도 여전히 필요합니다. 그러나 네트워크의 주장을 네트워크가 운영할 권한이 있는 이름과 채널로 옮깁니다. 이제 날씨 원 서버가 우연한 발견 표면이 될 필요는 없습니다.

511이 담을 수 있었던 좁은 진실

511은 포털을 인증하거나, 가로채기를 합법화하거나, TLS를 무력화하거나, 누군가 무언가에 동의했음을 증명할 수 없습니다. 원 서버가 401이나 403의 대체물로 사용할 수도 없습니다. 그 기여는 더 좁았습니다. 접속 허가 요구의 발신자로서 접속 네트워크에 이름을 붙이고, 그 요구가 재사용 가능한 원 서버 콘텐츠처럼 보이지 않게 하는 것입니다.

이후의 API 아키텍처는 같은 원칙을 확장합니다. 권한은 자신의 신원으로부터 말해야 합니다. 네트워크는 전달을 제어할 수 있습니다. 그러나 그 통제를 설명하기 위해 목적지의 목소리를 빌릴 필요는 없습니다.

출처