요약

  • 성공적인COMPRESS응답은206행이 끝난 직후 양방향 압축을 활성화했고, 이를 끄는 세션 내 명령은 제공되지 않았습니다.
  • 애플리케이션 압축이 시작된 이후에는 이후의STARTTLS,AUTHINFO,MODE READER전환이 금지되었습니다. TLS, 계정 인증, 압축을 함께 사용하려면 바로 이 순서를 따라야 했습니다.
  • 압축은 SASL과 TLS 보호보다 먼저 실행되었기 때문에, 사전 범위, 관찰 가능한 길이, 플러싱, 손상된 스트림의 실패가 단순한 대역폭 설정이 아니라 보안 및 운영상의 결정이 되었습니다.

마지막 명확한 행

서버는206 Compression active를 쓰고 CRLF로 응답을 종료합니다. 이것이 마지막 비압축 응답 바이트입니다. 바로 그 다음 옥텟은 전혀 다른 연결 문법에 속합니다. 이제 양방향의 명령과 응답은 선택된 압축기를 통과합니다.

RFC 8054에서 이 경계가 유독 정확한 이유는 모호함이 스트림을 파괴할 수 있기 때문입니다. 한쪽 엔드포인트가 DEFLATE를 한 바이트 일찍 시작하거나 다른 쪽이 한 바이트 늦게 시작하면, 어느 쪽도 유효한 NNTP 행을 볼 수 없습니다. 따라서 클라이언트는COMPRESS를 파이프라인할 수 없으며, 다른 어떤 것을 보내기 전에 판정을 받아야 합니다.

실패는 기존 연결 문법을 그대로 둡니다. 잘못된 알고리즘 이름, 지원되지 않는 알고리즘, 자원 실패는 서로 다른 거부 경로를 갖습니다. 성공은 다릅니다. 공유 상태를 즉시, 그리고 그 연결이 유지되는 동안 영구적으로 변경합니다.

압축은 특별한 응답이 아니라 계층이었다

그 이전에는 표준화되지 않은 메커니즘들이 선택된 서버 응답만 압축했습니다. 이는 한 방향의 바이트를 아끼지만 각 명령이 자신의 압축 변형을 확보해야 했습니다. RFC 8054는 대신 하나의 무손실 계층을 이후의 모든 NNTP 명령과 응답 아래에 배치했습니다.

이 변경은 양방향을 모두 포괄했습니다. 반복되는 클라이언트 명령도 서버의 대형 목록, 기사 헤더, 본문 텍스트와 함께 이점을 얻을 수 있었습니다. RFC의 참고용 측정 결과 일부 다중 행 응답은 압축률이 높았지만, 짧은 응답과 인코딩된 첨부 파일은 훨씬 적게 절약되는 경우가 많았습니다. 이 예시들은 명세가 연구한 워크로드를 설명할 뿐, 현재 배치 환경의 벤치마크가 아닙니다.

RFC 1951에서 정의된 DEFLATE가 이 확장의 유일한 표준 알고리즘이자 필수 구현 대상이었습니다. 각 발신자는 자신의 합리적인 압축 수준을 선택할 수 있고, 반대편 복원기는 이에 적응해야 했습니다. 대칭성은 계층의 존재에 적용되었지, 튜닝 결정에는 적용되지 않았습니다.

이후의 선택을 제거한 지름길

가동 중인 압축기는 히스토리를 유지합니다. 그래서 RFC 8054는 압축기의 활성화를 일방향 연결 전환으로 취급했습니다. 압축이 활성화되면 서버는COMPRESS와STARTTLS광고를 중단합니다. 이후 이들에 대한 유효한 명령은502를 받습니다.MODE READER도 전환 이후에는 사용할 수 없었습니다.

UNCOMPRESS는 존재하지 않았습니다. 다시 일반 NNTP를 원하는 클라이언트는QUIT을 사용해 새 연결을 만들어야 했습니다. 이 규칙은 다음 바이트가 원시 프로토콜인지 압축 스트림 상태인지에 대해 두 엔드포인트가 불일치하는 것을 막았습니다.

현재 능력이 기억된 능력보다 중요했습니다.RFC 3977은 하나의 세션 내에서 능력 목록이 바뀔 수 있음을 허용합니다. RFC 8054는 압축이 암호화를 약화시킬 수 있기 때문에 이전 연결에서 캐시된 COMPRESS 결과에 의존하는 것을 구체적으로 금지합니다. 어제의 광고가 오늘의 전환을 승인할 수 없었습니다.

비밀번호는 압축기를 따라올 수 없었다

압축은 유사성을 이용해 길이를 줄입니다. 암호화는 내용을 숨길 수 있지만 여전히 압축 결과의 길이는 드러냅니다. 공격자가 일부 평문에 영향을 주고 변하는 암호문 길이를 관찰할 수 있다면, 공유된 패턴이 정보를 노출할 수 있습니다. RFC 8054는 이 위험 부류의 예로 CRIME과 BREACH를 인용합니다.

