더 큰 OpenVPN 키가 재키 타이머를 없애지 못하는 이유

AES-256이나 더 긴 키를 고르는 것은 그 키를 얼마나 오래 쓸 수 있는지에 대해 아무것도 말해 주지 않습니다. 키 강도는 알고리즘을 설명합니다; 재키 정책은 세션이 언제 새 키 자료를 도출하는지 결정합니다. 배포는 사용 가능한 가장 강한 암호를 선택하고도 두 결정이 서로 다른 곳에서 내려지므로 갱신에 대해 틀릴 수 있습니다. 이 둘을 혼동하면 불필요한 암호 변경이나 정책보다 조용히 더 오래 살아남는 세션이 생깁니다.

암호를 건드리기 전에 재키 설정을 읽고, 그럴 때는 양쪽 피어를 모두 읽으세요.

키 강도와 키 수명은 서로 다른 질문에 답합니다

암호와 키 크기는 감청된 트래픽에 대한 공격이 얼마나 비쌀지를 제한합니다. 재키 간격은 하나의 키가 보호하는 트래픽 양과 유출된 키가 유용하게 남는 기간을 제한합니다. 두 가지는 독립된 조절 장치이며, 더 강한 암호가 세션의 안전한 수명을 늘려 주지는 않습니다. 'AES-256을 쓰라'는 대부분의 안내가 갱신에 대해 침묵하는 것은 갱신이 알고리즘 선택이 아니라 정책의 문제이기 때문입니다.

배포 노트에 데이터 채널을 무엇이 보호하는지와 그 키의 교체를 무엇이 촉발하는지를 함께 적으세요.

재키에는 세 가지 트리거가 있고, 어느 쪽 피어든 발동할 수 있습니다

OpenVPN 2.6은 바이트, 패킷, 경과 시간에 따른 재협상 트리거를 각각 문서화합니다. 시간 트리거는 대부분의 배포가 기본값으로 두는 것이며, 즉 조용한 터널도 일정대로 재키합니다. 어느 쪽 피어든 교환을 시작할 수 있고, 시작하지 않은 쪽은 이를 따릅니다. 따라서 한쪽에서 타이머를 바꾼다고 세션의 동작이 정해지지는 않으며, 유효한 값은 먼저 시작하는 쪽의 것입니다.

바이트와 패킷 트리거는 처리량이 높거나 패킷이 작은 부하에서 중요합니다. 시간만 따르는 정책으로는 하나의 키가 의도보다 훨씬 많은 데이터를 보호하게 되므로, 그 카운터를 꺼 둔다면 기본값을 살펴보지 않은 채 두지 말고 노트에 의도적으로 적으세요.

재키는 인증 흐름을 드러냅니다

재협상은 새로운 TLS 핸드셰이크이므로 인증 경로가 다시 실행되고, 일회용 코드나 하드웨어 토큰, RADIUS 챌린지를 쓰는 배포는 이를 힘든 방식으로 알게 됩니다. 첫 연결은 되지만 두 번째 핸드셰이크가 이미 사용된 코드를 요구할 때 한 시간 뒤 세션이 죽습니다. auth-gen-token 는 새 대화형 로그인을 요구하는 대신 서버가 재협상용 단명 토큰을 발급하게 해 그 간극을 메우기 위해 존재합니다.

갱신을 꺼야 한다는 증거가 아니라 운영자와 함께 풀어야 할 워크플로 문제로 다루세요.

부하 속에서 시험하는 갱신, 일 분짜리 세션에서는 안 됩니다

연결해서 핑을 한 번 보내고 끊는 인수 테스트는 재키에 결코 도달하지 않습니다. 설정된 트리거를 넘길 만큼 긴 세션을 돌리고, 그동안 전송을 계속 유지하며, 새 핸드셰이크를 위해 양쪽 피어의 로그를 보세요. 다음으로, 재협상을 끝내지 못할 때 클라이언트가 무엇을 하는지 실패 경로를 시험하세요. 깔끔하게 끊기는 터널이 죽은 세션으로 계속 보내는 터널보다 진단하기 쉽습니다.

성공한 대용량 전송을 암호학적 한계의 증거로 읽지 마세요. 그것은 경로와 카운터가 그만큼의 트래픽을 견뎠다는 것만 보여 줍니다.

두 선택을 모두 기록하세요

기록에는 두 줄, 즉 패킷을 어떻게 보호하는지와 그 보호를 언제 교체하는지가 필요합니다. 암호는 배포판 기본값에서 오고 타이머는 내부 정책에서 올 수 있으므로 값마다 근거를 붙이세요. 미래의 운영자가 설정 파일에서 둘 중 어느 것도 추측하지 않아야 합니다.

호환성이 예외를 강제한다면 버전과 종료일로 범위를 한정하세요. 이유보다 오래 사는 예외는 아무도 선택했다고 기억하지 못하는 정책이 됩니다.