HTTPS 기반 기본 인증과 IPsec 비교: 각각 무엇을 보호하는가

개발자 도구를 열고 내부 앱을 불러온 뒤 페이지가 렌더링되기 전에 요청 하나가 네 개의 검사 지점을 통과하는 모습을 지켜보십시오. 먼저 이름이 해석되고, 다음으로 TCP 연결이 열리고, 다음으로 TLS 핸드셰이크가 서버가 누구인지 확립하며, 그다음에야 애플리케이션이 당신이 누구인지 묻습니다. 각각 다른 증거로 실패하고 각각 다른 팀이 담당하기 때문에 이것들을 별개의 사건으로 다루십시오. 사고에서 혼란의 대부분은 401을 터널 문제로 읽거나, 터널 문제를 잘못된 비밀번호로 읽는 데서 옵니다.

검사 지점 하나: 이것이 당신이 말하려던 서버인가

TLS 핸드셰이크는 자격 증명이 전송되기 전에 그 질문에 답합니다. 클라이언트는 인증서 체인을 신뢰 저장소에 대고 검증하고 인증서의 이름이 당신이 입력한 호스트와 일치하는지 확인합니다. 이것이 실패하면 브라우저는 인증서 오류를 표시하고 Authorization 헤더를 아예 보내지 않습니다. 따라서 비밀번호 입력 요구는 서버가 진짜라는 증거가 아니라, 애플리케이션이 응답했다는 증거입니다.

여기서 첫 번째 경계가 나타납니다. TLS는 연결을 종료 지점까지만 보호합니다. 로드 밸런서가 TLS를 종료하고 애플리케이션에 평문 HTTP를 전달하면 암호화 구간은 로드 밸런서에서 끝나고, 자격 증명은 그 첫 구간에서만 보호됩니다.

검사 지점 둘: 401 교환에서 실제로 무엇이 이동하는가

HTTP 기본 인증은 사용자 식별자와 비밀번호를 헤더에 담아 보내며, Base64로 인코딩되고, 그 규격은 RFC 7617에 설명되어 있습니다. Authorization: Basic dXNlcjpwYXNz이 그 형태이며, 인코딩은 요청을 읽을 수 있는 사람이면 누구나 되돌릴 수 있으므로 모든 기밀성은 아래 전송 계층에서 옵니다. curl -v은 WWW-Authenticate: Basic 챌린지와 당신이 돌려보내는 헤더를 모두 보여줍니다.

그 헤더는 애플리케이션에 누가 묻는지 알려줍니다. 네트워크에 누가 연결할 수 있는지는 알려주지 않으며 그 자체로 무엇도 암호화하지 않습니다. 애플리케이션은 여전히 자격 증명을 저장소에 대고 확인하고 그 계정이 무엇을 할 수 있는지 결정해야 하며, 그것이 인가이고 인증 후에 일어납니다.

그 경로에서 IPsec 터널은 어디에 있는가

이제 브라우저에서 바깥으로 걸어가 보십시오. 게이트웨이 간 IPsec 터널은 두 보안 게이트웨이 사이의 선택된 트래픽을 보호하며, 당신의 노트북과 애플리케이션 프로세스 사이를 보호하지 않습니다. 터널 모드 ESP는 원래 패킷을 감싸고, 게이트웨이가 그것을 암호화하고 인증하며, 내부 주소는 남아 있어 먼 쪽이 요청을 애플리케이션으로 라우팅할 수 있습니다.

선택이 사람들을 발목 잡는 부분입니다. 정책 기반 터널은 트래픽 선택자를 사용하며, 흔히 접근 제어 목록으로 표현되어 어떤 패킷이 터널에 들어가는지 결정합니다. 경로 기반 터널은 대신 가상 인터페이스와 라우팅 테이블을 사용합니다. Linux에서는 ip xfrm policy이 선택자를, ip xfrm state가 설정된 보안 연관을 보여주며, 방화벽 장비에서는 터널의 SA 테이블과 패킷 추적기가 그에 해당합니다.

결과는 분명히 말할 가치가 있습니다. 패킷은 완전히 건강한 터널 안에 있으면서도 애플리케이션이 거부하는 HTTPS 요청을 실어 나를 수 있고, 유효한 자격 증명은 라우팅이 허용한다면 터널이 전혀 없는 경로로 도착할 수도 있습니다.

보고한 계층에서 실패를 읽으십시오

401은 애플리케이션이 자격 증명을 받아들이지 않았다는 뜻입니다. 403은 신원을 받아들이고 작업을 거부했다는 뜻입니다. TLS 오류는 클라이언트가 서버를 받아들이지 않았다는 뜻입니다. 경로가 없거나 정책이 맞지 않는다는 것은 패킷이 먼 게이트웨이에 도달하지 못했다는 뜻입니다. 네 가지 다른 실패, 네 명의 다른 담당자, 그리고 로그인 양식을 들여다보는 것으로는 그중 어느 것도 진단되지 않습니다.

상태와 헤더에는 브라우저의 네트워크 패널, 인증서 체인에는 openssl s_client -connect host:443, 터널 트래픽에는 게이트웨이의 SA 카운터와 로그, 계정 결정에는 애플리케이션 로그라는 각 계층의 증거를 사용하십시오. 두 계층이 동시에 오류를 보고하면, 죽은 터널이 인증 실패를 쉽게 가릴 수 있고 그 반대도 마찬가지이므로 더 낮은 계층을 먼저 고치십시오.

하나의 서비스를 끝에서 끝까지 지도로 그리기

진단 중인 서비스에 대해 터널이 어떤 피어를 연결하는지, 선택자가 어떤 서브넷과 포트를 허용하는지, TLS가 어디서 끝나고 인증서가 어떤 신원을 주장하는지, 어떤 애플리케이션 계정과 역할이 쓰이는지, 각 계층이 어디에 로그를 남기는지 다섯 줄을 쓰십시오. 지도의 목적은 한 계층의 책임이 어디서 끝나고 다음 계층이 어디서 시작하는지 보여 주는 것이므로 한 페이지에 담으십시오.

그다음 계층마다 부정 사례를 하나씩 시험하십시오. 잘못된 비밀번호를 쓰고 타임아웃이 아니라 401이 오는지 확인하십시오. 선택자 밖의 서브넷에서 연결하고 패킷이 터널을 통과하지 않는지 확인하십시오. 잘못된 이름의 인증서를 제시하고 클라이언트가 자격 증명을 보내기 전에 거부하는지 확인하십시오. 그 세 가지 결과는 어떤 상자 그림보다 설계에 대해 더 많이 알려 줍니다.

마지막으로 각 관계에 어떤 보호가 필요한지 의도적으로 결정하십시오. TLS 위의 기본 인증은 게이트웨이 뒤의 작은 내부 도구에 합리적인 선택이지만, 사용자별 인가나 TLS 종료 지점 너머의 트래픽 보호를 대신하지는 않습니다. 터널은 경로를, 인증서는 구간을, 401은 계정을 보호하며, 당신이 누구인지 아는 것은 마지막 하나뿐입니다.