자격 증명은 가장 명확하게 피할 수 있는 비밀이었습니다. 성공적인 애플리케이션 수준의COMPRESS이후, 인증되지 않은 클라이언트는AUTHINFO를 시도하는 것이 금지되었습니다. 서버는 해당 능력을 생략하거나 사용 가능한 인자 없이 표시할 수 있었고, 문법상 유효한 인증 명령은502를 받았습니다.

명령 순서는 이 경계에서 비롯되었습니다. 세 가지 속성을 모두 원하는 클라이언트는 먼저RFC 4642에서 정의된 NNTPSTARTTLS를 사용하고, 그다음RFC 4643의 메커니즘으로 인증하며, 그 이후에야 애플리케이션 압축을 요청했습니다. 대역폭을 먼저 선택하면 같은 연결에서 그 보호들을 나중에 추가할 능력을 포기하는 것이었습니다.

이것이 세 연산을 동등하게 만드는 것은 아닙니다. TLS는 전송 링크를 보호합니다.AUTHINFO는 서버가 받아들이는 계정 신원을 수립합니다.COMPRESS는 표현 방식을 바꿉니다. 어느 것도 프로토콜이 그들 사이에 순서를 요구한다는 이유만으로 다른 것의 권한을 물려받지 않습니다.

바이트는 도착 시점에 계층을 역순으로 만났다

RFC 8054는 구성을 명시적으로 지정했습니다. 전송 전에 NNTP 데이터는 먼저 애플리케이션 압축을 통과하고, 그다음 존재하는 SASL 보안 계층, 그다음 TLS를 통과합니다. 수신자는 순서를 역으로 적용합니다. TLS 처리, SASL 처리, 마지막으로 복원이 NNTP 바이트를 돌려줍니다.

압축은 반복을 찾기 위해 암호화보다 먼저 이루어져야 합니다. 바로 이 배치가 사전 범위가 왜 중요한지를 드러냅니다. 공개 자료와 기밀 기사는 활성 보안 계층 아래에서 압축 히스토리를 공유해서는 안 됩니다. RFC는 또한 실용적인 범위에서 서로 다른 기밀 기사 사이에 공유 사전을 피할 것을 권합니다. DEFLATE 사전을 지우는 것은 가능한 완화책 중 하나입니다.

이 표준은 압축된 모든 암호화 세션이 안전하지 않다고 선언하지 않습니다. 트레이드오프를 숨기기를 거부할 뿐입니다. 구현은 사용자가 인지적으로 선택하지 않는 한 보안 계층 아래에서 압축을 자동으로 활성화해서는 안 됩니다.

공유 상태가 손상을 단말로 만들었다

압축에 제출된 모든 바이트는 출력에 도달하고 피어가 완전히 복원할 수 있을 만큼 플러시되어야 했습니다. 발신자는 이득이 없는 데이터 주변에서 압축 수준을 바꿀 수 있었지만, 수신자는 여전히 하나의 연속된 유효 스트림에 의존했습니다.

어느 쪽이든 유효하지 않거나 손상된 압축 데이터를 받으면 즉시 연결을 닫았습니다. 다음 NNTP 명령을 찾아 앞으로 검색하는 시도는 없었습니다. 복원기의 히스토리가 압축기의 히스토리와 더 이상 일치하지 않게 되면, 그럴듯한 행 경계는 잃어버린 상태를 복구할 수 없습니다.

이 실패 규칙은 협상 규칙과 닮았습니다. 둘 다 하나의 공유된 사실을 보호합니다. 다음 바이트를 지배하는 변환이 무엇인가. 재연결은 깨끗한 사실을 만들어냅니다. 기존 스트림 내부에서의 추측은 그렇지 못합니다.

순서는 보안 속성이 되었다

IANA NNTP 매개변수 레지스트리는COMPRESS능력과 DEFLATE 알고리즘을 기록합니다. 등록은 구현에 공통 이름과 참조를 제공하지만, 서버가 이들을 지원하거나 안전하게 사용한다는 것을 인증하지 않습니다.

NNTP 압축은 명령 변형의 증식을 멈추었기 때문에 범용 계층으로서 성공했습니다. 그 대가는 더 결과적인 상태 머신이었습니다.206은 단지 더 작은 트래픽을 약속한 것이 아니었습니다. 양쪽 엔드포인트를 기억되는 변환에 묶고, 이후의 전환을 제거하고, 기밀 관련 순서를 운영 정책에서 드러나게 만들었습니다.

교훈은 알고리즘이 아니라 순서에 있습니다. 암호화하고, 인증하고, 리스크를 감수한다면 그다음에 압축하십시오. 성능 계층이 마지막에 올 수 있었던 이유는, 대화를 기억하기 시작하는 순간 이전의 일부 보안 선택은 더 이상 안전하게 내릴 수 없기 때문입니다.

출처