OpenVPN tls-ciphersuites 대 tls-version-min: 각각 무엇을 강제하는가

대부분의 OpenVPN TLS 논의에서 세 가지 다른 사실이 한 줄로 뭉뚱그려지는데, 그것은 클라이언트 빌드가 할 수 있는 일, 프로필이 허용하는 일, 그리고 세션이 실제로 협상한 일입니다. 짧은 TLS 1.3 스위트 목록은 가운데 질문에 절반만 답하며 프로토콜 버전의 하한에 대해서는 아무 말도 하지 않습니다. 아래 검사를 순서대로 진행하되, 이후 검사는 모두 앞선 검사가 정리되었다고 가정하므로 처음 성립하지 않는 곳에서 멈추십시오.

어떤 목록을 읽기 전에 빌드를 확인하십시오

구성 지시문은 프로토콜 지원이 없는 바이너리에 그것을 추가할 수 없습니다. 컴파일된 암호 라이브러리를 밝히는 버전 배너부터 시작하십시오:

openvpn --version

OpenSSL에 링크된 2.6 빌드는 tls-cipher과 tls-ciphersuites을 모두 받아들입니다. mbed TLS로 만든 빌드에는 TLS 1.3 스위트 선택이 전혀 없고, 2.6 설명서는 tls-ciphersuites을 OpenSSL 옵션으로 표시합니다. 서버가 다른 백엔드로 다시 빌드되면 구성 한 줄도 바꾸지 않고 같은 프로필의 동작이 달라질 수 있습니다.

여기 있는 동안 openvpn --show-tls을 실행하고 출력을 보관하십시오. 그것이 나중에 비교할 인벤토리이며, 누군가 프로필을 편집하기 시작하기 전에 확보하는 편이 저렴합니다.

배너와 목록은 채팅 창이 아니라 변경 티켓에 적으십시오. 여섯 주 뒤에 클라이언트가 스위트를 제공할 수 있는지를 두 사람이 다툴 때, 확보한 출력이 한 줄로 판정합니다.

버전 경계를 암호 목록과 분리해 두십시오

2.6 설명서에서 이것들은 하나가 아니라 세 가지 제어입니다:

• tls-cipher은 TLS 1.2 및 그 이전의 암호 정책을 설정하고 OpenSSL의 암호 목록으로 전달됩니다;
• tls-ciphersuites은 TLS 1.3 스위트를 선택합니다;
• tls-version-min과 tls-version-max은 연결이 사용할 수 있는 프로토콜 버전을 제한합니다.

따라서 세심하게 다듬은 TLS 1.3 스위트 목록은 구버전이 여전히 허용되는지에 대해 아무것도 증명하지 않습니다. 요구가 «TLS 1.3만»이라면 그것을 떠받치는 것은 버전 하한이며, 스위트 목록은 그 하한 안에서 선택을 좁힐 뿐입니다:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

이 짝은 두 가지 일을 합니다. 한 줄을 지우면 다른 쪽은 생각보다 약하게 강제하며, 바로 그것이 이 검사 전체가 존재하는 이유인 실패입니다.

데이터 채널은 네 번째 제어입니다. data-ciphers은 터널 안의 대칭 암호를 협상하며, 그 결과는 제어 채널의 TLS 버전에 대해 아무 말도 하지 않습니다. 세션 요약에서 AES-256-GCM을 보는 것은 어느 방향으로도 TLS 1.3의 증거가 아닙니다.

show-tls를 로컬 인벤토리로 읽으십시오

--show-tls은 이 바이너리가 링크된 암호 라이브러리가 지원하는 스위트를 선호 순서로 나열합니다. 게이트웨이에서 온 보고가 아닙니다. 설명서는 목록이 로컬 라이브러리에서 온다고 분명히 말하므로, OpenSSL 3.x가 설치된 노트북과 더 오래된 빌드의 라우터는 같은 서버와 대화하면서도 다른 목록을 출력합니다.

