본문 바로가기
ASAC

[ASAC 06] HTTPS

by suhsein 2024. 9. 11.
728x90
이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다. 

HTTPS (HTTP Secured, TLS)

  • 웹 통신 내 End-to-End 회선 보호
  • SSL(Secure Sockets Layer) 혹은 TLS(Transport Layer Security) 프로토콜을 통해 HTTP 보안 강화

HTTPS 목적

요청을 보내고, 응답을 받는 두 주체 (End-to-End)만 HTTPS 요청 및 응답을 읽을 수 있게 암호화

  • 목적 : MITM(Man-In-The-Middle) 공격 방지
    • 스니핑 (Sniffing) : Wireshark 사용 모든 웹 서핑 패킷 도청 가능
    • 패킹 주입 (Packing Injection) : DHCP/ARP로 LAN 내 컴퓨터 인지 후 패킷을 대신 받아 조작 주입
      • ARP Spoofing -> 위변조
        • Sniffing -> 도청 혹은 가로채기
    • 세션 하이재킹 공격
    • SSL 스트리핑 등

대칭키와 비대칭키

  • 비대칭키 => 알고리즘이 매우 복잡해서 느리다. 비밀키만 잘 관리하면 대칭키보다 안전하다.
    • 공개키는 누가나 볼 수 있고 노출 되어도 안전.
    • 노출되어도 안전한 공개키를 클라이언트에게 공유하여 암호화 통신을 위한 시작을 연다.
    • 비대칭 암호화는 갑을 관계를 내포한다. 갑(비공개키를 가진 서버), 을(공개키를 가진 클라이언트)
      GIT의 경우 SSH 통신 유저가 갑(비공개키를 가짐), 리포지토리들이 을(공개키를 가짐)
  • 대칭키 => 매우 빠르다. 키 하나기 때문에 노출되면 보안에 매우 위험.
    • 연산속도가 빨라 매번 클라이언트와 서버가 요청/응답을 주고받을 때 성능 영향을 안준다.

CA(Certification Authority)

  • SSL 인증서를 발급하는 기관, 신뢰할 수 있는 기관
  • 인증 기관에 의해 인증된 서버인지 = 인증 기관에 의해 암호화된 '서버의 공개키' 인지
  • 피싱 방지 : 클라이언트가 실제로 도메인을 소유하고 있는 올바른 서버와 통신하고 있는지 확인 목적

HTTPS 통신 절차

HTTPS 통신 시작 시 절차. => 2쌍의 비대칭키로 1쌍의 대칭키 만들기
일종의 hand shaking이다.

  1. CA 비공개키(전 세계에 하나)로 서버의 공개키를 암호화 한다.
    • 서버에는 매 클라이언트를 위한 비대칭키 페어를 가지고 있다.
  2. 웹 브라우저가 암호화된 서버의 공개키를 받는다.
  3. 브라우저는 요청을 할 때 CA의 공개키로 복호화 하여 서버의 공개키를 얻는다.
  4. CA 공개키는 브라우저에 저장되어 있다. (없다면 인증서 다운로드 하면 됨. 브라우저 혹은 로컬 PC에)
  5. 서버와 브라우저는 같은 PRE MASTER KEY를 가지게 된다.
    • PRE MASTER KEY -> MASTER KEY -> SESSION KEY
    • 결국 같은 SESSION KEY(대칭키)를 브라우저와 서버가 가지게 된다.

최종적으로 클라이언트와 서버는 대칭키로 통신을 하게 된다.

HTTPS는 비대칭키와 대칭키 암호화 전략을 모두 쓰기 때문에 장점만 취함.

  1. 비대칭키 장점 -> 안전하다
  2. 대칭키 장점 -> 빠르다

서버와 클라이언트가 비대칭키를 주고받아 이를 통해 생성한 대칭키로 암호화.
-> 유출되어도 안전, 인증 시 대칭키 알고리즘 사용으로 빠르다.

비대칭키 2 PAIR(CA 1 PAIR, 서버 1 PAIR), 대칭키 1 PAIR(서버와 브라우저가 같은 대칭키를 가지게 됨)

728x90