TLS 키 공유 대 클라이언트 인증서: 어느 쪽이 로그인을 수행하는가?

핸드셰이크에서 공개 키 교환 값을 실어 보내는 것은 클라이언트가 로그인하는 것과 같은 사건이 아닙니다. 하나는 연결을 위한 암호학적 상태를 세우고, 다른 하나는 클라이언트가 누구인지를 밝히며, 후자는 서버가 요청하고 교환이 이를 지원할 때만 일어납니다. 첫 번째를 두 번째로 여기면 VPN이 무엇을 숨기고 무엇을 숨기지 않는지에 대해 잘못된 결론에 이르게 됩니다. 메시지를 읽은 뒤 네 가지 속성 중 실제로 관찰한 것이 무엇인지 판단하십시오.

캡처에서 비슷하게 보이는 두 객체

TLS 1.3 클라이언트는 아무 인증서도 제시하지 않고 첫 비행에서 키 교환 자료를 제공할 수 있습니다. 그 기여는 서버가 공유 비밀을 도출하는 데 필요하기 때문에 설계상 공개입니다. 클라이언트 인증서는 다른 메시지이며 서버가 요청한 뒤에만 전송됩니다. 그것은 서버가 나중에 검증하는 신원을 담고, 상호 인증은 암호 모음이 함축하는 속성이 아니라 서버가 내리는 결정입니다. 애플리케이션 신원은 완전히 세 번째로, 로그인 양식, 베어러 토큰, 쿠키입니다. 그것들 중 어느 것도 핸드셰이크에 나타나지 않으며, 모두 네트워크 경로가 바뀌어도 유지됩니다.

네 행은 서로 독립적입니다. 연결은 첫째와 둘째 행을 가질 수 있고, 셋째 행을 건너뛰면서도 넷째 행을 쿠키 헤더에 실을 수 있습니다.

포착된 핸드셰이크가 무엇을 입증할 수 있는지 판단하십시오

핸드셰이크만으로 관찰자는 협상된 버전, 암호 모음, 서버 인증서, 공개 키 교환 값을 알게 됩니다. 그것으로 클라이언트 구현의 지문을 얻고 어느 서버와 연결했는지 볼 수 있습니다. 제공하지 않는 것은 연결을 복호화하는 데 필요한 비공개 상태이며, 그 비밀성은 공개된 몫이 아니라 일시적 교환에 기반합니다. 또한 계정 신원도 제공하지 않는데, 처음부터 핸드셰이크에 없던 것입니다.

따라서 정직한 결론은 좁은데, 이 교환에서는 클라이언트 인증서가 제시되지 않았습니다. 클라이언트가 연결 가능한 무엇도 보내지 않았다는 뜻도 아니고, 세션이 아무 식별자도 지니지 않았다는 뜻은 더욱 아닙니다.

암호 이름이 아니라 메시지를 읽으십시오

암호 모음에서 추론하는 대신 서버에 무엇을 요청하는지 물으십시오. 인증서 요청을 포함한 TLS 1.3 핸드셰이크는 기록에 보이며, 그것이 없다는 사실도 똑같이 보입니다.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

그다음 클라이언트 인증서를 구성해 반복하고 비교하십시오. 두 번째 실행은 인증서가 전송되고 수락되는 것을 보여야 하고, 첫 번째는 아무것도 보여 주지 않아야 하며, 그것이 논쟁의 구체적인 차이입니다.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

일반적인 브라우징 사례만 필요하다면 클라이언트의 상세 출력으로 프로토콜 버전, 검증 결과, 클라이언트 인증서가 제안되었는지를 보는 것으로 충분합니다. 인증서 요청을 결코 보내지 않는 서버는 그것을 받을 수 없습니다.

재개가 답을 바꾸는 곳

TLS 1.3의 재개는 비밀 상태에 연결된 티켓을 사용하므로 이후 연결이 완전한 인증서 교환 없이 완료될 수 있습니다. 그것은 관찰자가 보는 것을 줄이고 기록이 입증하는 것을 바꿉니다. 없던 신원을 만들어 내지는 않습니다. 재개된 세션은 여전히 같은 애플리케이션 세션에 속하며, 그 세션의 쿠키나 토큰은 중요한 식별자로 남습니다.

그래서 "클라이언트 인증서 없음"에서 멈추는 프라이버시 검토는 흥미로운 부분을 놓칩니다. 물어야 할 질문은 어느 쪽이 안정적인 식별자를 보유하는가이며, 한 번의 핸드셰이크에서 어떤 메시지가 빠졌는가가 아닙니다.

판정 하나가 아니라 네 가지 속성을 기록하십시오

키 합의, 서버 검증, 클라이언트 인증, 애플리케이션 신원을 각각의 근거와 함께 네 개의 별도 행으로 적으십시오. 이 목록은 프로토콜 버전이 바뀌어도 유지되며, 프라이버시에 관한 주장을 다른 사람이 검증할 수 있게 만듭니다. 그다음 네트워크 경로가 기여하는 바를 추가하십시오. VPN은 서비스가 보는 출발지 주소를 바꾸지만, 애플리케이션이 이미 가진 로그인, 쿠키, 기기 지문을 없애지는 않습니다.

연결의 협상된 버전과 인증서 요청 결과를, 다른 사람이 자기 캡처 없이 당신의 결론을 재현하는 데 필요한 짝이므로 함께 기록하십시오.