OpenVPN에서 dh none과 RSA 인증서를 함께 쓸 수 있습니까?

여기에 RSA라고 적힌 인증서 옆에 dh none이라고 적힌 서버 구성이 있고, 둘 중 하나는 반드시 틀렸다는 괴로운 의심도 함께 있습니다. 아무것도 틀리지 않았습니다. 인증서는 서명하고 인증하며, 키 교환은 공유 비밀을 설정합니다. 이는 같은 핸드셰이크 안의 두 가지 다른 작업이며, TLS는 RSA 인증서가 임시 타원 곡선 합의를 사용하는 핸드셰이크를 인증하도록 허용합니다.

혼란은 보통 마이그레이션 안내서와 함께 옵니다. DH 매개변수 파일을 dh none로 바꾸라고 하고, 독자는 인증서가 타원 곡선 인증서가 아니라는 점을 알아차리며, 두 사실이 모순으로 취급됩니다.

두 설정이 관련 있어 보이는 이유

OpenVPN의 오래된 구성이 DH 매개변수 파일을 요구한 것은 유한체 Diffie-Hellman이 양쪽이 합의하는 도메인 매개변수를 필요로 하기 때문입니다. dh 지시문이 그 파일을 가리켰습니다. 배포가 ECDH로 넘어가면 매개변수는 대신 이름 있는 곡선에서 오고 파일은 더 이상 필요 없으며, 그것이 dh none이 표현하는 바입니다.

인증서는 별개의 축입니다. 인증서는 서버의 신원을 증명하는 공개 키와 서명을 담고 있으며, 그 키는 세션 키가 어떻게 합의되는지와 무관하게 RSA이거나 타원 곡선일 수 있습니다. 키 합의에 ECDHE를, 인증에 RSA를 사용하는 핸드셰이크는 흔하고 널리 배포되어 있습니다.

이름 붙이기가 겹침을 악화시킵니다. 타원 곡선은 ECDHE와 ECDSA 스위트 이름 모두에 나타나므로, 곡선을 언급하는 연결이라면 반드시 곡선 인증서를 포함해야 한다고 가정하기 쉽습니다. 그렇지 않습니다.

TLS 1.2 스위트 이름을 올바르게 읽는 법

ECDHE-RSA-AES256-GCM-SHA384를 봅시다. 첫 번째 토큰은 키 교환 계열로, 임시 타원 곡선 Diffie-Hellman입니다. 두 번째는 인증 계열로, RSA입니다. 나머지는 레코드 보호와 핸드셰이크에 사용되는 해시를 설명합니다.

ECDHE-ECDSA 스위트는 같은 키 교환 계열을 다른 인증 방식으로 사용하므로 타원 곡선 인증서가 필요합니다. DHE-RSA 스위트는 RSA 인증과 함께 유한체 임시 Diffie-Hellman을 사용하며, 그것은 실제로 DH 매개변수가 필요합니다.

스위트 이름을 왼쪽에서 오른쪽으로 읽고 각 부분을 제 작업에 배정하십시오. 토큰이 분리되면 질문은 «내 인증서가 dh none과 맞는가»에서 «내 서버가 키 교환에 DH 파일이 필요 없는 스위트를 허용하는가»로 바뀝니다.

dh none이 실제로 비활성화하는 것

dh none은 서버에 유한체 DH 매개변수 파일을 로드하지 말라고 지시합니다. 인증, 인증서 검증, TLS 자체를 비활성화하지는 않습니다. 다만 협상된 키 교환이 그러한 매개변수를 필요로 하지 않아야 한다고 요구하며, 실제로는 ECDHE 스위트나 TLS 1.3 핸드셰이크를 뜻합니다.

바로 그 요구에서 고장이 나옵니다. 서버의 TLS 암호 정책이 DHE 스위트로 제한되어 있거나 클라이언트가 그것만 제공한다면, 매개변수 파일을 제거해도 사용할 수 있는 키 교환 방법이 남지 않아 핸드셰이크가 실패합니다. 오류는 보통 제어 채널 핸드셰이크 중, 사용자 인증 전에 나타납니다. 없는 파일을 탓하기 전에 암호 목록을 읽으십시오.

타원 곡선 쪽에서는 곡선을 서버의 TLS 구성이 선택하며, OpenVPN은 오래된 브랜치에서 그것을 선택하는 옵션을 제공합니다. TLS 1.3은 그룹 협상을 프로토콜 내부에서 처리하며 DH 파일을 전혀 참조하지 않습니다.

dh none 자체는 보안 저하가 아닙니다. 교환의 강도는 실제로 협상된 곡선과 스위트에 달려 있으므로, 다음 단계는 없는 파일이 아니라 상대가 무엇을 선택했는지 보는 것입니다.

편집 전에 협상 확인하기

서버와 클라이언트의 상세 수준을 높이고 연결 후 OpenVPN이 출력하는 제어 채널 줄을 읽으십시오. TLS 버전과 협상된 암호를 명시하고 상대 인증서의 키 유형을 보고합니다. 그 한 줄이 구성 파일이 암시할 뿐인 질문에 답합니다.

TLS 1.2와 ECDHE-RSA 스위트, RSA 인증서를 보여 준다면 그 조합은 dh none이 기대하는 바로 그 것이며 고칠 것이 없습니다. DHE 스위트나 공통 암호 없는 핸드셰이크 실패를 보여 준다면 해결책은 암호 정책이나 클라이언트 기능에 있지 인증서에 있지 않습니다.

지원하려는 가장 오래된 클라이언트를 테스트하십시오. 현재 클라이언트는 TLS 1.3을 협상할 수 있지만 더 오래된 것은 TLS 1.2 스위트로 제한될 수 있습니다. 가장 오래된 클라이언트에 겹침이 없으면 허용된 스위트를 넓히거나 그 엔드포인트를 업그레이드하십시오.

핸드셰이크 실패를 피하려고 인증서 검증을 끄지 마십시오. 실패는 상대가 키 교환에 합의하지 못했음을 알려 주며, 검증을 끄면 합의를 해결하지 않은 채 신원 보증을 없앱니다.

체크리스트: 인증서가 RSA인가, ECDHE 스위트가 허용되는가, 로그에 그 스위트가 보이는가, 지원되는 가장 오래된 클라이언트도 그것을 협상하는가? 네 가지 모두 예라면 dh none은 제 일을 하고 있습니다.