HTTPS

웹 서핑을 하다 보면,
웹 브라우저 주소창에 http:// 또는 https://로 시작하는 주소를 흔히 볼 수 있다.
여기서 http 와 https는 무엇일까?

HTTP (HyperText Transfer Protocol) 이란?

웹 브라우저와 웹 서버 간의 데이터 통신을 위한 프로토콜로
클라이언트가 서버에 요청을 보내면
서버는 이에 대한 응답을 다시 클라이언트에 응답하는 방식으로
서비스 제공자와 서비스 요청자로 구분되는 서버/클라이언트 모델인 프로토콜이다.

요청/응답 모델이라고 부르는데
서버/클라이언트 모델에서 말하는 “모델”은 시스템의 구조를 의미하고
요청/응답 모델에서 말하는 “모델”은 시스템의 동작방식을 의미한다.

💡 모델

시스템이나 과정의 동작 방식을 추상적으로 나타내는 개념이고
각 프로토콜들은 각자의 상호 작용 방식을 가지고 있다.

💡 프로토콜

네트워크에서 통신하는 장치들 간의 상호작용을 규정하는 규칙들의 집합이고
이런 규칙들을 통해서 우리는 웹 페이지를 보거나 데이터를 주고 받을 수 있다.

💡 프로토콜의 발전배경

초기 컴퓨터 네트워킹 시대에는 컴퓨터들이 서로 다른 방식으로 통신했는데
즉, 정해진 프로토콜이 아닌 특정한 목적이나 환경에 맞춰 설계된 프로토콜을 주로 사용하다보니
각각의 프로토콜이 모델과 패킷의 구조, 오류처리방식에서 차이가 날 수 있었고
이것이 서로 다른 프로토콜을 사용하는 시스템 간에 통신이 원활하지 못하게 하는 원인이 되었다. (상호운용성 문제)
이를 해결하기 위해 표준화된 통신 규칙을 필요로했다.
점차 표준 프로토콜이 개발되고 오늘날 TCP/IP와 같은 프로토콜들이 자리 잡으면서
예전의 프로토콜들은 점차 사용이 줄어들거나 사라지게 되었다.
또한 상호운용성 뿐만 아니라 데이터 전송의 신뢰성과 보안,
그리고 특정 용도에 맞는 프로토콜들이 개발되어 통신의 효율성을 높이고 있다.

HTTP 요청/응답 모델이란?

HTTP 프로토콜이라는 틀 안에서 이루어지는 구체적인 통신 방식으로
서버에 특정한 정보를 요청하고 서버가 해당 요청에 대한 응답을 보내는 방식으로 동작하기 때문에
요청/응답 모델이라고 한다.

HTTP의 작동 방식

클라이언트가 서버에 요청을 보낼 때 무엇을 보낼까?

• HTTP 메서드: 서버에게 어떤 동작을 수행해야 하는지 지시하는 역할 (예: 데이터 요청, 데이터 전송 등)
• Header: 요청에 대한 부가 정보를 담고 있는 부분 (예: 요청을 보낸 클라이언트의 종류, 요청하는 데이터의 형식 등)
• Body: 서버에 전송할 실제 데이터 (예: 폼 데이터, 파일 등)

서버는 클라이언트로부터 요청을 받으면

요청 내용을 분석해서 적절한 처리를 수행한 후 응답할 때 무엇을 보낼까?

• Status Code: 요청 처리 결과를 나타내는 숫자 코드 (예: 성공, 실패, 오류 등)
• Header: 응답에 대한 부가 정보를 담고 있는 부분 (예: 응답 데이터의 형식, 캐싱 정보 등)
• Body: 클라이언트에게 전송할 실제 데이터 (예: HTML 문서, 이미지, JSON 데이터 등)

클라이언트는 서버로부터 받은 응답을 해석해서 사용자에게 보여주게된다.

HTTP 메서드의 종류와 역할

클라이언트가 서버에 요청하는 작업의 종류를 나타내는 명령어로
서버는 메서드를 보고 어떤 작업을 수행할지 판단하게 된다.

GET 메서드

