DH 파일인가 tls-auth 키인가? 두 OpenVPN 파일 구별하기

두 파일, 두 지시문, 그리고 둘 다 설정하는 대상의 이름으로 부르는 습관. 이렇게 해서 dh.pem가 tls-auth 줄에 들어가고 클라이언트는 예상치 못한 키 형식이라는 메시지와 함께 실패합니다. 당신 앞의 결정은 어느 파일이 더 강한가가 아닙니다. 배포에 실제로 필요한 역할이 무엇인가이며, 세 가지 조건이 그것을 정합니다: TLS 스택이 어떤 키 교환을 협상할지, 제어 채널 인증을 원하는지, 자료가 비밀로 남아야 하는지입니다.

이 순서대로 답하면 파일 질문은 스스로 풀립니다. 건너뛰면 지시문 이름이 서로 바꿔 쓸 수 있는 것처럼 보이기 시작하고, 그것이 바로 이 실수가 나오는 상태입니다.

파일 이름보다 라벨을 먼저 읽으세요

파일의 첫 줄은 이름보다 많은 것을 알려 줍니다. 이름은 인간의 관습이고 라벨은 도구가 만들기 때문입니다. Diffie-Hellman 매개변수는 BEGIN DH PARAMETERS라는 PEM 라벨을 가집니다. OpenVPN 정적 키는 전혀 다른 구조로, 자체 헤더와 십육진 페이로드를 가집니다.

이름을 바꿔도 아무것도 변환되지 않습니다. ta.key라는 이름의 매개변수 파일은 여전히 매개변수이고, dh.pem라는 이름의 정적 키는 여전히 정적 키입니다. 파서는 내용을 읽고 불일치를 거부합니다. 프로필을 편집하기 전에 확인하세요.

head -n 1 dh.pem
head -n 1 ta.key

필요한 파일을 정하는 세 가지 조건

첫째 조건은 교환입니다. 유한체 Diffie-Hellman 핸드셰이크에는 그룹이 필요하고, dh 지시문은 서버가 그 매개변수를 지정하는 곳입니다. 타원 곡선 핸드셰이크에는 그 파일이 전혀 필요 없습니다. 곡선 자체가 매개변수 집합이기 때문입니다. 서버가 ECDHE 스위트만 협상한다면 DH 파일은 추가 강도가 아니라 죽은 무게입니다.

둘째 조건은 제어 채널 인증으로, 자체 자료를 가진 별도 기능입니다. tls-auth 파일은 두 피어가 가진 공유 정적 키이며, 제어 채널 패킷에 서명하는 데 쓰여 인증되지 않은 피어가 핸드셰이크를 마치는 것조차 할 수 없게 합니다. 유한체 DH를 쓰든 쓰지 않든 존재하며, 그룹 매개변수와는 무관합니다.

셋째 조건은 비밀성과 배포입니다. DH 매개변수는 세션을 약화하지 않고 공개할 수 있습니다. 비밀 값이 핸드셰이크마다 생성되어 피어를 떠나지 않기 때문입니다. 정적 키는 공개해서는 안 됩니다. 양쪽 끝에서 같은 바이트이며 스스로 회전하지 않고, 가진 사람은 누구나 유효한 제어 채널 서명을 만들 수 있습니다. 이 두 답은 전혀 다른 취급 규칙을 가리키며, 그래서 한 파일은 저장소에 둘 수 있고 다른 파일은 그럴 수 없습니다.

역할마다 올바른 자료를 생성하세요

지시문이 기대하는 형식을 생성하는 도구를 쓰고, 둘 사이를 변환하지 마세요. OpenVPN 2.6의 공유 키에서는 생성기의 타입 지정 형식이 목적을 명시합니다.

openvpn --genkey tls-auth ta.key

그 명령은 새 비밀 자료를 만듭니다. 기존 키를 수리하거나 검사하지 않으며, 다시 실행하면 다른 피어가 갖지 못한 다른 키를 얻습니다. 결과 파일은 어떤 공유 비밀에도 쓸 법한 경로로 필요한 피어에게 복사하고, 방향 관례를 일관되게 유지하세요. tls-auth에서는 한쪽이 key-direction 0을, 다른 쪽이 key-direction 1을 사용합니다.

DH 매개변수는 필요할 때 키 생성기가 아니라 매개변수 생성에서 나오며, 출력이 공개적이어도 출처가 중요합니다. 알 수 없는 출처에서 가져온 그룹은 공개되었다고 신뢰할 수 있게 되지 않습니다. 여전히 피어가 합의하는 그룹이어야 하고, 크기나 구성으로 약화되지 않아야 합니다.

dh none이 의미하는 것과 의미하지 않는 것

dh none는 좁은 의미의 실제 지시문입니다. 핸드셰이크가 타원 곡선 Diffie-Hellman을 쓰므로 유한체 매개변수 파일은 로드되지 않습니다. 무엇인가를 약화한다는 뜻의 “DH 단계를 건너뛴다”는 약어가 아니며, OpenVPN에 다른 파일을 대체물로 받아들이라고 하는 것도 결코 아닙니다.

잘못 읽으면 두 가지 실수가 생깁니다. 첫째는 dh none이 tls-auth의 필요를 없앤다고 가정하는 것입니다. 둘은 서로 다른 것을 제어합니다. 둘째는 곡선만 쓰는 구성 옆에 오래된 dh 줄을 남겨 두고 서버가 실제로 어느 파일을 쓰는지 궁금해하는 것입니다. 지시문이 있으면 파일을 읽고, 거기의 깨진 경로는 앞으로 협상될 교환과 무관한 이유로 시작을 실패시킵니다.

잘못된 파일이 이미 배포되었다면

프로필 소유자에게서 의도된 비밀을 복원하고, 그동안 인증서 검증은 건드리지 마세요. 실패는 형식 불일치이지 신뢰 실패가 아니며, 오류를 피하려고 검증을 끄면 시작 문제가 조용한 문제로 바뀝니다.

그다음 사람들이 흔히 합치는 두 사건을 분리하세요. DH 매개변수 파일을 공개하는 것은 거의 무해합니다. 매개변수가 설계상 공개이기 때문입니다. tls-auth 키를 노출하는 것은 다른 사건입니다. 키는 그것을 가진 모든 피어의 제어 채널 패킷을 인증하므로, 교체는 한 호스트가 아니라 배포 전체에서 조정되어야 합니다.

오 분의 점검으로 어느 경우인지 판정됩니다. 각 파일의 첫 줄을 읽고, 그것을 참조하는 지시문을 확인하고, 파일의 배포가 자료의 요구와 맞는지 확인하세요. 이것은 동작하는 PKI를 다시 만드는 것보다 작은 일이며, 세 가지 조건이 줄곧 가리키던 것이 바로 이것입니다.