HTTP에서 Early Data 사용

이 문서는 Internet Standards Track 문서입니다.

이 문서는 Internet Engineering Task Force (IETF)의 산물입니다. 이는 IETF 커뮤니티의 합의를 나타내며, 공개 검토를 거쳐 Internet Engineering Steering Group (IESG)에 의해 출판 승인을 받았습니다. 인터넷 표준에 관한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.

이 문서의 현재 상태, 오류 정정(errata), 및 피드백 제공 방법에 대한 정보는 https://www.rfc-editor.org/info/rfc8470에서 얻을 수 있습니다.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

TLS 1.3 [TLS13] 은 얼리 데이터(제로 라운드 트립 타임(0-RTT) 데이터라고도 함)의 개념을 소개합니다. 클라이언트가 동일한 서버와 최근에 통신한 적이 있다면, 얼리 데이터는 TLS 핸드셰이크가 완료되기를 기다리지 않고 연결의 첫 번째 왕복에서 클라이언트가 서버로 데이터를 보낼 수 있게 합니다.

HTTP [HTTP] 와 함께 사용될 때, 얼리 데이터는 클라이언트가 즉시 요청을 보낼 수 있게 하여 TLS 핸드셰이크에 필요한 한두 번의 왕복 지연을 피할 수 있게 합니다. 이는 중요한 성능 향상이나, 중요한 제약이 존재합니다.

얼리 데이터를 사용할 때의 주요 위험은 공격자가 해당 요청들을 캡처하여 재생(replay)할 수 있다는 점입니다. TLS [TLS13] 은 공격자가 요청을 성공적으로 재생할 가능성을 줄이기 위해 사용할 수 있는 기술들을 설명하지만, 이러한 기술은 배포가 어렵고 여전히 성공적인 공격 가능성을 완전히 배제하지는 않습니다.

이는 자동 또는 사용자가 시작한 재시도와는 다르다는 점에 유의하십시오; 재플레이는 클라이언트의 인지 없이 공격자에 의해 시작됩니다.

HTTP에서 재플레이 위험을 완화하기 위해, 이 문서는 서버에서 이러한 위험을 제어하는 기법의 개요를 제공하고 얼리 데이터에서 요청을 보낼 때 클라이언트에 대한 요구사항을 정의합니다.

이 문서의 권고는 HTTP over QUIC에서의 0-RTT 사용([HQ])에도 적용됩니다.

개념적으로, 얼리 데이터는 다른 애플리케이션 데이터와 이어붙여 단일 스트림을 형성합니다. 이는 요청이 얼리 데이터 안에 완전히 포함될 수 있거나 요청의 일부만이 얼리 데이터일 수 있음을 의미합니다. HTTP/2 [RFC7540] 또는 HTTP/QUIC [HQ] 같은 멀티플렉스 프로토콜에서는 여러 요청이 부분적으로 얼리 데이터로 전달될 수 있습니다.

이 문서가 가정하는 모델은 TLS 핸드셰이크가 완료되면 해당 TLS 연결에서 수신된 얼리 데이터가 재생된 복사본이 아님이 알려진다는 것입니다. 다만, 이것은 얼리 데이터가 다른 연결에서 재생되지 않을 것이라는 의미는 아니라는 점을 주의해야 합니다.

서버는 TLS 세션 티켓을 보낼 때 클라이언트가 향후 연결에서 얼리 데이터를 보낼 수 있도록 허용할지 여부를 결정합니다.

TLS [TLS13] 은 공격자가 얼리 데이터를 성공적으로 재생할 가능성을 줄이는 재생 감지 전략의 사용을 요구합니다. 이러한 반재생 기술은 재생 가능성을 줄이지만 완전히 제거하지는 않으며 재생 횟수에 대한 고정된 상한을 보장합니다.

1. 서버는 TLS 계층에서 얼리 데이터를 거부할 수 있습니다. 서버는 얼리 데이터를 선택적으로 거부할 수 없으므로, 이는 얼리 데이터로 전송된 모든 요청이 폐기됨을 의미합니다.
2. 서버는 TLS 핸드셰이크가 완료될 때까지 얼리 데이터의 처리를 지연시키도록 선택할 수 있습니다. 처리를 연기함으로써 해당 연결이 성공적으로 완료된 경우에만 그 안의 요청이 사용되도록 보장할 수 있습니다. 이는 서버에 얼리 데이터가 재생되지 않았을 것이라는 일부 확신을 제공합니다. 서버가 얼리 데이터에서 여러 요청을 수신하면, HTTP 처리를 요청별로 지연할지 여부를 결정할 수 있습니다.
3. 서버는 재생 위험이 너무 크다고 판단되는 경우 425 (Too Early) 상태 코드(섹션 5.2)로 응답하여 클라이언트가 개별 요청을 재시도하게 만들고 얼리 데이터를 사용하지 않도록 할 수 있습니다.