• 정보 요청: GET 메서드는 서버로부터 특정 정보를 요청할 때 사용된다.
  데이터를 가져오는 것이 주 목적으로 데이터 검색이나 조회에서 사용된다.
• URL 쿼리 파라미터: 요청에 필요한 데이터는 URL 뒤에 쿼리 파라미터 형태로 붙여서 전송한다.
• 안전성 (Safe): GET 메서드는 서버의 상태를 변경하지 않는 안전한 메서드이다.
  즉, GET 요청을 보내도 서버의 데이터가 변경되지 않는다.
• 멱등성 (Idempotent): 동일한 GET 요청을 여러 번 보내도 결과가 항상 동일한 멱등성을 가진다. 즉, 같은 요청을 반복해도 서버의 상태가 여러 번 바뀌는 것이 아니라, 항상 같은 결과를 얻을 수 있다.

POST 메서드

• 데이터 전송 및 처리: POST 메서드는 서버에 데이터를 전송하여 새로운 리소스를 생성하거나, 기존 리소스를 변경하여 특정 작업을 수행할 때 사용된다.
  주로 회원 가입, 로그인, 게시글 작성, 파일 업로드 등 데이터를 생성하거나 변경하는 작업에 사용된다.
• 요청 본문 (Body): 전송할 데이터는 요청의 본문에 담아 전송한다.
  URL에 데이터를 노출시키지 않기 때문에, 비교적 많은 양의 데이터나 민감한 데이터를 전송할 때 적합하다.
• 비멱등성: POST 메서드는 일반적으로 멱등성을 가지지 않는다.
  동일한 POST 요청을 여러 번 보낼 경우, 서버의 상태가 여러 번 변경될 수 있다.
  예를 들어, 동일한 주문 요청을 여러 번 보내면 주문이 여러 번 생성될 수 있다.

PUT 메서드

• 리소스 전체 대체: PUT 메서드는 서버의 리소스를 완전히 대체할 때 사용된다.
  즉, 기존 리소스의 모든 내용을 요청 본문에 담긴 데이터로 덮어쓴다.
• 리소스 생성: 만약 지정된 URI에 리소스가 존재하지 않으면, 새로운 리소스를 생성한다.
• 전체 데이터 덮어쓰기: 부분적인 수정은 불가능하며, 전체 데이터를 덮어쓰는 개념이다.
• 멱등성: PUT 메서드는 멱등성을 가진다. 동일한 PUT 요청을 여러 번 보내도 결과는 동일하다.

PATCH 메서드

• 리소스 부분 수정: PATCH 메서드는 서버의 리소스를 부분적으로 수정할 때 사용된다.
• 부분 데이터 수정: PUT과 달리 전체 데이터를 덮어쓰는 것이 아니라, 변경할 부분만 지정하여 수정할 수 있다.
• 멱등성: PATCH 메서드는 멱등성을 가질 수도 있고, 가지지 않을 수도 있다. 서버 구현 방식에 따라 달라진다. 예를 들어, 단순히 필드 값을 변경하는 경우 멱등성을 가지지만, 특정 값을 누적시키는 연산을 수행하는 경우(예: 조회수 증가) 멱등성을 가지지 않는다.

DELETE 메서드

• 리소스 삭제: DELETE 메서드는 서버의 리소스를 삭제할 때 사용된다.
• 멱등성: DELETE 메서드는 멱등성을 가진다. 동일한 요청을 여러 번 보내도 결과는 동일하다 (이미 삭제된 리소스를 다시 삭제하려고 시도해도 아무런 변화가 없다).

HTTP 헤더

HTTP 헤더는 요청과 응답에 대한 부가 정보를 담고 있다.
즉 헤더를 통해 클라이언트는 서버에게 필요한 정보를 제공하고,
서버는 클라이언트에게 응답에 대한 추가 정보를 제공할 수 있다.

1. 일반 헤더 (General Headers): 요청과 응답 모두에서 사용되는 일반적인 정보
   • 메시지 전체에 대한 일반적인 정보를 제공한다.
   • Connection, Date, Transfer-Encoding 등
