포스트

네트워크 보안의 기초와 암호화 프로토콜

네트워크 보안의 기초와 암호화 프로토콜

네트워크 보안이란 컴퓨터 네트워크 인프라와 그 위에서 전달되는 데이터를 인가되지 않은 접근, 변경, 파괴, 유출로부터 보호하기 위한 일련의 정책, 절차, 기술적 조치를 의미합니다.

네트워크 보안의 필요성

개인정보 및 기밀 데이터 보호(Data Privacy & Leakage Prevention)

현대의 애플리케이션은 사용자 계정 정보, 결제 내역, 행동 로그 등 방대한 양의 민감 데이터를 다룹니다.

해커는 네트워크의 취약점을 노려 데이터베이스에 접근하거나, 통신 중인 패킷을 스니핑(Sniffing)하여 데이터를 탈취합니다. 이는 단순한 정보 유출을 넘어 크리덴셜 스터핑(Credential Stuffing, 탈취한 계정으로 타 사이트에 대입하는 공격)과 같은 2차 피해로 이어집니다. 따라서 TLS/SSL 암호화와 네트워크 분리(Network Segmentation) 를 통해 인가되지 않은 자의 데이터 접근을 원천 차단해야 합니다.

데이터 변조 방지(Data Integrity Protection)

네트워크를 통해 전달되는 데이터는 여러 라우터와 스위치를 거치며 목적지에 도달합니다.

이 과정에서 공격자가 중간에 개입하여 데이터를 가로채고 조작하는 중간자 공격(MitM, Main-in-the-Middle Attack) 이 발생할 수 있습니다. 예를 들어, 송금액 ‘10,000원’을 ‘1,000,000원’으로 변조하거나, 수신자의 계좌번호를 바꾸는 치명적인 결과를 낳습니다. 이를 막기 위해 데이터가 전송 중에 단 1비트도 변경되지 않았음을 수학적으로 증명하는 해시(Hash) 및 디지털 서명 기술이 네트워크 프로토콜에 강제되어야 합니다.

시스템 다운 방지 및 비즈니스 연속성 보장(Preventing Downtime & Ensuring Business Continuity)

B2C 서비스나 기업용 SaaS에서 시스템의 다운타임(Downtime)은 곧 즉각적인 매출 손실과 고객 이탈을 의미합니다.

좀비 PC들을 동원하여 서버의 네트워크 대역폭이나 자원을 고갈시키는 DDoS(분산 서비스 거부) 공격은 시스템을 마비시키는 대표적인 원인입니다. 네트워크 보안은 비정상적인 트래픽을 식별하고 걸러내는 트래픽 스크러빙(Traffic Scrubbing), 웹 방화벽(WAF), 로드 밸런서(Load Balancer) 등을 통해 24시간 365일 무중단 서비스를 제공할 수 있는 탄력성(Resilience)을 확보하는 과정입니다.

악성 코드 및 타겟형 해킹 방지 (Malware Propagation & APT Defense)

하나의 서버나 PC가 감염되면, 해당 기기를 교두보 삼아 내부 네트워크 전체로 피해가 확산(Lateral Movement)됩니다.

랜섬웨어(Ransomware)나 웜(Worm)과 같은 악성 코드는 네트워크의 열린 포트나 취약한 프로토콜(예: 구버전 SMB)을 통해 스스로 전파됩니다. 또한, 특정 기업을 집요하게 노리는 APT(지능형 지속 위협) 공격자들은 백도어(Backdoor)를 설치하여 지속적으로 내부 정보를 빼냅니다. 네트워크 보안은 침입 탐지/방지 시스템(IDS/IPS) 을 통해 악성 페이로드(Payload)가 네트워크 경계를 넘지 못하도록 심층 패킷 분석(Deep Packet Inspection)을 수행합니다.

법적 규제 준수 및 기업 신뢰도(Compliance & Brand Trust)

기술적인 이유 외에도, 보안 사고는 기업에 막대한 법적, 재정적 타격을 줍니다. ISMS-P(정보보호 및 개인정보보호 관리체계 인증)나 GDPR 같은 글로벌 컴플라이언스를 준수하지 않으면 천문학적인 과징금이 부과될 수 있습니다. 보안은 기업의 가치를 지키는 ‘보험’이자 ‘필수 투자’입니다.

