캡 티브 포털의 SSL 인증서 오류

상황 : 호텔 고객이 우리의 포로 포털을 통해 인터넷에 액세스하려고합니다. 문제 : Google, Yahoo 및 이제 더 많은 사이트가 모든 홈 페이지를 HTTPS로 리디렉션하므로 게스트가 로그온 페이지로 리디렉션 할 때 인증서 오류가 발생합니다. SSL의 올바른 목적은 정확히이 작업을 수행하는 것이지만 방화벽을 통한 액세스를 활성화하기 전에 게스트 로그온 확인 프로세스를 관리하여 ID를 확인하는 다른 방법이 있는지 궁금합니다. 이해하지 못하는 사람들을 놀라게합니다. 기본적으로 포로 포털 / 인증 프로세스를 위해 다른 아키텍처가 필요하며 어떤 생각을 가지고 있는지 궁금합니다. 감사.

"포로 포털"의 전체 정의는 "자신의 지식없이 사용자를 리디렉션"하는 것입니다. 이는 SSL을 피하기 위해 만든 것 중 하나입니다.

브라우저에서 열려고하는 첫 번째 URL이 HTTPS 인 경우 인증서 오류없이 트래픽을 리디렉션 할 수 없습니다.

Chromium 프로젝트에는 캡 티브 포털을 감지하기위한 로직의 작동 방식 을 설명하는 유용한 페이지가 있습니다 .

1. 잘 알려진 호스트 + URI에 연결 (일반 HTTP) 시도
2. 배고 있다 HTTP 204 No Content
3. 다른 응답이 수신되면 포로 포털이라고 가정하십시오.

제공된 링크에는 잘 알려진 호스트 등을 해결하려고 할 때 DNS 실패를 처리하는 방법에 관한 다른 세부 정보가 있습니다. 이것은 단지 하나의 예일 뿐이지 만 (개인 경험상) 현대 OS 설계는 이와 유사한 프로세스를 사용하여 탐지합니다. 경우에 따라 사용자가 브라우저를 열기 전에도 사용자에게 메시지를 표시합니다. (고려 : IMAP 클라이언트 또는 다른 비 HTTP 서비스 만 사용하려는 사람)이 경우 SSL / TLS를 통해 탐지 되지 않으므로 걱정할 필요가 없습니다.

RFC 6585 6 장511 Network Authentication Required 에서는 SSL / TLS 사례에 도움이되지 않지만 아직 사용하지 않을 경우 고려해야 할 또 다른 표준 인 새로운 HTTP 상태 코드 를 제안 합니다.

어쨌든 사용자에게 인증서 오류가 발생하면 인증서 가 사이트 호스트 이름 과 일치하지 않기 때문 입니다.

귀하의 경우 이는 URL을 변경하지 않고 사용자를 포털로 리디렉션한다는 의미입니다. 사용자 는 주소 표시 줄에 " http://www.google.com "이 표시되고 화면에는 포털이 표시됩니다. 이것들은 분명히 일치하지 않으며 인증서도 일치하지 않습니다.

HTTP로 (HTTPS 점프하기 전에) 포털 주소 (또는 서버 이름)로 리디렉션하고 로그인 한 다음 원하는 대상으로 다시 리디렉션해야합니다.

HTTP 3xx 코드, 특히 303으로 수행하는 방법 은 https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx 를 참조 하십시오 .

임시 솔루션은 사용자가 Wi-Fi 신호가 연결된 후에 만 ​​"http"로 시작하는 URL을 시작하도록 안내합니다.

그러나 불행히도 사용자는 그것을 좋아하지 않습니다. "WiFi 서비스가 얼마나 복잡 했습니까?"