2. 요청 헤더 (Request Headers): 클라이언트가 서버에 보내는 요청에 대한 부가 정보
   • 요청에 대한 정보를 제공하여 서버가 적절히 처리하고 응답할 수 있도록 돕는다.
   • Host, User-Agent, Accept, Accept-Language, Cookie, Referer, Origin 등
3. 응답 헤더 (Response Headers): 서버가 클라이언트에게 보내는 응답에 대한 부가 정보
   • 응답에 대한 정보를 제공하여 클라이언트가 이를 올바르게 해석하고 처리할 수 있도록 한다.
   • Server, Date, Location, Set-Cookie 등
4. 엔티티 헤더 (Entity Headers): 메시지 본문에 대한 정보
   • 메시지 본체 (Body)에 포함된 콘텐츠에 대한 세부 정보를 제공한다.
   • Content-Type, Content-Length, Content-Encoding 등
5. 인증 헤더 (Authentication Headers): 인증 관련 정보
   • 클라이언트와 서버 간의 인증 및 권한 부여에 사용된다.
   • Authorization, WWW-Authenticate 등
6. 캐싱 헤더 (Caching Headers): 캐싱 관련 정보
   • 클라이언트와 중간 캐시 서버가 응답을 어떻게 캐싱해야 하는지 지시한다.
   • Cache-Control, Expires, ETag, Last-Modified 등
7. CORS 헤더 (Cross-Origin Resource Sharing Headers): 교차 출처 리소스 공유 관련 정보
   • 웹 페이지의 스크립트가 다른 출처의 리소스에 접근하는 것을 제어한다.
   • Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등
8. 보안 헤더 (Security Headers): 보안 관련 정보
   • 웹 애플리케이션의 보안을 강화하기 위한 다양한 정책을 정의한다.
   • Content-Security-Policy, Strict-Transport-Security, X-Frame-Options 등
9. 기타 헤더 (Other Headers): 특정 기능 관련 정보
   • 위에 분류되지 않은 특정 기능과 관련된 헤더들을 포함한다.
   • Location, Range 등

HTTP 상태 코드

HTTP 상태 코드는 서버가 클라이언트의 요청을 어떻게 처리했는지 나타내는 3자리 숫자 코드이다.
상태 코드는 크게 5가지 범주로 나뉜다.

• 1xx (Informational): 요청 처리 진행 중
• 2xx (Success): 요청 성공
• 3xx (Redirection): 리디렉션 필요
• 4xx (Client Error): 클라이언트 오류
• 5xx (Server Error): 서버 오류

자주 사용되는 상태 코드의 몇 가지 예는 다음과 같다.

• 200 OK: 요청 성공
• 400 Bad Request: 잘못된 요청
• 404 Not Found: 요청한 리소스가 존재하지 않음
• 500 Internal Server Error: 서버 내부 오류

상태 코드를 통해 클라이언트는 서버의 응답 결과를 명확하게 파악하고, 필요한 조치를 취할 수 있다.

HTTP의 무상태성(Stateless) 이란?

HTTP는 ‘무상태성’이라는 중요한 특징을 가지고 있다.
’무상태성’은 서버가 클라이언트의 이전 요청에 대한 어떠한 정보도 기억하지 않는다는 것을 의미한다.

예를 들어, 웹사이트에 로그인했을때 무상태성이라는 특징 때문에
서버는 사용자가 로그인 페이지를 거쳐 로그인했다는 사실을 기억하지 못한다.
따라서, 로그인이 필요한 다른 페이지에 접근할 때마다 서버는 사용자의 신원을 확인하기 위해 다시 로그인 정보를 요청하게 된다.

무상태성의 장점과 한계

무상태성은 서버의 부담을 줄이고 확장성을 높이는 데 큰 장점을 제공한다.
각 요청이 독립적으로 처리되기 때문에, 서버는 이전 요청에 대한 정보를 저장하고 관리할 필요가 없다.
따라서 서버의 자원을 효율적으로 사용할 수 있도록 해준다.