STRIDE Threat Modeling

이러한 다양한 위협들을 방어하기 위해, 소프트웨어나 네트워크 아키텍처를 설계하는 초기 단계에서 마이크로소프트가 고안한 STRIDE 위협 모델링을 실무에서 널리 사용합니다. 개발자와 보안 엔지니어는 시스템을 구축하기 전, 다음 6가지 관점에서 발생할 수 있는 취약점을 미리 식별하고 설계에 반영합니다.

  1. Spoofing (위장) : 다른 사용자나 시스템인 척 속이는 행위 (예: IP 스푸핑) $\rightarrow$ 인증(Authentication)으로 방어
  2. Tampering (변조) : 전송되거나 저장된 데이터를 악의적으로 수정하는 행위 $\rightarrow$ 무결성(Integrity) 보장으로 방어
  3. Repudiation (부인) : 특정 행위를 해놓고 하지 않았다고 발뺌하는 것 $\rightarrow$ 로그 기록 및 부인 방지(Non-repudiation) 기술로 방어
  4. Information Disclosure (정보 유출) : 기밀 데이터를 권한 없는 자에게 노출하는 행위 $\rightarrow$ 암호화(Encryption)로 방어
  5. Denial of Service (서비스 거부) : 정상 사용자의 서비스 이용을 방해하는 행위 (예: DDoS) $\rightarrow$ 가용성(Availability) 확보로 방어
  6. Elevation of Privilege (권한 상승) : 일반 사용자가 관리자 권한을 탈취하는 행위 $\rightarrow$ 접근 제어(Access Control) 및 최소 권한 원칙으로 방어

보안의 3대 요소(CIA Triad)

네트워크 보안을 설계할 때 가장 기본이 되는 철학이자 목표가 바로 CIA Triad입니다. 모든 보안 솔루션과 정책은 결국 이 세 가지 요소를 유지하기 위해 존재합니다.

기밀성(Confidentiality)

인가된 사용자만 정보에 접근할 수 있도록 보장하는 특성입니다. 데이터가 전송 중이거나 저장되어 있을 때 제3자가 그 내용을 엿보지 못하게 막는 것이 핵심입니다.

  • 데이터 암호화(Encryption) : 저장된 데이터(Data at Rest)와 전송 중인 데이터(Data in Transit)를 수학적 알고리즘(AES, RSA 등)으로 변환하여, 해커가 탈취하더라도 내용을 알아볼 수 없게 만듭니다.
  • 접근 제어(Access Control) : RBAC(역할 기반 접근 제어) 등을 통해 사용자의 부서나 직급에 따라서 접근할 수 있는 데이터의 범위를 엄격하게 제한합니다.

고려 사항

  • 성능(Performance) vs. 보안(Security) : 기밀성을 높이기 위해 복잡한 암호화 알고리즘을 사용하거나 암호화 키 길이를 늘리면(예: RSA-2048에서 RSA-4096으로 변경), 서버의 CPU 사용량이 급증하고 암호화/복호화에 걸리는 지연 시간(Latency)이 길어집니다.
  • 관리의 복잡성(Key Management) : 암호화 자체가 뚫리기보다 ‘암호화 키(Key)’ 관리를 소홀히 하여 하드코딩된 키가 유출되는 경우가 훨씬 많습니다. 안전한 키 관리 시스템(KMS, Key Management Service)을 도입해야 하는 운영 오버헤드가 발생합니다.

무결성(Integrity)

데이터가 생성, 전송, 저장되는 모든 과정에서 인가되지 않은 방식으로 변경, 삭제, 훼손되지 않았음을 보장하는 특성입니다. 수신한 데이터가 송신자가 보낸 원본과 100% 동일함을 증명해야 합니다.

  • 해시 함수(Hash Functions) : SHA-256과 같은 단방향 함수를 사용하여 데이터의 ‘디지털 지문(Digest)’을 만듭니다. 원본 데이터가 1비트라도 바뀌면 해시값이 완전히 달라지므로 변조 여부를 즉각 알 수 있습니다.
  • 디지털 서명 및 HMAC : 데이터에 발신자의 비밀키로 서명(Signature)을 남겨, “누가 보냈는지”와 “내용이 바뀌지 않았는지”를 동시에 증명합니다.

