ALPN HTTP 헤더 필드

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 및 "OPTIONAL"이라는 핵심 단어들은 RFC 2119에 설명된 바와 같이 해석됩니다 [RFC2119].

프로토콜 필드의 유효한 값은 [ALPN-IDS] 레지스트리에서 가져오며, 이는 [RFC7301]에 의해 설정됩니다.

ALPN 헤더 필드 값의 ABNF(Augmented Backus-Naur Form) 구문은 아래와 같습니다. 이 구문은 섹션 1.2에서 정의된 구문을 사용합니다 [RFC7230].

ALPN 프로토콜 이름은 형식에 대한 추가 제약이 없는 옥텟 시퀀스입니다. 토큰에서 허용되지 않는 옥텟([RFC7230], 섹션 3.2.6)은 섹션 2.1에 따라 퍼센트 인코딩되어야 합니다 [RFC3986]. 결과적으로, 퍼센트 문자 "%" (16진수 25)를 나타내는 옥텟도 퍼센트 인코딩되어야 합니다.

어떤 ALPN 프로토콜 이름이든 정확히 한 가지 방식으로 표현되도록 하기 위해 다음 추가 제약이 적용됩니다:

• ALPN 프로토콜의 옥텟은 "%"를 제외한 유효한 토큰 문자인 경우 퍼센트 인코딩하면 안 됩니다.
• 퍼센트 인코딩을 사용할 때는 대문자 16진수 숫자를 사용해야 합니다.

이러한 제약으로 수신자는 프로토콜 식별자를 일치시키기 위해 단순한 문자열 비교를 적용할 수 있습니다.

예:

  CONNECT www.example.com HTTP/1.1
  Host: www.example.com
  ALPN: h2, http%2F1.1
  

ALPN 헤더 필드에서 ALPN 식별자는 단일 프로토콜 계층이나 구성 요소가 아니라 전체 애플리케이션 프로토콜 스택을 식별하는 데 사용됩니다.

TLS로 보호되는 프로토콜을 전달하는 CONNECT 터널의 경우, ALPN 헤더 필드의 값은 TLS ClientHello 메시지에서 전송될 동일한 ALPN 식별자 목록을 포함합니다 [RFC7301].

TLS를 사용하지 않는 등 프로토콜 협상이 발생하지 않을 것으로 예상되는 경우, ALPN 헤더 필드는 의도된 애플리케이션 프로토콜에 해당하는 단일 ALPN 프로토콜 식별자를 포함합니다. 다른 형태의 프로토콜 협상이 가능할 경우, ALPN 헤더 필드는 협상될 수 있는 프로토콜 집합을 포함합니다.

프록시는 ALPN 헤더 필드 값을 사용하여 CONNECT 터널 요청을 보다 명확하고 효율적으로 거부할 수 있습니다. HTTP 계층에서 프로토콜 정보를 노출하면 프록시는 더 일찍 요청을 거부하고(예: 403 상태 코드와 같은) 더 나은 오류 보고를 제공할 수 있습니다. ALPN 헤더 필드는 위조될 수 있으므로 요청 승인에 대한 충분한 근거로 사용될 수 없습니다.

프록시는 사용 중인 프로토콜을 결정하기 위해 패킷을 검사하려 시도할 수 있습니다. 이는 프록시가 각 ALPN 식별자를 이해해야 함을 요구합니다. TLS와 같은 프로토콜은 협상된 프로토콜을 숨길 수 있으며, 또는 프로토콜 협상 세부사항이 시간이 지나며 변경될 수 있습니다. 프록시는 프로토콜을 인식하지 못한다는 이유만으로 CONNECT 터널을 차단해서는 안 됩니다.

프록시는 ALPN 헤더 필드 값을 사용하여 연결 관리 또는 우선순위 지정 방식을 변경할 수 있습니다.

5.1. 규범 참조

[RFC2119]

Bradner, S., “RFC에서 요구 수준을 표시하기 위한 핵심 단어 사용”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997년 3월, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3864]

Klyne, G., Nottingham, M., and J. Mogul, “메시지 헤더 필드 등록 절차”, BCP 90, RFC 3864, DOI 10.17487/RFC3864, 2004년 9월, <http://www.rfc-editor.org/info/rfc3864>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “통합 리소스 식별자(URI): 일반 구문”, STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005년 1월, <http://www.rfc-editor.org/info/rfc3986>.

[RFC7230]

Fielding, R. and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, 2014년 6월, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7231]

Fielding, R. and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, 2014년 6월, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7301]

Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, 2014년 7월, <http://www.rfc-editor.org/info/rfc7301>.

5.2. 정보 참조

[ALPN-IDS]

IANA, “Application-Layer Protocol Negotiation (ALPN) Protocol ID”, <http://www.iana.org/assignments/tls-extensiontype-values>.

[MSG-HDRS]

IANA, “Permanent Message Header Field Names>”, <https://www.iana.org/assignments/message-headers>.

[RFC5246]

Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, 2008년 8월, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5766]

Mahy, R., Matthews, P., and J. Rosenberg, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)”, RFC 5766, DOI 10.17487/RFC5766, 2010년 4월, <http://www.rfc-editor.org/info/rfc5766>.

[TRAFFIC]

Pironti, A., Strub, P-Y., and K. Bhargavan, “Identifying Website Users by TLS Traffic Analysis: New Attacks and Effective Countermeasures, Revision 1”, 2012, <https://alfredo.pironti.eu/research/publications/full/identifying-website-users-tls-traffic-analysis-new-attacks-and-effective-counterme>.