클라이언트가 스위트 A, B, C를 지원하고 한 세션이 B를 고른다고 합시다. 그것은 서버가 A나 C를 허용하는지도, B가 유일하게 허용된 선택인지도 확립하지 않습니다. 세 줄을 분리해 두면 혼란스러운 TLS 스레드 대부분이 스스로 풀립니다.

인벤토리는 그래도 보관할 가치가 있는데, 세션이 실패할 때 라이브러리 목록과 프로필 목록을 비교하면 클라이언트가 서버가 원한 것을 제공할 기회가 있었는지 알 수 있습니다. 또한 백엔드 변경이 구형 클라이언트가 의존하는 풀에서 TLS_CHACHA20_POLY1305_SHA256을 조용히 제거했는지도 보여 줍니다. 다른 사람들은 아무것도 눈치채지 못하는 동안 소수 사용자만 연결에 실패하는 그런 종류의 회귀입니다.

게이트웨이에 답할 수 있는 질문을 하십시오

서비스를 관리한다면 디스크의 파일이 아니라 실행 중인 인스턴스의 유효 구성을 살피십시오. OpenVPN이 다른 --config 경로로 시작되었거나, 포함 파일을 가져오거나, 편집 후 재시작되지 않았을 수 있습니다. 클라이언트가 마주치는 것은 실행 중인 데몬의 정책입니다.

관리하지 않는다면 운영자에게 지원되는 클라이언트 요구 사항이나 범위가 한정된 승인 테스트를 요청하십시오. 거부된 시도가 자동으로 거부된 스위트는 아니며, 버전 하한, remote-cert-tls 같은 인증서 신원 검사, 또는 tls-auth과 tls-crypt의 불일치가 스위트 선택이 중요해지기 전에 교환을 끝낼 수 있습니다. 클라이언트 목록을 바꾸기 전에 서버 오류를 읽으십시오, «handshake failed»는 네 가지 다른 원인을 덮고 그중 하나만 암호 불일치입니다.

openssl s_client을 VPN 포트로 향하게 해도 질문은 재현되지 않습니다. 제어 채널은 OpenVPN 자체의 프레이밍 안에서 동작합니다. 따라서 원시 TLS 프로브는 다른 것을 기대하는 포트에서 다른 프로토콜을 시험하며, 거기서 나온 어떤 결론도 프로브에 관한 것이지 터널에 관한 것이 아닙니다.

두 결과를 기록하고 분리해 두십시오

새로 허용된 세션은 프로토콜 버전과 선택된 암호를 밝히는 제어 채널 줄과, 터널 암호를 밝히는 별도의 데이터 채널 줄을 만듭니다. 둘 다 클라이언트 버전과 프로필 이름과 함께 확보하고, 어느 서버 인스턴스가 응답했는지 적으십시오:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

그다음 두 줄을 기억이 아니라 그 파일에서 읽으십시오. 그 짝이 증거이며, 스위트 이름만은 선호이고, 버전 경계는 서버가 무엇을 거부하는지에 관한 별도의 진술입니다.

검사를 이 순서로 수행하십시오. --version으로 빌드와 백엔드를 확인하십시오. 무엇이든 바꾸기 전에 --show-tls을 확보하십시오. 필요한 버전 하한을 스위트 목록과 분리해 밝히십시오. 실행 중인 인스턴스의 유효 정책을 소유자와 확인하십시오. 허용된 세션 하나를, 계획이 허락한다면 구버전으로 거부된 시도 하나도 관찰하십시오. 제어 채널과 데이터 채널 결과를 별개의 발견으로 기록하십시오.

필수 클라이언트가 새로운 최소 요건을 충족할 수 없다면, 배포가 끝난 것처럼 보이게 하려고 무관한 승인 규칙을 조용히 낮추지 말고 그 마이그레이션 또는 예외 결정을 명시적으로 내리십시오.