HTTP와 HTTPS 차이, 왜 HTTPS를 사용해야 할까?

1. HTTP 프로토콜이란

Hyper Text Transfer Protocol 약자로

웹에서 데이터를 주고받기 위한 프로토콜이다.

 

클라이언트의 요청에 응답을 보낸 후 연결을 끊는 특징(Stateless)이 있다. 일반적인 REST 통신 방법이 HTTP 기반 통신 방법이다.

 

특징

상태 정보를 저장하지 않는 Stateless 특징을 가지고 있어, 사용자 인증을 위해 쿠키, 세션, JWT 토큰 방식을 사용한다.

 

2. HTTPS란

HTTPS는 내가 사이트에 보내는 정보들을 제 3자가 못 보게 하고, 접속한 사이트가 믿을 만한 곳인지 알려주며, HTTP 보다 보안이 강화된 프로토콜이다.

 

💬 어떻게?
클라이언트와 서버가 생성한 난수를 통해 Secret Key를 만들어 대칭키 암복호화를 진행한다.
Secret Key를 생성하기 이전에 서버는 인증 기관으로부터 SSL 인증서를 발급받아 가지고 있는다.

암호화 기법

대칭키 : 데이터 암복호화에 동일한 키를 활용한다.

공개키 : 모든 사람이 접근 가능한 공개키, 각 사용자만이 가지고 있는 개인키가 있다.

 

공개키 시나리오

• A가 B 공개키를 통해 데이터를 암호화해서 B에게 전달한다.
• B는 개인키를 통해 암호화된 데이터를 복호화하여 내용을 확인한다.

공개키는 암호화 목적으로 사용하며, 개인키로만 복호화할 수 있다.

SSL 인증서 역할

SSL 인증서는 웹 서버와 사용자 간의 데이터를 암호화하여 안전하게 전송할 수 있게 도와주는 디지털 인증서이다.

• 데이터 암호화 : 클라이언트와 서버 간의 통신을 암호화한다.
• 신원 인증 : 웹 사이트의 신뢰성을 보장하고 사용자가 접속하는 사이트가 올바른 사이트인지 확인한다.
• 무결성 보장 : 전송 중 데이터가 변경되지 않음을 보장

CA (Certificate Authority)

신뢰할 수 있는 제 3자로, SSL 인증서를 발급하고 관리하는 기관이다.

클라이언트가 접속한 서버의 인증서가 유효한지 확인한다.

 

💬 어떻게?
서버는 SSL 인증서가 필요하기 때문에 인증 기관에 서버의 공개키와 서버 정보를 전달하여 인증서를 발급한다.

 

1. 서버는 서버 공개키와 정보를 CA에 전달한다

2. CA는 인증 기관 개인키로 서명하여 서버로 전달한다.

 

• 인증 기관에서는 전달받은 데이터를 인증기관의 개인키로 서명한다.
  • 서명한 정보가 바로 서버의 인증서이다.
  • 서버는 인증 기관으로부터 전달받은 인증서를 서버에 저장한다.

⭐️ 인증 기관은 → 브라우저에 인증 기관의 공개키를 제공한다.

• 즉, 브라우저는 이미 주요 인증기관의 리스트 공개키를 보유하고 있다.
• 왜냐하면, 인증된 인증서인지 확인하기 위해 공개키를 소지하고 있어야 한다. 개인키로 서명한 것은, 해당 인증서에서 발급한 것을 의미함.

SSL HandShake 과정

 

1. 클라이언트가 먼저 서버에 접속해서 말을 건다. (Client Hello)

• 내가 브라우저 주소창에서 naver.com 입력하면 내 브라우저는 네이버 웹 서버에 접속을 시도한다.
• HTTP는 TCP의 일종이니, TCP 연결을 위한 3-Way Handshake를 수행한 브라우저는 네이버가 HTTPS를 사용하는 것을 알게 된다.
• 브라우저는 다음 정보를 Client Hello 단계에서 보냅니다.
  • 브라우저가 사용하는 SSL 혹은 TLS 버전 정보
  • 브라우저가 지원하는 암호화 방식 모음(cipher suite)
  • 브라우저가 순간적으로 생성한 임의의 난수(숫자)
  • 만약 이전에 SSL 핸드 셰이크가 완료된 상태라면, 그때 생성된 세션 아이디(Session ID)

cipher suite 란

보안을 위해 사용하는 방식을 패키징 한 것

• 안전한 키 교환
• 전달 대상 인증
• 암호화 알고리즘
• 메시지 무결성 확인 알고리즘

 

2. 이에 서버가 응답하여, 클라이언트에게 다음 정보를 보낸다. (Server Hello)

• 브라우저의 암호화 방식 정보 중에서, 서버가 지원하고 선택한 암호화 방식 선택 후 응답 (cipher sutie)
• (인증서는 CA의 개인키로 암호화되어 발급된 상태), 서버의 공개키가 담긴 SSL 인증서를 전달한다.
• 서버가 순간적으로 생성한 임의의 난수(숫자)

3. 클라이언트는 서버의 SSL 인증서가 믿을 만 한지 확인한다.

• 대부분 브라우저는 CA 기관의 정보와 CA 가 만든 공개키가 이미 설치되어 있다.
• 서버가 보낸 SSL 인증서가 정말 CA가 만든 것인지 확인하기 위해 내장된 CA 공개키로 암호화된 인증서를 복호화한다.

 

4. 클라이언트는 자신이 생성한 난수와 서버의 난수를 사용하여 Premaster secret을 생성한다.

• 웹 서버 인증서에 딸려온 웹 사이트의 공개키로 이것을 암호화하여 서버로 전송한다.

 

5. 서버는 사이트의 개인키로, 클라이언트가 보낸 Premaster secret 값을 복호화한다.

• 복호화 한 값을 master secret 값으로 저장한다.
• 이를 사용해 방금 브라우저와 만들어진 연결에 고유한 값을 부여하기 위한 session key를 생성한다.
  • Sesstion Key는 대칭키 암호화에 사용할 키이다. 이것으로 브라우저와 서버 사이에 주고받는 데이터를 암호화하고 복호화한다.

 

Final) 6. SSL Handshake를 종료하고, HTTPS 통신을 시작한다.

• 클라이언트와 서버는 SSL handshake가 정상적으로 완료되었고, 웹 사이트에서 데이터를 Session Key를 사용하여 암호화/복호화하며 HTTPS 프로토콜을 통해 주고받을 수 있습니다.
• HTTPS 통신이 완료되는 시점에서 서로에게 공유된 Session Key를 폐기합니다. 만약 세션이 여전히 유지되고 있다면 브라우저는 SSL handshake 요청이 아닌 세션 ID만 서버에게 알려주면 됩니다.

 

내용 정리

HTTPS는 HTTP에 SSL/TLS 암호화가 추가된 보안 프로토콜이다.

대칭키, 공개키 암호화 기법을 통해 데이터 전송 시 기밀성, 무결성, 신뢰성을 보장한다.