고려 사항

  • 엄격성(Strictness) vs. 유연성(Flexibility) : 무결성을 너무 엄격하게 검증하면, 네트워크의 아주 미세한 패킷 손실이나 포맷 변환 과정에서도 데이터가 ‘변조’된 것으로 오탐지되어 정상적인 서비스 흐름이 끊길 수 있습니다. 시스템의 성격에 맞춰 무결성 검증의 민감도를 조절해야 합니다.

가용성(Availability)

인가된 사용자가 필요할 때 언제든지 시스템과 데이터에 접근하고 사용할 수 있도록 보장하는 특성입니다. 아무리 기밀성과 무결성이 뛰어나도, 정작 필요할 때 서버가 다운되어 있다면 보안이 뚫린 것과 다름없습니다.

  • 이중화 및 다중화(Redundancy) : 서버, 데이터베이스, 네트워크 라우터를 2중, 3중으로 구성하여 한 대가 고장 나더라도(SPOF, Single Point of Failure 제거) 다른 장비가 즉각 서비스를 이어받도록(Fail-over) 설계합니다.
  • 트래픽 분산(Load Balancing) 및 Anti-DDoS 솔루션 : 막대한 트래픽이 몰려도 서버가 뻗지 않도록 부하를 분산시키고, 악의적인 대규모 패킷 공격을 앞단에서 걸러냅니다.

고려 사항

  • 비용(Cost) vs. 가동 시간(Uptime) : 가용성은 곧 ‘돈’입니다. 시스템 가동률 99.9%(연간 약 8.7시간 장애)를 99.999%(연간 약 5분 장애)로 끌어올리려면 인프라 투자 비용이 기하급수적으로(때로는 10배 이상) 증가합니다. 비즈니스가 감당할 수 있는 목표 복구 시간(RTO)을 설정하고 그에 맞는 경제적인 아키텍처를 설계하는 것이 핵심입니다.

확장된 보안 모델(CIA + AAA)

현대의 복잡한 IT 환경에서는 CIA Triad만으로는 부족하여, 이를 실무 시스템에 적용하기 위한 통제 프레임워크인 AAA 모델을 함께 엮어서 설계합니다.

  • Authentication (인증 - “너는 누구인가?”) : 사용자의 신원을 확인합니다. (예: ID/PW, 생체 인식). 기밀성을 보장하기 위한 첫 관문입니다.
  • Authorization (인가 - “무엇을 할 수 있는가?”) : 인증된 사용자에게 적절한 권한을 부여합니다. (예: 일반 유저는 읽기만, 관리자는 쓰기까지). 기밀성과 무결성을 통제합니다.
  • Accounting (과금/추적 - “무엇을 했는가?”) : 사용자의 모든 시스템 접근과 행동을 로그로 기록합니다. 이는 사후 감사(Audit)와 부인 방지(Non-repudiation, “내가 안 했어”라고 발뺌하는 것을 막는 것) 에 필수적입니다.

대칭키 암호화(Symmetric Key Cryptography)

대칭키 암호화는 암호화(Encryption)와 복호화(Decryption) 과정에 동일한 하나의 비밀키(Secret Key, $K$)를 사용하는 방식입니다.

이를 수학적 모델로 표현하면 다음과 같습니다. 평문을 $P$(Plaintext), 암호문을 $C$(Ciphertext), 암호화 함수를 $E$, 복호화 함수를 $D$라고 할 때:

  • 암호화 : $C = E_K(P)$
  • 복호화 : $P = D_K(C)$

즉, 동일한 $K$를 양방향 연산에 적용하는 대칭적(Symmetric) 구조를 가집니다. 따라서 이 방식 시스템의 보안성은 암호화 알고리즘의 비밀성에 의존하는 것이 아니라, ‘오직 키($K$)를 얼마나 안전하게 비밀로 유지하는가(Kerckhoffs’s principle)’ 에 전적으로 달려 있습니다.

암호화 과정과 핵심 매커니즘