하지만, 앞서 언급한 로그인 상태 유지와 같은 연속적인 작업을 처리하는 데에는 한계가 있다.
예를 들어 쇼핑몰에서 장바구니에 물건을 담는 경우 무상태성이라면,
페이지를 이동할 때마다 장바구니가 비어버리는 문제가 발생한다.

쿠키 (Cookie): 클라이언트 측의 기억 장치

이러한 무상태성의 한계를 극복하기 위해 사용되는 기술 중 하나가 ‘쿠키’이다.
쿠키는 서버가 클라이언트의 컴퓨터(웹 브라우저)에 저장하는 작은 텍스트 파일이다.

로그인 과정을 예로 들어 설명하자면

1. 사용자가 아이디와 비밀번호를 입력하여 로그인을 시도한다.
2. 서버는 인증 과정을 거친 후, 사용자를 식별할 수 있는 정보를 담은 쿠키를 생성하여 클라이언트에게 전달한다.
3. 클라이언트는 전달받은 쿠키를 컴퓨터에 저장한다.
4. 이후 클라이언트가 서버에 요청을 보낼 때, 저장된 쿠키를 함께 전송한다.
5. 서버는 쿠키에 담긴 정보를 확인하여 사용자를 식별하고, 로그인 상태를 유지할 수 있다.

이를 통해 로그인 상태 유지, 장바구니 기능, 사용자 설정 저장 등과 같은 기능을 구현할 수 있다.

세션 (Session): 서버 측의 기억 장치

‘세션’은 서버 측에서 클라이언트의 상태 정보를 저장하는 방식이다.

쿠키와 마찬가지로 로그인 과정을 예로 들어 설명하자면

1. 사용자가 로그인을 시도한다.
2. 서버는 인증 과정을 거친 후, 세션 ID를 생성하고, 해당 사용자의 정보를 서버의 저장소(세션 저장소)에 저장한다.
3. 생성된 세션 ID는 쿠키를 통해 클라이언트에게 전달된다.
4. 클라이언트는 세션 ID가 담긴 쿠키를 저장하고, 이후 요청 시 함께 전송한다.
5. 서버는 쿠키에 담긴 세션 ID를 통해 세션 저장소에서 해당 사용자의 정보를 찾아 로그인 상태를 유지한다.

세션은 중요한 정보를 서버에서 관리하기 때문에, 쿠키보다 보안성이 높다는 장점이 있다.
또한, 쿠키의 크기 제한보다 더 많은 정보를 저장할 수 있다.

HTTP의 진화

HTTP/1.0 (1996년): 초기 웹의 기반

HTTP/1.0은 웹의 초기 단계에서 사용된 프로토콜로, 매우 단순한 형태였다.

• 요청-응답 후 연결 종료: 각 요청마다 새로운 TCP 연결을 맺고, 응답을 받은 후에는 연결을 끊었다. 이는 각 리소스마다 새로운 TCP 연결을 생성해야 했으므로 상당한 오버헤드를 발생시켰다.
• 지속 연결 부재: 매번 연결 설정 과정(3-way handshake)을 거쳐야 했기 때문에 불필요한 지연이 발생했다.
• 캐싱 기능 제한적: 기본적인 수준의 캐싱 기능만 제공했다.
• 가상 호스팅 부재: 하나의 IP 주소에 여러 웹 사이트를 호스팅하는 것이 불가능했다.

HTTP/1.1 (1999년): 웹의 대중화를 이끈 표준

HTTP/1.1은 HTTP/1.0의 한계를 극복하기 위해 등장하였다.

