Android 14 บล็อกการแก้ไขใบรับรองระบบ แม้มีสิทธิ์รูตก็ตาม?
(httptoolkit.com)- Android 14 (API v34) เปลี่ยนมาอ่านใบรับรอง CA ของระบบจาก โมดูล
com.android.conscryptที่ใช้ APEX แทน/systemทำให้เวิร์กโฟลว์ดีบักแบบเดิมที่ฉีดใบรับรองด้วยสิทธิ์รูตใช้ไม่ได้ - ตั้งแต่ Android 7 Nougat เป็นต้นมา คลังความเชื่อถือเริ่มต้นของแอปถูกแยกเป็น CA ของระบบและ CA ของผู้ใช้ ทำให้เครื่องมือสำหรับพัฒนา ทดสอบ และวิศวกรรมย้อนกลับ ต้องพึ่งการแก้ไขไดเรกทอรี CA ของระบบโดยตรง
- โครงสร้างใหม่นี้ทำให้สามารถอัปเดตใบรับรอง CA ผ่าน Google Play System Update ได้ ช่วยให้ถอด CA ที่มีปัญหาและกระจาย CA ใหม่ได้เร็วขึ้น แต่ก็ลดอำนาจควบคุมของเจ้าของอุปกรณ์ลง
- ในอีมูเลเตอร์ Android 14 รุ่นเบตา แม้จะครอบ
/system/etc/security/cacerts,/system/etc/security/cacerts_google,/apex/com.android.conscrypt/cacertsฯลฯ ด้วย tmpfs หรือลบออกไปแล้ว Settings และแอปก็ยังคงเห็นรายการ Google CA อยู่ - ณ เวลาที่เขียน ทางเลือกที่ใช้งานได้จริงคือคง Android 13 ไว้ หรือใช้ระบบปฏิบัติการแบบคัสตอมที่ไม่ใช้ APEX และผู้เขียนระบุว่าในการอัปเดตภายหลังมีการค้นพบ วิธีเลี่ยงการฉีดใบรับรองบน Android 14 หลายแบบแล้ว
แนวทางการจัดการ Android CA ที่เปลี่ยนมาเรื่อย ๆ
- ตอนที่ Android เปิดตัวโดย Open Handset Alliance ในปี 2007 มีการเน้นความเปิดกว้างด้วยคำอย่าง “open platform” และ “complete access to handset capabilities and tools”
- แต่เมื่อเวลาผ่านไป ขอบเขตที่ผู้ใช้ นักพัฒนา และนักวิจัยจะควบคุมอุปกรณ์ของตนเองได้กลับถูกมองว่าแคบลงเรื่อย ๆ
-
การเปลี่ยนแปลงใน Android 7 Nougat
- รายการ CA ที่เจ้าของอุปกรณ์แก้ไขได้ถูกแยกเป็น CA ของระบบ และ CA ของผู้ใช้
- รายการ CA ของระบบแบบคงที่ที่ผู้ขาย OS จัดให้ กลายเป็นค่าเริ่มต้นสำหรับทุกแอป
- รายการ CA ที่ผู้ใช้แก้ไขได้จะถูกใช้ก็ต่อเมื่อแอประบุ opt-in อย่างชัดเจนเท่านั้น
- ผลคือแทบทุกแอปจะไม่เชื่อถือ CA ของผู้ใช้โดยค่าเริ่มต้นอีกต่อไป
ทำไมใบรับรอง CA จึงสำคัญ
- CA ที่อุปกรณ์เชื่อถือคือรายชื่อองค์กรที่รับประกันความปลอดภัยของทราฟฟิกเครือข่ายที่เข้ารหัส
- CA สามารถออกใบรับรองสำหรับโดเมนใดก็ได้เพื่อนำไปใช้กับการเชื่อมต่อ TLS เช่น HTTPS และอุปกรณ์ที่เชื่อถือ CA นั้นก็จะยอมรับใบรับรองดังกล่าวว่าเป็นหลักฐานของการเชื่อมต่อที่ถูกต้อง
- หากผู้ใช้ทำให้ CA ที่ตนสร้างเองกลายเป็น CA ที่อุปกรณ์เชื่อถือได้ ก็จะสามารถดักดูทราฟฟิก HTTPS หรือ TLS ของตนเองได้
- ตรวจสอบข้อมูลที่โทรศัพท์ส่งและรับได้
- และหากต้องการก็สามารถแก้ไขหรือบล็อกได้
- การควบคุมลักษณะนี้สำคัญต่อ งานวิจัยด้านความปลอดภัยและความเป็นส่วนตัว งานวิศวกรรมย้อนกลับ การดีบักและทดสอบแอป การตั้งค่าเครือข่ายภายในองค์กร และผู้ใช้ที่ไม่ต้องการเชื่อถือ CA เริ่มต้น
- การทำให้ผู้ใช้ที่ไม่เชี่ยวชาญเปลี่ยน CA ได้ยากขึ้น หรือป้องกันไม่ให้ถูกเปลี่ยนโดยที่ผู้ใช้ไม่รู้ตัวนั้นสมเหตุสมผล แต่หากจำกัดอำนาจควบคุมของผู้ใช้ขั้นสูงไปด้วย ก็จะทำให้หลายกรณีการใช้งานทำได้ยาก
วิธีเลี่ยงแบบใช้รูตหลัง Android 7
- แม้หลัง Android 7 หากอุปกรณ์มีสิทธิ์รูต ก็ยังสามารถจัดการ คลัง CA ของระบบ ได้โดยตรง
- วิธีที่ใช้กันทั่วไปคือใส่ใบรับรองที่ต้องการเชื่อถือไว้ใน
/system/etc/security/cacerts/ - โดยปกติ
/systemจะเป็นแบบอ่านอย่างเดียวแม้บนเครื่องที่รูตแล้ว จึงมีการใช้สองวิธีหลัก- ปรับให้ไดเรกทอรี
/systemเขียนได้แล้วรีบูต จากนั้นแก้ไขไดเรกทอรีใบรับรองระบบจริง - เมานต์ไฟล์ซิสเต็มชั่วคราวแบบอ่าน/เขียนทับบนไดเรกทอรีแบบอ่านอย่างเดียว คัดลอก CA เดิมมา แล้วเพิ่มใบรับรองใหม่
- ปรับให้ไดเรกทอรี
- เพื่อให้ระบบยอมรับใบรับรอง ยังต้องตั้งค่าอย่างชื่อไฟล์ สิทธิ์ และ ป้ายกำกับ SELinux ให้ถูกต้องด้วย
- HTTP Toolkit ทำขั้นตอนแบบเมานต์ชั่วคราวนี้ให้เป็นอัตโนมัติ และเคยให้การตั้งค่าการดักจับแบบคลิกเดียวบนอุปกรณ์ Android ที่รูตแล้วหรืออีมูเลเตอร์
- แนวทางนี้ทำงานได้กับอุปกรณ์รูตแบบคัสตอม ดิสทริบิวชัน Android เฉพาะทาง และอิมเมจอีมูเลเตอร์ทางการของ Google ส่วนใหญ่
- ข้อยกเว้นคืออิมเมจรุ่น full “Google Play” ที่ล็อกไว้เหมือนอุปกรณ์ OEM ทั่วไป
- เอกสารการตั้งค่า mitmproxy บล็อกโพสต์หลายแห่ง คำตอบบน StackOverflow โพสต์ในฟอรัม แพ็กเกจ Magisk และคำแนะนำของ cacert.org ก็ใช้แนวทางคล้ายกัน
โครงสร้างอัปเดต CA แบบใหม่ของ Android 14
- Android 14 ณ เวลาที่เขียนอยู่ในช่วงเบตาสุดท้ายและมีกำหนดออกในอีกไม่กี่สัปดาห์
- หนึ่งในฟีเจอร์ความปลอดภัยหลักคือ ใบรับรอง CA ที่อัปเดตจากระยะไกลได้
- การจัดการใบรับรอง CA ถูกแยกออกจากอิมเมจ OS หลัก และย้ายไปเป็นคอมโพเนนต์แยกที่แจกจ่ายและอัปเดตผ่าน Google Play
- ด้วยโครงสร้างนี้ Google จะเพิกถอนความเชื่อถือจาก CA ที่มีปัญหาได้เร็วขึ้น
- ไม่ต้องรอให้ผู้ผลิตโทรศัพท์แต่ละรายปล่อยอัปเดต OTA ของทั้งระบบก่อน
- เพียง Google Play System Update ก็เปลี่ยนรายการ CA บนอุปกรณ์ Android 14+ ได้
- CA ที่เชื่อถือโดยค่าเริ่มต้นมีอำนาจสูง จึงจำเป็นต้องมีการกำกับดูแลและบทลงโทษ และหาก CA ใดล้มเหลวก็ต้องถูกถอดอำนาจอย่างรวดเร็ว
- ตัวอย่างเช่นในเดือนมกราคม 2023 TrustCor สูญเสียความเชื่อถือในฐานะ CA จากผู้เล่นหลักรวมถึง Google หลังมีการพบความเชื่อมโยงใกล้ชิดกับองค์กรกระจายมัลแวร์และผู้รับเหมาด้านกลาโหมและข่าวกรองของสหรัฐฯ
- ในทางกลับกัน หากการกระจาย CA ใหม่ล่าช้าก็เกิดปัญหาได้เช่นกัน
- Let’s Encrypt เคยต้องเลื่อนการปล่อยการปรับปรุง certificate chain หลายครั้ง เพราะอุปกรณ์ Android รุ่นเก่าไม่มี root CA รุ่นใหม่ล่าสุด
- โครงสร้างที่เพิ่มความไวในการอัปเดต CA มีคุณค่าในตัวเอง แต่การใช้งานใน Android 14 กลับทำให้การแก้ไข CA ของระบบแทบเป็นไปไม่ได้
ตำแหน่งไฟล์จริงและการทำงานของ APEX
- การเปลี่ยนแปลงสำคัญของ Android 14 คือหากมี
/apex/com.android.conscrypt/cacertsอยู่ ระบบจะอ่านใบรับรองจากตรงนั้นแทน/system/etc/security/cacerts /apexคือพาธที่ใช้เมานต์ Android Pony EXpress หรือ คอนเทนเนอร์ APEX- โมดูล APEX คือคอมโพเนนต์ระบบที่อัปเดตได้อย่างอิสระ และถูกแจกจ่ายเป็นคอนเทนเนอร์แบบไม่เปลี่ยนแปลงที่มีการลงนาม
- ใบรับรอง CA ของ Android 14 จึงกลายเป็นส่วนหนึ่งของโมดูล
com.android.conscryptซึ่งเป็นไลบรารี TLS/SSL หลักของ Android - รายละเอียดการทำงานระดับล่างของ APEX มีเอกสารไม่เพียงพอ และลิงก์รายละเอียดสำคัญบางส่วนก็มีเฉพาะในเว็บไซต์ภายในของ Google เท่านั้น
- จากการทดสอบ ดูเหมือนว่าเนื้อหาของโมดูล APEX จะถูกเปิดให้แต่ละโปรเซสเห็นโดยตรง ทำให้แม้จะแก้ไขไฟล์จากตำแหน่งอื่น ก็ไม่สะท้อนต่อสิ่งที่แอปมองเห็น
สิ่งที่พบในอีมูเลเตอร์ Android 14
- อิมเมจ AOSP และ “Play Services” ของอีมูเลเตอร์ทางการ Android 14 รุ่นเบตา สามารถเข้าถึงรูตได้
- ส่วนอิมเมจ “Google Play” จะถูกล็อกไว้เหมือนอุปกรณ์ OEM ทั่วไป
- สามารถสร้างอีมูเลเตอร์ด้วยอิมเมจ API 34 “Google APIs” และเปิด root shell ได้
- แต่เมื่อใช้วิธีเมานต์ชั่วคราวแบบเดิมครอบพาธต่อไปนี้ด้วย tmpfs ก็ไม่เกิดผลตามที่คาด
/system/etc/security/cacerts/system/etc/security/cacerts_google/apex/com.android.conscrypt/cacerts/apex/com.android.conscrypt@340818022/cacerts
- ใน Settings → Security & Privacy → More → Encryption → Trusted Credentials แท็บ “System” ยังคงแสดงใบรับรองที่คิดว่าซ่อนไว้ทั้งหมด
- ตัวอย่างเช่น หากค้นหาไฟล์ใบรับรอง “ACCV” ชื่อ
3c9a4d3b.0ทั่วทั้งไฟล์ซิสเต็ม ระหว่างที่ถูกเมานต์ทับอยู่จะหาไม่เจอ แต่ใน Settings กลับยังแสดงอยู่ - เมื่อทำขั้นตอนเดียวกันบนอิมเมจ Android 13 รายการใบรับรองใน Settings จะว่างเปล่า แสดงว่าวิธีเดิมยังทำงานตามคาด
แม้แก้อิมเมจระบบโดยตรงก็ยังไม่สำเร็จ
- สามารถเปิดอีมูเลเตอร์ Android 14 ด้วย
-writable-systemแล้วใช้adb root,adb remount,avbctl disable-verificationและรีบูต เพื่อทำให้ระบบเขียนได้ - หลังจากนั้นสามารถลบใบรับรองใน
/system/etc/security/cacerts/*,/system/etc/security/cacerts_google/*ได้ - แต่ไม่สามารถลบใบรับรองใน
/apexได้- แม้ remount แล้วก็ยังเป็นแบบอ่านอย่างเดียว
- คำสั่ง
mount -o remount,rw ...ก็ล้มเหลว
- สิ่งที่ทำได้ใกล้เคียงที่สุดคือ
umountพาธใบรับรองนั้นจนไม่ปรากฏในผลลัพธ์ของmount - แต่ถึงอย่างนั้น รายการ “Trusted” ใน Settings ก็ยังคงโหลดใบรับรอง CA อยู่ต่อไป
- ผู้เขียนมองว่าไม่ใช่ปัญหาแคชของแอป Settings เพราะในมุมมองของคลังใบรับรองที่แอปต่าง ๆ ใช้ก็เกิดอาการเดียวกัน
- ไม่ว่าไฟล์ซิสเต็มจะถูกแก้อย่างไร แอปก็ยังคงเห็นรายการ Google CA ต่อไป
ผลกระทบและข้อจำกัด
- บน Android 14 เวิร์กโฟลว์เดิมที่ติดตั้งใบรับรอง CA ของระบบเพื่อใช้กับงานดีบัก วิศวกรรมย้อนกลับ การทดสอบ และการวิจัย ใช้งานไม่ได้แล้ว
- ณ เวลาที่เขียน ทางเลือกคือคง Android 13 ไว้ หรือใช้ระบบปฏิบัติการคัสตอมที่ไม่ใช้โมดูล APEX สำหรับการจัดการใบรับรอง CA
- แต่เมื่อเวลาผ่านไป ทางเลือกเหล่านี้อาจใช้งานจริงได้น้อยลง เพราะต้องแยกจากคอมโพเนนต์ภายในหลักของ Android mainline หรือไม่ก็ต้องใช้ซอฟต์แวร์เก่าต่อไป
- หากเนื้อหาภายในโมดูล APEX แก้ไขไม่ได้แม้ด้วยสิทธิ์รูต ก็อาจหมายความว่าในอนาคต ทุกคอมโพเนนต์ระบบที่ถูกย้ายเข้า APEX จะทำให้ผู้ใช้ควบคุมได้น้อยลงเรื่อย ๆ
- เรื่องนี้อาจกระทบ Android fork อย่าง GrapheneOS, LineageOS รวมถึง Magisk และโมดูลต่าง ๆ ด้วย
- อย่างไรก็ตาม ตามอัปเดตด้านบน ระบุว่าภายหลังมีการอภิปรายและการวิจัยวิธีเลี่ยง ทำให้มีหลายแนวทางที่สามารถฉีดใบรับรองบน Android 14 ได้
- หากต้องการดีบักทราฟฟิก HTTPS บน Android 14 ก็ไม่อาจตั้งสมมติฐานได้อีกต่อไปว่าจะใช้เพียง การฉีดระบบ CA แบบอาศัยรูต แบบเดิมได้เสมอ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
จากมุมมองของคนที่เคยทำงานกับเครื่องมือรูท Android สมัยก่อน, ROM คัสตอมอเนกประสงค์ยุคใหม่ และงานต่าง ๆ ที่เกี่ยวกับ Android OS มาหลายอย่าง ผมคิดว่าหัวข้อนี้ผิด ทั้งตอนนี้และต่อไปในอนาคต
คำว่า root ใน Android ก็คือ สิทธิ์ root จริง ๆ และทำอะไรก็ได้ตามต้องการ [1]
Magisk ซึ่งเป็นวิธีรูท Android ในปัจจุบัน มีความสามารถในการ “แก้ไข” ไปถึงโค้ด Java ด้วย ดังนั้นต่อให้ซ่อนอยู่ลึกแค่ไหนก็ควรเข้าถึงได้
การที่ผู้เขียนทำไม่ได้ไม่ได้แปลว่าเป็นไปไม่ได้ แต่อาจเป็นปัญหาว่า zygote แคช CA ไว้จนต้องรีสตาร์ตด้วย
stop;startหรืออาจต้องสลับไปยัง mount namespace ที่ถูกต้องก่อนรันคำสั่งGrapheneOS และ LineageOS มีสิทธิ์เข้าถึงซอร์สโค้ดทั้งหมด จึงเปลี่ยนได้ตามต้องการ ข้อจำกัดมีแค่ความน่ารำคาญในการตามสิ่งที่ Google ทำพังด้วยความเร็วสูงมากให้ทัน
เมื่อ Android เริ่มเป็นปฏิปักษ์กับผู้ใช้มากขึ้นเรื่อย ๆ โดยเฉพาะ power user ก็หวังว่าจะมีคนย้ายไปใช้ ROM คัสตอมมากขึ้น
ในฝัน ผมคงทำ fork ของ Android อย่าง “OwnerDroid” ที่บรรทัดแรกของโมเดลความปลอดภัยไม่ใช่ “ผู้ใช้คือศัตรู” แต่ตอนนี้ทำได้แค่อิฐก้อนเล็ก ๆ ไม่กี่ก้อน ส่วนโปรเจกต์เต็มต้องใช้แรงงานมหาศาล
[1] ยกเว้นการป้องกันบางอย่างในระดับเคอร์เนล แต่ GKI ช่วยลดความเสี่ยงนั้นได้
ตอนนี้ทำแบบนั้นไม่ได้แล้ว
แน่นอนว่าถ้ามีซอร์สโค้ดทั้งหมดก็ทำอะไรก็ได้ และจะ build อิมเมจระบบ Android ตั้งแต่ต้นโดยปิดโมดูลแบบนี้ก็ได้ รวมถึง GrapheneOS/LineageOS ก็รับมือได้เช่นกัน
แต่มันสร้างงานใหม่ขึ้นมาเยอะ และถ้าแยกจาก implementation ของ Android ในคอมโพเนนต์หลัก ก็อาจต้องบำรุงรักษามากขึ้นอีกในอนาคต
สำหรับผู้ใช้ส่วนใหญ่ที่ได้รับผลกระทบ การบอกว่า “ก่อนอื่นให้ build อิมเมจระบบเอง” นั้นเกินขอบเขตความสบายใจและเวลาที่พร้อมลงทุนไปมาก
ท้ายที่สุดคงมีทางแก้อื่นออกมา แต่ก็น่าจะเป็นแนวทางอย่างขุดเข้าไปใน namespace แล้วแก้ mount ของโปรเซสเป้าหมายทีละตัว, build และติดตั้งโมดูล APEX ของตัวเองในแบบที่ Android เชื่อถือเพื่อแทนที่โมดูลระบบ, หรือ hook แอปรายตัวด้วย Frida
ถึงอย่างนั้น นี่ก็ยังเป็น ปัญหาใหญ่ ที่ทำให้ผู้ใช้ควบคุมอุปกรณ์ของตัวเองได้เต็มที่ยากขึ้น
ส่วนสำคัญอย่างการตรวจจับ root ของแอปธนาคารที่จำเป็น หรือฟีเจอร์ที่เกี่ยวกับ Google มักไม่มีเอกสาร และแทบเป็นไปไม่ได้ที่จะหาข้อมูลว่าชุดผสม “รุ่นมือถือ + แอปธนาคารท้องถิ่น + ROM คัสตอม” ผ่านการทดสอบและใช้งานได้ดีจริง
ผมเห็นด้วยกับเสรีภาพและทางเลือก แต่สำหรับผู้ใช้มือถือทั่วไป ถ้าไม่ยอมใช้มือถือหลายเครื่องและเวลาทำงานหลายวัน หรือไม่ได้เป็นผู้เชี่ยวชาญตั้งแต่แรก ก็ยากจะเรียกว่าเป็นแนวทางที่ทำได้จริง
ผมเป็น power user บนคอมพิวเตอร์ แต่คิดว่ามือถือจะโง่กว่านี้หน่อยก็ไม่เป็นไร
อย่างไรก็ตาม ถ้าต้องใช้มือถือเป็น อุปกรณ์ยืนยันตัวตนหลายปัจจัย มากขึ้นเรื่อย ๆ หรือถูกผูกไว้กับอารมณ์ของบริษัทที่มีอำนาจต่อรองสูงกว่าอย่างธนาคาร ก็ยากที่จะเป็นแบบนั้นได้
ผมไม่คิดจะเปลี่ยนบัญชีธนาคารสามครั้งเพื่อหาแอปที่ทำงานบนมือถือที่รูทแล้วได้
ถ้าจะถามว่า “fork ของ Android เป็นคู่แข่งตรงไหน” ก็แปลว่ากลยุทธ์นั้นได้ผลแล้ว
ถ้าวิธีใหม่คือเมื่อมี
/apex/com.android.conscrypt/cacertsก็อ่านใบรับรองจากตรงนั้น ก็น่าจะซ่อน/apex/com.android.conscrypt/cacertsเฉพาะในโปรเซสที่ต้องการได้ เหมือนการเลี่ยง SafetyNet, การซ่อน root หรือการซ่อน Magisk ในปัจจุบัน เพื่อให้ fallback กลับไปใช้วิธีเดิมมันเป็นพื้นที่ของแฮกเกอร์ และแม้แต่ในกลุ่มนั้นก็มีแค่ส่วนน้อยมากที่ใช้
ที่นี่มีคอมเมนต์ดี ๆ เยอะ แต่ผมยังคิดอยู่เรื่อย ๆ ว่าโชคดีแค่ไหนที่ PC ไม่ทำงานเหมือนสมาร์ตโฟน
Android ทำตัวเองพังอย่าง彻底เสียจนผมรู้สึกแปลกที่ตัวเองพูดว่ารู้สึกขอบคุณที่ Microsoft ไม่ได้บริหารโลก PC แบบที่ Google บริหารโลกสมาร์ตโฟน
Windows เองเมื่อเทียบกับ Android แล้วแทบจะเป็นป้อมปราการของความเสถียรและสามัญสำนึก และเราไม่จำเป็นต้องถูกบังคับให้อัปเกรดจนกว่าฮาร์ดแวร์จะเสียตามอายุการใช้งานจริง ๆ
Microsoft ก็ไม่ได้ควบคุมทั้ง pipeline ฮาร์ดแวร์-ซอฟต์แวร์เหมือน Google แต่ก็มีพลังที่จะทำให้การเป็นเจ้าของ PC ลำบากสุด ๆ ได้ เช่น บังคับบรรทัดฐานผ่าน Store หรือกดไม่ให้แก้สภาพแวดล้อมด้วยวิธีแบบ SafetyNet
ผมจำได้เลือน ๆ ว่า Microsoft เคยถูก ฟ้องคดีผูกขาด จากเรื่องทำนองนี้มาก่อน เลยสงสัยว่าเมื่อไหร่เรื่องเดียวกันจะมาถึง Google
Microsoft ก็เพิ่ม DRM จำนวนมากเข้าไปใน Windows แล้วภายหลังก็ทำบางอย่างพังเองด้วย และ remote attestation ก็ฝังอยู่ใน OS เช่นกัน
Google เปลี่ยน implementation ภายในของ Android ที่เดิมไม่ควรถูกพึ่งพาอยู่แล้ว ทำให้นักพัฒนาเดือดร้อน ซึ่ง Microsoft ก็ทำเรื่องแบบนี้อยู่เสมอ
มีโอกาสสูงว่าแค่รอ Magisk module ที่อัปเดตแล้วสักไม่กี่สัปดาห์ก็พอ และพูดตรง ๆ มันก็ไม่ได้แย่ขนาดนั้น
แค่ไม่กดปุ่มอัปเดตบนอุปกรณ์ 5–6 เครื่องที่จะได้ Android 14 จนกว่าจะถึงตอนนั้นก็พอ
Windows 11 ต้องการ TPM และ Secure Boot
เคยได้ยินว่าบางประเทศกำลังพัฒนาบังคับให้ติดตั้ง CA ของรัฐเพื่อทำ man-in-the-middle กับทุกการเชื่อมต่อ ถ้าทำให้เรื่องนี้ยากมาก ๆ ก็จะทำให้การบังคับผู้ใช้ปิดความเป็นส่วนตัวของตัวเองเกิดขึ้นจริงได้ยากขึ้น
ใช้ PinePhone Pro เป็นเครื่องหลักประจำวันอยู่
Chase.com พยายามอย่างดื้อด้านมากที่จะบล็อกเบราว์เซอร์ที่ไม่ใช่มาตรฐานอย่าง Librewolf รวมถึงเบราว์เซอร์บนโทรศัพท์/แท็บเล็ต และพยายามบังคับให้ใช้แอปมือถือ
อย่างน้อยจนกว่า WEI จะถูกบังคับใช้ มาตรการโง่ ๆ แบบนี้ยังเลี่ยงได้ง่ายจึงไม่ใช่ปัญหาร้ายแรงนัก แต่เพราะ Chase เป็นธนาคาร เลยสงสัยว่ามีช่องทางให้โต้แย้งทางกฎหมายได้หรือไม่
เดาแรก ๆ คือเรื่องการปฏิบัติตาม ADA แต่ก็ไม่แน่ใจ
ตอนนี้เหนื่อยมากจนไม่แน่ใจแล้วว่าการบอกว่าอยากฟ้องเรื่องนี้เป็นแค่คำพูดลอย ๆ หรือเปล่า
ถึงจะเป็นประเด็นข้างเคียง แต่ก็เกี่ยวข้อง เพราะมันแสดงให้เห็นอีกด้านหนึ่งว่าการหลุดพ้นจาก ระบบกึ่งผูกขาดของ OS มือถือ แทบเป็นไปไม่ได้
ต่อให้ตลาดเฉพาะของโทรศัพท์ Linux เติบโตได้อย่างปาฏิหาริย์ไปถึงไม่กี่เปอร์เซ็นต์ Android ก็มีแนวโน้มจะแย่ลงต่อไป และเราต้องมีอะไรสักอย่าง
รู้สึกว่ายุคของ ศักดินาดิจิทัล กำลังจะมาถึง
เราจะต้องใช้อุปกรณ์ที่บริษัท “ผู้มีเมตตา” บางแห่งจัดให้ และบริษัทนั้นเป็นเจ้าของทุกแง่มุมของอุปกรณ์ โดยต้องจ่ายเงินถึงจะใช้งานได้ราวกับการขับรถ
เส้นทางอื่น ๆ ส่วนใหญ่จะถูกล็อกไว้ คอมพิวติ้งเอนกประสงค์จะเหลืออยู่แค่สำหรับ “องค์กร” และแม้จะยังมี “เว็บเสรี” อยู่ แต่มันจะค่อนข้างเป็นเรื่องทางเทคนิคและไม่เป็นมิตรกับผู้ใช้
ตลาดส่วนใหญ่ โดยเฉพาะทุกที่ที่เกี่ยวข้องกับเงิน จะหลีกเลี่ยงมันเหมือนโรคระบาด
ผมมองว่า Google ฆ่า เว็บเปิด ด้วยสิ่งนี้ไปแล้ว
ถึงอย่างไรมันก็เริ่มน่าเบื่ออยู่บ้างแล้ว แต่การที่ตอนนี้การใช้ชีวิตโดยไม่มีโทรศัพท์หรือเบราว์เซอร์ที่ “ได้รับอนุมัติ” ยากขึ้นมากนั้นน่าหงุดหงิด
การที่ผู้ใช้เชี่ยวชาญรู้วิธีติดตั้งซอฟต์แวร์เพิ่มเพื่อแก้ปัญหาได้นั้นก็ดี แต่จะดีกว่าถ้า Chase แก้เว็บไซต์พื้นฐานของตัวเอง เพื่อให้ผู้ใช้มือใหม่ที่มีความต้องการคล้ายกันได้รับความช่วยเหลือด้วย
ในประเด็นนี้ ผมมองว่า Android เคยและยังคงบีบบังคับมากกว่า Apple
แม้ในช่วงที่ยังติดตั้งและเชื่อถือ root CA ใหม่ได้ แอปบางตัวก็สามารถเพิกเฉยต่อมันได้ และก็ทำเช่นนั้นจริง
ทั้ง iOS และ Android ต่างก็ให้แอปใช้ certificate pinning ได้ แต่ตั้งแต่ Android 7+ ในปี 2016 เป็นต้นมา โดยค่าเริ่มต้นแอปจะเพิกเฉยต่อ CA ที่ผู้ใช้เพิ่มเอง[1]
บน iOS ขั้นตอนการเชื่อถือ root CA นั้นยุ่งยาก ต้องติดตั้งโปรไฟล์และเจอคำเตือนน่ากลัว ซึ่งในตัวมันเองก็สมเหตุสมผล แต่จากประสบการณ์ แอปส่วนใหญ่จะเชื่อถือมัน เว้นแต่จะใช้ certificate pinning
[1]: https://android-developers.googleblog.com/2016/07/changes-to...
Android ซึ่งใกล้เคียงกับคอมพิวเตอร์ทั่วไปมากกว่า iOS มีปัญหา stalkerware ใหญ่มาก
stalkerware ไม่ได้ถูกหยุดด้วย prompt, ใช้ความเข้ากันได้ย้อนหลังเป็นอาวุธ และเกี่ยวข้องกับการล่วงละเมิดทุกรูปแบบ
บน iOS มันง่ายอย่างน่าตกใจที่จะให้ใครสักคนยืมโทรศัพท์ 5 นาที แล้วความเป็นส่วนตัว HTTPS ถูกพลิกคว่ำไปเป็นเวลาหลายปี
ผมอยากได้ตัวเลือกที่จะเชื่อถือใบรับรอง CA ที่ติดตั้งไว้จริง ๆ แต่ก็หงุดหงิดที่แม้แต่ Firefox ซึ่งเป็นเว็บเบราว์เซอร์ ก็ยังไม่ใช้ใบรับรองผู้ใช้หากไม่มีการตั้งค่าและชุดแท็บที่ซ่อนอยู่
ถึงอย่างนั้น เมื่อคิดถึงความเสี่ยงที่จะเกิดกับผู้ใช้ Android ทั่วโลก ก็ยากจะบอกว่าฟีเจอร์นี้สำคัญขนาดนั้นสำหรับช่างเทคนิคไม่กี่สิบคนที่ใช้มันเป็นประจำ
กรณีนี้ดูเหมือนเป็นผลข้างเคียงจากการปรับปรุง sandboxing ที่ดีของ Google และกลไกอัปเดต CA store ที่ล่าช้ามานาน มากกว่าจะเป็นแผนชั่วร้ายของ Google เพื่อขัดขวางแผนของแผนก IT ท้องถิ่น
โมดูล Magisk น่าจะออกมาเป็นทางเลี่ยงในเร็ว ๆ นี้ และโมดูลเดิม ๆ อาจพังไปสักพัก แต่หลังการอัปเดต Android รุ่นใหญ่ก็เป็นเรื่องปกติ
ถ้าจำเป็นก็เขียนโมดูลเองได้
ผมว่าอันนี้ก็แค่เป็นวิธีที่ mount ทำงานไม่ใช่หรือ
ถ้ามีบางอย่างถูก mount อยู่ที่
/apex/whateverและแต่ละแอปมี mount namespace แยกกัน การ mount ทับ/apex/whateverอีกครั้งใน namespace ของตัวเองก็จะไม่ทำให้อะไรเปลี่ยนใน namespace อื่นต้องแก้ไฟล์ซิสเต็มโดยตรง หรือเข้าไปใน mount namespace ของแอปอื่นแล้ว mount tmpfs ที่นั่นด้วย
shared mount อาจช่วยได้ แต่ไม่แน่ใจ และต้องดูรายละเอียดมากกว่านี้ว่าเกิดอะไรขึ้นจริง ๆ
ผมมองว่าผลลัพธ์นี้น่าจะเป็นผลพลอยได้จากงานด้าน namespace/containerization ของ Google มากกว่าความพยายามโดยเจตนาที่จะไม่ให้ผู้ใช้เปลี่ยน root CA ได้แม้มีสิทธิ์ root
แต่ผลลัพธ์สุดท้ายก็ยังเป็นปัญหาใหญ่
ส่วนที่น่าประหลาดใจตรงนี้คือ “mount namespace แยกกัน”
เมื่อก่อน ถ้าเปิดเชลล์แล้ว mount ลงไฟล์ซิสเต็มหรือแก้ไขโดยตรง แอปก็อ่านไฟล์จาก mount นั้นได้ดี
แต่ตอนนี้ไฟล์ cacert เหล่านี้ไม่เป็นเช่นนั้น และในวิธีใหม่ก็แก้ไขโดยตรงไม่ได้ด้วย
ก่อนการเปลี่ยนแปลงนี้ ผมไม่รู้ด้วยซ้ำว่าแอป Android ใช้ mount namespace ของตัวเอง
แทบไม่มีเอกสารอธิบายว่ามันทำงานอย่างไรกันแน่ และก็ไม่แน่ใจว่าจนถึงตอนนี้เคยมีกรณีที่เผยให้เห็นชัดเจนแบบนี้หรือไม่
ดู manifest v3 ก็พอ
ผมตอบผู้เขียนไว้ใน Twitter แล้ว แต่อาจไม่ได้เห็น เลยมาทิ้งไว้ตรงนี้ด้วย
ผมเป็นคนที่เขียนบล็อกโพสต์เกี่ยวกับใบรับรองที่อัปเดตได้ของ Android 14 ซึ่งบทความนี้ลิงก์ถึงอยู่
จริง ๆ แล้วมี system property ที่ตั้งค่าให้ข้ามการอ่านจากไดเรกทอรีใบรับรอง APEX ได้
system.certs.enabled=trueที่มา: https://android-review.googlesource.com/c/platform/framework...
อันนั้นเป็นพร็อพเพอร์ตี
java.lang.Systemหรือพูดอีกอย่างคือค่าคอนฟิกที่ตั้งภายใน JVM/แอปหนึ่ง ๆ ไม่ใช่พร็อพเพอร์ตีของ OS อย่างandroid.os.SystemPropertiesที่ตั้งค่าได้ทั่วทั้งอุปกรณ์ด้วยadbเท่าที่ผมดู ถ้าจะตั้งค่าอย่างแรกใหม่ก็คงต้องแก้ตัวแอปเอง
มันมีประโยชน์สำหรับการทดสอบอัตโนมัติ หรือการสลับค่าระหว่างบิลด์ debug/prod แต่ถ้าอยากให้อุปกรณ์ทั้งเครื่องเชื่อถือใบรับรอง CA ก็ไม่ค่อยช่วยอะไร
แน่นอน ถ้าคุณรู้วิธีตั้งพร็อพเพอร์ตีแบบนั้นจากภายนอกให้มีผลกับทุกแอปได้ มันคงทำงานได้ดีมาก ผมอยากฟังจริง ๆ
อ้อ ผมเป็นผู้เขียนเอง และใน Twitter ผมไม่เห็นข้อความตอบกลับแบบนั้น
สมกับเป็น Twitter ปี 2023 จริง ๆ
ดูเหมือนจะดีต่อความปลอดภัย และคงเป็นนรกสำหรับนักพัฒนาบางคน แต่ก็สงสัยว่าอีก 2–3 ปีข้างหน้าเมื่อ Android เวอร์ชันนี้ถูกทิ้งไปแล้วจะเป็นอย่างไร
ต้องภาวนาให้ใบรับรองที่ฮาร์ดโค้ดไว้ยังใช้ต่อได้อีกสักหลายปีงั้นหรือ
Android 14 ทำให้ใบรับรองรากสามารถอัปเดตผ่าน Google Play ได้ และไม่จำเป็นต้องใช้ OTA update เพื่อเพิ่มหรือลบใบรับรองรากเหมือนเมื่อก่อน
ยังมีวิธีเลี่ยงที่เพิ่งรู้วันนี้ด้วย [0]
ถ้าใช้ Android 7.0 หรือต่ำกว่า อาจต้องดำเนินการบางอย่างเพื่อให้ยังเข้าถึงเว็บไซต์ที่ป้องกันด้วยใบรับรอง Let’s Encrypt ได้ และเขาแนะนำให้ติดตั้งและใช้ Firefox Mobile ซึ่งใช้ trust store ของตัวเองแทน trust store ของ Android OS
[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
[1] https://www.xda-developers.com/android-14-root-certificates-...
เพราะในการอัปเดตของ Google ไม่มีใบรับรองตัวกลางที่ Let’s Encrypt ใช้อยู่
นี่ไม่ใช่ปัญหาสมมติในอนาคต แต่เป็นปัญหาที่มีอยู่ตอนนี้เลย
ทำไม Google ถึงต้องเป็นผู้ตัดสินขั้นสุดท้ายว่าผมจะเชื่อถือใคร
Google เองก็มีช่องโหว่อย่างแน่นอน
และในบรรดาผู้ให้บริการใบรับรองที่ได้รับอนุมัติแล้ว ก็มีบางรายที่เคยออกใบรับรองให้กับบุคคลและองค์กรที่ไม่ควรได้รับ ซึ่งจริง ๆ แล้วไม่ควรไว้ใจ
โดยทั่วไปแอปไม่ยอมรับใบรับรองของผู้ใช้ และเมื่อ Google Cloud หรืออะไรสักอย่างที่เกี่ยวข้องเปลี่ยนไปใช้ใบรับรองที่ใหม่กว่า แอปบางตัวก็เริ่มหยุดทำงาน
กล่าวคือมันถูกอัปเดตแบบ out-of-band ผ่าน Play Services และไม่ต้องพึ่งการอัปเดต OS จาก OEM
ทุกครั้งที่ Android ออกรีลีสใหม่ ก็เห็นว่ามีอะไรบางอย่างถูกเอาออก และมีสิ่งที่แทบไม่มีความหมายเพิ่มเข้ามา
iOS ดูเหมือนจะเดินไปในทิศตรงข้าม ดังนั้นค่อย ๆ มาบรรจบกันตรงกลาง และภายหลัง iOS อาจแซง Android ได้ทุกด้านก็เป็นได้
อยากฟังความเห็นตรง ๆ จากฝั่งคนใช้ Apple
ช่วงนี้ผมใช้ macOS อยู่ และไม่ชอบเพราะมันพลาดในประสบการณ์ผู้ใช้พื้นฐานมาก ๆ ที่ใน Windows/Linux ถือเป็นเรื่องปกติมาตั้งหลายสิบปีแล้ว
อย่าง Finder นี่แย่จริง ๆ
ถ้ารุ่นหน้าผมซื้อ iPhone แทน Android ผมจะมีปฏิกิริยาเชิงลบแบบเดียวกันกับ iOS ไหม
ใน use case ของสมาร์ตโฟน ถือได้ไหมว่า iOS เป็น ประสบการณ์ผู้ใช้ ที่สมบูรณ์และมีประโยชน์กว่า macOS
ผมอยากย้ายอยู่เหมือนกัน แต่ไม่อยากเสียทั้งเวลาและเงินเปล่า
Android ในอดีตเคยเป็นมากกว่าแค่ iOS ที่มี
.apkเท่านั้น น่าเสียดายจริง ๆสำหรับการใช้งานแบบนั้นก็โอเค
แต่ผู้ใช้ถูกจำกัดมากเกินไป จนอาจลองดูเรื่อง jailbreak ได้ แต่ผมพยายามใช้โทรศัพท์ให้น้อยที่สุด และทำเกือบทุกอย่างบนเดสก์ท็อป
เผื่อเป็นข้อมูล ผมเองก็กำลังทิ้ง macOS แล้วย้ายไป Linux อยู่เหมือนกัน
ใช้ PKI ส่วนตัวเพื่อเชื่อมต่อซอฟต์แวร์ที่โฮสต์เอง
เช่น เซิร์ฟเวอร์อีเมล ผู้ให้บริการปฏิทิน เซิร์ฟเวอร์โน้ต เครื่องมือซิงก์รูปภาพ และอื่น ๆ
ควรต้องเพิ่มใบรับรองรากของตัวเองเข้าไปในรายการผู้ออกใบรับรองได้
ไม่ได้อยากเปลี่ยนรายการที่ระบบให้มา แค่อยากเพิ่มใบรับรองของตัวเองเท่านั้น
มองว่าเป็นอุปกรณ์ของฉันเอง ถ้าอยากเปลี่ยนอะไรก็ควรทำได้
แอปอีเมลและปฏิทินก็น่าจะรวมอยู่ในกลุ่มนี้ด้วย
สิ่งที่มีแนวโน้มสูงว่าจะทำไม่ได้ คือการติดตั้ง CA ของตัวเองเพื่อดักทราฟฟิกระหว่างแอปกับเซิร์ฟเวอร์ของผู้พัฒนาแอป
เรื่องนั้นน่าเสียดาย เพราะผู้ใช้ควรตรวจสอบได้ว่าอุปกรณ์ของตัวเองกำลังทำอะไรอยู่ แต่กรณีใช้งาน PKI ส่วนตัวกับซอฟต์แวร์ที่โฮสต์เองนั้นรองรับแน่นอน
น่าจะต้องมีวิธีอะไรสักอย่าง
getlocalcert กำลังทำเครื่องมือสำหรับเรื่องนี้อยู่ [1]
เพราะเลี่ยงความจำเป็นในการเพิ่ม trust root ได้ ในบางเครือข่าย แนวทาง “ใบรับรองสาธารณะบนเครือข่ายส่วนตัว” จึงให้ประโยชน์โดยรวมมากกว่า
พูดตามตรง ไม่คิดว่า Android จะปิดกั้น CA ส่วนตัว แต่สุดท้ายก็เป็นแบบนี้
[1] https://www.getlocalcert.net/
ตอนนี้ไม่ได้ใช้โทรศัพท์ Android แต่จำได้ว่าเมื่อก่อนสามารถเพิ่มใบรับรอง CA ของตัวเองลงในโทรศัพท์ Android ได้จากตัวเลือกใน Settings โดยไม่ต้องมีสิทธิ์ root และอย่างน้อยแอปอย่างเว็บเบราว์เซอร์ก็เชื่อถือใบรับรองนั้น
ก็ไม่ใช่เรื่องนานมากแล้วด้วย
เลยไม่เข้าใจว่าทำไมการติดตั้งใบรับรองแบบกำหนดเองถึงต้อง root เครื่อง หรือเป็นเพราะใช้เพื่อวัตถุประสงค์อื่นกันแน่
HTTP Toolkit มีประโยชน์มากในการดึง API ที่ซ่อนอยู่จากแอปชาร์จรถยนต์ไฟฟ้าห่วย ๆ ของ Turkey
ใช้ Frida ร่วมด้วยเพื่อหลบ SSL pinning และการตรวจจับ root
แล้วก็เริ่มตระหนักว่าเหตุผลที่พวกเขาพยายามซ่อน API อาจเป็นเพราะ API เหล่านั้นมันเป็นของประหลาดสุด ๆ ก็ได้ /s