ALPN

  • ALPN은 Application Layer Protocol Negotiation의 약어
  • ALPN(Application-Layer Protocol Interval)은 "Hello 메시지" 교환 내에 프로토콜 협상을 포함하는 TLS 확장
  • ClientHello의 확장 기능으로, TLS handshake 이후에 application layer의 프로토콜과 버전을 결정하기 위한 기능
  • ALPN → 프로토콜을 협상
    1. secure connection을 통해 처리
    2. 효율적인 접속
    3. 추가적인 round trips을 방지

  • HTTP/2 프로토콜은 ALPN을 사용하여 웹사이트 로딩 시간을 줄이고 연결을 더 빠르게 암호화함
  • 핸드셰이크 프로세스는 client에서 server까지 왕복 2회에 해당
  • round trips이 많을수록 대기 시간은 길어지고 사용자는 서버로부터 정보를 받기 위해 더 오래 기다려야 함
  • round trips의 수는 주로 client와 server(ex.. DNS, TCP, HTTP) 간의 통신을 시작하기 위한 핸드셰이크에서 발생
  • round trips이 적은 상태에서 데이터를 전송하는 프로토콜을 개선할 수 있다면, 페이지 로딩 시간도 개선 가능

  • ALPN은 HTTP/2에서는 HTTP의 버전을 합의하기 위해서 ALPN을 사용
  • 먼저 client가 자신이 HTTP/1.1과 2를 지원한다는 사실을 ALPN으로 전송
  • server가 ALPN과 HTTP/2를 지원한다면 ServerHello의 확장 필드에 h2를 적으면 handhshake 이후 HTTP/2로 통신이 시작
  • ALPN을 지원하지 않으면, ServerHello에 ALPN 필드가 없으므로 HTTP/1.1로 통신


TLS handshake 동작 원리

  • ALPN 확장을 사용할 경우의 이점을 완전히 이해하기 위해서는 먼저 TLS 핸드셰이크가 어떻게 작동하는 지 숙지 필요
  • TLS handshake 단계 (TLS 포함)
    1. client와 server는 "Hello 메시지"를 교환하여 알고리즘에 합의하고 랜덤 값을 교환(exchange random value)하며 세션 재개(session resumption)를 확인
    2. 필요한 암호 파라미터(cryptographic parameters)의 교환을 통해 client와 server가 premaster secret를 허용
    3. master secret은 premaster secret에서 생성되고 임의의 값을 교환
    4. record layer에 security parameters를 제공
    5. client와 server는 peer가 동일한 security parameters를 계산했는지, 공격자가 조작하지 않고 handshake가 발생했는지 확인
  • premaster secret
    • Client는 세션키를 생성하여 서버에게 전송
    • 암호화된 세션키를 premaster secret이라고 함
  • master secret
    • 서버측에서 복호화할 때 사용
    • premaster secret을 통해 master secret가 생성
    • premaster secret을 사용하여 master secret를 복호화 → 데이터 추출 가능

ALPN의 동작 원리

  1. ALPN client는 "TLS ClientHello 메시지"가 지원되는 application protocol 목록을 server로 전송 → "ClientHello 메시지" 안에 지원하는 목록을 가진 ProtocolNameList 필드를 추가
  2. 목록을 수신한 server는 프로토콜을 선택하고 "ServerHello 메시지"로 프로토콜을 다시 전송 → 수신한 ProtocolNameList 필드를 살피고 "SeverHello 메시지"의 일부에 선택된 프로토콜을 나타내는 ProtocolName 필드를 반환
  3. Server는 하나의 프로토콜 명을 응답하겠지만, 만약 Client가 요청한 목록에서 지원되는 것이 없다면 연결은 끊어지게 됨
  4. 일단 TLS hadnshake가 완료되면 보안 연결이 수립되고 Client 와 Server는 어떤 응용프로그램 프로토콜을 사용할지 동의
  5. 협상된 프로토콜을 통해 Client와 Sever는 바로 메시지를 교환 가능
  6. aplication protocol negotiation은 TLS handshake 내에서 하나의 round trip에서 달성
  7. 위 방법은 server가 각 application protocol에 다른 인증서를 연결할 수 있도록 함
  8. support protocols 목록은 first message에서 server로 전송되어 필요한 왕복 여행의 양을 최소화

NPN vs ALPN (NPN과 ALPN의 비교)

1. NPN(client가 프로토콜 선택)

  • Next Protocol Negotiation의 약어
  • TLS Handshake 중에 효과적인 응용프로그램 프로토콜 협상을 위해서 구글에서 개발한 SPDY의 일부로 개발된 TLS 확장
  • NPN은 ALPN의 전신이며 SPDY와 함께 널리 사용 (ALPN과 상당히 유사)
  • NPN은 "ClientHello 메시지"에 지원되는 프로토콜 목록을 포함 X → ALPN과 차이
  • NPN extension에서는 "ClientHello 메시지"에 프로토콜 목록이 포함되지만 일반적인 NPN은 client가 선택할 수 있는 프로토콜 목록을 다시 보내는 것은 server이다.

2. ALPN (server가 프로토콜 선택)

  • NPN을 업그레이드 한 버전(client와 server의 프로토콜 목록 전송은 반대 과정)
  • ClientHello 메시지는 server가 선택할 수 있도록 지원되는 프로토콜 목록을 포함
  • ALPN은 "ClientHello 메시지"를 받은 이후 리소스 선택 프로세스(resource selection process)를 시작할 수 있어 역방향 프록시(reverse proxy)에도 유리
  • ALPN이 다른 프로토콜 협상 표준과 더 유사


ALPN의 성장

  • HTTP/2는 사용자 경험 향상(better user experience)과 로딩 시간 단축(faster load times)으로 인기가 높아짐
  • ALPN 확장이 HTTP/2와 결합하여 제공됨으로 ALPN도 같이 성장
  • 2016년 SPDY가 공식 폐지되면서 HTTP/2의 성장이 두드러짐
  • 인상적인 속도 및 강화된 보안 기능으로 ALPN 발전
  • 웹 사이트에서 HTTP/2 및 ALPN을 지원하는지 확인 : https://gf.dev/http2-test

ALPN 참고 자료 : https://www.ietf.org/proceedings/88/slides/slides-88-httpbis-1.pdf


저작자표시 비영리 변경금지

+ Recent posts

티스토리툴바