HTTPS 복호화 (중간자 공격, MitM)

Chute는 MitM을 통해 HTTPS 트래픽을 복호화할 수 있습니다. 자세한 내용은 Wikipedia 문서를 참조하세요. iPhone, Apple TV, Android에서는 라이선스가 필요한 기능이며 엔진이 이를 강제합니다. 라이선스가 없으면 구성이 무엇이라고 하든 아무것도 복호화되지 않습니다. 라이선스와 활성화를 보세요.

인증서 생성기는 디버깅을 위해 새 CA 인증서를 생성하고 시스템에서 인증서를 신뢰하도록 설정하는 데 도움을 줍니다. Chute Mac과 Chute iOS의 구성 편집기에서 사용할 수 있습니다. 이 인증서는 로컬에서 생성되며 프로필 파일과 시스템 키체인에만 저장됩니다. 새 인증서의 키는 OpenSSL을 사용하여 무작위로 생성됩니다. Chute Android에는 생성기가 없습니다. 편집기의 MitM → CA 구성에서 기존 PKCS#12를 가져오고, CA 설치가 그 CA 인증서를 Android 인증서 설치 프로그램에 넘깁니다 — CA 인증서 설치 및 신뢰를 보세요.

기존 CA 인증서를 사용할 수도 있습니다. 인증서를 PKCS#12 형식(.p12)으로 암호와 함께 내보내세요. 암호는 비워둘 수 없습니다. Chute는 암호 없는 PKCS#12를 불러오기를 거부합니다. "base64" 명령어를 사용하여 base64 문자열로 인코딩하고 아래 설정을 구성 파일에 추가하세요.

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
hostname = *google.com

Chute는 여기에 선언된 호스트에 대한 트래픽만 복호화하므로 반드시 설정하세요. 모든 플랫폼에서 [MITM] 섹션을 켜 두었더라도 hostname을 선언하지 않으면 아무것도 복호화하지 않습니다. 키가 아예 없든, hostname-disabled 항목만 주어졌든 마찬가지입니다. HTTP 프록시를 거칠 때는 CONNECT로 들어온 HTTPS만 복호화합니다. 평문 HTTP 요청은 호스트가 hostname에 있더라도 평소대로 전달됩니다.

와일드카드 문자 및 ?가 지원됩니다. 단, ?는 규칙에 `도 포함되어 있을 때만 와일드카드로 동작하며,?`만 포함된 규칙은 리터럴로 비교됩니다.

• 접두사 -를 사용하여 호스트명을 제외합니다. 항목은 적힌 순서대로 검사되며 처음 일치한 항목이 결정하므로, 제외 항목은 그것이 예외를 두려는 항목보다 앞에 와야 합니다: hostname = -*.apple.com, *는 apple.com을 그대로 두지만, hostname = *, -*.apple.com은 apple.com을 복호화합니다.
• 기본적으로 포트 443에 대한 요청만 복호화됩니다.
  • 접미사 :port를 사용하여 다른 포트를 허용합니다.
  • 접미사 :0을 사용하여 모든 포트를 허용합니다.

예:

• -*.apple.com: 포트 443에서 *.apple.com으로 전송된 모든 요청을 제외합니다.
• www.google.com: 포트 443에서 www.google.com에 대한 MitM을 허용합니다.
• www.google.com:8080: 포트 8080에서 www.google.com에 대한 MitM을 허용합니다.
• www.google.com:0: 모든 포트에서 www.google.com에 대한 MitM을 허용합니다.
• *: 포트 443에서 모든 호스트명에 대한 MitM을 허용합니다. (권장하지 않음)
• *:0: 모든 포트에서 모든 호스트명에 대한 MitM을 허용합니다. (권장하지 않음)

네 가지 키워드는 대상의 부류 전체를 나타내며, 이름과 마찬가지로 - 접두사와 :port 접미사를 붙일 수 있습니다: <ip-address>(IP 리터럴로 향하는 모든 연결), <ipv4-address>, <ipv6-address>, <simple-hostname>(intranet처럼 점이 없는 이름). hostname = -<simple-hostname>, *는 단일 라벨 이름을 제외한 모든 것을 복호화하고, hostname = <ip-address>는 주소로 향하는 연결만 복호화합니다. 주소 키워드는 HTTP 프록시를 거쳐 주소로 향하는 CONNECT에만 적용됩니다. TUN 연결은 호스트 이름 — Chute가 그 연결을 위해 해석한 이름, 또는 sniffing-enabled가 켜져 있을 때 TLS 핸드셰이크의 서버 이름 — 으로만 복호화되므로, 서버 이름 없이 맨 주소로 맺은 연결은 결코 복호화되지 않습니다.

