요약

  • RFC 3436은 서로 마주 보는 SCTP 스트림을 쌍으로 묶어 양방향 채널을 만들고 각 채널마다 별도의 TLS 연결을 수립했다. 세션 재사용과 핸드셰이크 지연은 가능했지만, 보호되는 모든 스트림은 여전히 자신만의 핸드셰이크 완료가 필요했다.
  • TLS 보호는 순서가 보장되고 완전히 신뢰할 수 있는 전달을 요구했으며, SCTP 연결의 제어 청크가 아니라 사용자 데이터만을 다루었다. 이후 RFC 6083은 그 비용을 언급하면서 하나의 DTLS 컨텍스트로 무순서 전달, 부분 신뢰성, 더 많은 스트림 수를 회복했다.

존재하지 않았던 '보안 연결(association)'

32개의 스트림을 가진 SCTP 연결(association)을 상상해 보라. 운영자가 “이 association에 TLS가 활성화되어 있다”고 말한다. RFC 3436 기준에서 이 문장은 위험할 정도로 정확하지 않다. 스트림 0은 완전한 핸드셰이크를 마쳤을 수도 있고, 스트림 1은 같은 TLS 세션을 재사용하고 있을 수도 있으며, 스트림 2는 애플리케이션이 실제로 필요로 하기 전까지 핸드셰이크를 시작하지 않을 수도 있다. 사양상 TLS를 전혀 운반할 수 없는 여러 단방향 스트림도 있다. 또 다른 쌍으로 묶인 스트림은 여전히 순수 SCTP로 남아 있을 수 있다.

association은 실제로 존재한다. 개별 TLS 연결들도 실제로 존재한다. 그러나 상정된 단일 보안 상태는 존재하지 않는다.

2002년 12월에 발표된RFC 3436은 당시 새로 등장한 스트림 제어 전송 프로토콜(SCTP) 위에서 TLS 1.0을 실행하는 방법을 기술했다. 이 문서의일반 텍스트 판,RFC Editor 기록,Datatracker 파일,이력,참고 문헌,후속 인용,정오표 검색은 문서적 기록을 확립한다. 그러나 이것들은 특정 제품이 이를 구현했다거나, 두 구현이 상호 운용되었다거나, 운영 서비스가 그 혜택을 받았다는 사실을 증명하지는 않는다.

TLS는 강물을 기대했지만 SCTP는 꼬리표 달린 소포를 제공했다

TLS 1.0은 레코드를 순서대로 전달하는 신뢰 가능한 바이트 스트림을 전제했다.SCTP의 원래 사양은 신뢰 가능한 메시지, 다중 스트림, 다중 엔드포인트 주소를 제공했다.체크섬 갱신은 RFC 3436이 나올 때 이미 SCTP 기록의 일부였다.

이 적용(adaptation)은 하나의 TLS 레코드를 하나의 SCTP 사용자 메시지로 삼았다. IP 단편화를 피하고 MTU 지식을 보안 계층 아래에 유지하기 위해, 그 메시지를 단편화하고 재조립해야 하는 주체는 SCTP였지 TLS가 아니었다. 구현은 최소 18,437바이트, 즉 이 문서가 사용한 최대 TLSCiphertext 크기인2^14 + 2048 + 5를 수용해야 했다. 논리적 레코드는 여전히 하나의 메시지이지만 부분 전달 API가 필요할 수도 있었다.

이 선택은 눈에 보이는 경계를 유지했다. 네트워크 단편은 TLS 레코드가 아니었다. 하나의 SCTP 사용자 메시지가 하나의 레코드를 운반했다. 그리고 레코드가 완전했다고 해서 애플리케이션이 그것을 수용하거나 처리했다는 증거는 아니었다.

스트림 쌍이 보안 컨테이너가 되었다

SCTP는 각 방향마다 독립적으로 송신 스트림을 협상했다. A가 Z 쪽으로n개의 스트림을 갖고 Z가 A 쪽으로m개를 갖는다면, RFC 3436은 동일한 식별자를 짝지어min(n,m)개의 양방향 스트림을 만들었다. 남는 것은 단방향으로 남았다.