대칭키가 데이터를 섞는 근본적인 원리는 정보 이론의 아버지인 클로드 섀넌(Claude Shannon)이 제안한 두 가지 개념에 기반합니다.

  • 혼돈 (Confusion) : 평문과 암호문, 그리고 키 사이의 상관관계를 극도로 복잡하게 만들어, 암호문을 분석해도 키를 유추할 수 없게 만듭니다. (주로 비트 치환을 통해 구현)
  • 확산 (Diffusion) : 평문의 단 1비트만 변경되어도 암호문 전체의 절반 이상이 변경되도록(눈사태 효과, Avalanche Effect) 데이터를 흩뿌립니다. (주로 비트 위치의 순열 및 섞기를 통해 구현)

이러한 원리를 바탕으로, 대칭키 알고리즘은 데이터를 처리하는 단위에 따라 크게 블록 암호스트림 암호로 나뉩니다.

  • 블록 암호 (Block Cipher) : 데이터를 고정된 크기의 ‘블록(Block, 예: 128비트)’ 단위로 쪼개어 암호화합니다. 현재 전 세계 표준이자 가장 널리 쓰이는 AES(Advanced Encryption Standard) 가 대표적입니다.

AES의 동작 원리 (SPN 구조)

AES는 평문 블록과 키를 XOR 연산하는 것을 시작으로, 데이터를 치환하고(SubBytes), 행을 섞고(ShiftRows), 열을 섞고(MixColumns), 다시 키와 XOR 하는(AddRoundKey) 과정을 한 ‘라운드(Round)’ 로 정의합니다. 키의 길이(128, 192, 256비트)에 따라 이 라운드를 10~14회 반복하여 평문의 흔적을 완전히 지워버립니다.

  • 스트림 암호 (Stream Cipher) : 데이터를 블록으로 쪼개지 않고, 비트(Bit)나 바이트(Byte) 단위로 물 흐르듯 실시간으로 암호화합니다.

동작 원리

짧은 비밀키를 시드(Seed)로 사용하여 무한히 긴 의사 난수열(Keystream)을 생성한 뒤, 이 난수열과 평문을 연속적으로 XOR ($\oplus$) 연산하여 암호문을 만듭니다. 통신 환경이나 IoT 기기처럼 지연 시간(Latency)이 없고 리소스가 제한적인 곳에서 ChaCha20과 같은 알고리즘이 널리 쓰입니다.

대칭키의 장점

  • 압도적인 연산 속도와 효율성 : 수학적으로 무거운 소인수분해를 요구하는 비대칭키와 달리, 대칭키는 단순한 비트 논리 연산(XOR, Shift 등)의 반복입니다. 비대칭키 대비 수백~수천 배 빠릅니다.
  • 하드웨어 가속 지원 : 최신 CPU들은 AES-NI(AES New Instructions)라는 전용 하드웨어 명령어를 내장하고 있어, 소프트웨어 레벨의 오버헤드 없이 기가비트급 속도로 암호화를 수행합니다.
  • 작은 암호문 크기 : 평문의 크기와 암호문의 크기가 거의 동일하게 유지되어 네트워크 대역폭이나 스토리지 낭비가 적습니다.

대칭키의 단점

  • 키 분배 문제 (Key Distribution) : 물리적으로 떨어진 송수신자가 안전하지 않은 네트워크를 통해 어떻게 이 ‘동일한 키’를 교환할 것인가가 가장 큰 딜레마입니다. 중간에 키가 탈취되면 시스템이 붕괴됩니다.
  • 키 관리의 확장성 부재 : $N$명의 사용자가 서로 안전하게 1:1 통신을 하려면 $\frac{N(N-1)}{2}$ 개의 키가 필요합니다. 사용자가 1,000명만 되어도 약 50만 개의 키를 관리해야 하는 복잡성이 발생합니다.
  • 부인 방지(Non-repudiation) 불가능 : 송신자와 수신자가 같은 키를 가지므로, 수신된 메시지를 송신자가 보낸 것인지 수신자가 스스로 조작한 것인지 제3자에게 증명할 수 없습니다. 즉, ‘전자 서명’을 구현할 수 없습니다.

비대칭키 암호화(Asymmetric Key Cryptography)

대칭키가 하나의 열쇠로 문을 잠그고 여는 방식이었다면, 비대칭키는 수학적으로 긴밀하게 연결된 두 개의 다른 열쇠(Key Pair)를 사용합니다.

  • 공개키 (Public Key) : 자물쇠와 같습니다. 전 세계 누구에게나 공개하고 나누어 줍니다.
  • 개인키 (Private Key / Secret Key) : 자물쇠를 여는 유일한 열쇠입니다. 소유자만이 절대적으로 안전하게 보관해야 하며, 절대 네트워크를 통해 전송하지 않습니다.

