대칭키/비대칭키 차이와 HTTPS 암호화 방식

대칭키 암호 비대칭키 암호 용도에 따른 두 가지 활용 대칭키와 비대칭키 비교 양방향 암호화와 단방향 해시 TLS는 왜 둘 다 쓰는가 사전 준비: 인증서 1단계. 인증서 전송 및 검증 2단계. 세션 키 생성 및 전송 3단계. 서버의 세션 키 획득 4단계. 대칭키로 실제 통신 4단계 요약 세션 키를 매번 새로 만드는 이유: 순방향 비밀성 TLS가 보호하지 못하는 것

HTTPS는 대칭키와 비대칭키를 둘 다 사용한다. 하나만 사용하면 될 것 같지만, 둘은 서로 다른 문제를 해결한다. TLS 핸드셰이크는 이 두 암호화 방식을 조합해 각자의 장점은 살리고 단점은 보완하는 과정이다.

대칭키 암호

키 하나로 암호화와 복호화를 모두 처리하는 방식이다. 대표 알고리즘은 AES, DES, 3DES다.

장점: 연산이 빠르고 비용이 낮다. 대용량 데이터 암호화에 적합하다.

단점: 키 배포 문제가 있다. 대칭키는 통신 양쪽이 같은 키를 공유해야 하지만, 그 키를 안전하게 전달하는 방법이 없다. 키를 그대로 전송하면 중간에서 탈취될 수 있고, 공격자는 그 키로 이후의 모든 통신을 복호화할 수 있다.

비대칭키 암호

공개키와 개인키 두 개를 사용하는 방식이다. 대표 알고리즘은 RSA, ECC, DSA다.

공개키(Public Key): 누구나 알아도 되는 키다. 공개해도 안전하다.

개인키(Private Key): 소유자만 보관하는 키다.

동작: 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있다. 반대로 개인키로 서명한 데이터는 공개키로 검증한다.

공개키는 공개해도 되므로 대칭키의 키 배포 문제가 해결된다. 대신 연산이 느리다. 대용량 데이터를 전부 비대칭키로 암호화하기는 어렵다.

용도에 따른 두 가지 활용

어느 키로 암호화하느냐에 따라 목적이 달라진다.

기밀 전송(암호화 목적): 수신자의 공개키로 암호화하고, 수신자의 개인키로 복호화한다. 개인키는 수신자만 보관하므로 다른 사람은 내용을 읽을 수 없다.

디지털 서명(인증 목적): 송신자의 개인키로 서명하고, 송신자의 공개키로 검증한다. 검증에 성공하면 그 메시지를 보낸 사람이 개인키 소유자라는 것이 증명된다.

대칭키와 비대칭키 비교

	대칭키	비대칭키
키 개수	1개	2개 (공개키 + 개인키)
속도	빠름	느림
키 배포	어려움 (배포 자체가 위험)	쉬움 (공개키는 공개 가능)
대표 알고리즘	AES, DES, 3DES	RSA, ECC, DSA
적합한 대상	대용량 데이터	키 교환, 서명

양방향 암호화와 단방향 해시

암호화는 원본으로 되돌릴 수 있는지에 따라서도 나뉜다.

양방향 암호화: 암호문을 원본으로 복원할 수 있다. 대칭키와 비대칭키가 모두 여기에 해당한다. AES, RSA가 대표적이다. 통신 내용과 파일 암호화에 사용한다.

단방향 해시: 원본을 해시로 변환할 수 있지만 해시에서 원본을 복원할 수 없다. SHA-256, bcrypt가 대표적이다. 비밀번호 저장과 데이터 무결성 검증에 사용한다.

비밀번호를 단방향 해시로 저장하는 이유가 여기 있다. 서버는 사용자의 비밀번호 원본을 알 필요가 없다. DB가 유출되어도 원본을 복원할 수 없어야 하기 때문이다.

TLS는 왜 둘 다 쓰는가

TLS(Transport Layer Security)는 클라이언트와 서버의 통신 내용을 암호화하는 표준 프로토콜이다. HTTPS의 S가 이 TLS다. 예전에는 SSL이라 불렀고, 발전 과정에서 TLS로 바뀌었다. "SSL 인증서"라는 표현이 아직 쓰이지만 실질적으로 같은 것을 가리킨다.

TLS가 해결하는 문제는 세 가지다.

기밀성(Confidentiality): 중간에서 통신 내용을 도청할 수 없다.

무결성(Integrity): 중간에서 내용을 변조할 수 없다.

인증(Authentication): 접속한 서버가 진짜인지 확인할 수 있다.

세 번째가 중요하다. 암호화가 완벽해도 통신 상대가 공격자라면 의미가 없다. 지금 통신하는 서버가 진짜라는 것을 먼저 확인해야 암호화가 성립한다. 인증서는 이 확인을 위해 사용한다.

