[Web] - HTTPS / SSL

in Web on Https, Ssl


웹을 사용하다보면 Https를 정말 많이 접하게 된다. 보안이 적용됬다고는 알았지만 정확한 원리를 모르고 있어서 이번에 정리해보고자 한다.

HTTP

Hypertext Transfer Protocol

서로 다른 시스템들 사이에서 통신을 주고 받게 하는 가장 기본적인 프로토콜

⇒ 탈취하면 내용이 다 보인다. 그래서 HTTPS 보안이 필요하다.

HTTPS

Hypertext Transfer Protocol Secure

SSL (보안 소켓 계층) 사용

SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와준다.

사용하는 이유

  1. 보안성 : HTTP는 해커가 비밀번호등 민감한 정보를 탈취할 수 있다.
  2. SEO (검색 엔진 최적화) : 구글 등에서는 HTTPS를 해야 가산점을 받을 수 있다. AMP(Accelerated Mobile Page)를 만들때 HTTPS는 필수이다.

SSL / TLS

SSL의 업그레이드 버전이 TLS라고 한다. 나중에 알아보자.

SSL은 Secure Sockets Layer의 약자로 Netscape Communications Corporation에서 웹서버와 웹 브라우저간의 보안을 위해 만든 프로토콜

Let’s Encrypt, AWS Certificate Manager 등 무료로 SSL을 발급해주는 서비스들이 있다.

여기서 암호화 방식으로는 공개키 / 대칭키 2가지 방식을 모두 활용한다.

대칭키란?

대칭키

대칭키는 대칭키하나로 암호화와 복호화가 가능한 암호화 방식이다.

장점 : 암호화 복호화가 쉽고 빠르다.

단점: 키를 전달할때 조심해야 한다. 해커가 대칭키를 가져가면 내용을 다 확인 할 수 있다.

공개키 / 개인키

공개키개인키

공개키 개인키 방식은 암호화는 공개키로, 복호화는 개인키로 진행한다.

프로세스 순서를 확인해보자.

  1. 내용을 전달받고 싶은 사람(A)이 개인키와 공개키 쌍을 만든다. (쌍으로 생성된다)
  2. 상대방(B)에게 공개키를 전달한다.
  3. 공개키를 전달받은 사람(B)은 내용을 공개키로 암호화해서 전달한다.
  4. 데이터를 받은 사람(A)는 내용을 개인키로 복호화해서 확인한다.

이렇게 사용하면 공개키를 유출당해도 확인 할 수 없기에 안전하다.

또한, 개인키를 외부로 유출할 이유가 없다.

단점 : 암호화 연산비용이 크다.

장점 :

  • A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화 하면 A키로 복호화 할 수 있는 방식
  • 클라이언트가 서버로 안전하게 메시지를 발송하는 것을 쉽게 해준다.

대칭키의 장단점과 공개키/개인키 방식의 장단점이 상호보완적이다. 그래서 HTTPS방식에서는 두가지 모두 사용한다.

SSL 통신 과정

통신과정

SSL 통신 프로세스를 확인해보자.

  1. A가 B에게 접속을 요청한다.
  2. B는 공개키/개인키 쌍을 생성한다. 그리고 공개키만 A에게 전달한다.
  3. A는 대칭키를 공개키로 암호화한다. 그리고 전달한다.
  4. B는 개인키로 암호화된 대칭키를 복호화한다.

이렇게 안전하게 A와 B가 대칭키를 공유하게 되었다. 핵심은 공개키/개인키의 보안성을 통해 암호화 비용이 적은 대칭키를 공유하는 것이다. 실제 통신 내용은 대칭키를 통해 이뤄진다! 참 똑똑한 사람들이 많다

실제 사례

ssl통신과정

이제 실제 사례를 확인해보자.

3가지 주체가 있다.

  1. 접속을 요청하는 사용자 (아마도 우리?) : A
  2. 접속을 시도하려는 사이트 서버 : B
  3. HTTPS 인증서를 관리해주는 인증기관, **CA (Certificate Authority)** : C

사이트 접속전 HTTPS 인증서 받는 과정

  1. 사이트(B)가 사이트정보과 공개키를 인증기관(C)에 보낸다.
  2. 인증기관(C)에서는 사이트 정보와 공개키를 검증한다.
  3. 검증이 완료되면 검증기관(C)의 개인키로 ‘사이트 정보와 공개키’를 암호화 한다.
  4. 암호화된 ‘사이트 정보과 공개키’ 즉, 사이트 인증서를 사이트(B)에게 전송한다.
  5. 그리고 우리(A) 브라우저에 인증기관(C)의 공개키를 전송한다. (브라우저에 내장)

이제 사이트의 인증서가 사이트에 생성되었고

우리는 인증기관의 공개키를 가지고 있다.

사이트에 접속 요청을 날려보자!

HTTPS 서버에 접속 요청 프로세스

  1. 사용자(A)가 서버(B)에 접속을 요청한다.
  2. 사이트 서버(B)는 자신이 신뢰가능한 사이트임을 증명하기 위해 사이트 증명서(’사이트 정보와 공개키 암호화 파일’)을 전달한다.
  3. 사용자(A)는 브라우저에 내장된 인증기관(C)의 공개키로 사이트 증명서를 복화한다. 이때 나온 내용은 ‘사이트 정보’와 ‘사이트 공개키’이다.
  4. 이렇게 얻은 사이트 공개키로 사용자(A)의 대칭키를 암호화해서 전달한다.
  5. 사이트(B)는 암호화된 대칭키를 자신의 공개키로 복호화한다.
  6. 이제 사용자(A)와 사이트(B)는 안전하게 대칭키를 교환하였다. 앞으로 데이터 통신은 대칭키로 진행한다.

SSL 통신과정

아래는 더 자세히 본 SSL 통신과정이다.

네트워크 통신에는 핸드쉐이크 ⇒ 세션 ⇒ 세션 종료의 과정을 거친다.

HTTPS는 먼저 SSL 핸드쉐이크 과정을 거친다.

핸드쉐이크의 목적은 아래와 같다.

  • 프로토콜 버전번호 교환
  • 양쪽이 알고 있는 pre master secret 키 생성 및 교환
  • 양쪽의 신원 인증
  • 채널을 암호화 하기 위한 임시 세션 키 생성

ssl통신과정2

참고 자료

HTTPS와 SSL 인증서, SSL 동작방법

[10분 테코톡] 🍭 다니의 HTTPS

HTTPS 통신 원리 쉽게 이해하기 (Feat. SSL Handshake, SSL 인증서)