CDN SSL/TLS | CDN 보안

CDN의 보안 위험

CDN도 인터넷에 노출된 모든 네트워크와 마찬가지로 경로 상 공격, 데이터 유출, DDoS 공격을 사용하여 목표 원본 서버 네트워크를 압도하려는 시도 등으로부터 보호해야 합니다. CDN의 취약성을 완화하기 위한 전략에는 적절한 SSL/TLS 암호화 및 암호화 전용 하드웨어 등이 있습니다.

SSL/TLS 암호화란 무엇입니까?

TLS(Transport Layer Security)는 인터넷을 통해 전송하는 데이터를 암호화하는 프로토콜입니다. TLS는 최초로 널리 채택된 웹 암호화 프로토콜인 SSL(Secure Sockets Layer)을 확장한 것으로, 기존 프로토콜의 보안 결함을 대부분 해결하였습니다. 이러한 역사적 배경이 있어 업계에서는 이 두 가지 용어를 혼용합니다. http://가 아니라 https://로 시작하는 웹 사이트는 브라우저와 서버 간의 통신에 TLS/SSL을 사용합니다.

공격자가 중요한 데이터에 액세스하지 못하게 하려면 적절한 암호화가 필요합니다. 인터넷은 수많은 위치 간에 데이터가 전송되는 방식으로 설계되었으므로, 전세계로 이동하는 중요한 정보의 패킷을 가로채는 것이 가능합니다. 암호화 프로토콜을 사용하게 되면, 의도된 수신자만 정보를 해독하고 읽을 수 있으며 중간자는 전송된 데이터의 콘텐츠를 해독할 수 없습니다.

TLS 프로토콜의 설계에는 3가지 구성 요소가 있습니다.

1. 인증 - 제공된 ID의 유효성을 검증하는 역량
2. 암호화 - 호스트 간에 전송되는 된 정보를 변조하는 역량
3. 무결성 - 위조 및 변조를 발견하는 역량

Cloudflare의 무료 SSL/TLS에 대해 자세히 알아보세요.

SSL 인증이란 무엇입니까?

사이트에서 TLS를 사용하려면, SSL 인증서 및 해당 키가 필요합니다. 인증서란 사이트의 소유자에 대한 정보 및 비대칭 키 쌍의 공개된 절반을 갖고 있는 파일입니다. 인증서의 정보가 올바른지 확인하기 위해 인증 기관 (CA)이 인증서에 디지털 서명합니다. 인증서를 신뢰하는 것이 인증 기관이 실사를 수행했음을 신뢰하는 것입니다.

일반적으로 운영 체제 및 브라우저에는 암묵적으로 신뢰하는 인증 기관 목록이 있습니다. 웹 사이트가 신뢰할 수 없는 인증 기관이 서명한 인증서를 제공한다면, 브라우저는 방문자에게 무슨 일이 발생할 수 있다고 경고합니다.

인증서 및 인증서의 구현 방식은 또한 강도, 프로토콜 지원, 기타 특징들에 기초하여 독립적으로 평가할 수 있습니다. 시간이 지남에 따라 새롭고 개선된 구현 방식을 이용할 수 있게 되거나 기타 요인들로 인해 인증서 구현의 전반적인 보안이 낮아지게 되면, 등급은 변경될 수 있습니다. 원본 서버에 과거 하위 등급의 SSL 보안 방식이 구현된 경우 일반적으로 등급이 낮게 평가되며 이는 위협에 취약할 수 있습니다.

CDN에는 CDN 제공 인증서를 사용하며 동일 네트워크 내에서 호스팅되는 자산을 방문하는 사람들에게 보안을 제공한다는 추가적인 이점이 있습니다. 방문자는 CDN에만 연결하기 때문에, 원본 서버와 CDN 사이에 사용 중인 낡거나 덜 안전한 인증서가 클라이언트의 경험에 영향을 주지 않게 다.