이 두 키는 ‘트랩도어 일방향 함수(Trapdoor One-Way Function)’ 라는 수학적 난제에 기반합니다. 한 방향으로 연산(암호화)하기는 매우 쉽지만, 반대 방향으로 역산(복호화)하는 것은 우주 나이만큼의 시간이 걸릴 정도로 어렵습니다. 단, 숨겨진 지름길인 ‘트랩도어(개인키)’를 알고 있는 사람만 순식간에 역산을 해낼 수 있는 원리입니다.

암호화 과정과 핵심 시나리오

비대칭키의 가장 주요한 점은 어떤 키를 먼저 사용하느냐에 따라 목적이 완전히 달라진다는 것입니다. 실무에서는 이 두 가지 메커니즘을 명확히 구분하여 설계해야 합니다.

시나리오 A : 수신자의 공개키로 암호화 $\rightarrow$ “기밀성 보장”

A가 B에게 비밀 메시지를 보내고 싶을 때 사용하는 방식입니다.

  1. A는 B의 ‘공개키’ 를 구해서 메시지를 암호화합니다.
  2. 암호화된 메시지는 네트워크를 통해 전송됩니다. (해커가 가로채도 풀 수 없습니다.)
  3. 메시지를 받은 B는 오직 자신만 가지고 있는 ‘개인키’ 로 메시지를 복호화하여 읽습니다.

오직 B만이 이 데이터를 읽을 수 있도록 보장합니다.

시나리오 B : 송신자의 개인키로 암호화 $\rightarrow$ “무결성 보장”

A가 “이 메시지는 진짜 내가 보낸 것이 맞다”고 증명하고 싶을 때 사용하는 방식입니다.

  1. A는 자신의 ‘개인키’ 로 메시지(주로 메시지의 해시값)를 암호화하여 원본과 함께 보냅니다. 이를 ‘서명(Sign)’한다고 합니다.
  2. 수신자들은 A가 미리 배포해 둔 ‘공개키’ 를 사용해 암호화된 부분을 복호화해 봅니다.
  3. 만약 정상적으로 복호화가 된다면? 이 세상에서 A의 공개키로 풀리는 암호문을 만들 수 있는 사람은 ‘A의 개인키를 가진 사람’뿐이므로, A가 보냈음이 100% 수학적으로 증명됩니다.

데이터의 출처를 인증(Authentication)하고, 송신자가 나중에 발뺌하지 못하도록 부인 방지(Non-repudiation)를 구현합니다.

비대칭키의 장점

  • 키 분배 문제의 완벽한 해결 : 개인키는 내 PC나 서버에 가만히 두고, 공개키만 자유롭게 배포하면 되므로 네트워크 중간에 키가 탈취될 위험이 원천 차단됩니다.
  • 뛰어난 확장성 : $N$명의 사용자가 통신할 때 $\mathcal{O}(N)$ 개의 키 쌍만 있으면 됩니다. (대칭키의 $\mathcal{O}(N^2)$ 문제 해결)
  • 전자 서명 구현 가능 : 앞서 설명한 시나리오 B를 통해 온라인 계약, 공인인증서, 블록체인 트랜잭션 등 현대 디지털 신뢰 시스템의 뼈대를 형성합니다.

비대칭키의 단점

  • 최악의 연산 퍼포먼스 : 거대한 소수(Prime Number)를 곱하고 나누는 모듈러(Modulo) 연산 등을 사용하기 때문에, 대칭키 알고리즘(AES)에 비해 속도가 1,000배 이상 느리며 막대한 CPU 리소스를 소모합니다.
  • 긴 키 길이 요구 : 수학적 안전성을 확보하기 위해 키의 길이가 매우 길어야 합니다. 대칭키인 AES는 256비트면 국방급 보안을 자랑하지만, 비대칭키인 RSA는 최소 2048비트, 권장 3072비트 이상을 사용해야 안전합니다.
  • 중간자 공격(MitM)의 위험 : 해커가 중간에 개입하여 수신자에게 ‘가짜 공개키’를 던져주면 통신이 뚫릴 수 있습니다. (이를 막기 위해 공개키의 신뢰성을 보증하는 제3자 기관인 PKI/인증서 시스템이 필요해집니다.)

