ความเป็นไปได้ที่ทราฟฟิก DNS จะรั่วออกนอก VPN tunnel บน Android

 (mullvad.net)
2 คะแนน โดย GN⁺ 2024-05-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในบางชุดค่าผสมของแอปและสถานะบน Android DNS query อาจออกไปนอก VPN tunnel ได้ และ Mullvad มองว่าสาเหตุคือบั๊กของ Android OS มากกว่าตัวแอป VPN
  • การรั่วอาจเกิดขึ้นได้ในช่วงเปลี่ยนผ่านสั้น ๆ เช่นตอนที่เปิด VPN อยู่แต่ เซิร์ฟเวอร์ DNS ยังว่างเปล่า, ระหว่างการ reconfigure tunnel, หรือเมื่อแอป VPN ถูกบังคับปิดหรือ crash
  • ผลกระทบดูจะกระจุกอยู่กับแอปที่เรียก getaddrinfo โดยตรง ส่วนแอปที่ใช้เฉพาะ Android API อย่าง DnsResolver ไม่พบการรั่ว
  • แม้จะเปิด Always-on VPN และ “Block connections without VPN” ก็ยังป้องกันปัญหานี้ได้ไม่หมด และมีการยืนยันในหลายเวอร์ชันรวมถึง Android 14
  • Mullvad จะบรรเทาบางกรณีชั่วคราวด้วยการตั้งค่าเซิร์ฟเวอร์ DNS ปลอม แต่การรั่วระหว่าง reconnect ยังยากจะปิดกั้นได้ทั้งหมดหากไม่มีการแก้ไขที่ระดับ OS

เงื่อนไขที่ทำให้เกิด DNS leak บน Android

  • Mullvad ยืนยันจากรายงานของผู้ใช้ Reddit เมื่อวันที่ 22 เมษายนว่า เมื่อเปิด “Block connections without VPN” ไว้ การปิดแล้วเปิด VPN ใหม่อาจทำให้เกิด DNS leak ได้
  • จากการตรวจสอบภายใน พบสถานการณ์เพิ่มเติมที่ Android OS อาจส่งทราฟฟิก DNS ออกนอก VPN
    • VPN ทำงานอยู่แต่ ยังไม่ได้กำหนดค่าเซิร์ฟเวอร์ DNS
    • ระหว่างที่แอป VPN กำลัง reconfigure tunnel
    • ช่วงเวลาสั้น ๆ ที่แอป VPN ถูกบังคับปิดหรือ crash
  • พฤติกรรมนี้ไม่ใช่สิ่งที่ Android OS ควรทำตามที่คาดหวังไว้ และต้องแก้ที่ระดับ OS ชั้นบน

แอปที่ได้รับผลกระทบและเส้นทางการ resolve ชื่อ

  • การรั่วดูจะเกิดในแอปที่เรียกใช้ C function getaddrinfo โดยตรงเพื่อ resolve ชื่อโดเมน
  • ไม่พบการรั่วในแอปที่ใช้เฉพาะ Android API DnsResolver
  • เบราว์เซอร์ Chrome เป็นตัวอย่างของแอปที่อาจใช้ getaddrinfo โดยตรง
  • การใช้ getaddrinfo เองไม่ใช่เรื่องผิด และหากต้องการปกป้องผู้ใช้ Android ทุกคน ก็จำเป็นต้องมี วิธีแก้ที่ระดับ OS

ข้อจำกัดของ Always-on VPN และการตั้งค่าบล็อก

  • การรั่วที่ยืนยันแล้วเกิดขึ้นได้ไม่ว่าจะเปิด Always-on VPN และ “Block connections without VPN” หรือไม่ก็ตาม
  • แม้เมื่อเปิด “Block connections without VPN” ทราฟฟิกที่ออกนอกอุปกรณ์ควรมีเพียงทราฟฟิก WireGuard ที่เข้ารหัสเท่านั้น แต่ในการทดสอบกลับสังเกตเห็น DNS แบบ plaintext ที่เราเตอร์
  • Mullvad ประเมินว่าการตั้งค่านี้ยังไม่เป็นไปตามชื่อหรือพฤติกรรมที่มีการอธิบายไว้ในเอกสาร และมีข้อบกพร่องหลายอย่าง
    • ทราฟฟิก DNS อาจรั่วได้ภายใต้เงื่อนไขข้างต้น
    • ทราฟฟิกตรวจสอบการเชื่อมต่อที่เคยรายงานก่อนหน้านี้ก็ยังคงรั่ว