현실적으로는, 서버와 에지 간의 취약한 보안도 취약성이므로 피해야 합니다. 특히 무료 원본 암호화를 사용하여 원본 서버의 보안을 업그레이드하는 것이 매우 쉬워졌으므로, 이는 꼭 필요한 사항입니다.

적절한 보안은 유기적 검색에도 중요합니다. 암호화된 웹 자산은 Google 검색에서 순위가 높아집니다.

SSL/TLS 연결은 기존 TCP/IP 연결과 다르게 작동합니다. TCP 연결의 초기 단계가 마무리되면, 보안 연결을 설정하기 위한 별도의 교환이 발생합니다. 이 글에서는 보안 연결을 요청하는 장치를 클라이언트, 보안 연결을 제공하는 장치를 서버로 부를 것입니다. 이는 SSL/TLS로 암호화된 웹 페이지를 로드하는 경우도 마찬가지입니다.

먼저 3단계에 걸쳐 TCP/IP 핸드쉐이크가 수행됩니다.

1. 클라이언트가 연결을 시작하기 위해 SYN 패킷을 서버로 전송합니다.
2. 그런 후에 서버는 이 통신을 승인하기 위해 SYN/ACK 패킷으로 해당 초기 패킷에 응답합니다.
3. 마지막으로 클라이언트는 서버로부터 패킷의 수신을 승인하기 위해 ACK 패킷을 반환합니다. 이러한 패킷의 전송 및 수신 순서를 완료하고 나면 TCP 연결이 열리고 데이터를 전송하고 수신할 수 있습니다.

TCP/IP 핸드쉐이크가 이뤄지면, TLS 암호화 핸드쉐이크가 시작됩니다. TLS 핸드쉐이크 구현의 상세한 프로세스는 이 안내서의 범위를 벗어나므로, 여기에서는 핸드쉐이크의 핵심 목적 및 이 과정을 마치는 데 걸리는 시간을 주로 다루겠습니다.

개괄적으로 보면, TLS 핸드쉐이크는 3가지 기본 요소로 구성됩니다.

1. 클라이언트와 서버가 TLS 버전과 통신에 사용할 암호의 유형에 대해 협상합니다.
2. 클라이언트와 서버가 는 상호 인증된 통신을 보장하기 위한 단계를 수행합니다.
3. 향후 암호화된 통신에서 이용할 키를 교환합니다.

아래 그림에서는 TCP/IP 핸드쉐이크와 TLS 핸드쉐이크에 관련된 각 단계가 표시되어 있습니다. 화살표마다 클라이언트와 서버 간에 물리적으로 이동해야 하는 별도의 통신을 나타냅니다. TLS 암호화를 사용하면 전체 메시지 수가 증가하기 때문에 웹 페이지 로드 시간이 길어집니다.

예시를 위해, TCP 핸드쉐이크에 약 50ms가 걸치고, TLS 핸드쉐이크는 약 110ms가 걸린다고 하겠습니다. 이는 대부분 클라이언트와 서버 간에 데이터를 전송하는 데 걸리는 시간으로 인한 것입니다. 장치 간에 정보가 왕복하는 데 걸리는 시간을 말하는 RTT(round-trip time) 개념을 이용하면, 연결을 생성하는 일이 얼마나 "비싼지" 정량화할 수 있습니다. 최적화하지 않고 CDN을 사용하지 않는 경우, RTT가 커진다는 것은 대기 시간과 최종 사용자의 로드 시간이 늘어난다는 의미입니다. 다행히 전체 로드 시간을 개선하고 왕복 여행 횟수를 줄이기 위해 이용할 수 있는 최적화 방식이 있습니다.

SSL로 인한 대기 시간의 개선 방법

SSL 최적화를 통해 RTT를 줄이고 페이지 로드 시간을 개선할 수 있습니다. 다음은 TLS 연결을 최적화할 수 있는 3가지 방법입니다.