• 지속 연결 (Keep-Alive) 및 파이프라이닝: HTTP/1.0에서는 각 요청마다 새로운 TCP 연결을 맺어야 했지만, HTTP/1.1에서는 TCP 연결을 재사용하여 연결 설정 오버헤드를 줄였다. 이를 통해 여러 요청을 하나의 연결에서 처리할 수 있게 되었다. 특히, HTTP/1.1은 HTTP 파이프라이닝이라는 기능을 도입하여 클라이언트가 서버의 응답을 기다리지 않고 여러 요청을 연속적으로 전송할 수 있도록 하였다. 서버는 받은 순서대로 요청에 대한 응답을 전송하였다. 하지만 파이프라이닝은 HOL (Head-of-Line) Blocking 문제, 즉 하나의 응답이 지연되면 후속 응답들도 모두 지연되는 문제와 중간 프록시 및 방화벽과의 호환성 문제 등으로 인해 널리 사용되지 못했다.
• 캐싱 (Caching): Cache-Control 헤더를 도입하여 캐싱 기능을 강화하였다.
• 청크 전송 (Chunked Transfer Encoding): 큰 데이터를 여러 청크로 나누어 전송할 수 있게 되었다.
• 가상 호스팅 (Virtual Hosting): Host 헤더를 도입하여 하나의 IP 주소에 여러 도메인을 호스팅할 수 있게 되었다.

하지만 HTTP/1.1은 여전히 다음과 같은 문제점을 가지고 있었다.

• HOL (Head-of-Line) Blocking: (파이프라이닝의 문제점과 더불어, 지속 연결 자체에서도 발생 가능) 하나의 TCP 연결에서 여러 요청을 처리할 때, 하나의 요청이 지연되면 다른 요청들도 함께 지연되는 문제가 발생했다.
• 텍스트 기반 프로토콜: 파싱에 비용이 많이 들고, 헤더가 중복되어 전송되는 등 비효율적인 부분이 있었다.

HTTP/2 (2015년): 성능 향상을 위한 혁신

HTTP/1.1의 성능 문제를 해결하기 위해 등장하였다. 주요 특징은 다음과 같다.

• 이진 프로토콜 (Binary Protocol): 텍스트 대신 이진 데이터를 사용하여 파싱 효율성을 높였다.
• 헤더 압축 (Header Compression): HPACK 알고리즘을 사용하여 헤더의 중복을 제거하고 크기를 줄였다.
• 다중화 (Multiplexing): 하나의 TCP 연결에서 여러 요청과 응답을 동시에 처리하여 HOL Blocking 문제를 해결하였다.
• 서버 푸시 (Server Push): 서버가 클라이언트의 요청 없이도 필요한 리소스를 미리 전송할 수 있도록 하여 페이지 로딩 속도를 더욱 향상시켰다.

HTTP/2는 웹 성능을 크게 향상시켰지만, TCP 기반이라는 근본적인 한계는 여전히 존재하였다. TCP는 신뢰성 있는 전송을 보장하지만, 패킷 손실이 발생할 경우 재전송으로 인해 지연이 발생할 수 있다.

HTTP/3 (2018년): UDP 기반의 차세대 프로토콜

HTTP/2의 한계를 극복하기 위해 QUIC (Quick UDP Internet Connections) 프로토콜을 기반으로 개발되었다. 주요 특징은 다음과 같다.

• UDP는 TCP와 달리 연결 설정 과정이 단순하여 초기 연결 시간을 줄일 수 있다. 또한, 패킷 손실이 발생하더라도 TCP처럼 모든 후속 패킷이 지연되는 현상을 방지한다.
• 향상된 보안: TLS 1.3을 기본적으로 사용하여 보안성을 강화하였다.
  HTTP/3는 특히 모바일 환경과 같이 네트워크 환경이 불안정한 상황에서 더욱 뛰어난 성능을 보여준다.

HTTP Keep-Alive

HTTP는 기본적으로 요청-응답 후 연결을 끊는 방식(단기 연결)으로 작동한다. 즉, 하나의 요청을 보내고 응답을 받으면 TCP 연결이 종료된다. 하지만 웹 페이지는 보통 여러 개의 리소스(이미지, CSS, JavaScript 파일 등)를 포함하고 있기 때문에, 매번 연결을 맺고 끊는 것은 비효율적이다.

Keep-Alive는 이러한 비효율성을 개선하기 위해 HTTP/1.1 에서 도입된 기능으로, 클라이언트와 서버간의 TCP연결을 재사용하여 여러 개의 HTTP 요청과 응답을 주고받을 수 있도록 한다.
따라서, 매 요청마다 TCP 핸드셰이크와 같은 추가작업이 필요없기 때문에 오버헤드가 줄어들어 웹페이지 로딩 속도를 향상시키는데 큰 역할을 한다.

