요약

  • RFC 3268은 TLS의 협상 메커니즘을 대체하지 않았습니다. 기존 메뉴에 두 가지 키 길이 각각에 대해 6가지 키 교환/인증 패턴, 즉 총 12개의 AES 암호 스위트 식별자를 추가했을 뿐입니다.
  • 스위트 이름은 단순한 암호화 선택 이상을 담고 있었습니다. AES-256 자체는 상대방 인증이나 순방향 비밀성을 제공하지 않았으며, 이러한 성질은 선택된 핸드셰이크 방식과 그 구현에 의존했습니다.

새 암호는 낡은 메뉴를 통해 들어왔다

AES가 새 표준으로 발표되었다고 해서 자동으로 사용 가능한 TLS 옵션이 된 것은 아닙니다. 클라이언트와 서버는 여전히 레코드 보호와 핸드셰이크 선택 전체를 하나의 세트로 지칭할 공유된 명명 방식이 필요했습니다. TLS 1.0에는 이미 그 메커니즘이 있었습니다. 클라이언트가 ClientHello에서 암호 스위트 목록을 제시하고, 서버가 지원하는 하나를 선택하는 방식이었습니다. RFC 2246은 스위트를 키 교환, 대량 암호화, 메시지 인증 알고리즘을 포괄하는 조합으로 정의했습니다.

2002년 6월에 발표된 RFC 3268은 이 기존 자리를 사용했습니다. AES를 HMAC-SHA-1과 함께 CBC 모드로 도입했지만, 하나의 불가분한 'AES 옵션'으로 제시하지는 않았습니다. RSA, DSS 또는 RSA 인증서를 사용하는 정적 DH, DSS 또는 RSA 서명을 사용하는 임시 DHE, 익명 DH라는 6가지 핸드셰이크 계열을 AES 128비트 및 256비트 키 길이로 정의했습니다. 6 곱하기 2로 12개의 스위트 식별자가 나왔습니다.

이 매트릭스는 TLS가 이미 노출하던 선택들을 그대로 보존했습니다. RSA 키 전송, 인증된 유한체 디피-헬만, 익명 디피-헬만은 레코드 암호가 AES라는 이유만으로 동등해지지 않았습니다. DHE는 새 임시 키, 안전한 폐기, 건전한 난수 생성을 갖추었을 때 순방향 비밀성을 제공할 수 있었습니다. 익명 DH는 상대방 인증을 제공하지 않았으며, 다른 메커니즘이 양측을 동일한 TLS Finished 트랜스크립트에 결합하지 않는 한 중간자 공격에 계속 취약했습니다. 이들은 모두 AES 키 길이가 아니라 핸드셰이크 선택의 성질이었습니다.

키 크기 메뉴 자체도 선택적이었습니다. AES는 128, 192, 256비트 키를 허용하지만, RFC 3268은 스위트 이름이 더 늘어나는 것을 피하기 위해 128과 256비트만 지정했습니다. 12개 스위트 모두 AES의 128비트 블록 크기를 사용했으며, 더 큰 키가 더 큰 블록을 의미하지는 않았습니다. 모든 스위트는 HMAC 구성에서 CBC와 SHA-1도 그대로 유지했습니다. 따라서 'AES'라는 이름은 더 넓고 역사적으로 특정한 패키지 안의 한 구성 요소를 가리키는 것이었습니다.

호환성은 더 큰 메뉴의 대가로 얻어졌다

RFC의 서두는 구체적인 격차를 지적합니다. 당시 TLS에서 이용 가능한 DHE 스위트는 트리플 DES를 중심으로 했고, 만족스럽지 못한 키 길이의 익스포트 변형들이 함께 있었습니다. 클라이언트와 서버가 TLS 1.0 핸드셰이크와 스위트 목록 협상을 유지하는 가운데 AES가 들어올 수 있었습니다. 그 호환성의 대가는 더 큰 레지스트리 표면이었습니다. 추가되는 조합마다 고유한 이름, 코드 포인트, 정책, 구현 의무가 부여되었습니다.

이는 제품들이 특정 속도로 해당 스위트를 채택했다거나, 가장 강한 이름의 옵션이 일상적으로 선택되었다는 증거가 아닙니다. 프로토콜 레지스트리에 스위트가 존재한다는 것은 할당을 증명할 뿐, 지원, 선호, 성공적인 협상 또는 안전한 배치를 증명하지 않습니다. 이들은 서로 별개의 관찰입니다.

이후의 TLS 설계를 보면 이 역사적 결합이 더 잘 드러납니다. TLS 1.2는 여전히 많은 경우 키 교환과 레코드 보호를 묶은 스위트 이름을 사용했습니다. TLS 1.3은 암호 스위트 식별자의 의미를 바꾸었습니다. 이제 식별자는 AEAD 알고리즘과 해시를 지칭하고, 키 교환 그룹과 서명 알고리즘은 별도의 매개변수로 협상됩니다. 2002년의 매트릭스는 단순히 'TLS의 AES'가 아니라, TLS가 자신의 선택들을 배치하는 위치를 바꾸어 온 긴 변화의 한 단계였습니다.

RFC 3268은 익숙한 라벨 뒤에 숨은 제어 표면을 드러낸다는 점에서 유용한 역사입니다. 알고리즘, 키 길이, 인증, 키 합의, 레코드 구성은 서로 바꿔 쓸 수 있는 보장이 아닙니다. 암호 스위트는 협상된 패키지이며, 한 구성 요소의 이름을 보안 판정으로 읽는 것은 패키지를 전체 연결로 착각하는 일입니다.

출처