Application Layer Protocol Negotiation (ALPN)

네트워크의 두 양단은 사용되어져온 응용프로그램 프로토콜을 서로의 통신을 위해 사용하는 것을 원할 것이다. 이 문제를 해결할 한가지 방법은 80, 443 과 같이 잘알려진 포트를 할당 하여 미리 프로토콜을 정하여 모든 Client와 Server들이 사용할 수 있도록 설정한다. 그러나 실제로 이 방법은 속도가 느리고 비현식적인 과정이다. 각각의 포트 할당은 반드시 승인되어야 하고 방화벽이나 다른 중간 통신 매개체애서 포트 80번과 443번의 트래픽만 허용하는 경우가 많기 때문이다.

결과적으로 사용되어져온 프로토콜을 배포하는 쉬운방법은 응용프로그램 프로토콜 협상으 을 위한 추가적인 과정을 사용하고 80번이나 443번 포트를 재사용 해야만한다. 80번 포트는 HTTP에 예약되어 있고, HTTP 명세는 다양한 목적을 위해 Upgrade flow를 제공한다. 그러나 Upgrade의 사용은 추가적인 RTT 지연을 발생시킬수 있다.

해결법은 443포트를 이용하는 것이다. 443포트는 TLS 위에서 동작하는 HTTPS 세션을 위해 예약되어 있다. 양단간에 암호화된 터널의 사용은 데이터를 이해하지 못하게 만들고 새로운 응용프로그램 프로토콜들을 배포하는 빠르고 믿을만한 방법을 제공한다. 그러나 여전히 TLS 세션 내에서 사용되어야 할 프로토콜을 위해 다른 과정의 필요로 하다.

ALPN은 이름에서 의미하는 바와같이 이러한 필요를 충족시키는 TLS 확장이다. TLS Handshake를 확장하여 네트워크 peer들 간에 추가적인 roundtrip 없이 프로토콜을 협상하도록 한다. 과정은 다음과 같다.

• Client는 ClientHello 메시지 안에 응용프로그램이 지원하는 목록을 포함하고 있는 ProtocolNameList 필드를 추가한다.
• Server 는 ProtocolNameList 필드를 살피고 SeverHello 메시지의 일부에 선택된 프로토콜을 나타내는 ProtocolName 필드를 반환한다.

Server는 하나의 프로토콜 명을 응답하겠지만, 만약 Client가 요청한 목록에서 지원되는 것이 없다면 연결은 끊어지게 될것이다. 일단 TLS hadnshake가 완료되면 보안 연결이 수립되고 Client 와 Server는 어떤 응용프로그램 프로토콜을 사용할지 동의한다. 그리고 협상된 프로토콜을 통해 Client와 Sever는 바로 메시지를 교환할 수 있다.

NPN과 ALPN의 역사와 관계

Next Protocol Negotiation (NPN) 은 TLS Handshake 중에 효과적인 응용프로그램 프로토콜 협상을 위해서 구글에서 개발한 SPDY의 일부로 개발된 TLS 확장이다. ALPN과 동등한 기능적인 결과를 가져온다.

ALPN은 NPN을 수정하여 확장된 버전으로 IETF에 승인을 받았다. NPN에서는 Server 가 어떤 프로토콜을 지원한느지 알려주고 Client는 프로토콜을 선택하고 결정한다. ALPN에서는 이 교환이 역으로 진행된다. Client가 어떤 프로토콜을 지원하는지 알려주고, Server는 프로토콜을 선택하고 결정한다. 그 이유는 ALPN이 다른 프로토콜 협상 표준과 더 가깝기 때문이다.

Server Name Indication (SNI)

암호화된 TLS 연결은 TCP peer들 간에 수립될수 있다. Client는 다른 Peer와 연결을 수립과 TLS handshake를 위해 IP주소만 알면된다. 그러나 동일한 IP주소로 Server가 다수의 사이트를 제공하고자 할때 각 사이트의 TLS 인증서가 무엇인지 알수가 없다.

이 문젤르 해결하기 위해서 Server Name Indication (SNI) 확장이 TLS 프로토콜에 도입되었다. SNI는 Client TLS handshake의 일부과정으로 연결을 시도하는 hostname을 알려준다. 그결과 Server는 ClientHello 메시지를 통해 보내진 SNI Hostname을 확인하고 적절한 인증서를 선택하여 원하는 host에 대한 TLS handshake를 완료한다.