TLS는 짝이 맞은 스트림만 사용할 수 있었다. 각 쌍은 자신만의 연결과 자신만의 핸드셰이크를 받았다. 이는 SCTP의 스트림 간 HOL(head-of-line) 블로킹 방지를 보존했다. 한 스트림에서 TLS 레코드가 멈추더라도 association의 다른 모든 스트림이 멈출 필요는 없었다. 그러나 그 독립성에는 자원 비용이 따랐다. 보호된 스트림 쌍 20개는 곧 그만큼의 TLS 연결과 핸드셰이크 상태 기계를 의미했다.

RFC는 이 비용을 관리하는 세 가지 방법을 제시했다. 스트림은 완전한 핸드셰이크를 수행할 수 있고, 다른 연결에서 만들어진 세션을 재사용하는 축약 핸드셰이크를 수행할 수도 있었다. 이때 그 연결은 다른 association에 속한 것일 수도 있었다. 또는 애플리케이션이 실제로 스트림을 사용할 때까지 핸드셰이크를 지연시킬 수도 있었다. 왕복 지연이 큰 네트워크에서는 여러 완전 핸드셰이크를 병렬로 수행하는 편이 더 빠를 수 있었고, 연산 부담이 큰 환경에서는 세션 재사용이 더 저렴할 수 있었다. 이 문서는 어떤 정책도 모든 네트워크에서 지배적이라고 주장하지 않았다.

세션 재사용은 연결 경계를 지우지 않았다. 공유된 세션 식별자는 작업량을 줄였지만, 스트림 0이 준비되었다는 이유만으로 스트림 1이 보호된 애플리케이션 데이터를 보낼 수는 없었다. 스트림 1 자신의 핸드셰이크가 여전히 완료되어야 했다.

보호는 두 가지 광고된 자유를 제거했다

TLS 레코드는 엄격하게 순서대로 도착해야 했다. 그래서 RFC 3436은 TLS 스트림에서 SCTP의 무순서 전달 기능을 금지했다. 같은 이유로 TLS 레코드에 수명을 부여하고 오래되었을 때 폐기하는 것도 불가능했다. 단방향 스트림 역시 TLS 매핑 밖에 남았다.

같은 association의 다른 스트림은 그런 제약 없이 순수 SCTP를 계속 사용할 수 있었다. 그 결과 혼합된 association이 생겼다. 여기는 보호되는 순서 보장 사용자 데이터, 저기는 제약 없는 SCTP 사용자 데이터, 그 밖에는 단방향 트래픽. “이 association은 TLS를 사용한다”는 말은 어떤 메시지가 어떤 보장을 받는지를 감추었다.

RFC 3758은 이후 부분 신뢰성을 표준화하여 송신자가 데이터를 폐기할 수 있게 했다. 그러나 그 유용한 기능은 RFC 3436의 직렬 TLS 레코드 스트림에 끼워 넣을 수 없었다. 수년 뒤에도RFC 7496은 SCTP 위의 TLS는 부분 신뢰성 SCTP에 사용할 수 없다고 명시했다.

자물쇠는 전송 제어를 덮지 않았다

가장 날카로운 한계는 RFC 3436 바깥에 있었다.RFC 4895는 SCTP 위의 TLS가 사용자 데이터만 보호하기 때문에 SCTP 청크 인증 문제를 해결하지 못한다고 설명했다. 공격자가 전송 제어에 개입할 수 있는 능력은 별도의 association 수준 메커니즘인 SCTP-AUTH가 요구했다.

이것은 말장난이 아니다. 기밀 애플리케이션 레코드, 인증된 TLS 피어, 인증된 DATA 청크, 인증된 제어 청크는 서로 다른 수령 증명이다. 스트림 선택, 순서/무순서 처리, 주소 재구성, FORWARD-TSN 지시가 전달에 영향을 준다면, 페이로드 자체의 보안만으로 그것을 둘러싼 전송 결정을 입증할 수 없다.

