openssl rand가 tls-crypt가 원하는 키를 만들 수 없는 이유

OpenSSL은 이미 설치되어 있고 호스트에는 엔트로피가 있으며, 그것으로 키를 만드는 것이 뻔한 지름길처럼 보입니다. 출력은 무작위이고 비밀이며 완전히 쓸모없을 것이고, 실패는 키 형식을 언급하는 무언가가 아니라 제어 채널 오류로 나타납니다. 그 오도가 비싼 부분인데, 사람들을 암호 방식 점검으로 보내기 때문입니다. VPN이 읽는 것은 특정한 파일 구조이지 임의의 바이트 블록이 아니며, 이 기능의 한 변형은 서버 밖에서는 아예 만들 수 없습니다.

디스크의 파일이 실제로 무엇이어야 하는가

OpenVPN의 정적 키 파일은 텍스트입니다. 그것이 무엇인지 선언하는 주석 줄로 시작하고, 고정 폭 행에 헥스 데이터를 담으며, 총 256바이트의 키 자료를 가집니다. OpenVPN은 그것을 제어 채널의 공유 비밀로 읽으며, 인증서로도, 암호 문구로도, TLS 라이브러리가 알아볼 무언가로도 읽지 않습니다.

같은 객체 유형이 제어 채널의 두 기능 모두에 쓰입니다. tls-auth에서는 한쪽의 패킷이 자기에게 반사되지 않도록 각 피어에 방향도 필요합니다. tls-crypt에서는 단일 공유 비밀이 제어 채널을 양방향으로 암호화하고 인증하며, 이는 핸드셰이크를 숨기는 동시에 보호합니다.

그중 어느 것도 비밀 지식이 아니고 형식이 핵심도 아닙니다. 핵심은 파일이 읽는 쪽이 기대하는 헤더, 행 폭, 끝의 줄바꿈, 전체 길이와 정확히 일치해야 한다는 것입니다. 한 행이 어긋난 파일은 쓰레기로 로드되거나 완전히 실패합니다. 따라서 두 피어를 바이트 단위로 비교하는 것은 정당한 첫 시험이며, 두 구성 파일 중 어느 것을 읽는 것보다 빠릅니다.

하나를 만드는 지원되는 방법

그것을 소비할 도구로 단순한 정적 키를 생성한 다음 양쪽 끝에서 참조하십시오:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

옵션의 표기는 시간이 지나면서 바뀌어, 2.4 시대의 오래된 설치에서는 파일 이름 앞에 별도 플래그를 두는 형태를 썼지만, 현재 빌드는 더 짧은 형태를 받아들입니다. 어느 쪽이든 결과 파일은 같은 유형의 객체이므로, 확인할 것은 두 피어가 동일한 바이트를 가지고 있는지입니다.

두 번째 세대는 어떤 외부 생성기도 발명할 수 없는 구조를 더하며, 서버 키가 한 번 생성되고 각 클라이언트는 그것에서 파생된 감싼 키를 받습니다.

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

클라이언트가 받는 것은 서버 자신의 키를 복제한 것이 아닙니다. 서버만 풀 수 있는 메타데이터를 담은 감싼 객체이며, 이 감싸기 덕분에 장치별 파일을 다른 어떤 장치도 건드리지 않고 폐기할 수 있습니다. 서버 키는 서버에 두고 그 장치별 신뢰의 뿌리로 취급하십시오.

손으로 만든 바이트가 무너지는 곳

올바른 헤더 아래에 256개의 무작위 바이트를 헥스로 인쇄하면 이론적으로 로드되는 정적 키 파일이 됩니다. 그래도 나쁜 생각입니다. 모든 서식 세부가 로드 시 실패하거나, 더 나쁘게는 인증 실패로만 드러나는 서로 다른 값을 두 피어가 갖게 만드는 자료를 만들 기회가 됩니다.

v2 변형에서는 그에 상응하는 것이 불가능합니다. 감싼 클라이언트 키는 서버 키 프로세스의 출력으로만 존재하며, 서버는 그것을 풀기 위해 필요한 자료를 보관합니다. 무작위 덩어리는 거부되거나 그냥 복호화에 실패하고, 두 메시지 어느 것도 무작위성을 언급하지 않습니다.

버전 호환성은 이 모든 것 위에 있습니다. 첫 세대는 양쪽 끝에서 그것을 지원하는 릴리스가 필요하고, 두 번째 세대는 다시 더 새로운 릴리스가 필요합니다. 기능이 존재하기 전에 빌드된 클라이언트는 감싼 자료만 받아들이는 서버와 핸드셰이크를 완료할 수 없고, 보고되는 실패는 버전이 아니라 제어 채널을 가리킵니다.

모두를 잠그지 않고 교체하기

단일 공유 비밀을 교체하는 것은 기술적인 작업이 아니라 조정 작업입니다. 서버가 이전 것을 거두기 전에 모든 클라이언트가 교체 파일을 손에 쥐고 있어야 하며, 옛 값을 아직 가진 기계는 그 순간 실패합니다. 근무일 한가운데에 그 교체를 시작하지 마십시오.

v2 배치에서는 교체가 장치별이어서, 한 기계에 새 감싼 키를 발급하고 옛것은 그 기계에 대해서만 은퇴시키십시오. 모든 클라이언트가 그것을 지원하는 릴리스에 있을 때 이동해야 하는 주된 이유입니다.

파일 권한도 같은 대화에 속합니다. 키는 서비스를 실행하는 계정만 읽을 수 있어야 하고, 그것이 보호하는 프로필과 같은 저장소에 있으면 안 됩니다. OpenVPN 2.6 참조는 생성 형식과 키 자료 절을 문서화하며, 이는 포럼 게시물에서 복사한 명령보다 나은 출처입니다.