이 모든 기법은 효과가 동일하며, 서버는 자신에게 가장 적합한 방법을 사용할 수 있습니다.

특정 요청에 대해 재생 위험에 대한 허용 수준은 그 요청이 작동하는 자원에 특화되어 있으며(따라서 오리진 서버만이 알 수 있음), 얼리 데이터를 사용할 때의 주요 위험은 서버가 요청을 처리할 때 발생하는 동작들입니다. 중복 요청을 처리하면 중복된 효과와 부작용이 발생할 수 있습니다. TLS의 Appendix E.5도 중복된 요청을 처리할 때 발생하는 기타 효과를 설명합니다.

요청 메서드의 안전성([RFC7231], 섹션 4.2.1)은 이를 판단하는 한 방법입니다. 그러나 일부 자원은 안전한 메서드로도 부작용을 일으킬 수 있으므로 이 방법만으로 전적으로 신뢰할 수는 없습니다.

오리진 서버는 리소스가 요청에서 얼리 데이터를 사용하는 것이 적절한지 명시적으로 구성할 수 있도록 허용하는 것이 권장됩니다. 그런 명시적 정보가 없으면 오리진 서버는 얼리 데이터를 거부하거나 이 문서에 설명된 기법을 구현하여 TLS 핸드셰이크 완료 이전에 요청이 처리되지 않도록 해야 합니다.

요청이 일부는 얼리 데이터로, 나머지는 핸드셰이크 완료 후에 전송될 수 있습니다. 이것이 반드시 그 요청의 처리를 변경하는 것은 아니며, 중요한 것은 서버가 요청의 내용을 언제 처리하기 시작하는가입니다. 어떤 서버 인스턴스라도 핸드셰이크 완료 이전에 처리를 시작할 수 있는 경우, 모든 서버 인스턴스는 얼리 데이터의 재생 가능성과 그것이 처리에 미칠 수 있는 영향을 고려해야 합니다(참조: 섹션 6.2).

서버는 불완전한 요청을 부분적으로 처리할 수 있습니다. 값에 대해 동작을 수행하지 않고 헤더 필드를 파싱하거나 요청 라우팅을 결정하는 것은 부작용 측면에서 안전할 가능성이 높지만 다른 동작은 그렇지 않을 수 있습니다.

중계 서버(인터미디어리)는 얼리 데이터를 처리할 수 있는지 여부를 판단하기에 충분한 정보를 갖고 있지 않으므로, 섹션 5.2에서는 특정 요청이 얼리 데이터에 적합하지 않음을 오리진이 중계에 신호할 수 있는 방법을 설명합니다. 얼리 데이터를 수용하는 중계는 해당 메커니즘을 구현해야 합니다.

서버는 TLS 계층에서 얼리 데이터를 선택적으로 거부할 수 없다는 점에 유의하십시오. TLS는 서버가 얼리 데이터를 모두 허용하거나 전혀 허용하지 않는 것만을 허용합니다. 서버가 얼리 데이터를 허용하기로 결정하면, 서버는 요청을 425 (Too Early)로 거부하더라도 얼리 데이터에 있는 모든 요청을 처리해야 합니다.

서버는 early_data TLS 확장의 max_early_data_size 필드로 얼리 데이터의 양을 제한할 수 있습니다. 이는 핸드셰이크가 완료될 때까지 지연할 수 있는 요청에 대해 임의의 양의 메모리를 할당하는 것을 피하기 위해 사용될 수 있습니다.

얼리 데이터를 사용하려는 클라이언트는 TLS ClientHello를 보낸 직후에 HTTP 요청을 즉시 전송함으로써 시작합니다.

본질적으로 클라이언트는 특정 요청을 얼리 데이터로 보낼지 여부를 제어할 수 있으므로 재플레이 위험을 제어할 수 있습니다. 다른 정보가 없으면 클라이언트는 얼리 데이터가 사용 가능할 때 안전한 HTTP 메서드 ([RFC7231], 섹션 4.2.1)에 해당하는 요청을 얼리 데이터로 전송할 수 있으며, 안전하지 않은 메서드(또는 안전성이 알려지지 않은 메서드)를 얼리 데이터로 전송해서는 안 됩니다.

서버가 TLS 계층에서 얼리 데이터를 거부하면, 클라이언트는 연결이 새로 열린 것처럼 다시 전송을 시작해야 합니다. 이는 얼리 데이터에 대해 낙관적으로 사용된 프로토콜([ALPN]) 과 다른 협상된 프로토콜을 사용하는 것을 포함할 수 있습니다. 얼리 데이터로 보낸 모든 요청은 클라이언트가 포기하지 않는 한 다시 전송되어야 합니다.

