การถอดรหัส HTTPS (Man-in-the-Middle Attack, MitM)

Chute สามารถถอดรหัสทราฟฟิก HTTPS โดย MitM โปรดดูบทความ Wikipedia สำหรับข้อมูลเพิ่มเติม บน iPhone, Apple TV และ Android นี่เป็นคุณสมบัติที่ต้องมีใบอนุญาตและเอนจินบังคับใช้เอง: หากไม่มีใบอนุญาตจะไม่มีการถอดรหัสใด ๆ ไม่ว่าการกำหนดค่าจะระบุอย่างไร ดูใบอนุญาตและการเปิดใช้งาน

ตัวสร้างใบรับรองสามารถช่วยคุณสร้างใบรับรอง CA ใหม่สำหรับการดีบักและทำให้ใบรับรองเชื่อถือโดยระบบ มันมีให้ใน Chute Mac และ Chute iOS Chute Editor ใบรับรองนี้ถูกสร้างขึ้นในเครื่องและบันทึกเฉพาะในไฟล์โปรไฟล์ของคุณและ Keychain ของระบบ คีย์ของใบรับรองใหม่ถูกสร้างขึ้นแบบสุ่มโดยใช้ OpenSSL Chute Android ไม่มีตัวสร้าง: นำเข้า PKCS#12 ที่มีอยู่ที่ MitM → กำหนดค่า CA ในตัวแก้ไข แล้ว ติดตั้ง 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 จะถอดรหัสเฉพาะ HTTPS ที่เข้ามาทาง CONNECT เท่านั้น คำขอ HTTP ธรรมดาจะถูกส่งต่อตามปกติ แม้โฮสต์ของมันจะอยู่ใน hostname

รองรับอักขระ wildcard และ ? โปรดทราบว่า ? จะทำหน้าที่เป็น wildcard ก็ต่อเมื่อกฎนั้นมี `อยู่ด้วย ส่วนกฎที่มีเพียง?` จะถูกเปรียบเทียบแบบตรงตัวอักษร

• ใช้คำนำหน้า - เพื่อยกเว้นชื่อโฮสต์ รายการจะถูกตรวจสอบตามลำดับที่เขียน และรายการแรกที่ตรงกันจะเป็นตัวตัดสิน ดังนั้นการยกเว้นต้องมาก่อนรายการที่มันตัดส่วนออกมา: hostname = -*.apple.com, * จะไม่แตะต้อง apple.com ขณะที่ hostname = *, -*.apple.com จะถอดรหัสมัน
• โดยค่าเริ่มต้น เฉพาะคำขอไปยังพอร์ต 443 เท่านั้นที่ถูกถอดรหัส
  • ใช้ส่วนต่อท้าย :port เพื่ออนุญาตพอร์ตอื่น
  • ใช้ส่วนต่อท้าย :0 เพื่ออนุญาตทุกพอร์ต

ตัวอย่าง:

• -*.apple.com: ยกเว้นคำขอทั้งหมดที่ส่งไปยัง *.apple.com บนพอร์ต 443
• www.google.com: อนุญาต MitM สำหรับ www.google.com บนพอร์ต 443
• www.google.com:8080: อนุญาต MitM สำหรับ www.google.com บนพอร์ต 8080
• www.google.com:0: อนุญาต MitM สำหรับ www.google.com บนทุกพอร์ต
• *: อนุญาต MitM สำหรับชื่อโฮสต์ทั้งหมดบนพอร์ต 443 (ไม่แนะนำ)
• *:0: อนุญาต MitM สำหรับชื่อโฮสต์ทั้งหมดบนทุกพอร์ต (ไม่แนะนำ)

คีย์เวิร์ดสี่ตัวแทนปลายทางทั้งประเภท และใช้คำนำหน้า - กับคำต่อท้าย :port ได้เช่นเดียวกับชื่อ: <ip-address> (การเชื่อมต่อใด ๆ ที่ไปยัง IP ตรง ๆ), <ipv4-address>, <ipv6-address> และ <simple-hostname> (ชื่อที่ไม่มีจุด เช่น intranet) hostname = -<simple-hostname>, * ถอดรหัสทุกอย่างยกเว้นชื่อส่วนเดียว และ hostname = <ip-address> ถอดรหัสเฉพาะการเชื่อมต่อที่ไปยังที่อยู่ คีย์เวิร์ดแบบที่อยู่มีผลเฉพาะกับ CONNECT ไปยังที่อยู่ผ่านพร็อกซี HTTP เท่านั้น: การเชื่อมต่อ TUN จะถูกถอดรหัสตามชื่อโฮสต์เท่านั้น — ชื่อที่ Chute แปลงชื่อไว้ให้การเชื่อมต่อนั้น หรือชื่อเซิร์ฟเวอร์ในการจับมือ TLS ของมันเมื่อเปิด sniffing-enabled — ดังนั้นการเชื่อมต่อที่ไปยังที่อยู่ตรง ๆ โดยไม่มีชื่อเซิร์ฟเวอร์จะไม่มีวันถูกถอดรหัส