세대교체(RSA vs ECC)

현재 IT 업계 표준 비대칭키 알고리즘은 크게 두 가지로 나뉘며, 모바일과 클라우드 환경을 고려하여 최적의 알고리즘을 선택해야 합니다.

RSA (Rivest–Shamir–Adleman)

“두 개의 거대한 소수를 곱하기는 쉽지만, 그 결과를 다시 두 소수로 인수분해하기는 극도로 어렵다”는 난제에 기반합니다.

역사상 가장 널리 쓰인 표준이지만, 컴퓨터 성능이 발전함에 따라 안전을 위해 키 길이를 계속 늘려야(2048 $\rightarrow$ 3072 $\rightarrow$ 4096비트) 했고, 이로 인해 연산 부하가 너무 커지는 한계에 직면했습니다.

ECC (Elliptic Curve Cryptography, 타원 곡선 암호)

타원 곡선 상의 점들의 수학적 특성(이산 대수 문제)을 이용합니다.

현대 비대칭키의 새로운 표준입니다. ECC 256비트의 보안 강도는 RSA 3072비트와 맞먹습니다. 즉, 훨씬 짧은 키 길이로 동일한 보안성을 제공하므로 연산이 빠르고 배터리 소모가 적습니다. 현재 비트코인 등 블록체인 지갑 주소 생성과 최신 TLS 1.3 웹 환경에서는 대부분 ECC(ECDSA, ECDHE)를 표준으로 사용합니다.

HTTPS와 SSL/TLS

HTTP는 웹 브라우저와 웹 서버 간에 데이터를 주고받는 기본 규약입니다. 하지만 데이터가 평문(Plaintext) 으로 전송되기 때문에, 카페의 공용 와이파이 같은 곳에서 해커가 패킷을 스니핑(Sniffing)하면 비밀번호나 신용카드 번호가 그대로 노출됩니다.

HTTP 통신을 보안 채널 위에서 수행하도록 업그레이드한 프로토콜이 HTTPS 입니다. 이 ‘보안 채널’을 만들어주는 핵심 기술이 바로 SSL/TLS입니다. (즉, HTTPS = HTTP + SSL/TLS)

SSL vs. TLS

SSL(Secure Sockets Layer)** 은 1990년대 넷스케이프가 만든 초기 버전입니다. 이후 보안 취약점들이 발견되어 표준화 기구(IETF)로 이관되었고, 이름을 TLS(Transport Layer Security) 로 바꾸어 발전시켰습니다. 현재 SSL 1.0~3.0은 모두 위험성이 높아 폐기(Deprecated)되었으며, 실무에서는 TLS 1.2 또는 TLS 1.3을 사용합니다. 다만 관습적으로 “SSL 인증서”처럼 묶어서 부르기도 합니다.

HTTPS의 3가지 보안

HTTPS는 앞서 배운 CIA Triad를 웹 환경에 완벽하게 구현합니다.

  • 기밀성 (대칭키 사용) : 서버와 클라이언트는 각 세션마다 일회성 대칭키(Session Key)를 생성하여 데이터를 고속으로 암호화합니다.
  • 무결성 (MAC/AEAD 사용) : 전송 중 데이터가 단 1비트라도 조작되지 않았음을 보증합니다.
  • 인증 (비대칭키 + 인증서 사용) : “내가 접속한 google.com 서버가 해커가 만든 가짜 서버가 아니라 진짜 Google 서버가 맞다”는 것을 수학적으로 증명합니다.

인증서(Certificate)와 CA

인증(Authentication)을 위해 가장 중요한 것이 디지털 인증서(Digital Certificate) 입니다.

만약 제가 비대칭키를 만들어 “이게 진짜 구글의 공개키야”라고 우기면, 클라이언트는 속을 수밖에 없습니다(중간자 공격). 이를 막기 위해 전 세계적으로 신뢰받는 제3의 기관인 CA(Certificate Authority, 인증 기관) 가 존재합니다. DigiCert, Let’s Encrypt 등이 대표적입니다.

  • 서버는 자신의 공개키를 CA에게 제출하며 인증서 발급을 요청합니다.
  • CA는 이 서버가 진짜 구글이 맞는지 신원 조회를 한 뒤, CA의 ‘개인키’로 서버의 공개키를 암호화(전자 서명) 하여 인증서를 발급해 줍니다.
  • 사용자의 브라우저(OS)에는 전 세계 유명 CA들의 ‘공개키’가 기본적으로 내장되어 있습니다. 따라서 사이트에 접속했을 때 받은 인증서를 내장된 CA의 공개키로 열어봄으로써, 위조되지 않은 진짜 서버임을 즉시 검증할 수 있습니다.