💡 Connection 헤더와 Keep-Alive

Connection 헤더는 클라이언트와 서버 간의 연결 상태를 제어하는 역할을 한다. Keep-Alive를 사용하기 위해서는 Connection 헤더의 값을 keep-alive로 설정할 수 있다.

파이프라이닝

클라이언트가 이전 요청에 대한 응답을 기다리지 않고 여러 개의 요청을 연속적으로 보내는 방식이다. 이를 통해 네트워크 지연 시간을 줄일 수 있지만, HTTP/1.1에서는 헤드 오브 라인 블로킹(Head-of-Line Blocking) 문제로 인해 효율성이 제한적이었다.

HTTPS (Hyper Text Transfer Protocol Secure) 이란?

HTTP 요청과 응답을 암호화하는 HTTP의 보안 버전으로
TLS(SSL)라는 알고리즘을 이용해서 HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방식이다.
HTTP over SSL(TLS), HTTP over Secure라고 부르기도 한다.

HTTPS를 왜 쓸까?

• 정보 보호 (암호화): 사용자가 웹사이트에 보내는 정보(예: 아이디, 비밀번호, 결제 정보 등)를 제3자가 알아볼 수 없도록 암호화하여 보호한다.
• 신뢰성 확인: 사용자가 접속한 웹사이트가 진짜 믿을 만한 곳인지 확인해준다. 가짜 웹사이트로 유도되는 피싱 공격 등을 방지할 수 있다.

대칭키와 비대칭키

SSL/TLS는 핸드셰이크(Handshake)라는 과정을 통해 클라이언트와 서버 간의 안전한 연결을 설정한다.
이 과정에서 대칭키 암호화, 비대칭키 암호화등의 기술이 사용된다.

대칭키 암호화

대칭키 암호화는 암호화와 복호화에 같은 키를 사용하는 방식이다.

• 장점: 암호화/복호화 속도가 매우 빠르다.
• 단점: 암호화에 사용한 키를 상대방에게 안전하게 전달해야 한다. 만약 키가 중간에 유출되면 모든 정보가 노출되는 위험이 있다.

예를 들어, A와 B가 대칭키를 사용하여 편지를 주고받는다고 가정해 보겠다. A가 편지를 암호화하기 위해 사용한 열쇠와 B가 편지를 해독하기 위해 사용하는 열쇠가 같다. 이 열쇠를 전달하는 과정에서 누군가 훔쳐보면 편지의 내용을 모두 읽을 수 있게 된다.

비대칭키 암호화

비대칭키 암호화는 암호화와 복호화에 서로 다른 키를 사용하는 방식이다.
두 개의 키는 ‘공개키(Public Key)’와 ’개인키(Private Key)’라고 불린다.

• 공개키: 누구에게나 공개되어 있는 키이다. 이 키로 암호화할 수는 있지만, 복호화는 할 수 없다.
• 개인키: 키 소유자만이 가지고 있는 비밀 키이다. 공개키로 암호화된 내용을 이 키로만 복호화할 수 있다.

비대칭키 암호화는 마치 우체통과 같은 원리이다. 누구나 우체통(공개키)에 편지를 넣을 수 있지만, 우체통의 열쇠(개인키)를 가진 사람만 편지를 꺼내볼 수 있다.

• 장점: 키 분배의 어려움을 해결할 수 있다. 공개키는 누구나 가질 수 있으므로 안전하게 전달할 필요가 없다.
• 단점: 대칭키 방식보다 암호화/복호화 속도가 느리다.

개인 키로 복호화하면 진짜 보안을 위한 목적이고, 공개 키로 복호화하고 개인 키로 암호화하면 인증을 위한 목적이다.

HTTPS 암호화 과정

