HTTP(Hyper Text Transfer Protocol)

서버-클라이언트 모델을 따라 데이터를 주고받기 위한 프로토콜

  • 초기에는 HTML 파일을 전송하는 목적, 현재는 JSON, Image 파일 등 또한 전송
  • HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신규약으로 80번 포트 사용
    • 클라이언트는 80번 포트로 요청 보냄
    • HTTP서버가 80포트에서 요청 기다림
  • 단방향 통신 : 클라이언트의 요청이 있을때만 서버가 응답

HTTP 구조

  • 애플리케이션 레벨의 프로토콜
  • TCP/IP위에서 작동
  • 상태를 가지고있지 않은 Stateless 프로토콜
  • Method, Path, Version, Headers, Body 등으로 구성

제목 없음


HTTP 문제점

암호화되지 않은 평문데이터를 전송하는 프로토콜
-> 제 3자가 정보조회 가능
=> HTTPS 등장



HTTPS(Hyper Text Transfer Protocol Secure)

HTTP에 데이터암호화 추가된 프로토콜

  • 443 포트사용

대칭키 암호화

  • 클라이언트가 서버와 동일한 키를 사용해 암호화/복호화 진행
  • 연산속도가 빠름
  • 키가 노출되면 매우 위험

비대칭키 암호화

키

  • 1개의 쌍으로 구성된 공개키 & 개인키 사용해 암호화/복호화 진행
    • 공개키 : 모두에게 공개가능한 키
      • 공개키 암호화 (개인키로만 복호화) : 나만 볼 수 있음
    • 개인키 : 나만 가지고 알고 있어야하는 키
      • 개인키 암호화 (공개키로만 복호화) : 내가 인증한 정보임을 알려 신뢰성 보장 가능
  • 연산속도 느림
  • 키가 노출되어도 비교적 안전

HTTPS 동작과정

대칭키 암호화와 비대칭키 암호화 모두 사용 -> 빠른속도 + 안정성
HTTPS 연결과정(Hand-Shaking)에서 서버-클라이언트 간에 세션키 교환

  • 세션키를 공유하는 과정에서 비대칭키 사용
    • 세션키 : 주고받는 데이터를 암호화 하기위해 사용되는 대칭키
  • 데이터간의 교환에는 빠른 연산속도 필요해서 대칭키 사용

스크린샷(1)

  1. 클라이언트(브라우저)가 서버로 최초 연결시도
  2. 서버 : 클라이언트 에게 공개키(인증서) 넘겨줌 (아래에서 자세하게 보기)
  3. 클라이언트 : 인증서의 유효성 검사 -> 세션키 발급
    -> 세션키 보관 + 서버의 공개키로 세션키를 암호화하여 서버로 전송
  4. 서버 : 암호화된 세션키 복호화(개인키로) -> 세션키 얻음
    => 클라이언트 & 서버 동일한 세션키 공유 - 데이터 전달할 때 세션키로 암호화/복호화 진행

HTTPS 발급과정(서버가 비대칭키 발급받는 과정)

HTTPS 적용하기 위해 공개키/개인키 발급
인증된 기관에 공개키 전송하여 인증서 발급받음

  1. 서버: 공개키 보냄
  2. 인증된기관 : 인증서(서버의 공개키, 서버정보)를 인증기관의 개인키로 암호화한 인증서를 서버에 줌
    • 인증서는 서버의 공개키가 포함되어 있음 = 서버의 공개키라고 봐도 무방
  3. 클라이언트 : 인증기관의 공개키(이미 다운받아있음)로 인증서 복호화 해서 서버의 공개키 얻음

  • 인증서는 인증기관의 개인키로 암호화되어있어 신뢰성확보
  • 클라이언트는 서버의 공개키로 데이터 암호화 했기 때문에 서버만 복호화해서 원본의 데이터 얻을 수 있음

Reference
https://jeong-pro.tistory.com/89
https://mangkyu.tistory.com/98
https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/

업데이트:

참고