การบรรเทาชั่วคราวในแอป Mullvad และปัญหาที่ยังเหลือ

  • ปัจจุบันแอป Mullvad จะไม่ตั้งค่าเซิร์ฟเวอร์ DNS ในสถานะบล็อก
    • หากการตั้งค่า tunnel ล้มเหลวในลักษณะที่กู้คืนไม่ได้ แอปจะเข้าสู่ สถานะบล็อก
    • ในสถานะนี้จะกันไม่ให้ทราฟฟิกออกนอกอุปกรณ์ แต่เมื่อไม่มีเซิร์ฟเวอร์ DNS ก็อาจเกิดเงื่อนไขที่ทำให้รั่วได้
  • เพื่อหลบเลี่ยงบั๊กของ OS ชั่วคราว Mullvad วางแผนจะตอบสนองด้วยการตั้งค่า เซิร์ฟเวอร์ DNS ปลอม ไปก่อน และคาดว่าจะออกรุ่นที่มีการแก้ไขนี้ในเร็ว ๆ นี้
  • การรั่วที่เกิดระหว่างการ reconnect tunnel บรรเทาจากฝั่งแอปได้ยากกว่า
    • Mullvad กำลังหาทางแก้
    • อาจลดจำนวนครั้งของการ reconfigure tunnel ได้ แต่ตอนนี้ยังไม่มองว่าสามารถป้องกันการรั่วนี้ได้อย่างสมบูรณ์
  • Mullvad ได้รายงานปัญหาและข้อเสนอเพื่อการปรับปรุงไปยัง Google

สิ่งที่สังเกตได้จากการทดสอบซ้ำด้วย WireGuard และ Chrome

  • กรณีที่สองซึ่งเป็นการรั่วระหว่างการเปลี่ยนการตั้งค่า VPN tunnel สามารถทดสอบซ้ำได้ด้วยแอป WireGuard และ Chrome
    • WireGuard ถูกใช้เป็นกรณีอ้างอิงของการทำ VPN บน Android
    • Mullvad มองว่ามีความเป็นไปได้ที่จะทดสอบซ้ำได้ในแอป VPN อื่นบน Android ด้วย
    • Chrome ถูกใช้เป็นตัวกระตุ้นการรั่ว เพราะเป็นแอปที่ยืนยันแล้วว่าใช้ getaddrinfo
  • ขั้นตอนการทดสอบซ้ำประกอบด้วยองค์ประกอบต่อไปนี้
    • ดาวน์โหลด spam_get_requests.html
    • ติดตั้งแอป WireGuard และ Chrome
    • import wg1.conf, wg2.conf เข้าไปใน WireGuard
    • เปิดใช้ tunnel wg1 ใน WireGuard และอนุญาตสิทธิ์ VPN
    • ในการตั้งค่า VPN ของ Android ให้เปิด Always-on VPN และ “Block connections without VPN” สำหรับ WireGuard
    • เริ่มจับแพ็กเก็ตที่เราเตอร์ด้วย tcpdump -i <INTERFACE> host <IP of android device>
    • เปิด WireGuard กับ Chrome แบบ split screen, รัน spam_get_requests.html ใน Chrome แล้วสลับระหว่าง wg1 และ wg2 ใน WireGuard
  • ที่เราเตอร์สามารถสังเกตเห็น A record query และการตอบกลับ NXDomain ที่มุ่งไปยังพอร์ต 53 ของเราเตอร์ OpenWrt จากอุปกรณ์ Android
  • DNS leak สามารถถูกใช้เพื่อระบุตำแหน่งโดยประมาณของผู้ใช้หรือเว็บไซต์และบริการที่เข้าใช้งานได้ จึงอาจมี ผลกระทบด้านความเป็นส่วนตัว สูง
  • ขึ้นอยู่กับ threat model การใช้งานที่อ่อนไหวอาจควรหลีกเลี่ยง Android หรือใช้มาตรการบรรเทาอื่นเพื่อป้องกันการรั่ว
  • ผู้ใช้แอป Mullvad ควรอัปเดตแอปให้เป็นเวอร์ชันล่าสุด เพราะอาจมีการบรรเทาบางส่วนรวมอยู่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-04
