피들러같은 프록시 툴 원리

피들러같은 프록시 툴 원리

2025년 10월 30일

ref #

암호화 통신 #

이 글은 피들러에서 어떻게 암호화통신을 가로채고 복호화 하는지를 작성할 예정이기 때문에 기본 원리를 먼저 정리한다.

인증서 #

원리 #

일단 인증서는 보통 서버 도메인을 구입한 뒤 인증기관(CA)에 해당 도메인에 대한 인증서를 발급받고, 서버에 설치해서 클라이언트가 접근할때 SSL 핸드쉐이크 과정에서 인증서를 확인하는 과정을 거친다.

93062971-031d-4b6c-b3f8-72f2722ad0a8

발급 #

  1. 서버에 개인키/공개키 쌍을 만들고 CSR(발급요청서)에 등록할 도메인과 방금 만든 공개키를 추가한 후 CA에 요청한다.
  2. CA는 여러 방식(HTTP-01, DNS-01)으로 요청한사람이 해당 도메인을 컨트롤할 수 있는지 검증한다
    • HTTP-01: http://도메인/.well-known/acme-challenge/<토큰> 경로를 CA가 접근해서 확인하기 때문에 저 위치에 파일을 쓸 수 있어야한다. 시놀로지에서는 알아서 저 경로에 넣어주기 때문에 사용자가 신경쓸게 없고 80포트가 열려있어야 해서 방화벽을 내려야만 하는것이다.
    • TLS-ALPN-01: CA가 도메인:443 으로 특수한 인증서를 달라고 요청한다. 443포트를 컨트롤할 수 없다면 실패함
  3. CA가 자신의 개인키로 서명해서 만든 인증서를 서버에 전달해준다. + 추가로 중간CA 인증서들 1~2장도 전달해줌
  4. 발급된 인증서를 서버에 배치한다.

제공 #

  1. 클라이언트가 서버에 접근할때 SSL 핸드쉐이크 과정에서 서버로부터 인증서들의 모음(fullchain.pem)을 전달받는다.
  2. 클라이언트는 전달받은 인증서들에서 자신이 가지고있는 로컬 신뢰 저장소의 루트CA 까지의 경로를 만들어둔다.
  3. 바텀업 방식으로 서버의 인증서부터 그걸 서명해준 CA의 인증서를 차례로 검증해서 루트 CA가 서명해준 인증서까지 검사해본다.
    • 루트 CA는 어차피 완전 신뢰하는 인증서로 로컬에 설치해버리니까 검증하지 않아도 상관없음
  4. 체인이 끊기면 ‘신뢰할 수 없음’ 오류가 발생한다.

구조 #

인증서는


기본 SSL 통신 원리 #

9ca2ca73-a525-4d0a-874c-52d63ee7d295

중요한 부분만보자.

  1. 클라이언트와 서버가 서로 생성한 랜덤 데이터를 교환한다.
  2. 클라이언트가 사용 가능한 암호화방식 후보를 서버가 선택한다.(서버가 가능한 것으로)
  3. 서버의 인증서를 클라이언트에게 보내준다.
  4. 클라이언트가 pre_master_secret 을 생성하고 서버 인증서 안의 공개키로 암호화해서 전송
  5. 서버와 클라이언트가 모두 pre_master_secret으로 master_secretsession key(대칭키)를 파생
  6. session key로 암호화통신하고 세션종료시 폐기한다.
comments powered by Disqus