애플리케이션 로드 밸런서(ALB) 기반 서버 이름별(SNI) 다중 TLS 인증서 지원

오늘부터 우리는 애플리케이션 로드 밸런서(ALB)에서 서버 이름 표시(SNI)를 사용해 다중 TLS/SSL 인증서 지원을 시작합니다. 이제 단일 로드 밸런서 뒤에서 각각 자체 TLS 인증서를 갖는 다수의 TLS 보안 애플리케이션을 호스팅할 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의TLS 인증서를 자동으로 선택합니다. 이러한 새로운 기능은 추가 요금 없이 제공됩니다.

새로운 기능의 사용 방법에 대한 TL;DR을 찾고 있다면 여기를 클릭하십시오. 저처럼 TLS(Transport Layer Security)에 대해서 약간 서툴다고 생각한다면 아래 이어지는 내용까지 계속해서 읽어주십시오.

TLS? SSL? SNI?

SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다. 하지만 쉽게 이해할 수 있도록 이번 포스트에서는 TLS라는 용어를 사용하겠습니다.

TLS는 암호, 쿠키, 신용 카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 즉 인증 기관(CA)을 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.

SNI 지원이 시작되면서 이제는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 되었습니다. 다수의 인증서가 필요한 가장 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 단순 패턴이 일치하는 하위 도메인에서만 사용 가능합니다. 또한 SAN 인증서가 다수의 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.

포럼과 reddit, 그리고 저의 이메일 수신함으로 가장 자주 도착하는 요청 중 하나가 바로 TLS의 서버 이름 표시(SNI) 확장을 사용하여 클라이언트 인증서를 선택할 수 있도록 해달라는 것이었습니다. TLS는 HTTP 아래 단계인 전송 레이어에 속하기 때문에 클라이언트가 요청하는 호스트 이름을 알지 못합니다. 이때 클라이언트가 처음 연결 시 서버에게 “이것이 내가 인증서를 원하는 도메인입니다”라고 지정할 수 있도록 도와주는 것이 바로 SNI입니다. 그러면 서버가 올바른 인증서를 선택하여 클라이언트에게 응답할 수 있습니다. 오늘날 모든 웹 브라우저와 대다수 클라이언트는 SNI를 지원합니다. 실제로 CloudFront에 연결되는 클라이언트의 99.5% 이상이 SNI를 지원하고 있습니다.

ALB의 스마트 인증서 선택

ALB의 스마트 인증서 선택은 SNI보다 한 걸음 더 나아갑니다. 유효한 도메인 이름 목록이 저장되는 것 외에도 키 교환 유형과 서버가 지원하는 암호화, 그리고 인증서 서명에 사용되는 알고리즘(SHA2, SHA1, MD5)이 인증서에 설명되어 있습니다. TLS 연결을 구성하려면 먼저 클라이언트가 프로토콜 버전, 확장자, 암호 그룹, 압축 방법 등 클라이언트의 기능을 간략히 나타낸 “ClientHello” 메시지를 전송하여 TLS 핸드섀이크를 시작합니다. 그러면 ALB의 스마트 선택 알고리즘이 각 클라이언트가 지원하는 기능에 따라 연결에 적합한 인증서를 선택하여 클라이언트에게 보냅니다. ALB는 고전적인 RSA 알고리즘과 최근에 등장하여 더욱 빠른 속도를 자랑하는 타원 곡선(Elliptic-curve) 기반 ECDSA 알고리즘을 모두 지원합니다. ECDSA 지원이 SNI만큼 클라이언트 사이에 널리 퍼진 것은 아니지만 오늘날 모든 웹 브라우저에서는 이미 지원되고 있습니다. 속도가 더욱 빠를 뿐만 아니라 CPU 사용량도 적기 때문에 지연 시간이 매우 낮은 애플리케이션에 유용할 뿐만 아니라 모바일 애플리케이션에서 사용되는 배터리 양을 절약하는 데도 매우 효과적입니다. ALB가 TLS 핸드섀이크를 통해 각 클라이언트가 지원하는 기능을 알 수 있기 때문에 RSA 인증서와 ECDSA 인증서를 동일한 도메인에 모두 업로드할 수 있습니다. 그러면 ALB가 각 클라이언트마다 가장 알맞은 인증서를 자동으로 선택합니다.

ALB와 SNI의 사용

여기에서 2개의 웹사이트인 VimIsBetterThanEmacs.com과 VimIsTheBest.com를 예로 들겠습니다. 저는 이 두 도메인을 구매하여 Amazon Route 53에 호스팅한 후 각 도메인에 사용할 인증서 2개를 AWS Certificate Manager(ACM)에 프로비저닝하였습니다. 이때 단일 ALB를 통해 두 사이트를 모두 안전하게 운영하고 싶다면 콘솔에서 인증서 2개를 빠르게 추가할 수 있습니다.

먼저 콘솔에서 내 로드 밸런서를 선택한 후 리스너 탭으로 이동하여 “view/edit certificates”를 선택합니다.

그런 다음 왼쪽 상단 모퉁이에 있는 “+” 버튼을 사용하여 인증서를 선택한 다음 “Add” 버튼을 클릭합니다.

이제 다 끝났습니다. GUI 사용에 익숙하지 않다면 AWS 명령줄 인터페이스(CLI)(또는 SDK)를 사용하여 새로운 인증서를 쉽게 추가하는 방법도 있습니다.

aws elbv2 add-listener-certificates --listener-arn <listener-arn> --certificates CertificateArn=<cert-arn>

알아야 할 것들

ALB 액세스 로그에는 클라이언트가 요청한 호스트 이름과 사용한 인증서 ARN이 포함됩니다. “hostname” 필드가 비어있다면(“-“로 표시) 클라이언트가 요청에서 SNI 확장을 사용하지 않았기 때문입니다.
ACM 또는 IAM에서는 어떤 인증서든 사용할 수 있습니다.
동일한 도메인이라고 해도 다수의 인증서를 보안 리스너로 바인딩할 수 있습니다. 그러면 ALB가 클라이언트 기능을 포함하여 여러 가지 요인에 따라 최적의 인증서를 선택합니다.
클라이언트가 SNI를 지원하지 않으면 ALB가 기본 인증서(리스너 생성 시 지정한 인증서)를 사용합니다.
새로운 ELB API 호출은 AddListenerCertificates, RemoveListenerCertificates, DescribeListenerCertificates 등 세 가지가 있습니다.
로드 밸런서 1개당 바인딩이 가능한 인증서는 최대 25개입니다(기본 인증서 제외).
이번에 새롭게 추가된 기능은 처음부터 AWS CloudFormation에서 지원됩니다.

새로운 기능의 사용 예는 저의 동료인 Jon Zobrist가 만든 웹사이트(https://www.exampleloadbalancer.com/)에서 찾아볼 수 있습니다.

저는 개인적으로 이 기능을 사용할 예정이며 수많은 AWS 사용자들 역시 커다란 이점을 경험하게 될 것입니다. AWS 사용자들을 위해 이처럼 멋진 기능을 개발하느라 수고해 주신 Elastic Load Balancing 팀에게 깊은 감사를 드립니다.

– Randall;

이 글은 Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI 한국어 번역입니다.

Source: 애플리케이션 로드 밸런서(ALB) 기반 서버 이름별(SNI) 다중 TLS 인증서 지원