HTTPS와 연결 과정

bagt13·2022년 11월 30일

CS Handshake https 암호화

CS

목록 보기

6/11

HTTPS

HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법

HTTP와 달리 중간에 암호화 계층(6L)을 거쳐서 패킷을 암호화하기 때문에, 중간에 패킷을 가로채더라도 데이터를 확인할 수 없다.

HTTPS의 기능

1. 암호화 (데이터 암호화 -> 중간에 데이터를 탈취해도 내용을 알아볼 수 없음)

HTTPS에서는 client와 server가 데이터를 암호화하여 주고받기 위해 비대칭키 방식과 대칭키 방식을 혼용하여 사용한다.

대칭키 방식 : 서버와 클라이언트가 통신할 때, 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화 및 복호화하는 것
비대칭키 방식 : 각각 공개키와 비밀키를 가지고, 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것

비대칭키 알고리즘은 대칭키보다 훨씬 복잡하기 때문에, 대칭키를 사용하여 데이터를 암호화 및 복호화하는 것이 서버에 부담을 덜 준다. 따라서 클라이언트와 서버가 데이터를 주고받을 때는 대칭키를 사용한다.

하지만 대칭키를 서로 주고받는 과정에서부터 정보가 탈취될 수 있기 때문에, HTTPS는 대칭키를 주고받을 때는 비대칭키 방식으로 주고받는다. 앞서 말했듯, 비대칭키는 공개키로 암호화한 정보는 개인이 가진 비밀키로만 풀 수 있으므로 중간에 대칭키가 탈취되더라도 개인키가 없이는 이를 복호화할 수 없기 때문이다.

2. 인증서 - 데이터 제공자 신원보장, 도메인 종속

HTTPS에서는 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다. 이러한 인증서는 서버의 신원을 보증해준다. 이때 이를 보증할 수 있는 제 3자를 CA(Certificate Authority) 라고 부른다.

CA(Certificate Authority) : 인증서를 발급해주는 엄격하게 공인된 기관들.
이러한 CA들은 서버의 공개키와 정보를 CA의 비밀키로 암호화하여 인증서를 발급한다.

웹사이트의 인증서를 확인해보면, 인증서를 발급한 CA, 서명에 사용한 알고리즘, 서명, 공개 키 정보 등이 들어있는 것을 확인할 수 있다.

인증서가 CA의 비밀키로 암호화되어 있으므로 CA의 공개키로 복호화 가능하기 때문에, 해당 CA에서 발급한 인증서라는 것을 보증할 수 있다.

CA 검증 절차

서버가 클라이언트에게 CA에서 발급받은 인증서를 전달
클라이언트는 OS 또는 브라우저에 미리 내장되어 있던 CA 리스트를 통해 브라우저에서 인증된 CA에서 발급받은 인증서인지 먼저 확인한다.
만약 인증된 CA에서 발급한 인증서가 아니라면 화면에 경고창을 띄워 서버와 연결이 안전하지 않다는 화면을 보여준다.

HTTPS 연결 성립 과정

1. hand shake

1-1. client hello

클라이언트가 최초 서버에 요청을 보내는 것이다.
이때, 클라이언트에서 생성한 랜덤 데이터, 클라이언트가 사용할 수 있는 암호화 방식 등을 보낸다.
만일 이전에 handshaking 기록이 있다면, 기존 세션을 활용하기 위한 session ID를 보낸다.

1-2. server hello, 공개키/인증서 정보 전달

서버가 클라이언트의 요청에 대한 응답으로써, 공개키가 포함된 인증서를 비밀키로 암호화하여 전달한다.
이때, 서버에서도 랜덤 데이터와 서버가 선택한 클라이언트의 암호화 방식을 함께 보낸다.

1-3. client의 서버 인증서 검증

클라이언트는 서버의 인증서를 통해 서버가 신뢰할 수 있는지 판단한다.
이때, 클라이언트의 웹 브라우저에는 서버의 인증서가 신뢰할 수 있는지 확인하기 위해 '신뢰할 수 있는 인증서' (공개 키)가 미리 등록되어 있다.
이 '신뢰할 수 있는 인증서' 목록에는 Root CA의 인증서, ICA의 인증서 등이 포함되어 있다.
전 세계에 배포된 공개키로 복호화할 수 있다면, 인증 기관이 가지고 있는 비밀키로 암호화된 인증서라는 것이 입증되기 때문에, 신뢰할 수 있다고 판단하는 것이다.