정의
HTTPS에서 클라이언트와 서버간 통신 전 SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식
1. HTTP와 HTTPS
HTTP (HyperText Transfer Protocol)
- 인터넷에서 데이터를 주고받기 위한 통신규약
- HTTP는 정보를 텍스트 기반의 평문으로 주고받기 때문에 네트워크에서 정보를 탈취하거나 변조할 수 있는 보안 취약점이 존재함
- 그래서 나온게 HTTPS
HTTPS (HyperText Transfer Protocol + Secure socket layer)
- 기본적인 사항은 HTTP와 거의 동일
- HTTP 메시지에 포함되는 콘텐츠 정보에 암호화를 추가함
- 모든 요청과 응답 데이터는 네트워크로 보내지기 전 SSL 계층을 통해 암호화됨
- HTTPS는 클라이언트와 서버간의 통신을 제 3자가 인증해줘야 한다.
- 이런 일을 해주는 공인된 회사들을 **CA(Certificate Authority)**라고 하고 CA는 SSL 인증서를 기준으로 클라이언트가 접속한 서버가 맞는지 확인해줌
2. SSL(Secure Socket Layer) / TLS(Transport Layer Security)
SSL 인증서
클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서
클라이언트는 서버에 접속한 직후 서버로부터 이 인증서를 내려받아 검증한다.
인증서에는 서버의 공개키가 담기는데 이 인증서는 CA의 개인키로 암호화된다.
브라우저의 모든 CA들이 공개키를 가지고 있어서 인증서를 복호화하고 내용을 볼 수 있음
인증서를 통해 클라이언트가 접속한 서버가 신뢰할 수 있는 서버인지 판단하고 SSL 통신에 사용될 공개키를 클라이언트에게 전달함
SSL 인증서로 서버가 신뢰할 수 있는지 판단하기 위해 공개키 서명 방식을 사용하는데 이 때 방식을 SSL/TLS Handshake라고 한다.
SSL/TLS handshake
통신을 암호화하는데 사용할 암호화 알고리즘과 키를 결정하고 서버를 확인하며 실제 데이터 전송을 시작하기 전에 보안 연결이 이루어졌는지 확인하는 과정
handshake 과정에 앞서 알아야 할 암호화 방식
대칭키 암호화 방식
- 암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 기법
- 암호화한 정보를 보낼 때 암호키를 같이 보내 타인에게 노출 시 보안에 취약함
- 대신 연산 속도가 빠르다.
공개키 암호화 방식(비대칭키 암호화)
- 공개키와 비밀키가 존재함. 공개키는 누구에게나 공개하는 키, 개인키는 자신만 갖고 있는 키
- 공개키로 암호화
- 상대방의 공개키로 데이터를 암호화하고 전달하면 받은 사람이 자신의 개인키로 복호화
- 개인키로 암호화
- 개인키로 암호화하고 공개키와 함께 전달하는 방식
- 데이터 보호의 목적보다 공개키가 데이터 제공자의 신원을 보장하기 위함임
- 왜냐? 암호화된 데이터가 공개키로 복호화된다는건 공개키와 쌍을 이루는 개인키로 암호화 했다는 뜻이니까
- 그래서 데이터 제공자의 신원 확인이 보장된다는 뜻! 전자서명에 씀
SSL/TLS handshake 과정에 사용하는 암호화
‘handshake’ 그 자체는 공개키 암호화를 사용!
handshake 하는 동안 암호 해독을 위한 암호화 및 개인키로 사용하고 서버와 클라이언트가 각각 새로 생성한 공유키를 설정하고 교환하게 됨
3. SSL/TLS Handshake
위에 파란색이 TCP layer의 3-way handshake이다.
HTTPS가 TCP 기반의 프로토콜이라서 SSL Handshake에 앞서 연결하는 과정임
그리고 노란색이 SSL Handshake
진행 순서
- 클라이언트는 서버에게 client hello 메시지를 담아 서버로 보낸다. 이때 암호화된 정보를 함께 담는데, 버전, 암호 알고리즘, 압축 방식 등을 담는다.
- SSL / TLS 서버는 클라이언트가 제공한 목록에서 서버가 선택한 암호 알고리즘, 선택한 압축 방식과 세션 ID 및 CA(Certificate Authority)가 사인한 서버의 공개 인증서를 "server hello" 메시지에 담아 응답한다. 이 인증서는 대칭키가 생성되기 전까지 클라이언트가 나머지 handshake 과정을 암호화하는 데에 쓸 공개키를 담고 있다.
- 클라이언트 측은 서버에서 보낸 CA 인증서가 유효한 지 CA 목록을 통해 확인한다.
- 받은 공개키를 이용해 SSL 인증서를 복호화함
- 복호화에 성공하면 이 인증서는 CA가 서명한 것이 맞음 = 인증서 검증
- CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 의사 난수(pseuco-random) 바이트를 생성하여 서버의 공개키로 암호화한다. 이 난수 바이트는 대칭키를 정하는데 사용이 되고, 나중에 메시지 데이터를 암호화할 때 사용한다.
- 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.
- 클라이언트 인증이 필수인데 디지털 인증서가 없을 경우 handshake 실패
- 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화해 대칭키 생성에 활용한다.
- 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다.
- 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보낸다.
- 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고받을 수 있게 된다.
'Computer Science > Network' 카테고리의 다른 글
| [네트워크] DNS(Domain Name System)란? (0) | 2023.01.30 |
|---|---|
| [네트워크] OSI 7계층과 TCP/IP모델 (0) | 2022.12.19 |
| [네트워크] Circuit/Packet Switching 이란? (0) | 2022.11.27 |
| 컴퓨터의 클라이언트와 서버에 대해 알아보자 (0) | 2022.04.27 |