SSL 인증서 동작 방식을 이해한다는 것은
HTTPS 통신 원리를 이해한다는 것과 같기에
HTTPS 통신 원리로 설명하고자 합니다.

목차

1. HTTPS 기본 개념
2. SSL 인증서란, 발급 과정 및 원리
3. SSL Handshake 동작원리

1. HTTPS 기본 개념

hypertext Transfer Protocol Secure 의 준말로, 컴퓨터 네트워크를 통한 보안 통신에 사용되며 인터넷에서 널리 사용된다. HTTPS에서 통신 프로토콜은 TLS(Transport Layer Security) 또는 이전에는 SSL(Secure Sockets Layer)을 사용하여 암호화된다. 따라서 "HTTP over TLS" 또는 "HTTP over SSL" 이라고도 불린다.

HTTPS 를 사용하는 웹 사이트는 https://~ 와 같은 주소를 갖는다.

HTTPS 프로토콜을 사용하기 위해서는 인증기관(CA)으로 부터 SSL 인증서를 발급받아야 한다.

2. SSL 인증서

인증서를 발급받은 웹 사이트는 아래처럼 인증서 정보를 확인 할 수 있다.

F12 -> Security

(자체서명) 인증서 발급 과정

서버에서 HTTPS 프로토콜 사용을 위해 SSL 인증서를 발급받는 과정은 아래와 같다.
여기서 CA 란 인증기관을 뜻한다.

1. 인증서 생성 (자체서명)

1) root 디렉토리 certs 디렉토리 생성 후 certs 디렉토리로 이동.

cd ~
mkdir -p ~/certs
cd ~/certs

2) CA(Certificate authority:인증기관) Certificates 생성(사설 인증서 생성)

ca.key → private key.(개인키)
ca.crt → public key.(공개키)
둘은 쌍으로 이루어진다.

인증서는 나의 공개키에게 공개키가 맞다는
사실을 개인키로 전자서명을 한 것이다.

클라이언트가 서버가 제대로 된 서버인지 확인하기 위해 필요하다.

나와 통신하려는 상대가 내 인증서를 확인하고
그 인증서 안에 있는 나의 공개키를 이용하여
나에게 암호화된 데이터를 만들어 보내주는 것이다.

즉 CA(인증기관)을 생성하여 서버의 인증서가 안정하다 인증해주는 절차.
개인용 CA 역할이 ca.key, ca.key의 짝이 되는 CA.crt 공개키를 생성하는 작업

Root CA의 비밀키 생성

openssl genrsa -out ca.key 4096

인증서 생성

openssl req -x509 -new -nodes -sha512 -days 3650 \
 -subj "/C=KR/ST=Seoul/L=GangNam/O=Hwan/OU=T3Large/CN=www.auction-price.co.kr" \
 -key ca.key \
 -out ca.crt

OpenSSL 이란?

네트워크를 통한 데이터 통신에 쓰는 프로토콜인 TLS와 SSL의 오픈 소스 구현판.
C언어로 작성되어있다

-- genrsa란? generates an RSA private key .

-out ← out 뒤 파일 이름 입력으로 생성.
6000 ← numbits : 생성할 Private key의 크기(비트)

-- openssl req 명령어(CRT 인증서 만들기)
인증서 요청을 만들고 처리하는 명령 req(request)

1) x509 : PKI(공개키) 인증서 형식 정의하는 디지털 인증서,
해당옵션 사용시 인증서명대신 Self Sighned 인증서 생성한다.
2) new : 새 인증서 생성 요청.
3) nodes : 이 옵션 사용 시 private key가 암호화 되지 않는다. (생략 시 매번 비밀번호 입력해야한다)
4) SHA512 : 서명에 사용할 SHA512 알고리즘을 사용한다는 이야기
5) subj : 인증서 안에 들어갈 정보를 명시해주는 부분 옵션 아래와 같다.
arg 형식으로 작성이 필수.

C(COUNTRUYNAME)=KR(나라이름)

ST(State)=SEOUL(도시)

L(Locality)=GANGNAM(지역)

O(Organization) = rockplace(회사명)

OU(OrganizationalUnit) = PS1(부서명)

CN(CommonName) = www.auction-price.co.kr
(서비스 도메인)

6) key : ca.key 이름의 Private key 이름을 써주도록 한다. PEM형식도 허용(인증서에 서명하는 개인키)

