VPN 인증서 지문을 별도 채널로 검증하는 방법
지문은 기대값이 공격자가 통제하지 않는 채널로 도착할 때만 신원을 증명합니다. 다음 순서로 점검하십시오.
지문은 무엇을 기대해야 하는지 알려 준 채널만큼만 신뢰할 수 있습니다. 비교하는 값이 지금 시험 중인 바로 그 연결로 도착했다면, 그 비교는 그 연결을 통제하는 쪽이 일관적이라는 사실 말고는 아무것도 증명하지 못합니다. 점검은 정해진 순서로 진행되어야 하며, 실패한 단계는 다음 단계로 밀어내는 대신 멈추게 해야 합니다. VPN 클라이언트가 인증서가 바뀌었다고 보고할 때 제가 쓰는 순서는 다음과 같습니다.
값을 부르기 전에 대상을 부르십시오
기대값이 서버 리프 인증서의 것인지, 발급한 CA의 것인지, 리프 안의 공개 키의 것인지 정하십시오. 이들은 서로 다른 세 가지 점검이며, 서로 다른 방식으로 실패합니다. 일치하는 CA 지문은 서버를 고정하지 않으며, 공개 키 해시는 같은 키를 유지하는 재발급을 의도적으로 견딥니다.
알고리즘도 적어 두십시오. SHA-256이 지금의 표준 기대값이지만, 오래된 도구는 다른 것을 요청하지 않으면 SHA-1을 출력했고, 40자리 헥스 값은 곧 서로 다른 두 가지를 비교하려 한다는 신호입니다.
기대값을 두 번째 채널로 받아 오십시오
두 번째 채널은 경계하는 상대가 쓸 수 없는 채널이어야 합니다. 이미 인증하는 프로비저닝 시스템, 금고에 보관된 인쇄 기록, 구성 데이터베이스, 다른 프로세스가 전달하는 서명된 문서는 모두 해당합니다. 동료의 채팅 메시지, 검색 결과로 도달한 지원 페이지, 지금 디버깅 중인 터미널에 붙여 넣은 것은 모두 해당하지 않습니다.
전체 값과 알고리즘을 요청하고, 접두사는 절대 요청하지 마십시오. 콜론과 대소문자는 중요하지 않지만, 잘라내면 256비트 점검이 추측 게임이 됩니다.
독립된 출처에서 기대값을 제시할 수 있는 사람이 없다면, 정직한 결과는 이 인증서를 오늘 검증할 수 없다는 것입니다. 그렇게 말하는 편이 클라이언트가 방금 표시한 값을 고정하는 것보다 낫고, 후자는 경고를 습관으로 바꿉니다.
값을 자기 쪽에서 추출하십시오
인증서 파일이라면 명령은 openssl x509 -in server.crt -noout -fingerprint -sha256 입니다. 명시적 다이제스트가 중요하며, 지정하지 않으면 출력이 OpenSSL 버전에 따라 달라집니다. 결과는 콜론으로 구분된 헥스 문자열이므로, 비교하기 전에 콜론을 제거하고 양쪽을 소문자로 맞추십시오.
TLS를 직접 말하는 엔드포인트라면 연결해서 인증서를 파이프로 빼내십시오: openssl s_client -connect vpn.example.com:443 -servername vpn.example.com < /dev/null | openssl x509 -noout -fingerprint -sha256. 이것은 웹 관리 패널이나 TLS 리스너에는 통하지만, 제어 채널이 터널 안에 있는 OpenVPN에는 통하지 않습니다. OpenVPN의 경우 소켓에서 잡으려 하지 말고 디스크의 프로필에서 인증서를 읽으십시오.
비교는 기계적이어야 합니다. tr -d ':' 와 대소문자 통일로 두 값을 정규화한 다음 문자열 전체를 비교하십시오. 눈으로 비교하는 것이 바로 일치하는 접두사가 마지막 바이트의 불일치를 숨기는 방식입니다. 문자열이 다르면 설명을 찾기 전에 그 차이를 실제로 받아들이십시오.
중지 조건
대상이 다르면, CA 지문은 리프 인증서를 면제해 주지 못하고 리프도 CA를 면제해 주지 못하므로 멈추십시오. 알고리즘이 다르면, SHA-1 값과 SHA-256 값을 비교해도 아무것도 알 수 없으므로 멈추십시오. 지문이 일치해도 인증서가 만료되었거나 폐기되었거나 다른 이름으로 발급되었다면, 일치하는 해시는 유효성 점검이 아니며 끊어진 체인을 고치지도 않으므로 멈추십시오. 일련번호가 대조하는 기록의 일련번호와 다를 때도, 바꿔치기된 인증서를 알아채는 가장 값싼 방법이므로 멈추십시오.
새 값이 시험 중이던 채널로 도착했다면 멈추십시오. 회전은 지문을 정당하게 바꿀 수 있지만, 대체 값은 여전히 신뢰된 프로세스에서 와야 하며 질문을 촉발한 경고 대화상자에서 와서는 안 됩니다.
권고된 수정이 호스트 이름 검증이나 체인 검증을 끄는 것이라면 멈추십시오. 지문은 정상 점검에 제약을 하나 더하는 것이지 대체하는 것이 아니며, 배포가 의도적으로 핀 전용 모델을 택한 경우가 아니라면 그 선택에는 자체 운영 비용이 따릅니다.
비교 후에
무엇을 비교했는지, 기대값이 어디서 왔는지, 언제였는지를 기록하십시오. 인증서가 재발급되었다면 같은 신뢰 채널로 저장된 기대값을 갱신하고, 다음 회전을 감사 가능하게 만드는 일련번호를 새로 적어 두십시오.
그다음 한계를 분명히 하십시오. 지문은 가지고 있는 인증서가 누군가 기대하라고 알려 준 바로 그 인증서임을 확인합니다. 호스트가 침해되지 않았다는 것에 대해서는 아무 말도 하지 않으며, 그 인증서가 어디까지 닿을 수 있는지를 서비스가 기록하거나 제한하는지에 대해서도 아무 말도 하지 않습니다.