HTTPS와 TLS

HTTPS(HTTP Secure, 보안 HTTP)는 HTTP 메시지를 TLS(Transport Layer Security, 전송 계층 보안)로 암호화한 연결 위에서 주고받는 방식이다. TLS는 세 가지를 한꺼번에 해결한다. 엿보지 못하게 암호화하고, 중간에 바꾸면 알아채게 하며, 접속한 서버가 진짜인지 인증서(certificate)로 확인한다. 이를 위해 느리지만 키를 나누기 쉬운 공개 키 암호화(public-key encryption)와, 빠른 대칭 키 암호화(symmetric-key encryption)를 섞어 쓴다.

평문 HTTP의 세 가지 위험

암호화하지 않은 HTTP 메시지는 공용 와이파이나 중간 네트워크 장비를 지나면서 그대로 노출된다.

위험	무슨 일이 생기나	TLS의 대응
도청	비밀번호·로그인 정보를 누군가 읽는다	암호화
변조	응답 페이지에 악성 스크립트를 끼워 넣는다	무결성 검사
위장	가짜 서버가 진짜 사이트인 척한다	인증서로 서버 인증

TLS의 무결성 검사는 암호화한 데이터마다 대칭 키로 계산한 검사 값을 붙이는 방식이다. 받는 쪽이 같은 키로 다시 계산해 값이 다르면 중간에 바뀐 것으로 보고 버린다.

세 번째가 특히 중요하다. 암호화만 하고 상대를 확인하지 않으면, 중간에 끼어든 공격자와 암호화 통신을 하게 될 수 있다. 이런 공격을 중간자 공격(man-in-the-middle attack)이라고 한다.

대칭 키와 공개 키

대칭 키 암호화는 잠글 때와 풀 때 같은 키 하나를 쓰는 방식이다. 대표가 AES(Advanced Encryption Standard, 고급 암호화 표준)다. 계산이 빠르고 요즘 CPU는 AES를 하드웨어로 지원하므로 큰 데이터를 암호화하기에 알맞다. 문제는 키를 나누는 일이다. 처음 만나는 서버와 같은 키를 가지려면 그 키를 네트워크로 보내야 하는데, 그 순간 엿보이면 끝이다.

공개 키 암호화는 짝을 이루는 두 키를 쓴다. 공개 키(public key)는 누구에게나 나눠 주고, 개인 키(private key)는 주인만 가진다. 공개 키로 잠근 것은 개인 키로만 풀 수 있으므로, 키를 미리 나누지 않아도 안전하게 비밀을 전할 수 있다. 대표가 RSA(Rivest–Shamir–Adleman)와 타원 곡선 암호(elliptic curve cryptography)다. 타원 곡선 암호는 RSA보다 훨씬 짧은 키로 같은 수준의 안전성을 낸다. 대신 계산이 대칭 키보다 훨씬 느리다.

그래서 TLS는 둘을 섞는다. 연결 초반의 짧은 협상에서는 공개 키 기술로 양쪽만 아는 대칭 키를 안전하게 만들고, 그 뒤 실제 데이터는 그 대칭 키로 빠르게 암호화한다.

해시와 전자 서명

해시 함수(hash function)는 임의 길이의 데이터를 고정 길이 값으로 바꾸는 함수다. TLS와 인증서에 쓰는 SHA-256(Secure Hash Algorithm 256-bit, 256비트 값을 내는 보안 해시 알고리즘) 같은 암호 해시는 원본이 1비트만 달라도 결과가 완전히 달라지고, 결과값으로 원본을 거꾸로 알아내는 것이 계산량이 너무 커서 현실적으로 불가능하다. 그래서 받은 데이터의 해시 값이 보낸 쪽의 값과 같으면 내용이 바뀌지 않았다고 볼 수 있다. 다만 공격자가 데이터와 해시 값을 함께 바꿔 보내면 알아챌 수 없다. 그래서 해시 값을 공격자가 만들 수 없게 묶는 장치가 필요하고, 그것이 전자 서명(digital signature)이다.

전자 서명은 해시와 공개 키를 합친 것이다. 보내는 쪽은 데이터의 해시 값을 자기 개인 키로 계산해 서명 값을 만들어 붙인다. 받는 쪽은 받은 데이터로 해시를 직접 계산하고, 보낸 쪽의 공개 키로 그 해시와 서명 값이 짝이 맞는지 검증한다. 검증이 통과하면 개인 키 주인이 만들었다는 것과 내용이 바뀌지 않았다는 것을 동시에 확인한다.

인증서와 인증서 체인

서버의 공개 키를 받았다고 해도, 그 키가 정말 그 사이트의 것인지는 알 수 없다. 인증서는 이 문제를 푼다. 인증서는 "이 공개 키는 www.example.com의 것이다"라는 내용에 CA(Certificate Authority, 인증 기관)가 전자 서명을 붙인 문서다. 도메인 이름(domain name), 공개 키, 유효 기간, 발급한 CA 정보가 들어 있다.

브라우저는 CA를 무조건 믿지 않는다. OS와 브라우저에는 미리 믿기로 한 루트 인증서(root certificate) 목록이 들어 있다. 루트 CA의 개인 키가 새면 그 루트를 믿는 모든 인증서가 무너진다. 그래서 루트 키는 오프라인에 보관하고, 서버 인증서 서명은 권한을 받은 중간 CA에게 맡긴다. 검증은 이 사슬을 따라 올라간다.

다이어그램 로딩…

브라우저는 서버 인증서의 서명을 중간 CA의 공개 키로, 중간 CA 인증서의 서명을 루트 CA의 공개 키로 검증한다. 이 인증서 체인(certificate chain)이 내장된 루트까지 이어지고, 인증서의 도메인이 접속한 주소와 맞고, 유효 기간 안이어야 통과한다. 하나라도 어긋나면 브라우저는 경고 화면을 띄운다.

이어지는 내용은 HTTPS와 TLS 2에서 다룬다. 여기서 본 암호 기술과 인증서가 TLS 1.3 핸드셰이크(handshake)에서 어떻게 맞물리는지, TLS 1.2와 무엇이 다른지를 본다.

면접 포인트

• "HTTPS는 어떻게 안전한가요?" → 인증서로 서버 인증 + 공개 키 기술로 대칭 키 합의 + 데이터는 대칭 키 암호화 + 무결성 검사.
• "왜 대칭 키와 공개 키를 섞나요?" → 공개 키는 키 배송 문제를 풀지만 느리고, 대칭 키는 빠르지만 키 배송이 어렵다.
• "인증서는 어떻게 검증하나요?" → 체인을 따라 서명 검증 → 내장 루트 CA까지 도달 + 도메인·유효 기간 확인.