1. Client Hello:
   클라이언트는 서버에 연결을 요청하며, 지원하는 프로토콜 버전(TLS 1.2, TLS 1.3 등), 암호 스위트(Cipher Suite, 지원하는 암호 알고리즘과 해시 함수 조합) 목록, 그리고 난수(Client Random)를 전송한다.
   핵심: 클라이언트가 서버에 자신이 지원하는 암호화 방식을 전달하며, 안전한 통신을 위한 필수 정보를 제공하는 단계이다.
2. Server Hello:
   서버는 클라이언트가 제안한 정보 중에서 자신이 지원하는 프로토콜 버전과 암호 스위트를 선택하고, 자신의 인증서(인증서에는 서버의 공개키, 유효 기간, 발급 기관 등의 정보가 포함되어 있다. 이 인증서는 CA의 전자 서명으로 보호되어 있음)와 난수(Server Random)를 함께 전송한다.
   핵심: 서버가 클라이언트의 제안에 대한 응답을 보내고, 자신의 신원을 증명하는 인증서를 제공하는 단계이다. 서버의 인증서는 신뢰할 수 있는 인증기관(CA)에 의해 발급되어야 한다.
3. Certificate Verification:
   클라이언트는 서버로부터 받은 인증서를 검증한다. 클라이언트는 브라우저에 내장되어 있는 CA리스트와 비교해서 일치하는 CA의 공개키로 복호화하여 검사한다. 이 과정에서 CA의 전자 서명을 확인함으로써 인증서가 위조되지 않았음을 검증한다. 복호화가 된다면, CA의 개인키로 암호화된 문서임을 암시적으로 보증된 것이다. 인증서에 포함된 공개키는 나중에 암호화를 할 때 사용된다.
   핵심: 클라이언트가 서버의 신원을 위조된 것이 아닌지 확인하는 매우 중요한 단계이다. 만약 인증서가 유효하지 않거나 신뢰할 수 없는 CA에 의해 발급된 경우, 클라이언트는 연결을 거부할 수 있다.
4. Pre-master Secret 생성 및 전송:
   클라이언트는 랜덤한 값인 Pre-master Secret을 생성하고, 인증서에 포함된 서버의 공개키를 이용하여 이 값을 암호화하여 서버로 전송한다.
   핵심: 클라이언트와 서버 사이에 공유될 비밀키를 생성하기 위한 첫 번째 단계이다. 비대칭 암호화를 이용하여 안전하게 Pre-master Secret을 교환한다.
5. Pre-master Secret 복호화:
   서버는 자신의 개인키를 이용하여 클라이언트로부터 받은 암호화된 Pre-master Secret을 복호화한다. 이제 클라이언트와 서버는 동일한 Pre-master Secret을 공유하게 된다.
   핵심: 서버가 클라이언트와 동일한 비밀 정보를 갖게 되는 단계이다.
6. Session Key 생성:
   클라이언트와 서버는 공유된 Pre-master Secret, Client Random, Server Random을 이용하여 Session Key를 생성한다. Session Key는 대칭키 암호화에 사용될 비밀키이다.
   핵심: 이후 통신에 사용될 실제 암호키를 생성하는 단계이다.
7. Finished:
   클라이언트와 서버는 Session Key를 사용하여 암호화된 메시지를 주고받으며 핸드셰이크가 성공적으로 완료되었음을 확인한다.
   핵심: 핸드셰이크 과정이 완료되었음을 나타내는 단계이다.
8. Application Data:
   핸드셰이크가 완료된 후, 클라이언트와 서버는 생성된 Session Key를 이용하여 암호화된 데이터를 주고받으며 안전하게 통신한다.
   핵심: 실제 데이터를 안전하게 주고받는 단계이다.

💡 전자 서명

전자 서명은 전자 문서의 작성자 또는 발신자의 신원을 확인하고 문서의 무결성을 보장하기 위해 사용되는 암호화된 데이터로,
전자 서명은 문서의 해시값을 작성자의 개인 키로 서명하여 생성된다.
SSL 핸드셰이크 과정에서 CA는 서버의 인증서의 해시값을 생성하고,
해당 해시값을 CA의 개인 키로 서명하여 전자 서명을 생성한다.
이 전자 서명을 통해 수신사가 인증서가 위조되지 않았음을 검증한다.