요약

  • NNTPSTARTTLS는 하위 연결을 유지하면서 애플리케이션 프로토콜을 인사 직후의 상태에 가깝게 초기화했습니다.
  • 양쪽 모두 TLS 이전에 학습한 민감한 정보를 폐기해야 했습니다. 클라이언트는 기능 목록을 다시 조회했고, 서버는 선택된 그룹이나 현재 기사 번호 같은 상태를 잊었습니다.
  • TLS는 한 구간만 보호했습니다. 그 자체로 NNTP 사용자를 인증하거나 기사의 출처를 확립하거나 멀티홉 Netnews 경로를 비공개로 만들지는 않았습니다.

하나의 소켓의 기묘한 연속성

대부분의 보안 설명은 진행 중인 대화 주위로 문이 닫히는 그림을 보여줍니다. NNTP의 규칙은 더 엄격했습니다. 서버가382로 응답한 후 TLS는 다음 옥텟부터 시작됩니다. 핸드셰이크가 성공하면 물리적 대화는 동일한 연결에서 계속되지만, 애플리케이션 대화는 초기 인사 직후의 시점으로 초기화됩니다. 두 번째 인사는 나타나지 않습니다. 클라이언트는 자신이 학습한 내용의 상당 부분이 더 이상 유효하지 않은 것처럼 행동해야 했습니다.

이 구분이RFC 4642의 핵심입니다. 암호화는 시간을 거슬러 작동하지 않습니다. 평문으로 받은 기능 목록은 변조에 노출되어 있었습니다. 핸드셰이크 이전에 선택된 그룹은 인증되지 않은 구간의 산물이었습니다. 어느 쪽 사실이라도 보호 구간을 지배하도록 허용하면 TLS는 불안전한 상태를 세탁하는 메커니즘이 되고 맙니다.

열린 대화에서 보안 경계로

RFC 977은 1986년 원조 NNTP 교환을 기술했습니다: 연결하고, 서버 인사를 받고, 명령을 보내고 세 자리 응답을 해석하는 것입니다. 이 설계는 원격 뉴스 전송을 대화형으로 만들었지만, 이후의 세션 내 TLS 전환은 담아내지 않았습니다.

2006년경에는 암호화되지 않은 NNTP 연결로 비밀번호를 보내는 일이 더 이상 용납되지 않았습니다. 일부 구현은 전용 포트 563을 TLS 우선 방식에 할당했습니다. RFC 4642는 포트를 늘리는 방식을 지양하고 일반 세션 내부의STARTTLS를 표준화했습니다. 서버가 기능을 광고하고, 클라이언트가 전환을 요청하며, 성공한382응답은 이후의 바이트를 NNTP 명령이 아닌 TLS 핸드셰이크 데이터로 만듭니다.

이것은 파이프라인에 놓여 있을 수 있는 평범한 명령이 아니었습니다. 경계에서의 모호성은 치명적이므로 파이프라인을 종료해야 했습니다. 한쪽이 뉴스 명령으로, 다른 쪽이 핸드셰이크 데이터로 해석하는 바이트는 세션을 불확정 상태로 남깁니다. 협상이 실패하면 양쪽 모두 연결을 닫는 것이 권고되었습니다.

그룹을 잊고, 기사를 잊고

NNTP는 상태를 유지하는 프로토콜입니다. 리더는 뉴스그룹을 선택하고 현재 기사 번호를 이동시킬 수 있습니다. 클라이언트는 또한 그 시점에 서버가 제공하는 기능 목록을 얻을 수 있습니다.RFC 3977은 이 목록이 명령이나 외부 이벤트로 상태가 바뀌면 세션 중에도 달라질 수 있다고 명시합니다.

RFC 4642는 이 일반적 사실을 보안 규칙으로 만들었습니다. TLS 이후 서버는 핸드셰이크 밖에서 클라이언트로부터 학습한 지식을 폐기해야 하며, 여기에는 현재 그룹과 기사 번호가 포함됩니다. 클라이언트는 핸드셰이크 이전에 서버로부터 학습한 지식, 특히 기능 목록을 폐기해야 하고 그에 의존해서는 안 됩니다. 선택된 그룹은 단순히 불편한 상태가 아니라 신뢰 경계의 잘못된 쪽에서 이루어진 주장이었습니다.

한 가지 예외가 규칙을 더 정밀하게 만듭니다.MODE READER가 이미 서버의 운영 역할을 변경했다면 핸드셰이크가 그 효과를 되돌리지 않습니다. 초기화는 모든 역사적 사실을 파괴한다는 뜻이 아니라, TLS가 확립하지 않은 민감한 지식의 상속을 거부하면서 정의된 애플리케이션 상태로 돌아간다는 뜻입니다.