7) out : 옵션 뒤 이름으로 파일 생성

Server Certificates 생성
서버의 인증서 생성 절차.

ca.key 비밀키와 공개키를 만들 때와 마찬가지로 서버의 비밀키 생성, 생성한 비밀키를 넣어
공개키 파일을 만든다.

현재하는 CSR(Certificate Signing Request) 생성 작업은 인증서 서명 요청을 의미.

CSR파일은 인증서를 발급 받기위해
나는 누구, 어떤 키값을 가지고 있다는 정보를 저장하고 있는 파일이다.

Server 비밀키 생성

openssl genrsa -out www.auction-price.co.kr.key 4096

Server CSR 파일 생성
CN(CommonName)칸에 도메인이나 아이피주소 입력

openssl req -sha512 -new \
    -subj "/C=KR/ST=Seoul/L=GangNam/O=Hwan/OU=T3LARGE/CN=www.auction-price.co.kr" \
    -key www.auction-price.co.kr.key \
    -out www.auction-price.co.kr.csr

SSL Handshake 동작 원리 및 과정

요약
1. A라는 서버를 만드는 기업이 HTTPS를 적용하기 위해 공개키와 개인키를 만듭니다.

2. 신뢰할 수 있는 CA 기업에 공개키 관리를 부탁하며 계약을 맺습니다.

3. 계약이 완료된 CA 기업은 A 서버의 공개키, 해당 기업의 이름, 공개키 암호화 방법을 담은 인증서를 만들고 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공합니다.

4. A 서버는 직접적인 공개키가 아닌 암호화된 인증서를 보유하게 되었습니다.

5.클라이언트가 통신 요청을 보내면 앞선 SSL/TLS Handshake 과정을 수행하여 연결을 수립합니다.

6.클라이언트와 A 서버와 통신을 시작합니다.

Handshake 란? 악수라는 뜻인데, 쉽게 말하면

서버와 클라이언트가 통신을 연결할 때 서로 악수(협상)를 통해 이런저런 정보를 주고받으며,
신뢰할 수 있는 서버인지,
우리 통신할 때 암호화는 이렇게 하자~
등등을 검증하고 정하는 과정이라고 생각하면 된다.

SSL Handshake 의 궁극적 목표 2가지
(이를 통해 얻는 2가지 중요 요소)
요것이 포인트 !!!!

서버와 클라이언트가 주고받을 데이터의 암호화 알고리즘을 결정
서버와 클라이언트가 주고받을 데이터의 암호화를 위한 동일한 대칭키(데이터를 암호화하는 키)를 얻는다 (대칭키 알고리즘 wiki)

**요약
1. 클라이언트가 서버에 연결 요청을 보냅니다.

2. 서버는 자신의 인증서와 공개 키를 클라이언트에게 전송합니다.

3. 클라이언트는 서버로부터 받은 인증서를 검증하고, 서버의 공개 키를 추출합니다.

4. 클라이언트는 서버의 공개 키를 사용하여 중요한 데이터(예: PreMasterSecret)를 암호화하고 서버로 전송합니다.

5. 서버는 자신의 개인 키를 사용
   하여 클라이언트가 보낸 암호화된 데이터를 복호화합니다.

6. 클라이언트와 서버는 양측에서 생성한 PreMasterSecret를 사용하여 세션 키를 계산합니다.

7. 이후의 통신은 세션 키를 사용하여 대칭 키 알고리즘으로 암호화되고 복호화됩니다.**

1. CLIENT(고객) -----> 서버 (Client Hello)

클라이언트가 서버에 연결 시도와 동시에 패킷 전송
이 때, 전송하는 패킷에 아래 내용이 들어있다.

1) 고객(브라우저)가 사용하는 SSL 혹은 TLS 버전 정보(SSL Protocol version)

2) 고객(브라우저)이 사용하는 암호화 방식모임(cipher_suite).

3) 고객(브라우저)가 생성한 임의의 난수(숫자) [스크린샷의 RANDOM: XXX 이부분 숫자]

4) Session id(만일 이전에 SSL 핸드 셰이크가 완성되었다면)

5) cipher_suite에 어떤 프로토콜(TLS/SSL)을 사용할지 인증서 검사 또는 데이터를 어떤 방식 으로 암호화 할지 표시.

6) etc...

