SECLEVEL=0은 증상을 고치지, 인증서를 고치지 않는다

OpenVPN 연결이 실패하고, 누군가 SECLEVEL=0을 추가하는 한 줄 수정을 찾으면 터널이 올라옵니다. 바뀐 것은 인증서도 암호화 제품군도 아니며, 라이브러리 전체의 수용 임계값이 이동했고, 이후 프로세스가 하는 모든 일이 새 경계를 물려받습니다. 같은 한 줄이 환경의 모든 프로필에 복사되기 전에 이 점을 이해할 가치가 있습니다.

어떤 라이브러리와 어떤 정책이 적용되는지 확인하십시오

SECLEVEL은 OpenSSL의 개념이므로 첫 질문은 빌드가 OpenSSL을 쓰는지 여부입니다. OpenVPN은 둘 이상의 암호화 라이브러리에 연결될 수 있고, 그중 하나에 적용되는 설정은 나머지에 아무 의미가 없습니다. 바이너리에 무엇으로 빌드되었는지 묻고, 그다음 라이브러리에 어떤 버전과 구성을 로드했는지 물으십시오:

openvpn --version | head -3
openssl version -a

버전 출력은 배포판이 기본값을 패치하기 때문에 주의 깊게 읽으십시오. 일부는 최소 수준을 업스트림 기본값보다 높이는 시스템 구성을 제공하며, 그래서 동일한 OpenVPN 패키지를 가진 두 머신에서 같은 프로필이 다르게 동작합니다. 유효한 정책은 실행 중인 프로세스가 로드한 것이지, 업스트림 설명서에 있는 것이 아닙니다.

그다음 사람들이 혼동하는 두 계층을 분리하십시오. OpenVPN에는 자체 TLS 제어가 있으며, 인증서 프로필 설정과 명시적 암호 목록이 포함되고, 이들은 라이브러리가 강제하는 모든 것 위에 있습니다. 라이브러리 수준을 낮춰도 OpenVPN 구성이 나열하는 암호가 바뀌지 않고, OpenVPN 목록을 좁혀도 라이브러리 임계값이 올라가지 않습니다. 어느 계층이 당신을 거부했는지 아는 것이 수정이 추측으로 남지 않게 하는 열쇠입니다.

거부될 수 있는 세 가지를 분리하십시오

첫 후보는 신원 자료입니다: 키가 너무 작은 인증서나 서명 알고리즘을 정책이 더 이상 받아들이지 않는 인증서입니다. 둘째는 키 교환 매개변수로, 정책이 너무 약하다고 보는 그룹 같은 것입니다. 셋째는 정책이 배제하는 암호 제품군입니다. 셋 모두 핸드셰이크 실패를 일으킬 수 있고, 오류 텍스트와 협상 단계만이 이들을 구별합니다.

이 세 가지 중 어느 것도 데이터 채널의 암호가 아닙니다. OpenVPN은 터널 암호화를 TLS 핸드셰이크와 별도로 협상하므로, 보안 수준 변경 후 성공한 연결은 어떤 암호가 페이로드를 보호하는지에 대해 아무것도 말하지 않습니다. 실제로 묻는 질문이 데이터 기밀성에 관한 것이라면, 완전히 잘못된 다이얼을 보고 있는 것입니다.

수준을 낮추면 세 입력 모두에 대한 수용이 동시에 넓어집니다. 사람들이 놓치는 부분이 바로 이것입니다: 오래된 인증서를 허용하는 수정은 약한 그룹과 아마 허용할 생각이 없었던 제품군까지 허용합니다. 하나의 오류가 변경을 촉발했고, 변경은 오류보다 넓습니다. 이 비대칭성이 제한된 예외가 환경 전체 기본값보다 나은 이유입니다.

임계값이 아니라 입력을 바꾸십시오

구성을 건드리기 전에, 그것을 보고한 단계와 지목한 객체도 포함하여 정확한 오류를 보존하십시오. 인증서 문제는 같은 파일을 다시 설치하는 대신 현재 정책이 받아들이는 것으로 인증서를 교체하는 것, 즉 기관에서 재발급하는 것으로 해결합니다.

거부된 입력이 당신이 통제하지 않는 피어의 것이라면, 대화는 그 피어의 소유자와 지원되는 대체 자료에 관한 것입니다. 아무도 유지하지 않는 시스템을 수용하려고 자신의 임계값을 낮추는 것은 비용을 그들에게서 그들 뒤에 연결하는 모든 사람에게로 옮깁니다.

서버가 정책을 적용하는 곳에서는 라이브러리를 탓하기 전에 OpenVPN 수준 설정이 실제 원인인지 확인하십시오. 배포된 인증서가 충족할 수 없는 더 엄격한 등급을 요구하는 인증서 프로필은 보안 수준이 무엇이든 실패하며, 그 프로필을 제거하는 것이 라이브러리 검사를 끄는 것보다 좁은 변경입니다.

낮춰야 한다면 범위를 좁히고 기록하십시오

때로는 승인된 호환성 예외가 올바른 답이며, 특히 폐기 일정이 있는 레거시 피어의 경우 그렇습니다. 호스트 전체가 아니라 그것을 필요로 하는 서비스로 한정하십시오: 서비스별 구성 파일이나 전용 OpenSSL 구성은 전역 프로필의 내보내기보다 영향 범위가 작습니다.

예외와 함께 정확한 설정, 승인한 소유자, 영향을 받는 클라이언트, 제거 조건이라는 네 가지를 적으십시오. 폐기 조건이 없는 예외는 임시 정당화를 붙인 영구적 약화입니다.

롤백은 이미 테스트한 한 단계여야 합니다. 이전 구성을 보관하고 변경을 적용하고 서비스가 시작되는지 확인하며, 다음 연결이 예상과 다르게 동작할 때 어떤 파일을 복원할지 정확히 알아 두십시오.

그런 다음 신원과 보호를 검증하십시오

성공한 연결은 수정된 조건이 그것을 허용했다는 것만 증명합니다. 호스트 이름과 피어 검증이 여전히 제 역할을 하는지, 사용 중인 인증서가 배포하려던 것인지, 협상된 데이터 채널이 당신이 생각하는 정책과 일치하는지 확인하십시오.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

OpenSSL 보안 수준 참조는 프레임워크가 키, 서명, 그룹, 제품군에 한계를 함께 적용하며 제로 수준은 콜백이 검사하는 모든 것을 허용한다고 분명히 밝힙니다. 그것이 당신이 바꾼 범위이며, 수정이 좁았는지 묻는 사람에게 인용할 문장입니다.

감사를 견디는 인수인계는 어떤 정책이 어떤 입력을 거부했는지, 무엇이 바뀌었는지, 결과적으로 무엇이 여전히 허용되는지를 말합니다. „SECLEVEL=0으로 작동한다“는 한 연결에 대한 관찰이며, 배포의 보안 평가가 아닙니다.