호스트명 항목은 첫 번째 / 뒤에 경로 패턴을 포함할 수도 있습니다. 다만 복호화 여부는 연결이 열릴 때 — CONNECT를 받을 때나 TUN 세션이 시작될 때 — 요청 경로를 알기 전에 정해지므로, 경로가 붙은 항목은 호스트가 일치하면 연결 전체를 복호화하고 -host/path 형태의 제외는 전혀 적용되지 않습니다. 특정 호스트를 복호화에서 빼는 수단으로 기대하지는 마세요.

• example.com/api/*: 포트 443에서 example.com에 대한 MitM을 허용합니다. 경로로 범위가 좁혀지지는 않습니다.

일반적인 구성은 다음과 같습니다:

hostname = -*.apple.com, -*.icloud.com, *

Chute는 모든 MitM 요청에 — 복호화된 연결의 첫 요청만이 아니라 그 연결의 모든 요청에 — URL 재작성, 헤더 재작성, 본문 재작성 및 모의 응답([Map Local]) 규칙과 스크립트를 적용합니다. 복호화된 HTTP/1.1 연결은 한 번의 주고받기만 실어 나릅니다: 응답을 다 보내면 Chute가 연결을 닫으므로, 클라이언트는 다음 요청을 새 연결로 보내고 그 연결도 같은 방식으로 처리됩니다. 같은 연결에서 첫 요청 뒤에 파이프라인으로 이어진 요청은 처리되지 않으며, 클라이언트가 새 연결에서 다시 보냅니다. 예외는 Chute Android가 VPN에서 복호화한 연결로, 열린 채로 유지되며 그 위의 요청이 차례로 같은 방식으로 처리됩니다. 다만 Chute가 직접 응답한 뒤(모의 응답, URL 재작성의 응답, 스크립트의 response)나, 헤더만으로 실행된 http-response 스크립트가 본문을 바꾼 응답을 보낸 뒤에는 연결이 닫힙니다. HTTP/2 연결은 연결을 유지하며 WebSocket 업그레이드도 마찬가지입니다: 101 응답 이후에는 데이터가 양방향으로 그대로 오갑니다.

MitM은 HTTP/2를 지원하며, HTTP 프록시를 거친 연결과 TUN을 거친 연결 모두 같습니다. Chute는 서버와 TLS 핸드셰이크를 하기 전에 클라이언트가 제시하는 프로토콜(ALPN)을 읽습니다: 클라이언트가 h2를 제시하고 [MITM]에 h2 = false가 없으면 서버에 h2와 http/1.1을 제시하고, 그렇지 않으면 http/1.1만 제시합니다. 그런 다음 클라이언트에는 서버가 고른 프로토콜을 제시하므로 양쪽은 항상 같은 프로토콜을 씁니다. 클라이언트가 그 프로토콜을 제시하지 않았다면 Chute는 ALPN 응답을 보내지 않으며 핸드셰이크는 그대로 계속됩니다. HTTP/2에서 트레일러(예: gRPC의 grpc-status)와 103 Early Hints 같은 1xx 중간 응답은 그대로 전달되며, 규칙과 스크립트는 이를 보지 못합니다. Surge의 [MITM] 키 tcp-connection은 구성 파일에서 허용되지만 무시됩니다.

일부 애플리케이션은 고정된 인증서나 CA를 사용하는 엄격한 보안 정책을 가지고 있습니다. 이러한 호스트에 대한 복호화를 활성화하면 문제가 발생할 수 있습니다.

Chute는 직접 발급한 호스트 인증서를 저장소에 보관하며, 가득 차면 가장 오래 사용되지 않은 것을 제거합니다. macOS는 512개, iOS·tvOS·Android는 128개입니다.

CA 인증서 설치 및 신뢰

CA를 생성(또는 가져오기)하는 것은 설정의 절반일 뿐입니다 — 운영 체제가 이를 신뢰하기도 해야 합니다. 두 단계가 모두 완료되기 전까지는 복호화되는 모든 사이트가 인증서 경고와 함께 실패합니다. 앱의 인증서 페이지에 현재 상태가 표시됩니다("신뢰할 수 있는 CA 인증서" / "신뢰할 수 없는 CA 인증서").

Chute iOS — 구성 편집기에서 MITM → CA 구성을 엽니다:

1. 새 CA 인증서 생성(기존 인증서가 있다면 P12 인증서 가져오기).
2. 시스템에 CA 인증서 설치를 탭합니다. Safari 페이지가 열립니다 — Install Certificate를 탭하고 다운로드를 허용한 다음, 설정 → 일반 → VPN 및 기기 관리에서 다운로드된 프로파일을 설치합니다.
3. 신뢰 설정: 설정 → 일반 → 정보 → 인증서 신뢰 설정에서 Chute CA에 대한 완전한 신뢰를 활성화합니다. 이 단계가 대부분의 사람이 놓치는 부분입니다 — 이 단계가 없으면 인증서는 설치만 되고 신뢰되지 않아 복호화가 계속 실패합니다.

Chute Mac — 구성 창에서 MitM을 엽니다:

1. 새 인증서 생성(또는 기존 인증서는 PKCS#12 파일에서 인증서 가져오기).
2. 시스템에 인증서 설치를 클릭합니다. macOS가 관리자 암호를 요청한 뒤 인증서를 신뢰할 수 있는 루트로 시스템 키체인에 추가합니다 — 키체인 접근에서의 수동 작업은 필요하지 않습니다.
3. 인증서 내보내기는 다른 기기에 설치할 수 있도록 .pem 사본을 저장합니다.

Chute Android — 구성 편집기에서 MitM → CA 구성을 엽니다:

1. P12 가져오기는 Apple 플랫폼의 앱과 마찬가지로 기존 PKCS#12를 base64로 ca-p12에 기록하므로, 그 CA가 구성에 담겨 다른 기기로 전해집니다. 그 암호는 CA 암호에 입력합니다. Chute Android에는 생성기가 없습니다. 이전 버전의 편집기가 기록했던 것처럼 파일을 가리키는 ca-p12도 여전히 읽힙니다.
2. CA 설치는 그 P12에 든 CA 인증서를 Android 인증서 설치 프로그램에 넘깁니다. Android 11부터는 앱이 이 방식으로 CA 인증서를 설치할 수 없으므로, 대신 시스템의 보안 설정에서 인증서 파일로 설치하세요 — Chute Mac에서 인증서 내보내기가 저장하는 사본처럼 .pem 또는 .crt 형식의 사본이면 됩니다.
3. Android는 이 인증서를 사용자 인증서로 보관하며, Android 7.0 이상을 대상으로 하는 앱은 스스로 허용한 경우에만 사용자 인증서를 신뢰합니다. 그래서 인증서를 설치한 뒤에도 많은 앱이 여전히 핸드셰이크에 실패합니다 — 그런 앱의 호스트는 hostname에서 제외하세요.

인증서가 신뢰되는데도 특정 앱이 여전히 실패한다면, 그 앱은 자체 인증서를 고정(pin)했을 가능성이 큽니다 — 맞서 싸우기보다 - 접두사로 해당 호스트를 hostname에서 제외하세요.

옵션

skip-server-cert-verify

skip-server-cert-verify = true

MitM 수행 시 원격 호스트의 인증서를 확인하지 않습니다. 활성화되면 Chute는 자체 서명된 인증서나 유효하지 않은 인증서를 포함하여 업스트림 서버가 제시하는 모든 인증서를 수락합니다. 이는 개발 환경에 유용하지만 보안이 저하됩니다.

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
skip-server-cert-verify = true
hostname = *google.com

보안 참고: skip-server-cert-verify를 활성화하면 Chute와 업스트림 서버 간의 MitM 연결이 중간자 공격에 취약해집니다. 신뢰할 수 있는 네트워크나 개발 목적으로만 활성화하세요.

hostname-disabled

hostname-disabled = *.bank.example, pay.example.com:8443

hostname의 항목에 해당하더라도 절대 복호화하지 않는 호스트입니다. 와일드카드는 hostname과 같이 동작하며, :port로 항목을 한 포트로 제한할 수 있습니다. 모듈을 수정하지 않고 모듈이 추가한 호스트를 끌 때 유용합니다.

auto-quic-block

auto-quic-block = true

복호화 대상이 되는 모든 호스트로 가는 QUIC을 차단해, HTTP/3 클라이언트가 TCP 위의 TLS로 폴백하게 합니다. 그러면 MitM이 트래픽을 볼 수 있습니다. block-quic을 대신하는 것이 아니라 그에 더해 동작합니다.