기능 목록은 다시 관찰해야 했습니다

핸드셰이크 이후 클라이언트는CAPABILITIES를 다시 발행하고 다른 상태를 재협상해야 했습니다. 결과는 달라질 수 있었습니다. TLS가 이미 활성화되어 있으므로STARTTLS자체는 사라졌습니다.MODE-READER는 광고되지 않았습니다. 클라이언트 인증서에 의존하는 인증 메커니즘은 새로 나타날 수 있었습니다.

이는 기능 발견을 정적 목록이 아닌 관찰로 만듭니다. 동일한 연결의 동일한 서버가 전환 전후로 서로 다른 목록을 진실하게 제시할 수 있습니다. 이전 세션에서 캐시한 목록은 보안이 존재하는지 판단하는 데 특히 위험합니다. 공격자가 평문 응답에서STARTTLS를 삭제할 수 있기 때문입니다.

그래서 프로토콜은 기억에 두 가지 역할을 부여했습니다. 세션 내에서는 TLS 이전의 기능 지식을 잊어야 했고, 세션 간에는 클라이언트가 이 서버가 이전에 TLS를 제공했다는 사실을 기억해 그 제안이 사라지면 경보를 울릴 수 있었습니다. 하나의 기억은 보안 구간을 오염시키고, 다른 하나는 다운그레이드를 노출할 수 있습니다.

인증서는 로그인이 아니었습니다

RFC 4642는 현대 인터페이스가 자주 흐리는 또 다른 경계를 그립니다. 클라이언트가 TLS 핸드셰이크 중 자격 증명을 제시하더라도 NNTP 서버는 인증되지 않은 애플리케이션 상태에 머뭅니다. 인증서는 연결을 식별할 수 있지만 NNTP 권한 부여를 자동으로 완료하지는 않습니다.

RFC 4643이 그 순서를 보여줍니다. TLS 이후 클라이언트는 새로운 기능 목록을 요청합니다. 그 목록은 이제 추가 SASL 메커니즘을 제공할 수 있습니다. 클라이언트가AUTHINFO SASL을 수행하면EXTERNAL메커니즘은 TLS 인증서에서 파생된 신원을 사용할 수 있습니다. 인증은 전송 계층 설정에서 조용히 추론되는 부작용이 아니라 자체 성공 응답을 갖는 의도적인 애플리케이션 이벤트가 됩니다.

이 분리는 권한을 제한합니다. TLS는 바이트를 보호하고 피어 자격 증명을 확립할 수 있습니다. NNTP는 여전히 그 자격 증명이 요청된 서비스에 대해 수용되는지를 결정합니다. STARTTLS를 구현한 서버는AUTHINFO나EXTERNAL을 전혀 구현할 의무가 없습니다.

하나의 보호된 홉은 사설 네트워크가 아니었습니다

가장 중요한 한계는 보안 고려 사항에 나타납니다. NNTP는 종단 간 프로토콜이 아닙니다. Netnews 기사는 여러 서버를 거칠 수 있습니다. 한 클라이언트/서버 쌍 사이의 TLS는 그 구간만 보호하며, 다음 릴레이나 그 이전 구간에 대해서는 아무것도 말하지 않습니다.

전달 클라이언트를 인증하는 것이 그 클라이언트가 기사를 어떻게 입수했는지를 증명하지도 않습니다. 전송 신원, 기사 저작, 릴레이 출처는 서로 다른 근거입니다. 보안 홉은 그 홉에서의 도청과 변조를 막을 수 있지만 더 넓은 배포 체인은 이질적으로 남습니다.

IANA NNTP 매개변수 레지스트리는STARTTLS를 표준화된 전송 보안 기능으로 기록합니다. 이 레지스트리 항목은 상호운용성을 확립할 뿐, 배포나 종단 간 보장을 확립하지 않습니다.

보안은 상속된 확신을 거부하는 데서 시작되었습니다

NNTP STARTTLS는 규율 있는 교훈을 줍니다. 보안 채널은 이후의 바이트가 암호화된다는 이유만으로 안전하지 않습니다. 그 바이트를 이끄는 가정들도 경계의 보호된 쪽에서 나와야 합니다.

이 프로토콜은 소켓은 유지하되 오래된 대화는 버렸습니다. 기능을 다시 구축하고, 운영 상태를 재선택하고, 인증을 별도의 교환으로 남겼습니다. 또한 하나의 암호화된 홉을 Netnews 전체 체인에 대한 주장으로 과장하는 것을 거부했습니다. 가장 중요한 보안 행위는 은폐가 아니라, 보호 구간이 무엇을 기억하도록 허용되는지에 대한 결정이었습니다.

출처