auth 다이제스트는 어떤 OpenVPN 패킷을 보호하는가

OpenVPN 다이제스트를 둘러싼 논쟁은 대개 엉뚱한 패킷에서 시작된다. auth SHA256 를 “SHA256을 제시하는 피어만 받아들인다”로 읽는 것은 가장 먼저 버려야 할 생각이다. 이 옵션은 특정 패킷에 대한 다이제스트를 지정하며, 어떤 패킷인지는 채널과 그 채널이 AEAD인지에 달려 있다. 아래 네 질문을 차례로 짚어 보면, 각 질문이 이 설정이 당신의 배포에서 무엇을 뜻할 수 있는지 좁혀 준다.

설정이 지켜야 할 채널을 지목하라

OpenVPN 에는 TLS 핸드셰이크 트래픽을 나르는 제어 채널과 터널 페이로드를 나르는 데이터 채널이 있다. auth 다이제스트는 둘 모두에서 역할을 하지만 같은 역할은 아니며, 프로필이 그 차이를 드러내는 경우는 드물다. 설정 파일을 건드리기 전에 둘 중 무엇을 제한하려는지 적어 두라.

아래 표는 같은 옵션이 각 문맥에서 어떻게 작동하는지 짧게 정리한 것이다.

의존하기 전에 데이터 채널이 AEAD인지 확인하라

협상된 데이터 암호가 AES-GCM 또는 CHACHA20-POLY1305라면 데이터 채널은 스스로를 인증하므로, 별도의 다이제스트가 당신이 상상하는 일을 하는 것은 아니다. 둘 다 AEAD 구성이라 무결성은 페이로드를 암호화하는 같은 연산에서 나온다. 이는 수준을 낮춘 것이 아니지만, “모든 데이터 패킷은 HMAC-SHA256”이라는 근거의 정책은 그 터널에서 사실과 다르다. 정책을 다시 쓰기 전에 협상된 값을 서버 로그나 클라이언트 상태 출력에서 확인하라.

협상은 집합의 다른 구성원에 이를 수 있으므로 프로필의 목록이 아니라 실제로 협상된 암호를 살펴보라.data-ciphers AES-256-GCM:AES-128-GCM 는 협상용 목록이며 두 항목 모두 AEAD이므로, 어느 쪽도 페이로드 보호를 위해 auth 다이제스트를 쓰지 않는다.

제어 채널 보호는 별개의 결정으로 다뤄라

tls-auth는 제어 채널 패킷에 HMAC을 더하고 그 다이제스트를 auth 설정에서 가져오므로, AEAD 터널에서도 의미 있는 다이제스트를 설정할 수 있다. tls-crypt는 자체 고정 보호를 가진 다른 방식이므로, tls-auth의 모든 성질을 물려받는다고 가정하지 마라. 가정을 옮기지 말고 고른 방식의 문서를 읽어라.

두 피어는 방식과 키 방향에도 합의해야 한다. 다이제스트는 맞아도 키 파일을 반대 방향으로 쓰면, 다이제스트 설정으로는 설명할 수 없는 이유로 핸드셰이크가 실패한다.

auth를 암호 협상과 인증서와 분리해 두라

세 가지 설정, 곧 auth 다이제스트와 데이터 암호 목록, 인증서의 서명 알고리즘이 늘 뒤섞인다. 첫째를 바꾼다고 인증서가 재발급되지 않고, 그 서명 다이제스트가 선택되지도 않으며, 사용자-비밀번호 방식이 생기지도 않는다. 프로토콜 옵션 정의는 OpenVPN 2.6 소스 에서 각각 독립된 절에 설명되어 있어, 이것들이 별개의 조정 항목임을 일러 준다.

다이제스트를 바꾼 뒤 피어가 연결을 거부하면 원인은 대개 나머지 두 설정 중 하나의 불일치다. 어느 쪽을 바꾸기 전에 양쪽을 읽어라.

정책을 적고 실행 중인 설정과 비교하라

플릿 수준의 문장은 허용되는 데이터 채널 모드와 선택한 제어 채널 보호를 같은 문장에서 분명히 밝혀야 한다. 그 문장은 검증할 수 있지만 “우리는 SHA256을 쓴다”는 검증할 수 없다. 그다음 저장소의 템플릿이 아니라 실제로 효력이 있는 서버와 클라이언트 프로필과 대조하라.

각 터널이 실제로 무엇을 협상했고 어떤 방식이 그 패킷을 인증했는지 기록하며 마무리하라. 프로필에 보이는 auth 줄은 설정 의도의 증거일 뿐이며, 의도는 확인 작업에서 가장 값싼 부분이다.