ความคิดเห็นจาก Hacker News

  • แม้จะไม่ได้ใช้ Mullvad แต่ก็ทำให้รู้สึกนับถือจริง ๆ ข้อมูลมีความหนาแน่นสูงและจัดเรียงอย่างดี ตั้งแต่ คำอธิบายปัญหา, วิธีเลี่ยงชั่วคราว, วิธีเลี่ยงที่คนอื่นอาจใช้ได้ ไปจนถึงส่วนที่ Android ควรแก้ไข

    • ผมเลือก Mullvad เป็นบริการ VPN ก็เพราะออก บล็อกโพสต์ แบบนี้ แทนที่จะทำสปอนเซอร์ YouTube ไม่รู้จบเหมือนคู่แข่ง
    • ต่อให้ไม่ได้ใช้ VPN, Mullvad ก็มี บริการ DNS ฟรีอยู่ ทราฟฟิก/ปริมาณการใช้งานที่เพิ่มขึ้นก็อาจถือเป็นการสนับสนุนรูปแบบหนึ่ง และน่าจะช่วยให้ผู้ใช้ Mullvad VPN ดูโดดเด่นน้อยลงเมื่อมองจากมุมของคำขอ DNS
      ข้อเสียคือในกรณีของผม เวลา ping สูงกว่า quad9 หรือ cloudflare ค่อนข้างมาก
      ผมเขียนวิธีบล็อกโฆษณาระดับ DNS และข้อมูลเกี่ยวกับ cloudflare ไว้ในเธรดนี้: https://news.ycombinator.com/item?id=40056162
    • เมื่อดูจากค่านิยม วิธีคิด ความซื่อสัตย์ต่อความเชื่อหลัก และหลักฐานความสม่ำเสมอที่รักษาคำขวัญมาตลอดหลายสิบปี ผมมองว่าเป็น VPN ที่ดีที่สุด
    • ในฐานะผู้ใช้ Mullvad ผมพอใจมาก ครั้งหนึ่งผมส่งเมลไปถามทีมซัพพอร์ตเรื่องการชำระเงิน และแนบ คำถามเกี่ยวกับ iptables เล็ก ๆ เกี่ยวกับปัญหาที่กำลังเจอไปด้วย
      พวกเขาแก้ปัญหาการชำระเงินได้รวดเร็ว และเรื่อง iptables ก็ได้รับคำตอบละเอียดพร้อมข้อดีข้อเสียของหลายวิธี พูดสั้น ๆ คือยอดเยี่ยม
    • ถ้าคุณใช้ VPN ก็สงสัยว่าใช้ตัวไหนอยู่

  • ผมเป็นนักพัฒนา rethinkdns
    สำหรับประโยคที่ว่า “ปัญหาเหล่านี้ต้องแก้ใน OS เพื่อปกป้องผู้ใช้ Android ทุกคน ไม่ว่าจะใช้แอปอะไร” นั้น ระบบเครือข่ายแบบหวาดระแวง ของ Android มีข้อยกเว้นให้แอประบบและแอปจาก OEM มาโดยตลอด นั่นรวมถึงแอปของ Google ด้วย
    การแก้บั๊กเหล่านี้ส่วนใหญ่ก็น่าจะไม่เปลี่ยนสมมติฐานหลักนั้น ดูโค้ดที่เกี่ยวข้องได้ที่: https://github.com/celzero/rethink-app/issues/224
    ส่วนประโยคที่ว่า “การรั่วไหลระหว่างการเชื่อมต่ออุโมงค์ใหม่บรรเทาในแอปได้ยากกว่า เรายังหาทางแก้กันอยู่” นั้น Android รองรับ การสลับแบบไร้รอยต่อ ระหว่างอุปกรณ์ TUN สองตัวระหว่างการกำหนดค่าใหม่ ทำให้ถูกต้องนั้นยุ่งยาก แต่ทำได้

    • ขนาดสิทธิ์อินเทอร์เน็ตของแอปไฟฉายยังปิดไม่ได้ เมื่อคิดว่า OS นี้ดำเนินการโดย บริษัทโฆษณาอินเทอร์เน็ต ก็สมเหตุสมผลอยู่

  • นี่เป็นปัญหาที่มีมานานแล้วบน Android ต่อให้คุณอยากบังคับให้ใช้เฉพาะเซิร์ฟเวอร์ DNS ภายใน Android ก็จะสลับไปใช้เซลลูลาร์แล้วใช้ DNS นั้น หากมันตัดสินว่าจำเป็นหรืออยากใช้
    เมื่อเร็ว ๆ นี้ผมเฝ้าดู adb debug เพื่อดูว่าการเชื่อมต่อไร้สายหลุดทำไม/เมื่อไร สุดท้ายถ้ามันไม่เห็นหรือแปลผลอะไรบางอย่างในกระบวนการตรวจสอบการมีชีวิตอยู่ มันก็จะเปิดข้อมูลเซลลูลาร์แล้วลอง
    มันน่าหงุดหงิดเป็นพิเศษเวลาใช้ DNS record ที่มีอยู่เฉพาะภายใน โทรศัพท์กลับทำงานตามอำเภอใจไม่ได้ ทั้งที่อุปกรณ์เชื่อมกับ Wi‑Fi ที่ให้เซิร์ฟเวอร์ DNS ภายในซึ่งมี record นั้นอยู่ แต่ด้วยเหตุผลบางอย่างของ Android กลับไป resolve จากภายนอก
    ไม่รู้ว่า Apple เป็นยังไง แต่จากที่โดยพื้นฐานแล้วพวกเขาพยายามพร็อกซีแม้กระทั่ง DNS ผ่าน DoH ด้วย “privacy” VPN ของตัวเอง ก็ยากจะจินตนาการได้ว่าจะดีกว่าเมื่อใช้สิ่งที่ถือเป็นผลิตภัณฑ์คู่แข่ง และเราก็รู้ว่า Apple ปฏิบัติต่อผลิตภัณฑ์แบบนั้นอย่างไร

    • ควรตรวจดูว่า “สลับไปใช้เซลลูลาร์แล้วใช้เมื่อจำเป็นหรืออยากใช้” นั้นเป็นเพราะเปิด Wi‑Fi Assist อยู่หรือเปล่า ฟีเจอร์นั้นถูกออกแบบมาอย่างชัดเจนให้สลับไปเซลลูลาร์เมื่อสัญญาณ Wi‑Fi แย่
    • Apple หรือ iOS มีวิธีในตัวที่ค่อนข้างแข็งแรงสำหรับกรองและบล็อกทราฟฟิกด้วย configuration profile ไม่แน่ใจว่าตั้งค่าแยกตามแอปได้หรือไม่ แต่ตั้งค่า รายการอนุญาต/รายการบล็อก ของ hostname ได้แน่นอน
      ตัวอย่างจริงดูได้จากตัวบล็อกโฆษณาทั้งระบบนี้: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • iOS ไม่ได้ใช้ Private Relay เป็นค่าเริ่มต้นเด็ดขาด ต่อให้รวมอยู่ใน subscription ก็ต้องเปิดเองอย่างชัดเจน
    • สงสัยว่าได้ลองปิด “ใช้ข้อมูลมือถือเสมอ” ใน Developer options แล้วหรือยัง
    • ผมเคยบิลด์ AOSP จากซอร์ส มันควรเป็นสิ่งที่ไม่มีข้อกำหนดเฉพาะของ Google และผมบล็อกเซิร์ฟเวอร์ Google ให้มากที่สุดเท่าที่ทำได้ในไฟล์ hosts เพื่อไม่ให้มันแอบติดต่อ Google
      ปัญหาเดียวที่ผมเจอคือ แม้อุปกรณ์จะเชื่อมต่อกับ AP ไร้สายที่ทำงานปกติ แต่มันกลับแสดงว่าไม่มีอินเทอร์เน็ต จริง ๆ แล้วใช้งานได้ แต่ดูเหมือนมันตรวจสอบว่าอินเทอร์เน็ตใช้งานได้หรือไม่ด้วยเซิร์ฟเวอร์ Google เพื่อจุดประสงค์ของไอคอนแถบสถานะและโค้ดระบบภายในอื่น ๆ
      ถ้าให้ความสำคัญกับความเป็นส่วนตัว ก็ควรอยู่ห่างจาก Android และอาจต้องระวังเทคโนโลยีโดยรวมด้วย

  • เมื่อหลายปีก่อนตอนทดสอบคอนฟิก VPN หลายแบบสำหรับโปรเจกต์ ผมมักวาง อุปกรณ์ไฟร์วอลล์ MikroTik ไว้ระหว่างคอมพิวเตอร์กับเราเตอร์หลัก จุดประสงค์มีแค่บล็อกทราฟฟิกทั้งหมดที่ปลายทางไม่ใช่ IP address ของเซิร์ฟเวอร์ VPN ที่ PC จะเชื่อมต่อไป
    วิธีนี้ทำงานได้ดีมากในการรับประกันว่าไม่มีทราฟฟิกรั่วออกนอกเส้นทางจาก PC ไปยังเซิร์ฟเวอร์ VPN ส่วน IP address ของเซิร์ฟเวอร์ VPN ที่ใช้ก็แทบไม่เปลี่ยน และถ้าเปลี่ยนก็แก้ในไฟร์วอลล์ MikroTik ได้ง่าย
    ถ้าไม่รู้ IP ของเซิร์ฟเวอร์หรือมันเปลี่ยนไป ก็มีวิธีบล็อกทราฟฟิกทั้งหมดที่ไม่ใช่คู่พอร์ต/โปรโตคอลที่เซิร์ฟเวอร์ VPN ใช้ เช่น ทิ้งทราฟฟิกที่ปลายทางไม่ใช่ UDP 1194 ตามชนิดของ VPN
    เราเตอร์ MikroTik ยังมีเครื่องมือเล็ก ๆ ชื่อ torch สำหรับดูทราฟฟิกได้อย่างรวดเร็วและง่ายดาย และรองรับการจับแพ็กเก็ตด้วย ราคามีตั้งแต่ 30 ดอลลาร์ถึง 3000 ดอลลาร์ ไม่มีไลเซนส์ซอฟต์แวร์ และถ้ารู้วิธีใช้ก็ทรงพลังและมีความสามารถมาก

    • อุปกรณ์ประเภทนี้เรียกว่า network slug และเป็นไอเดียที่ยอดเยี่ยมมาก
      ถ้าพูดอย่างเคร่งครัด slug ของจริงคือไฟร์วอลล์เลเยอร์ 2 แบบโปร่งใสที่ไม่มี IP address ถูกกำหนดไว้ แต่ในที่นี้ไม่จำเป็นต้องลงรายละเอียดนั้น
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • การกรองขาออก ตามที่อยู่ต้นทาง/ปลายทางและพอร์ต เป็นแนวคิดพื้นฐานของไฟร์วอลล์และเป็นการตั้งค่ามาตรฐานของทุกแพลตฟอร์มไฟร์วอลล์-เราเตอร์ การทำ policy-based routing ที่กรองตามเกตเวย์ก็อยู่ในบริบทเดียวกัน: https://en.wikipedia.org/wiki/Policy-based_routing
    โดยทั่วไปแล้ว มีแค่ผลิตภัณฑ์สำหรับผู้บริโภคหรือกึ่งมืออาชีพเท่านั้นที่ตั้งค่าเริ่มต้นให้อนุญาตทราฟฟิกขาออกทั้งหมด อยากรู้ว่าในคอนฟิกนี้ “เราเตอร์หลัก” คืออะไร เป็นอุปกรณ์ที่ ISP ให้มาหรือเปล่า?

    • ไหน ๆ ก็แนะนำแล้ว อยากรู้ด้วยว่ามีเราเตอร์ ไฟร์วอลล์เลเยอร์ 7 ที่ราคาถูกและดีบ้างไหม
      ถ้าเราแทรกไฟร์วอลล์ไว้ระหว่างแอปมือถือกับโมเด็มได้ก็คงดี

  • ปัญหา DNS ของ Android อยู่ที่แพลตฟอร์มนี้ไม่สามารถตั้งค่า เซิร์ฟเวอร์ IPv6 DNS เองได้ ทุกครั้งที่มีอะไรเปลี่ยนแปลงกับ Wi‑Fi มันก็จะเปลี่ยนไป
    แม้แต่ Android ที่รูทแล้ว ก็ไม่มีแอปที่ทำให้ระบบปฏิบัติการเปลี่ยนมันไม่ได้
    ถ้าใช้เราเตอร์ที่แจกจ่ายที่อยู่ IPv6 ตลอดเวลาและทำให้ปิดไม่ได้ ก็เท่ากับติดอยู่ตรงนั้น
    ก็ไม่รู้เหมือนกันว่าจะติดตั้งอุปกรณ์ไฟร์วอลล์ไว้หลังเราเตอร์นั้น แล้วลบเซิร์ฟเวอร์ IPv6 DNS ที่เราเตอร์โฆษณาออกได้หรือไม่

    • แทนที่จะตั้งค่า IP address ของเซิร์ฟเวอร์ DNS ลองใช้การรองรับ DNS-over-TLS ระดับระบบดีไหม มันเป็นการตั้งค่าแบบทั่วทั้งระบบ ดังนั้นไม่ว่าจะอยู่ในเครือข่ายไหน หรือเกิดอะไรขึ้นในเครือข่ายนั้น ก็ควรมีผลอยู่
      ถ้ากังวลเรื่อง DNS request รั่วไหล ยังไงก็ควรใช้ DoT หรือ DoH อยู่แล้ว
    • ใช้ rethink เปลี่ยน IPv6 DNS ได้ไม่ใช่หรือ?
    • ดูเหมือนหมายถึงกรณีที่โทรศัพท์เป็นอินเทอร์เฟซหลัก
      อยากรู้ว่า Wi‑Fi tethering ก็เกิดแบบเดียวกันไหม ถ้าใช้ VPN บนแล็ปท็อปที่เชื่อมต่อผ่าน Wi‑Fi ของโทรศัพท์ จะรั่วด้วยวิธีเดียวกันหรือเปล่า?

  • คอนฟิกที่ปลอดภัยที่สุดน่าจะเป็นการปิด mobile data ของโทรศัพท์ แล้วพก ฮอตสปอต OpenWRT ที่จัดการ VPN อยู่เหนือโทรศัพท์ไปด้วย

    • ใช่ บน iOS นี่เป็นฝันร้ายยิ่งกว่า
      “VPN ที่เปิดตลอดเวลา” ตั้งค่าได้เฉพาะบนอุปกรณ์ที่อยู่ในสถานะ “supervised” ผ่านโซลูชัน MDM ขององค์กรที่ Apple อนุมัติเท่านั้น ต้องมีการยื่นคำขอเป็นเอกสารและคุยโทรศัพท์กับพนักงานปัจจุบัน
      ไม่อย่างนั้นก็ต้องใช้แอป Apple Configurator บน Mac เท่านั้น ถึงจะสร้างโปรไฟล์การตั้งค่าที่มีคีย์ “always-on VPN” ได้
    • เคยลองทำแบบนี้อยู่หลายเดือนด้วย GL.inet E750 กับ iPhone ที่ไม่มี SIM แต่ผู้ให้บริการ GSM ในสหรัฐฯ มักจำกัด ทราฟฟิก UDP บนพอร์ตแปลก ๆ อย่างหนัก บางครั้งตกลงไปถึง 64~128kbps หรือประมาณ 0.1Mbps
      การแจ้งเตือนก็มักล่าช้าด้วย
    • ถ้าใช้ Wi‑Fi สาธารณะหรือเครือข่ายมือถือ นั่นคือทางออกที่ดีที่สุด หากมีใครตั้งสถานีฐานเอง โทรศัพท์ก็อาจไปเชื่อมต่อกับมันได้
      ถ้าไม่ใช่เครือข่ายของฉันเอง ก็ไม่ควรเชื่อมต่อโดยตรงโดยไม่มี เราเตอร์มือถือ
    • คนอื่น ๆ บอกว่า Android เปิด cellular data กลับขึ้นมาเงียบ ๆ ภายใต้เงื่อนไขหลายอย่าง ดังนั้นวิธีนี้ก็ไม่ใช่วิธีแก้ที่แน่นอน
      The Grugq เคยทำเครื่องมือสำหรับจุดประสงค์นี้ไว้เมื่อ 10 ปีก่อน ตอนนี้น่าเสียดายที่ไม่ได้มีการดูแลต่อแล้ว: https://github.com/grugq/portal
      มันเป็นส่วนหนึ่งของงานนำเสนอเรื่องความปลอดภัยเชิงปฏิบัติการสำหรับแฮกเกอร์ และถ้าสนใจกรณีของแฮกเกอร์หลายคนที่มีชื่อเสียงหรือฉาวโฉ่ ซึ่งคิดว่าตัวเองปลอดภัยแต่สุดท้ายก็ถูกจับ ก็ควรดู: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • ระบบที่ไม่มี สิทธิ์เข้าถึง root โดยนิยามแล้วไม่ปลอดภัย Android กับ iOS นี่น่าขำมาก

    • ก็อาจพูดได้เหมือนกันว่าระบบที่มีแนวคิดเรื่องการเข้าถึง root โดยนิยามแล้วไม่ปลอดภัย ประโยคฟันธงแบบนี้ใคร ๆ ก็พูดได้
    • ถ้าโทรศัพท์ไม่ได้มาแทนที่เดสก์ท็อป/แล็ปท็อปสำหรับคนส่วนใหญ่ ก็คงหัวเราะผ่าน ๆ ได้
      น่าเสียดายแทนเด็ก ๆ ที่เติบโตมา หรือกำลังจะเติบโตมา โดยมี “คอมพิวเตอร์” หลักเป็นอุปกรณ์ที่ออกแบบมาเพื่อการบริโภคสื่อและการเก็บข้อมูลส่วนตัวเป็นหลัก
    • นักพัฒนา GrapheneOS ต่อต้าน root อย่างหนักมาก อยากรู้ว่าคิดอย่างไรกับเรื่องนี้
    • ประเด็นชัดเจนและตรงกับหัวข้อ ดังนั้น โครงการอุปกรณ์มือถือแบบโอเพนซอร์สทั้งซอฟต์แวร์และฮาร์ดแวร์ จึงมีแต่จะเพิ่มขึ้นเรื่อย ๆ
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • ถ้าตามนิยามนั้น ระบบที่สำคัญที่สุดของฉันจำนวนมากก็คง “ไม่ปลอดภัย”
      ถ้าคุณเอาสำเนา SSH private key ของฉันจากอุปกรณ์พวกนั้นมาได้ ผมจะให้เงินสด 100,000 ดอลลาร์โดยไม่ถามอะไรสักคำ
      นิยามนั้นไม่มีความหมาย และไม่เป็นประโยชน์ต่อการให้เหตุผลหรือการสื่อสารเลย

  • “บล็อกการเชื่อมต่อเมื่อไม่มี VPN” กำลังพิสูจน์ตัวเองว่าเชื่อถือไม่ได้พอ ๆ กับความยับยั้งชั่งใจของฉันตอนอยู่หน้าบุฟเฟต์ ถ้าผมไม่ได้เข้าใจผิด DNS leak แบบนี้สามารถเปิดเผยทั้งเว็บไซต์ที่เข้าชมและตำแหน่งได้ไม่น้อย จนทำลายวัตถุประสงค์ของ VPN ไปเลย
    Android อาจปล่อยข้อมูล DNS รั่วแม้เปิด VPN อยู่ ดังนั้นถ้าใส่ใจความเป็นส่วนตัวจริง ๆ ก็ควรคิดไกลกว่าการใช้ Android เอง หรือย้ายงานที่อ่อนไหวออกจากโทรศัพท์จะดีกว่า

  • บางครั้งก็อดสงสัยไม่ได้ว่า “บั๊ก” แบบนี้ถูกวางไว้ตั้งใจอย่างเหมาะเจาะหรือเปล่า โดยเฉพาะเมื่อบริษัทเทคโนโลยียักษ์ใหญ่เคยร่วมมือกับหน่วยงานข่าวกรองหลายแห่ง
    นี่ก็ไม่ใช่ครั้งแรกที่ได้ยินบั๊กประเภทนี้บน Android ดังนั้นตอนนี้ยากจะเชื่อแล้วว่าบั๊กมากขนาดนี้ถูกใส่เข้ามา “โดยไม่ตั้งใจ”

    • “ครั้งหนึ่งคืออุบัติเหตุ สองครั้งคือ coincidence สามครั้งคือการกระทำของศัตรู” —Ian Fleming, Goldfinger

  • ตั้งแต่ก่อนหน้านี้ก็สงสัยอยู่พอสมควรว่ามันน่าจะเป็นแบบนี้ แม้เปิด VPN บน Android แล้ว MMS และ Visual Voicemail ก็ยังทำงานอยู่
    ทั้งสองอย่างอาจต้องมีการเข้าถึงเครือข่ายมือถือโดยตรง หรือไม่อย่างนั้นก็ถูกปฏิเสธได้ บางครั้งต้องอยู่บนเครือข่ายมือถือเท่านั้น หรือถ้าคำขอไม่ได้มาจากภายในเครือข่ายมือถือก็จะถูกปฏิเสธ สงสัยว่า VoLTE ก็น่าจะเหมือนกัน ถ้ามี VPN ฟีเจอร์พวกนี้อาจรวนได้
    บน Mobile Linux จะรู้ได้เพราะพอเปิด VPN แล้วฟีเจอร์เหล่านี้พังทั้งหมด
    ดูเหมือนไม่มีวิธีแก้ที่ชัดเจนบน Android โดยไม่ทำให้ฟีเจอร์ที่ผู้ใช้คาดหวังเสียหายไปมาก

    • แดกดันที่ SMS/MMS และ VVS เป็นงาน/ฟีเจอร์ไม่กี่อย่างที่พอจะมีเหตุผลให้ hardcode ไปที่การเชื่อมต่อของผู้ให้บริการได้ การอัปเดตระบบก็อาจเป็นแบบนั้นด้วย

ผมเคยต้องต่อสู้กับทีมซัพพอร์ตขั้นสูงของ AT&T เรื่องปัญหา VVS บน iOS ที่เปิด VPN อยู่ จึงยืนยันได้ว่าปัญหานี้ไม่ได้จำกัดอยู่แค่ Android

  • VoLTE ใช้ dedicated bearer ใน LTE stack หรือก็คืออินเทอร์เฟซเครือข่ายแยกต่างหาก ไม่ใช่อินเทอร์เฟซสำหรับข้อมูล
    bearer ที่ต่างกันอาจมีลำดับความสำคัญ/QCI ที่ต่างกัน หรือก็คือคุณภาพบริการที่ต่างกันได้ ในเครือข่าย LTE ที่แออัด VoLTE ควรให้ประสบการณ์ที่ดีกว่า VOIP บน bearer ที่มีลำดับความสำคัญต่ำ