TLS 세션 재개 - CDN은 추가 요청에 대해 동일한 세션을 재개함으로써, 원본 서버와 CDN 네트워크 간에 연결을 활성 상태로 오래 유지할 수 있습니다. 연결이 활성 상태로 유지되면 클라이언트가 캐시되지 않은 원본의 내용을 요청할 때 CDN과 원본 서버 간의 연결 재협상에 소모되는 시간이 줄어듭니다. CDN에 대한 연결이 유지되는 동안에 원본 서버가 추가 요청을 수신하는 한, 사이트에 대한 추가적인 방문자들이 경험하는 대기 시간은 짧아질 것입니다.

세션 재개의 전체 비용은 전체 TLS 핸드쉐이크의 50% 미만이며, 이는 전체 TLS 핸드쉐이크에는 왕복이 2회 필요하지만, 세션 재개는 1회의 왕복으로 끝나기 때문입니다. 또한 세션 재개에는 (새 세션에 필요한) 대량의 유한 필드 계산이 필요하지 않으므로 클라이언트의 CPU 비용은 전체 TLS 핸드쉐이크에서와 비교하면 거의 무시할 수 있습니다. 모바일 사용자의 경우, 세션 재개로 성능을 높이면, 훨씬 반응성이 좋아지고, 배터리 수명이 늘어나는 효과가 있습니다.

TLS 거짓 시작 사용 - 방문자가 처음으로 사이트를 방문한 경우에는 위에서 언급한 세션 재개가 도움이 되지 않습니다. TLS 거짓 시작을 이용하게 되면 송신자는 완전한 TLS 핸드쉐이크 없이 응용 프로그램 데이터를 전송할 수 있게 됩니다.

거짓 시작은 TLS 프로토콜 자체를 수정하는 것이 아니고, 데이터가 전송되는 시점만 변경합니다. 클라이언트가 키 교환을 시작하면, 암호화를 보장할 수 있으므로, 데이터 전송이 시작됩니다. 이렇게 조정함으로써 왕복 회수가 줄어들고 필요 대기 시간이 60ms 단축됩니다.

제로 왕복 시간 재개(0-RTT) - 0-RTT를 이용하면 연결에 RTT 대기 시간이 추가되지 않고 세션을 재개할 수 있습니다. TLS 1.3 및 0-RTT를 사용하여 재개된 연결의 경우 연결 속도가 향상되어 사용자들이 정기적으로 방문하는 웹 사이트에 대해 더 빠르고 보다 부드러운 웹 경험을 제공하게 됩니다. 이러한 속도 향상은 특히 모바일 네트워크 상에서 두드러집니다.

0-RTT는 효과적인 개선 방법이지만, 보안을 희생하는 면이 없지는 않습니다. CDN 서비스는 재생 공격이라고 하는 위험을 극복하기 위해 HTTP 요청의 유형 및 허용되는 매개변수에 대해 제한할 수 있습니다. 자세한 내용은 0-RTT 소개를 참조하세요.

DDoS 공격에 대한 CDN의 보호

현대 인터넷에서 웹 자산의 가장 큰 보안 취약점은 분산 서비스 거부(DDoS) 공격입니다. 시간이 지나면서, DDoS 공격은 규모와 복잡도가 증가했습니다. 공격자는 봇넷을 사용하여 공격 트래픽으로 웹 사이트를 공격합니다. 적절하게 구성된 대규모 CDN은 DDoS 방어를 위한 규모의 효과를 누릴 수 있습니다. CDN은 또한 데이터 센터가 충분히 분산되어 있고, 상당한 대역폭 성능을 유지하므로 목표 원본 서버를 쉽게 압도할 수 있을 정도의 유입 공격 트래픽을 감당하며 완화할 수 있습니다.

TLS 연결을 보안하기 위해 다른 조치를 취할 수도 있습니다. Cloudflare CDN 및 TLS 공격 최신 정보를 참조하시기 바랍니다. Cloudflare 진단 센터에서 웹 사이트가 적절한 HTTPS를 사용하는지 검토하시기 바랍니다.