[네트워크] HTTPS 와 SSL Handshake

hyyyynjn·2021년 9월 24일
0

면접대비

목록 보기
14/31
post-thumbnail
post-custom-banner

HTTPS

HTTPS는 기존의 HTTP에 보안 계층 프로토콜(SSL/TLS 프로토콜)을 추가하여 암호화한 프로토콜이다.

  • 새로운 애플리케이션 프로토콜이 아니다.
    HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)라는 프로토콜로 대체한 것이다.
  • SSL 버전 3.1부터 TLS로 명칭이 바뀌고부터 SSL와 TLS를 혼용하고 있다.
  • HTTP ⇆ TCP
    • HTTP는 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트가 주고 받는 메시지를 감청하는 것이 매우 쉽다.
  • HTTPS ⇆ SSL ⇆ TCP
    • HTTP에 의한 보안 취약점을 보완한 것이 HTTPS이다.

HTTPS는 제 3자 인증, 공개키 암호화, 비밀키 암호화를 사용한다.

  • 제 3자 인증
    신뢰할 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이다.
  • 공개키 암호화
    비밀키를 공유하기 위해 사용하는 방식이다.
  • 비밀키 암호화
    통신하는 데이터를 암호화하기 위해 사용하는 방식이다.

SSL의 동작방법

필요한 개념

  • 공개키와 비밀키 (Public Key/Private Key)
    공개키는 모두가 볼 수 있는 키이며
    비밀키는 소유자만이 가지고 있는 키로 암/복호화에 사용된다.
  • 대칭키 암호화
    서버와 클라이언트가 암/복호화에 동일한 비밀키를 사용하는 방식이다.
    • 키를 공유하는데 어려움이 있지만 속도가 빠르다.
  • 비대칭키 암호화
    서버와 클라이언트가 암/복호화에 서로 다른 비밀키를 사용하는 방식이다.
    • 공개키를 통해 암호화하고, 비밀키를 통해 복호화한다.
    • 공개키를 사용하기 때문에 키 관리에 어려움이 없지만 속도가 느리다.
  • 인증기관 (Certificate Authority, CA)
    클라이언트가 접속한 서버가 의도한 서버가 맞는지 인증해주는 역할을 하는 보증된 기업들이다.
    • 클라이언트는 서버에 요청하여 CA가 발급한 인증서를 받고
      ⇨ 브라우저에 내장되어있는 CA의 공개키로 복호화하여 신뢰할 만한 인증서인지 검증한다. (복호화되면 신뢰할 만한 것이다)

1. SSL Handshake 과정

SSL가 데이터를 암호화하여 전달하는 방식

  1. 클라이언트가 서버에 접속한다. 이 단계를 Client Hello라고 한다.
  • Client Hello 단계에서 주고 받는 정보
    • 클라이언트 측에서 생성한 랜덤 데이터
    • 클라이언트가 지원하는 암호화 방식들
      클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있으므로 상호간에 어떤 암호화 방식을 사용할지에 대한 협상을 해야한다.
    • 세션 아이디
      이미 SSL Handshake를 했다면 시간/비용을 절약하기 위해 기존의 세션을 재활용하게 된다. 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송한다.
  1. 서버는 Client Hello에 대한 응답으로 Server Hello를 한다.
  • Server Hello 단계에서 주고 받는 정보
    • 서버 측에서 생성한 랜덤 데이터
    • 서버가 선택한 클라이언트의 암호화 방식
      클라이언트가 전달한 암호화 방식중 서버에서도 사용가능한 암호화 방식을 선택해 클라이언트에 전달한다.
      이로써 암호화 방식에 대한 협상이 종료된다.
    • 인증서
  1. 클라이언트는 CA 인증서를 CA의 공개키로 복호화하여 접속 요청한 서버가 신뢰할만한지 검증한다.
  • 클라이언트에 내장된 CA 리스트를 확인한다.
    CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력한다.
  • 서버가 보낸 인증서가 CA에 의해 발급된 것인지 확인하기 위해서 클라이언트에 내장된 CA의 공개키로 복호화한다.
    • 복호화에 성공하면 인증서는 CA의 개인키로 암호화된 문서임을 암시적으로 보증된 것이다.
  1. 복호화가 되면 CA 인증서가 신뢰할 만하므로 데이터를 주고 받을 대칭키를 생성한다.
  • 클라이언트 측에서 생성한 랜덤 데이터서버 측에서 생성한 랜덤 데이터를 조합하여 pre master secret이라는 키를 생성한다.
    • 세션 단계에서 데이터를 주고 받을 때 암호화하기 위해 사용된다.
      이때 사용할 암호화 기법이 대칭키 암호화 기법이다.
      (pre master secret는 절대로 노출되어서는 안된다)
  1. 대칭키를 서버의 공개키로 암호화하여 서버에 전송한다.
  • pre master secret 값을 공개키 방식으로 서버에게 전달한다.
    • 서버의 공개키로 pre master secret 값을 암호화하여 서버로 전송하면, 서버는 자신의 개인키로 안전하게 복호화할 수 있다.
      • 클라이언트는 서버로부터 받은 인증서안에 서버의 공개키를 구할 수 있다.
  1. 서버는 자신의 비밀키로 클라이언트가 보낸 대칭키를 복호화한다.
  • 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키(비밀키)로 복호화한다.
  1. 서버는 복호화한 대칭키를 통해 데이터를 암호화한 뒤 전송한다.
  • 서버와 클라이언트는 모두 일련의 과정을 거쳐 pre master secret 값을 master secret 값으로 만든다.
  • master secret 값은 session key값을 생성한다
  • session key 값을 이용하여 서버와 클라이언트는 데이터를 암호화한 뒤 주고 받는다. (대칭키 방식으로 암호화)
  1. 클라이언트와 서버는 Handshake 단계의 종료를 서로에게 알린다.

2. 세션

세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다.

  • 이 단계에서 정보를 전송하기 전에 session key값을 이용하여 데이터를 대칭키 방식으로 암호화한다.

공개키를 사용하면 될 것을 왜 대칭키와 공개키를 조합하여 사용할까?

📢 공개키를 그대로 사용하면 많은 컴퓨터 파워를 사용하게 된다.
📢 대칭키를 사용하면 상대에게 대칭키를 전송해야하는데, 암호화되지 않은 인터넷을 통해 대칭키를 전송하는 것은 위험하다.
👉 속도는 느리지만 안전하게 데이터를 주고 받기 위해 공개키 방식으로 대칭키를 암호화하고,
실제 데이터를 주고 받을 때 대칭키를 이용하여 주고 받는다.

3. 세션 종료

데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다.

  • 이 때 통신에서 사용한 대칭키인 session key를 폐기한다.
post-custom-banner

0개의 댓글