여기서 두 암호화 방식이 각자 역할을 맡는다. 키 교환은 비대칭키로, 실제 데이터 암호화는 대칭키로 처리하는 하이브리드 구조다. 비대칭키의 안전한 키 배포와 대칭키의 속도를 각각 취한 것이다.

사전 준비: 인증서

서버는 자신이 진짜라는 것을 증명해야 한다. 이를 위해 신뢰할 수 있는 제3자 기관인 CA(Certificate Authority)가 발급한 인증서를 미리 보유한다. DigiCert, Let's Encrypt가 대표적인 CA다.

인증서에는 세 가지가 담긴다.

서버의 도메인 (예: naver.com)

서버의 공개키

CA의 디지털 서명. 이 인증서를 CA가 보증한다는 표시다.

1단계. 인증서 전송 및 검증

브라우저가 HTTPS로 접속하면 서버가 인증서를 보낸다. 브라우저는 세 가지를 확인한다.

CA의 서명이 유효한가. 신뢰할 수 있는 기관이 보증했는지 확인한다.

도메인이 일치하는가. 접속하려는 도메인용 인증서가 맞는지 확인한다.

인증서가 만료되지 않았는가.

세 가지를 모두 통과하면 브라우저는 인증서에 담긴 서버의 공개키를 신뢰한다.

2단계. 세션 키 생성 및 전송

통신에 사용할 암호 키를 정해야 한다. 비대칭키로 모든 데이터를 암호화하기에는 느리다. 그래서 이번 연결에서만 사용할 대칭키를 새로 만든다. 이 키를 세션 키라고 한다.

브라우저가 세션 키를 무작위로 생성한다. 이 키를 그대로 전송하면 탈취되므로 서버의 공개키로 암호화해서 보낸다. 공격자가 중간에서 가로채도 내용을 볼 수 없다. 서버의 공개키로 암호화한 데이터는 서버의 개인키로만 복호화할 수 있기 때문이다.

3단계. 서버의 세션 키 획득

서버는 받은 암호문을 자신의 개인키로 복호화해 세션 키를 얻는다. 이제 브라우저와 서버가 같은 세션 키를 보유한다. 중간의 공격자는 그 값을 알지 못한다. 키 교환이 끝났다.

4단계. 대칭키로 실제 통신

이후 통신에는 비대칭키를 사용하지 않는다.

브라우저는 요청 데이터를 세션 키로 암호화해 전송한다.

서버는 세션 키로 복호화해 요청을 처리하고, 응답도 같은 키로 암호화해 회신한다.

대칭 암호화는 연산이 빠르므로 실시간 통신에 부담이 없다. 세션이 끝나면 세션 키는 폐기된다. 다음 접속에는 새로운 세션 키를 생성한다.

4단계 요약


1단계    인증서로 서버 신원 확인       → 가짜 서버 방지        (인증)
2·3단계  비대칭키로 세션 키 교환       → 키 자체를 안전하게 전달
4단계    대칭키로 실제 데이터 암호화   → 빠른 통신             (기밀성)

비대칭키의 안전한 키 교환과 대칭키의 빠른 속도를 조합한 것이 TLS의 하이브리드 설계다. 대칭키와 비대칭키가 왜 둘 다 필요한지를 보여주는 사례다.

위 설명은 개념 이해를 위해 단순화한 것이다. 실제 TLS 1.3은 Diffie-Hellman 키 교환을 사용한다. 세션 키를 직접 전송하지 않고 양쪽이 각자 계산해 도출한다. 다만 비대칭키로 키를 정하고 대칭키로 통신한다는 구조는 동일하다.

세션 키를 매번 새로 만드는 이유: 순방향 비밀성

세션 키는 연결이 끝나면 폐기되고 매번 새로 생성된다. 이 성질을 순방향 비밀성(Forward Secrecy)이라고 한다.

공격자가 통신 패킷을 미리 수집해 두었다가 나중에 서버의 개인키를 탈취한 상황을 가정한다. 세션 키를 계속 재사용하는 구조라면 수집해 둔 과거 패킷을 전부 복호화할 수 있다. 세션마다 일회성 키를 사용하면 개인키가 유출되어도 과거 통신은 복호화할 수 없다.

TLS가 보호하지 못하는 것

TLS는 전송 중인 연결만 암호화한다. 보호 범위는 다음과 같이 제한된다.

데이터가 서버에 도착해 저장된 이후는 TLS의 범위 밖이다. 저장 데이터 암호화는 별도의 문제다.

라우팅에 필요한 IP 주소는 암호화하지 않는다. 암호화 대상은 실제 메시지와 헤더다.

인증서 체계 자체가 뚫리면 막지 못한다. CA가 공격당하거나 위조 인증서가 발급되면 신뢰의 출발점이 무너진다.

대칭키/비대칭키 차이와 HTTPS 암호화 방식 - TLS 핸드셰이크 4단계