구형 피어 하나가 TLS 1.0을 강제한다 — 예외를 좁히고 호스트를 낮추지 말 것

구형 기기가 하나 나타나 접속에 실패하면, 가장 빨라 보이는 수리는 연결이 성공할 때까지 호스트 전체를 약화시키는 것입니다. 그 거래는, 마침내 동작하는 하한을 아무도 제거하지 않기 때문에, 그 순간에는 보이지 않고 실제로는 영구적입니다. 압력을 만드는 고장은 아주 다른 두 가지이며, 그중 하나만 암호와 관련됩니다. 먼저 고장을 분류하고, 그다음 예외를 퍼질 수 없는 곳에 두세요.

지시문을 고치기 전에 실패를 둘로 나눈다

공유 암호가 없다거나 지원되지 않는 프로토콜 버전이라는 서버 로그 줄은 제어 채널에서 나오며, 양 끝이 협상 자체를 어떻게 보호할지 합의하지 못했다는 뜻입니다. 서버 인증서 검증 방법이 활성화되어 있지 않다는 클라이언트 줄은, 그 클라이언트가 누가 응답했는지조차 확인하지 않기 때문에, 전혀 다른 곳에서 나옵니다. 데이터 암호를 바꾸는 것은 두 번째 사례에 아무 효과가 없고, 역할 검사를 추가하는 것은 첫 번째 사례에 아무 효과가 없습니다.

연결이 끊기기 직전의 마지막 줄은 대개 결과일 뿐이므로, 각 측의 가장 이른 실패 줄을 택하고 그다음 클라이언트가 실제로 연 파일이 무엇인지 확인하세요. 가져온 프로필은 표시 이름만 다른 채 두 번 존재하는 경우가 많고, 아무도 읽지 않는 사본을 고치면 설득력 있는 '변화 없음'이 만들어집니다. 실행 중인 프로세스는 시작할 때의 설정을 유지하므로 저장한 파일은 불러온 파일이 아닙니다. 아래 명령은 같은 시도의 클라이언트 협상과 서버의 시점을 나란히 보여 줍니다.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

더 약한 하한은 두 번째 리스너에 두는 것이 정직하다

기기가 데이터 채널 2.5 이전 버전으로 TLS 1.0에 머무르면, 서버는 제어 채널의 더 낮은 하한과 구형 클라이언트가 알아보는 데이터 암호를 제공해야 합니다. 폴백 지시문은 바로 그 피어를 위한 것이고, 암호 목록은 현대 클라이언트를 현대 스위트에 붙잡아 둡니다. 두 지시문은 사용자나 연결이 아니라 리스너에 속하며, 이후 어떤 클라이언트별 옵션도 이들을 좁히지 않습니다. 그래서 메인 포트의 구형 기기 한 대는 그 포트를 공유하는 모든 피어에 대한 결정입니다.

플랫폼이 허용한다면 구형 리스너를 별도 포트의 독립 인스턴스로 실행하고, 그 포트는 기기의 주소에서만 허용하며, 메인 서비스는 그대로 두고, 두 번째 리스너가 왜 존재하는지 그 설정이 들어 있는 파일에 적어 두세요. 그렇지 않으면 나중의 정리 작업이 그것을 남은 잔해로 읽습니다. 더 약한 하한이 기기가 끝나는 곳에서 끝날 때만 이 분리는 의미가 있습니다.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

오래된 공급자 인증서가 실제로 깨뜨리는 것

검증 오류의 정체는 빠진 역할 바인딩이며, 그것이 없으면 클라이언트는 신뢰할 수 있는 CA로 이어지는 인증서라면 서버용으로 발급되었든 아니든 받아들입니다. 먼저 인증서를 서버 역할에 묶고, 그 묶음을 조정 손잡이가 아니라 요구 사항으로 취급하세요. 그 단계 뒤에도 여전히 실패하는 프로필만이 진짜 인증서 문제를 가집니다.

키 크기나 서명 알고리즘이 더 이상 OpenSSL 기본 정책을 만족하지 못하는 오래된 공급자 인증서는 제어 채널에서 보안 수준을 범위 한정해 바꿀 사례인데, 거기서 수준을 낮춰도 검증이 꺼지지 않으며, 빈 CA, 비활성화된 검증 설정, 확인하지 않은 호스트 이름과 절대 결합해서는 안 됩니다. 그 줄은 그것이 필요한 단 하나의 프로필 안에 두세요. 완화된 OpenSSL 구성을 전역으로 내보내면 기기의 모든 프로그램에 같은 완화를 넘겨주게 됩니다.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

배너가 아니라 협상된 값을 읽는다

verbosity 4에서는 양 끝이 합의한 제어 채널의 TLS 버전과 암호, 그리고 세션의 데이터 암호를 출력합니다. 초기화 배너는 성공만 알리고 그 조건은 알려주지 않으므로, 배너가 아니라 그 줄을 읽으세요. 공유 구성으로 새어 나간 예외는 여기서 가장 먼저 드러나므로, 그다음 현대 클라이언트를 메인 리스너에 다시 연결해 여전히 현대 스위트에 도착하는지 확인하세요. 복사해 둔 값은 다음 검토의 기준이 됩니다.

구형 기기를 단독으로 시험하세요: 연결되어야 하고, 로그에서 더 약한 매개변수를 보여 주는 유일한 세션이어야 합니다. 두 번째 피어도 구형 스위트를 협상한다면 예외가 의도보다 넓고 리스너 분리가 실제로 일어나지 않은 것입니다. 결론만이 아니라 두 관찰을 모두 기록하세요.

모든 예외에는 소유자와 날짜가 필요하다

제거 조건이 없는 예외는 조용히 기본값이 되므로, 기기, 소유자, 이유, 그리고 사라질 날짜를 그 예외를 정당화하는 구성 옆에 두세요. 그 한 줄이 없으면 더 약한 하한은 그것을 필요로 했던 하드웨어보다 오래 살아남습니다.

목표로 삼아야 할 결과는 클라이언트를 교체하거나 공급자에게 최신 프로필을 요청하는 것이며, 예외는 설계가 아니라 지연입니다. 기기를 폐기할 때는 리스너와 프로필을 같은 변경에서 제거해 어느 쪽도 계속 돌지 않게 하세요. 이 중 어느 것도 오래된 매개변수를 안전하게 만들지 않으며, 한 기기의 한계가 모두의 기준이 되는 것만 막을 뿐입니다.