자동 재시도는 재플레이 공격의 가능성을 만듭니다. 공격자는 얼리 데이터를 사용하는 연결을 가로채어 그 얼리 데이터를 다른 서버 인스턴스로 복사합니다. 두 번째 서버 인스턴스는 핸드셰이크를 완료하지 않더라도 얼리 데이터를 수락하고 처리할 수 있습니다. 그런 다음 공격자는 원래 연결이 완료되도록 허용합니다. 설령 얼리 데이터가 중복으로 감지되어 거부되더라도, 첫 번째 서버 인스턴스는 연결을 완료하도록 허용할 수 있습니다. 그런 다음 클라이언트가 얼리 데이터에서 보낸 요청을 재시도하면 요청이 두 번 처리될 수 있습니다.

여러 서버 인스턴스가 얼리 데이터를 수락하거나 동일한 서버가 여러 번 얼리 데이터를 수락하는 경우에도(후자는 TLS의 요구사항 위반이지만) 재플레이가 발생할 수 있습니다.

얼리 데이터를 사용하는 클라이언트는 425 (Too Early) 상태 코드를 수신하면 요청을 재시도해야 합니다; 섹션 5.2를 참조하십시오.

중계자는 이전 홉에서 얼리 데이터가 사용되었거나 요청을 안전하게 재시도할 수 있음을 알고 있지 않는 한, 요청을 전달할 때 얼리 데이터를 사용해서는 안 됩니다(일반적으로 오프라인 구성 사용). 더 나은 정보가 없으면 중계자는 요청이 얼리 데이터로 도착했거나 Early-Data 헤더 필드가 “1”로 설정되어 도착한 경우에만 얼리 데이터를 사용할 수 있습니다(참조: 섹션 5.1).

HTTP 요청은 여러 '홉'에 걸칠 수 있으므로, 요청이 이전 홉에서 얼리 데이터로 전송되었는지 여부를 명시적으로 전달할 필요가 있습니다. 마찬가지로, 얼리 데이터가 원치 않을 때 명시적으로 재시도를 유발하는 수단이 필요합니다. 마지막으로, 클라이언트가 실제로 그런 재시도를 수행할 것인지 알 필요가 있습니다.

• Early-Data 헤더 필드는 요청이 클라이언트와의 TLS 핸드셰이크 완료 이전에 중계자에 의해 전달되었을 가능성이 있는 경우에 포함됩니다.
• 425 (Too Early) 상태 코드는 서버가 가능한 재플레이 공격의 결과 때문에 요청을 처리할 수 없음을 나타내기 위해 정의됩니다.

이들은 사용자 에이전트와 오리진 서버 간의 얼리 데이터 사용에 대한 더 나은 조정, 그리고 게이트웨이(역프록시, CDN, 또는 서러게이트)가 있는 경우에도 조정을 가능하게 하도록 설계되었습니다.

게이트웨이는 주어진 요청이 얼리 데이터로 안전하게 처리될 수 있는지에 대한 구체적 정보를 갖고 있지 않은 경우가 많습니다. 많은 경우에 오리진 서버만이 재플레이 위험이 허용 가능한지 판단하는 데 필요한 정보를 가지고 있습니다. 이 확장들은 게이트웨이와 오리진 서버 간의 조정을 가능하게 합니다.

얼리 데이터를 사용하면 클라이언트의 요청이 재생될 위험에 노출됩니다. 재시도되거나 재생된 요청은 서버에서 다른 부작용을 초래할 수 있습니다. 이러한 부작용 외에, 재플레이와 재시도는 트래픽 분석에 사용되어 요청이나 요청이 대상으로 하는 자원에 대한 정보를 복구할 수 있습니다. 특히, 재생된 요청은 다른 응답을 유발할 수 있으며, 이는 콘텐츠가 비밀로 유지되더라도 보호된 데이터의 길이로부터 관찰될 수 있습니다.

이 문서는 “Permanent Message Header Field Names” 레지스트리에 Early-Data 헤더 필드를 등록합니다. 레지스트리는 <https://www.iana.org/assignments/message-headers>에 있습니다.

Header field name:

Early-Data

Applicable protocol:

http

Status:

standard

Author/Change controller:

IETF

Specification document(s):

이 문서

Related information:

(empty)

이 문서는 “HTTP Status Codes” 레지스트리에 425 (Too Early) 상태 코드를 등록합니다. 레지스트리는 <https://www.iana.org/assignments/http-status-codes>에 있습니다.

Value:

425

Description:

Too Early

Reference:

이 문서

이 문서를 작성하는 것은 쉽지 않았습니다. 다음 사람들은 문서의 품질과 완성도에 상당한 기여를 했습니다: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, 및 Victor Vasiliev.