OpenVPN tls-crypt-v2: 클라이언트 키와 래핑된 blob의 역할

tls-crypt-v2 프로필을 티켓에 붙여 넣는 것은 파일에 무엇이 들었는지 세어 보기 전까지는 무해해 보입니다. 클라이언트의 제어 채널 키는 같은 키의 암호화된 사본 옆에 있고, 세 번째 개체인 래핑 키는 받아들이는 서버를 결코 떠나지 않습니다. 이 셋은 보관, 공유, 폐기에 대해 서로 다른 질문에 답합니다. 이들을 분리하면 대부분의 정책 논쟁이 시작되기도 전에 정리됩니다.

프로필에 실제로 들어 있는 것

tls-crypt-v2의 클라이언트 절반은 키와 그 래핑된 사본입니다. 클라이언트는 제어 채널 보호에 평문 키를 사용하고 설정 중에 래핑된 사본을 서버에 건네므로, 서버는 클라이언트마다 평문 사본을 저장하지 않고 같은 키를 복구합니다. 래핑 키는 그 복구를 가능하게 하며 받아들이는 쪽에만 속합니다. 아래의 모든 내용은 그 세 개체가 어디에 사는지에서 나옵니다.

표를 이름이 아니라 보관 기준으로 읽으면 결과가 저절로 드러납니다. 래핑 키를 잃는 것이 비싼 사건인데, 프로필 안의 무엇도 그것을 재구성할 수 없고 정직한 복구는 그룹을 다시 발급하는 일이기 때문입니다. 유출된 프로필은 더 싸지만 훨씬 흔한데, 래핑된 사본이 파일을 공유해도 안전하게 만든다고 믿는 사람들이 프로필을 티켓에 붙이기 때문입니다. 두 실패에는 서로 다른 대응이 필요하며, 그래서 개체를 따로 둡니다.

래핑된 사본이 전부가 아닌 이유

프로필은 쓸 수 있는 클라이언트 자료를 래핑된 짝과 함께 나르므로, 서버를 위한 사본을 보호하는 것은 파일을 보호하는 것에 대해 아무 말도 하지 않습니다. blob은 전송에는 안전하고 게시에는 안전하지 않습니다. 그 안의 메타데이터는 blob을 받는 누구에게나 보이며, 나중에 그것이 붙은 티켓을 읽는 사람에게도 보입니다.

프로필을 구성 예제가 아니라 자격 증명으로 다루십시오. 유출된 파일은 서버가 그 신원을 받아들이기를 멈출 때까지 소지자에게 작동하는 클라이언트 신원을 주며, 래핑은 그 기간에 대해 아무것도 하지 않습니다. 클라이언트마다 프로필 하나를 발급해 회수가 단일 파일 결정으로 남게 하고, 래핑 키 백업은 그것이 가능하게 하는 서버 구성과 따로 하십시오. 두 습관 모두 침해된 프로필을 고치지 않지만, 둘 다 다음 것을 얼마나 빨리 억제할지 결정합니다.

검증 훅이 핸드셰이크에서 어디에 앉는가

검증 훅은 TLS 스택이 노출되기 전에 실행되며, 그 일은 래핑된 blob에 실린 메타데이터를 검사하는 것입니다. 훅은 그 메타데이터와 작고 문서화된 환경을 받으며, 인증 훅보다 다룰 재료가 적습니다. 사용자 이름, 세션 상태, 플러그인 변수를 볼 수 있다고 가정하는 것이 이 훅을 나쁘게 작성하는 흔한 방식입니다. 다른 훅에서 기대를 빌리지 말고 그 훅 자체의 설명서 절을 읽으십시오.

종료 상태, 즉 영이 아닌 결과는 클라이언트를 거부하고 영 결과는 핸드셰이크를 계속하게 하는 값이 결정입니다. 따라서 정책은 메타데이터가 없거나 해석할 수 없거나 예상 밖일 때 무슨 일이 일어나는지 말해야 합니다. 먼저 거부 경로를 쓰고, 그다음 어떤 값이 허용되는지 정하십시오.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

그 두 줄이 서버의 정책 표면으로, 하나는 래핑 키를 지목하고 다른 하나는 각 클라이언트를 판정하는 프로그램을 지목합니다. 흥미로운 것은 모두 스크립트 안에 있으며, 다른 어떤 접근 규칙과도 같은 버전 관리와 검토를 받을 만합니다.

계정, 인증서, 제어 키는 따로 폐기된다

TLS 신원 확인 전에, 어떤 계정 권한 부여보다도 전에 일어나므로 제어 채널의 조기 수용은 인증이 아닙니다. 계정 비활성화, 인증서 폐지, 클라이언트 제어 키 거부는 세 가지 메커니즘을 가진 세 가지 행동입니다. 그중 하나만 수행하는 배포에는 정책이 아니라 틈이 있습니다. 셋을 의도적으로 맞추고, 어느 단계가 어느 권한을 행사하는지 기록하십시오.

시점이 두 번째 구별입니다. 바뀐 수용 목록은 새 핸드셰이크에 적용되지만, 이미 성립된 세션은 무언가 끝낼 때까지 계속 돌아갑니다. 새 목록의 항목을 옛 세션이 끝났다는 증거로 세는 것이 바로 제거된 클라이언트가 몇 시간씩 연결되어 남는 방식입니다.

맞추지 않은 권한은 실무에서 쉽게 찾을 수 있는 두 구멍을 남깁니다. 계정이 비활성화되어도 그 제어 키가 여전히 핸드셰이크를 열 수 있고, 인증서가 폐지되어도 메타데이터 정책이 같은 클라이언트를 여전히 받아들일 수 있습니다. 둘 다 다른 곳에서의 같은 실수인데, 운영자가 한 목록을 전체 권한으로 취급했기 때문입니다. 제거 시점에 세 목록을 나란히 놓으면 실수가 보입니다.

프로필 발급과 회수

발급은 쉬운 절반으로, 받아들이는 쪽에서 클라이언트 키를 만들고, 프로필을 정확히 한 소유자에게 넘기고, 래핑 자료를 제한해 유지하고, 모든 받아들이는 서버에서 같은 검증 프로그램을 실행하십시오. 값싼 입장은 전체 그룹의 속성이지 가장 새 호스트의 속성이 아닙니다. 더 오래되었거나 더 느슨한 스크립트를 가진 두 번째 서버는 조용히 배포에서 가장 약한 경로가 됩니다.

회수에는 세 단계가 의도된 순서로 필요합니다. 새 핸드셰이크가 실패하도록 검증 훅에서 클라이언트를 거부하고, PKI를 쓰면 인증서를 폐지하고, 계정을 비활성화해 이후 권한 부여가 부여할 것을 남기지 않습니다. 그다음 세 가지 중 어느 것도 세션은 알아차리지 못하므로 옛 수용이 허용한 세션을 종료하십시오. 깨뜨려도 되는 클라이언트에서 순서를 연습하십시오.

프로필의 메타데이터는 그 정책에 대한 입력이지 접근 통제가 이미 있다는 증거가 아닙니다. OpenVPN 2.6 설계 문서는 개체와 그들이 긋는 경계를 설명하며, 강제는 운영자에게 남습니다.