OpenVPN 로그: 제어 채널 암호와 데이터 채널 암호

로그에 DHE-RSA-AES256-SHA 라고 표시되어도 그것은 연결 전체의 요약이 아닙니다. 이는 제어 채널을 보호하는 TLS 핸드셰이크에 속하며, 터널 내부의 트래픽은 전혀 다른 방식으로 암호화될 수 있습니다. 이것을 VPN의 데이터 암호라고 보고하는 것이 피해야 할 실수입니다.

중요한 결과는 두 가지이며 서로 다른 질문에 답합니다. 하나는 제어 채널에서 협상된 TLS 스위트이고, 다른 하나는 터널이 운반하는 패킷의 데이터 암호입니다.

두 가지 결과, 두 가지 질문

제어 채널은 핸드셰이크와 피어 간 관리 메시지를 운반합니다. 그 암호는 TLS 스택이 선택하므로 이름은 TLS 관례를 따릅니다. 데이터 채널은 사용자 트래픽을 운반하며 OpenVPN 자체의 암호 협상으로 구성됩니다.

어느 줄을 읽기 전에 어떤 질문에 답하는지 먼저 정하세요. 터널이 암호화되어 있는지와 핸드셰이크가 강한지는 같은 질문이 아닙니다.

두 줄을 모두 보여 주는 로그 발췌가 유용합니다. TLS 버전과 스위트는 제어 줄에서, 페이로드를 실제로 보호하는 알고리즘은 데이터 줄에서 읽으세요.

TLS 스위트 이름을 문맥 안에서 해독하기

OpenSSL 스타일의 역사적 이름인 DHE-RSA-AES256-SHA 에서는 각 구성 요소가 서로 다른 결정을 나타냅니다. DHE 은 일시적 Diffie-Hellman 키 합의이고, RSA 은 인증 방식이며, AES256 은 TLS 레코드에 대해 CBC 모드의 AES-256이고, SHA 은 SHA-1 기반 레코드 MAC입니다.

마지막 구성 요소는 인증서 지문이 아니며 그렇게 읽는 것은 흔한 오류입니다. 이름만으로는 프로토콜 버전을 알 수 없는 것은 TLS 1.3이 전혀 다른 명명 방식을 사용하기 때문입니다. TLS_AES_256_GCM_SHA384 는 그 새로운 형식을 따르며, 여기서 끝의 해시는 MAC 선택이 아니라 스위트 구성의 일부입니다. 구성 요소별 읽기는 오래된 명명 방식에만 적용하세요.

OpenSSL 스위트 참조 는 구성 요소가 낯설 때 이 이름들을 정의와 연결해 줍니다.

운반되는 트래픽에 대한 데이터 채널 결과 읽기

운반되는 트래픽의 경우 같은 세션의 데이터 채널 줄을 읽으세요. 설정의 data-ciphers 목록은 허용된 집합이며 특정 알고리즘이 협상되었다는 증거가 아닙니다. 로그는 선택을 기록하고, 설정은 후보 목록을 기록합니다.

AES-GCM 같은 AEAD 암호는 자체 무결성 검사를 갖고 있으므로 데이터 채널용 별도 HMAC은 그 경로에 포함되지 않습니다.

auth 지시문은 TLS, 인증서, 데이터 암호를 업그레이드하지 않습니다. 아직 다이제스트를 사용하는 프로토콜 부분을 위해 다이제스트를 선택하며, AEAD 데이터 암호에서는 구성할 별도의 데이터 HMAC이 없습니다.

신원 확인을 암호 결과에서 분리하기

인증서 서명 알고리즘, 신뢰 체인 검증, 피어 이름 확인은 또 다른 세 가지 속성이며 암호 이름은 이에 대해 아무것도 말하지 않습니다. 만료된 인증서는 스위트가 아무리 강해도 실패합니다. 서버 이름 불일치도 같은 방식으로 실패합니다. 프로필의 다이제스트 설정을 고쳐도 둘 중 어느 것도 복구되지 않습니다.

그 확인들은 암호 결과 옆에 리뷰 메모로 남기고, 결과에 합치지 마세요.

현재 세션에서 협상된 결과 기록하기

현재 연결에서 결과를 가져와 클라이언트와 서버 버전을 함께 기록하세요. 추가 전용 로그에는 이전 세션의 줄이 남을 수 있으며, 이를 현재 것으로 인용하면 해결된 문제가 계속되는 것처럼 보입니다.

정책 리뷰에서는 협상된 TLS 버전과 스위트, 선택된 데이터 암호, 인증서 검증 설정을 함께 설정 담당자에게 넘기세요. 그 계층을 바꾼 뒤 새 로그를 읽어 새로운 협상 값을 확인합니다.