TLS Handshake(동작 원리)

클라이언트(브라우저)와 서버가 처음 만나 안전한 통신 채널을 수립하는 과정을 TLS 핸드셰이크(Handshake) 라고 합니다. 앞서 배운 대칭키와 비대칭키의 하이브리드 교환 과정이 여기서 일어납니다.

  1. Client Hello : 클라이언트가 서버에게 인사하며 자신이 지원하는 암호화 알고리즘 목록(Cipher Suite)과 무작위 난수 1을 보냅니다.
  2. Server Hello & Certificate : 서버는 클라이언트가 보낸 목록 중 가장 안전한 알고리즘을 선택하고, 무작위 난수 2와 함께 자신의 ‘디지털 인증서(서버의 공개키 포함)’ 를 보냅니다.
  3. Client Key Exchange :
    • 클라이언트는 브라우저에 내장된 CA의 공개키로 서버의 인증서를 검증하여, 서버가 진짜임을 확인합니다.
    • 이후 클라이언트는 난수 1과 난수 2를 조합하여 ‘Pre-Master Secret’ 이라는 예비 대칭키를 만듭니다.
    • 이 예비 대칭키를 해커가 훔쳐보지 못하도록 서버의 ‘공개키’로 암호화(비대칭키 통신) 하여 서버로 전송합니다.
  4. Session Key 생성 : 서버는 암호화된 예비 대칭키를 자신의 ‘개인키’ 로 안전하게 복호화합니다. 이제 양쪽은 동일한 값을 가지게 되었고, 이를 바탕으로 실제 데이터를 암호화할 ‘대칭키(Session Key)’ 를 최종 완성합니다.
  5. Secure Communication (데이터 통신) : 이제 비대칭키의 역할은 끝났습니다. 방금 만든 ‘대칭키’를 사용하여 암호화된 웹 페이지 데이터(HTML, 이미지 등)를 주고받습니다.

오버헤드와 복잡성

  • 성능 오버헤드(Latency) : TLS Handshake 과정에서 브라우저와 서버가 여러 번 데이터를 주고받아야 하므로 RTT(Round Trip Time) 가 크게 증가합니다. 초기 연결이 찰나의 시간만큼 느려집니다.
  • 인증서 관리 비용 및 복잡성 : 인증서는 유효기간(보통 1년, Let’s Encrypt는 90일)이 있습니다. 만료일 관리를 자동화하지 않으면, 멀쩡한 서버가 브라우저에서 ‘위험한 사이트’로 차단되어 대형 서비스 장애로 이어집니다. 시니어 인프라 엔지니어는 반드시 자동 갱신 파이프라인(e.g., Certbot)을 구축합니다.

TLS 1.3의 혁신과 SNI

  • TLS 1.3의 최적화 : 구버전인 TLS 1.2는 핸드셰이크에 2-RTT(왕복 2번)가 필요해 느렸습니다. 최신 표준인 TLS 1.3은 이를 1-RTT로 단축시켜 체감 속도를 엄청나게 끌어올렸습니다. 심지어 이전에 접속했던 서버라면 0-RTT(핸드셰이크 없이 바로 데이터 전송) 기술도 지원합니다.
  • SNI (Server Name Indication) : 과거에는 하나의 IP 주소에 하나의 인증서만 매핑할 수 있었습니다. 현대의 클라우드나 CDN 환경에서는 하나의 서버 IP가 수백 개의 도메인(가상 호스트)을 서비스합니다. SNI는 Client Hello 단계에서 클라이언트가 접속하려는 도메인 네임을 명시하게 하여, 서버가 해당 도메인에 맞는 올바른 인증서를 골라서 응답할 수 있게 해주는 필수 기술입니다.
이 기사는 저작권자의 CC BY-NC 4.0 라이센스를 따릅니다.