รายการชื่อโฮสต์ยังสามารถระบุรูปแบบพาธต่อท้ายหลัง / ตัวแรกได้ด้วย แต่การตัดสินใจว่าจะถอดรหัสหรือไม่เกิดขึ้นตอนเปิดการเชื่อมต่อ — เมื่อได้รับ CONNECT หรือเมื่อเซสชัน TUN เริ่มต้น — ก่อนที่จะทราบพาธของคำขอใด ๆ ดังนั้นรายการที่ระบุพาธจะถอดรหัสทั้งการเชื่อมต่อเมื่อโฮสต์ตรงกัน และการยกเว้นแบบ -host/path จะไม่มีผลเลย อย่าพึ่งพามันเพื่อกันโฮสต์ออกจากการถอดรหัส

• example.com/api/*: อนุญาต MitM สำหรับ example.com บนพอร์ต 443 โดยพาธไม่ได้จำกัดขอบเขต

การกำหนดค่าทั่วไปอาจเป็นดังนี้:

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

Chute จะใช้กฎ URL Rewrite, Header Rewrite, Body Rewrite และการตอบกลับจำลอง ([Map Local]) รวมถึงสคริปต์กับคำขอ MitM ทั้งหมด — ทุกคำขอบนการเชื่อมต่อที่ถูกถอดรหัส ไม่ใช่เฉพาะคำขอแรก การเชื่อมต่อ HTTP/1.1 ที่ถูกถอดรหัสจะรับส่งเพียงหนึ่งรอบ: เมื่อส่งการตอบกลับเสร็จ Chute จะปิดการเชื่อมต่อ ไคลเอนต์จึงส่งคำขอถัดไปบนการเชื่อมต่อใหม่ ซึ่งจะถูกจัดการในลักษณะเดียวกัน คำขอที่ส่งต่อท้ายคำขอแรกแบบไปป์ไลน์บนการเชื่อมต่อเดียวกันจะไม่ถูกประมวลผล และไคลเอนต์จะส่งมันใหม่บนการเชื่อมต่อใหม่ ข้อยกเว้นคือการเชื่อมต่อที่ Chute Android ถอดรหัสจาก VPN ซึ่งจะยังเปิดอยู่ และคำขอแต่ละรายการบนการเชื่อมต่อนั้นจะถูกจัดการตามลำดับ แต่การเชื่อมต่อนี้จะถูกปิดหลังคำตอบที่ Chute สร้างเอง — การตอบกลับจำลอง คำตอบของ URL Rewrite หรือ response ของสคริปต์ — และหลังการตอบกลับที่ได้เนื้อหามาจากสคริปต์ http-response ที่ทำงานที่ส่วนหัว ส่วนการเชื่อมต่อ HTTP/2 จะคงการเชื่อมต่อเดิมไว้ การอัปเกรดเป็น WebSocket ก็เช่นกัน: หลังการตอบกลับ 101 ข้อมูลจะผ่านไปมาทั้งสองทิศทางโดยไม่ถูกเปลี่ยนแปลง

MitM รองรับ HTTP/2 ทั้งการเชื่อมต่อที่ผ่านพร็อกซี HTTP และที่ผ่าน TUN ก่อนการจับมือ TLS กับเซิร์ฟเวอร์ Chute จะอ่านโปรโตคอลที่ไคลเอนต์เสนอ (ALPN): เมื่อไคลเอนต์เสนอ h2 และ [MITM] ไม่ได้ตั้ง h2 = false จะเสนอ h2 และ http/1.1 ให้เซิร์ฟเวอร์ มิฉะนั้นจะเสนอเฉพาะ http/1.1 จากนั้นจะเสนอโปรโตคอลที่เซิร์ฟเวอร์เลือกให้ไคลเอนต์ ทั้งสองฝั่งจึงใช้โปรโตคอลเดียวกันเสมอ หากไคลเอนต์ไม่ได้เสนอโปรโตคอลนั้น Chute จะไม่ตอบ ALPN และการจับมือจะดำเนินต่อไป บน HTTP/2 trailers (เช่น grpc-status ของ gRPC) และการตอบกลับชั่วคราว 1xx อย่าง 103 Early Hints จะถูกส่งต่อตามเดิม กฎและสคริปต์มองไม่เห็นสิ่งเหล่านี้ ส่วนคีย์ tcp-connection ของ [MITM] ใน Surge นั้นรับค่าได้ในไฟล์การกำหนดค่าแต่จะถูกละเว้น

บางแอปพลิเคชันมีนโยบายความปลอดภัยที่เข้มงวดในการใช้ใบรับรองหรือ 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. เชื่อถือมัน: การตั้งค่า → ทั่วไป → เกี่ยวกับ → การตั้งค่าความน่าเชื่อถือของใบรับรอง และเปิดการเชื่อถือแบบเต็มสำหรับ CA ของ Chute ขั้นตอนนี้คือขั้นที่คนส่วนใหญ่พลาด — หากไม่ทำ ใบรับรองจะถูกติดตั้งแต่ไม่ถูกเชื่อถือ และการถอดรหัสจะล้มเหลวต่อไป

Chute Mac — ในหน้าต่างการกำหนดค่า เปิด MitM:

1. สร้างใบรับรองใหม่ (หรือ นำเข้าใบรับรองจากไฟล์ PKCS#12)
2. คลิก ติดตั้งใบรับรองลงในระบบ macOS จะขอรหัสผ่านผู้ดูแลระบบและเพิ่มใบรับรองลงใน System keychain เป็น root ที่เชื่อถือ — ไม่ต้องทำขั้นตอนใน Keychain Access ด้วยตนเอง
3. ส่งออกใบรับรอง บันทึกสำเนา .pem สำหรับติดตั้งบนอุปกรณ์อื่น

Chute Android — ในตัวแก้ไขการกำหนดค่า เปิด MitM → กำหนดค่า CA:

1. นำเข้า P12 จะเขียน PKCS#12 ที่มีอยู่ลงใน ca-p12 เป็น base64 เช่นเดียวกับที่แอปบนแพลตฟอร์มของ Apple ทำ การกำหนดค่าจึงพา CA ของมันไปยังอุปกรณ์อื่นได้ด้วย แล้วป้อนวลีรหัสผ่านของมันใน วลีรหัสผ่าน CA Chute Android ไม่มีตัวสร้าง ค่า ca-p12 ที่ระบุเป็นชื่อไฟล์ ตามแบบที่ตัวแก้ไขเวอร์ชันก่อนหน้าเขียนไว้ ยังคงอ่านได้
2. ติดตั้ง CA จะส่งใบรับรอง CA ใน P12 นั้นให้ตัวติดตั้งใบรับรองของ Android ตั้งแต่ Android 11 เป็นต้นไป แอปไม่สามารถติดตั้งใบรับรอง CA ด้วยวิธีนั้นได้อีก: ให้ติดตั้งจากไฟล์ใบรับรองในการตั้งค่าความปลอดภัยของระบบแทน — ใช้สำเนา .pem หรือ .crt ของใบรับรองนั้น เช่นไฟล์ที่ ส่งออกใบรับรอง บันทึกไว้บน Chute Mac
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 ทำให้การเชื่อมต่อ MitM เสี่ยงต่อการโจมตีแบบ man-in-the-middle ระหว่าง Chute และเซิร์ฟเวอร์อัปสตรีม เปิดใช้งานเฉพาะสำหรับเครือข่ายที่เชื่อถือได้หรือเพื่อการพัฒนาเท่านั้น

hostname-disabled

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

โฮสต์ที่จะไม่ถูกถอดรหัสเลย แม้จะมีรายการใน hostname ครอบคลุมอยู่ก็ตาม ไวลด์การ์ดใช้ได้เหมือนใน hostname และ :port จะจำกัดรายการไว้ที่พอร์ตเดียว สะดวกสำหรับการปิดโฮสต์ที่โมดูลเพิ่มเข้ามาโดยไม่ต้องแก้ไขโมดูล

auto-quic-block

auto-quic-block = true

บล็อก QUIC ไปยังทุกโฮสต์ที่จะถูกถอดรหัส เพื่อให้ไคลเอนต์ HTTP/3 ถอยกลับไปใช้ TLS บน TCP ซึ่ง MitM มองเห็นทราฟฟิกได้ ตัวเลือกนี้ทำงานเพิ่มเติมจาก block-quic ไม่ได้แทนที่