cipher_suite 보안 목표 달성을 위해 사용하는 방식을 패키지로 묶어놓은 것을 의미
(1) 안전한 키 교환
(2) 전달 대상 인증
(3) 암호화 알고리즘
(4) 메세지 무결성 확인 알고리즘 등이 담겨 있다

2. Server -> Client 응답 (Server Hello)

클라이언트에게 받은 패킷에 대해 서버가 응답한다.

1) 클라이언트에게 받은 cipher_suite 목록 중에
서버가 지원하고 선택한 1개의 암호화 방식(cipher_suite)[Session ID Length 아래]

2) 서버의 공개키가 담긴 SSL 인증서, 인증서는 CA의 비밀키로 암호화되어 발급된 상태.

3) 서버가 순간적으로 생성한 임의의 난수(숫자) [Randdom: xxx 부분]

4) 클라이언트 인증서 요청(선택사항)

5) etc

2-2. Server -> Client (Client Key Exchange, Certificate)

핸드세이크 프로토콜에 Certificate 패킷이 있다.

Certificate 패킷에 Server의 SSL 인증서 내용이 있다.

패킷 내부에 서명, 알고리즘, 공개키 정보를 알 수 있다.

Certificate 패킷을 전달 할 때 보면
Server Key Exchange가 있다.
인증서 내에 SSL 인증서에 서버의 공개키가 없을 때
서버가 직접 전달함을 의미.
서버에 공개키가 있다면 Server Key Exchange는 생략된다.

3. Client에서 Server의 SSL 인증서 검증. (Verify Server Certificate)

2-2번 단계에서 받은 서버 인증서를 검증한다.

클라이언트는 CA의 공개키를 어디서 구하나?

1. CA(인증기관)은 CA의 비밀키(Private key)를 이용해 인증서를 암호화 한다.

2. SSL 인증서는 CA의 공개키를 이용해서만 복호화 할 수 있다.

즉 클라이언트에서 CA(인증기관)에서 발행한 공개키(Public key)를 이용해 인증서를 복호화했을 때.

해당 인증서를 CA에서 발급되었다 라는 것을 검증 할 수 있다.

[위에 사설 인증서 발행할 때 적어놓았던 -subj에 해당하는 내용과 일치하는지 확인하는 것이다.]

인증서를 발급하는 주요 인증기관(CA) 리스트와 공개키를 가지고 있어서 매번 CA로 요청하지 않고 리스트에서 확인한다.
리스트에 없을 때 인터넷으로 인증기관의 정보와 공개키를 확인한다.

SSL 인증서를 사용 시 인터넷 접속이 필요한 이유이다.

** SSL 인증서 검증 정리

1) 클라이언트는 인증서를 발급한 인증기관(CA)의 공개키를 구함.
2) 1번에서 구한 공개키를 이용해 SSL 인증서를 복호화.
3) 복호화 성공 시, 인증서 검증 성공 **

4. Client -> Sever 대칭키(비밀키) 전달.(Client Key Exchange, Change Ciper Spec)

이제 클라이언트는 서버와 원하는 데이터를 안전하게 주고받기 위해서는 전달하는 데이터를 암호화해야 한다.

클라이언트는 데이터를 암호화하기 위한 대칭키(비밀키, 데이터를 암호화하는 키)를 생성한다

이렇게 생성한 대칭키(Private key)를 서버에 전달해야 하는데, 그냥 전달하면 문제가 생길 수 있다.

대칭키가 탈취되면 누구나 주고받는 데이터를 볼 수 있을 테니.

클라이언트는 이 대칭키(Private Key)를 서버만 볼 수 있게 하기 위해, 서버의 공개키로 암호화를 해서 서버에 전달한다. (Client Key Exchange)

서버의 공개키는 3번에서 SSL 인증서를 복호화해서 얻었었지.
또는 인증서 내부에 없을 경우에는 2-2번에서 서버로부터 직접 전달받는다(Server Key Exchange).

5. Server / Client SSL Handshake 완료

서버는 클라이언트가 5번에서 전달한 암호화된 대칭키(비밀키)를 받았다. 이 키는 서버의 공개키로 암호화되었으니, 서버의 비밀키로 복호화해서 얻을 수 있다.

이제 서버와 클라이언트 모두 동일한 대칭키(비밀키)를 갖고 있으니, 통신할 준비 완료 !!!

이제 통신할 준비가 완료되었다는 Change Ciper Spec 을 보낸다. 즉, 서버 쪽도 SSL Handshake 준비 완료라는 의미의 패킷.