멀티호밍 규칙도 같은 점을 다른 방향에서 지적했다. SCTP는 처음 관찰된 주소와 다른 주소에서 레코드를 보낼 수 있었다. RFC 3436은 결정이 전송 계층의 신원이 아니라 인증된 피어 신원에 근거해야 한다고 말했다. 주소의 연속성은 신원이 아니었고, 주소 변경이 반드시 신원 변경은 아니었다.

DTLS가 경계를 옮겼다

2011년RFC 6083은 서두에서 RFC 3436의 네 가지 심각한 한계를 언급했다. 무순서 메시지의 부재, 부분 신뢰성의 부재, 양방향에서 동일해야 하는 스트림 수, 그리고 양방향 스트림마다 하나의 TLS 연결을 요구해 규모가 커질 때 비용이 커진다는 점이었다.

그 대안은 SCTP association 안에 하나의 DTLS 연결을 두었다. 보안 제어 트래픽은 순서 보장과 무제한 신뢰성을 갖춘 스트림 0을 사용했다. 애플리케이션 데이터는 다른 많은 스트림을 사용해 메시지 경계를 유지하고, 순서 있게 또는 무순서로 이동하며, 부분 신뢰성을 활용할 수 있었다. DATA 청크는 SCTP-AUTH를 사용해야 했고, 부분 신뢰성이 활성화되면 FORWARD-TSN 청크도 인증이 필요했다.

이 대조는 역사적으로 유용하다. RFC 3436은 각 직렬 스트림을 따로따로 보호함으로써 일반 TLS를 그대로 유지했다. RFC 6083은 SCTP의 전송 의미론을 더 많이 보존하기 위해 association 경계에서 더 많은 통합 노력을 기울였다. 어느 쪽 문서도 배포를 증명하지는 않는다. 후자의 설계는 전자의 경계가 측정 가능한 아키텍처 비용을 지녔다는 증거이지, 모든 네트워크가 이전했다는 증거는 아니다.

RFC 8996은 이후 TLS 1.0과 1.1을 폐기(deprecated)했다. 따라서 RFC 3436의 원래 암호 스위트 언어는 현재의 암호학 권고가 아니라 역사적 메커니즘의 일부다.IANA SCTP 레지스트리는 조율된 프로토콜 할당을 증명할 뿐, 구현이나 트래픽에 대한 증거를 제공하지 않는다.

오래 지속되는 수령 증명 사슬

Lu Heng의현실 계층에 대한 논의는 이 오래된 전송 결정에 현대적 독해를 부여한다. 표준 지위는 공표된 조율 규칙을 증명한다. 완료된 핸드셰이크는 특정한 암호학적 상태를 증명한다. SCTP-AUTH는 지정된 청크가 인증되었다는 것을 증명한다. 애플리케이션 텔레메트리는 결과를 보여줄 수 있다. 어느 것도 다음 계층의 권위를 빌릴 자격이 없다.

그가 주장하는running-code 우선성은 손실, 순서 뒤집힘, 주소 변경을 견디는 구현과 사양을 분리해 둔다.최소 초기 사양의 관점은 RFC 3436이 왜 기존의 TLS와 SCTP를 재사용하고, 좁은 프로필을 수용하고, 더 풍부한 의미론을 후속 작업에 남길 수 있었는지를 설명한다. 이것들은 사후적 편집 적용이지, 저자들의 동기에 대한 주장이 아니다.

RFC 3436은 경계를 긋는 데서 실패하지 않았다. 그 경계를 점검 가능하게 만드는 데 성공했다. 하나의 association은 여러 보안 상태를 담을 수 있었다. 하나의 재사용된 세션이 여러 연결의 기초가 될 수 있었다. 하나의 보호된 스트림이 포기한 기능을 다른 스트림은 그대로 지니고 있었다. 솔직한 운영 서술은 결코 “SCTP가 보안 처리되어 있다”가 아니었다. 그것은 이렇다. 이 스트림은 이 핸드셰이크를 이 신원 아래에서, 이 전달 규칙 아래에서 완료했으며, 그리고 이 전송 제어들은 여전히 자신들만의 증명을 필요로 한다.

출처

추가 고정 기록