Linux에서 AnyConnect의 잘못된 TLS 버전: 먼저 수정 범위를 정하십시오

호스트 전체 LEGACY 정책, 프로세스별 OpenSSL 설정, 일회용 VM을 비교하고, 오류를 영구히 없애는 게이트웨이 변경까지 다룹니다.

이 오류는 비밀번호 입력 전에 나타납니다. 바로 그 점이 유용합니다. 아직 아무것도 인증되지 않았으므로 자격 증명이 문제가 아닙니다. Linux에서는 같은 AnyConnect 대화상자가 오래된 프로토콜 버전, 1024비트 키 교환 그룹, 또는 시스템 암호화 정책이 거부하는 암호화 제품군 때문에 나타날 수 있습니다. 저는 세 대의 컴퓨터에서 세 가지 다른 방식으로 이 문제를 없앴습니다. 그 해결책들을 구분하는 것은 영리함이 아니라 영향 범위입니다. 각각은 알맞은 자리에서는 정당하고 다른 모든 곳에서는 나쁜 기본값입니다.

정책을 건드리기 전에 메시지를 읽으십시오

대화상자의 정확한 문자열을 남겨 두십시오. 버전 불만은 프로토콜 계층을, 인증서 불만은 신뢰나 이름 지정을, 로그인 실패는 자격 증명을 가리킵니다. TLS 1.0, 1024비트 DHE 그룹, AES-256-CBC, SHA-1 서명을 제공하는 게이트웨이는 완전히 유효한 인증서를 갖고도 자격 증명이 전송되기 전에 현대적 정책에서 거부될 수 있습니다.

시스템의 OpenSSL로 엔드포인트를 확인하되, 실제 호스트 이름과 클라이언트가 쓰는 포트를 사용하십시오.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com가 실패하고 -tls1 -cipher DEFAULT@SECLEVEL=0가 성공하면 경계는 버전과 키 크기가 함께라는 뜻입니다. 첫 명령이 프로토콜 경고 대신 작은 DH 키를 보고하면 버전은 문제없고 그룹만 주의하면 됩니다. 확인 작업에 개인 키나 비밀번호를 절대 넣지 마십시오.

선택지 1: 암호화 정책으로 호스트 전체를 느슨하게

Fedora와 RHEL 8 및 9에서 update-crypto-policies --set LEGACY는 OpenSSL의 시스템 정책을 낮추고 update-crypto-policies --show는 무엇이 활성인지 확인합니다. 보통 터널이 복구되지만 정책은 프로세스가 시작될 때 읽히므로 다시 시험하기 전에 클라이언트와 그것이 띄운 보조 프로세스를 모두 다시 시작하십시오. 또한 그 컴퓨터의 모든 TLS 클라이언트에 오래된 프로토콜과 약한 그룹을 허용합니다. 옆 창의 브라우저부터 커널을 갱신하는 패키지 관리자까지 마찬가지입니다.

그 폭이 목적 전체이자 문제 전체입니다. LEGACY는 호스트 전체에 적용되고 지속되며 잊기 쉽습니다. 그래서 관리되는 빌드에서는 진단 단계나 문서화된 예외여야 하고, 워크스테이션의 상시 상태가 되어서는 안 됩니다. 내부 포털 하나가 필요해서 두 해 동안 LEGACY로 남은 사례를 본 적이 있는데, 언제 시작됐는지 아무도 말할 수 없었습니다.

Debian과 Ubuntu에는 이를 위한 단일 스위치가 없습니다. 그에 해당하는 것은 시스템 기본값 절에서 더 낮은 MinProtocol와 CipherString = DEFAULT@SECLEVEL=0를 설정하도록 /etc/ssl/openssl.cnf를 편집하는 일입니다. 범위는 같고 파일이 다르며, 릴리스 업그레이드 중에 놓치기 조금 더 쉽습니다.

선택지 2: 한 클라이언트를 위한 설정 파일 하나

프로세스별 OpenSSL 설정은 변경을 하나의 프로세스 트리 안에 가둡니다. 다만 파일이 라이브러리가 기대하는 방식으로 연결되어야 합니다. ssl_conf 절의 이름을 붙이는 것만으로는 부족합니다. OpenSSL은 최상위 openssl_conf 키를 읽고, 그것을 따라 초기화 절로 간 뒤에야 SSL 기본값에 도달합니다.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF를 그 파일로 지정하고, 그것을 내보내는 래퍼를 통해 VPN 클라이언트를 실행하십시오. 호스트의 나머지 모든 것은 기본 정책을 유지하며, 준수 질문이 들어올 때 중요한 것이 바로 이 성질입니다. 게이트웨이를 탓하기 전에 파일이 실제로 적용되는지 확인하십시오. OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1는 TLS 1.0 암호를 나열해야 하고, 빈 결과는 사슬이 끊겨 클라이언트가 조용히 시스템 기본값을 유지했다는 뜻입니다.

파일은 버전에 민감합니다. OpenSSL 1.1.1과 3.x는 같은 절 이름을 받아들이지만 공급자 주변의 지시문 처리는 3.x에서 바뀌었습니다. 파일이 읽혔다고 가정하지 말고 클라이언트 자체 로그와 시험 핸드셰이크로 확인하십시오. 절 이름의 오타는 열린 채로 실패하고, 클라이언트는 조용히 시스템 기본값을 씁니다.

한계는 적용 범위입니다. GnuTLS나 NSS에 링크된 것은 OPENSSL_CONF를 무시하며, 클라이언트가 환경을 물려받지 않고 실행하는 보조 프로세스도 마찬가지입니다. 래퍼를 만들기 전에 ldd로 바이너리가 실제로 어느 TLS 라이브러리에 링크되는지 확인하십시오. 그 답이 이 선택지의 존재 자체를 결정합니다.

선택지 3: 일회용 VM 또는 컨테이너

보름 동안 오래된 게이트웨이 하나만 공격하는 외부 인력에게는 느슨한 정책의 전용 VM이 워크스테이션보다 깨끗한 경계입니다. 오래된 표면과 일상적인 브라우저 프로필이 더 이상 커널 정책을 공유하지 않고, 폐기는 감사 지적이 아니라 삭제입니다.

그래도 네트워크에 연결된 기계이므로 접근을 제한하고 일반 브라우징에서 멀리 두십시오. 유지 비용은 패치할 이미지가 하나 더 늘어나는 것이며, 이는 실제이지만 제한적이고 눈에 보입니다. 노트북에 잊힌 LEGACY 플래그와는 다릅니다.

비교가 남기는 것

세 가지 질문으로 고르십시오. 누가 옛 프로토콜을 필요로 하는지, 얼마나 오래인지, 예외가 이유보다 오래 살면 누가 알아차리는지입니다. 앱 하나, 사람 하나, 며칠이면 프로세스별 설정입니다. 기기 하나 뒤의 함대 전체라면 게이트웨이 자체입니다. 호스트에 영구적인 LEGACY 정책이 필요한 것은 기술 옷을 입은 조달 결정입니다.

오래 가는 수정은 기기에 있습니다. TLS 1.2 이상, 최소 2048비트 그룹, AEAD 암호, 그리고 현대적 서명의 인증서입니다. 그 변경을 기기 소유자에게 요청하고, 협상된 버전과 암호를 클라이언트 로그에서 확인하십시오. 예외는 호스트, 게이트웨이, 협상된 프로토콜, 승인자, 만료일과 함께 기록하십시오. 그 기록이 임시 우회를 기본값으로 만드는 것을 막습니다.

관련 글