exit IP ของ Mullvad สามารถใช้ระบุตัวตนได้อย่างน่าตกใจ

 (tmctmt.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mullvad มี exit IP หลายตัวต่อหนึ่งเซิร์ฟเวอร์ แต่มีการจัดสรรแบบกำหนดแน่นอนตามคีย์ WireGuard จึงไม่ได้สุ่มเปลี่ยนทุกครั้งที่เชื่อมต่อ
  • ข้อมูล 3,650 จุดข้อมูล ที่เก็บจากการเปลี่ยน pubkey ซ้ำ ๆ บน 9 เซิร์ฟเวอร์ ถูกจัดสรรอยู่เพียง 284 ชุดค่าผสม จากชุดค่าผสมที่เป็นไปได้ 8.2 ล้านล้านชุด
  • exit IP ของแต่ละเซิร์ฟเวอร์จะอยู่ใน ตำแหน่งเปอร์เซ็นไทล์ ใกล้เคียงกันภายในพูล และชุดค่าผสมหนึ่งมักตรงกับประมาณเปอร์เซ็นไทล์ที่ 81 บนหลายเซิร์ฟเวอร์
  • สาเหตุน่าจะมาจากโครงสร้างที่เลือกดัชนี exit IP ด้วย RNG ที่อิง seed โดยใช้ pubkey หรือที่อยู่ท่อสัญญาณเป็น seed และใช้ขนาดพูลเป็นขอบเขตบน
  • หากช่วง float ในบันทึก IP ซ้อนทับกัน ก็อาจเชื่อมโยงบัญชีข้ามกันได้แม้ใช้เซิร์ฟเวอร์ Mullvad คนละตัว ทำให้เกิด ความเสี่ยงต่อการไม่เปิดเผยตัวตน สูงขึ้น

โครงสร้างที่ทำให้ exit IP ของ Mullvad กลายเป็นเวกเตอร์สำหรับการระบุตัวตน

  • Mullvad ให้ exit IP หลายตัวต่อหนึ่งเซิร์ฟเวอร์ และผู้ใช้สองคนที่เชื่อมต่อกับเซิร์ฟเวอร์เดียวกันก็มักจะได้ public IP คนละตัว
  • จำนวนเซิร์ฟเวอร์มี 578 เครื่อง ซึ่งน้อยกว่า Proton VPN ที่มี 20,000 เครื่อง ทำให้การขยายแบบแนวตั้งที่ไม่อัดผู้ใช้จำนวนมากไว้ใน IP เดียว อาจมีข้อดีในการหลีกเลี่ยงการบล็อก IP มากเกินไปและการจำกัดความเร็ว
  • แต่ทุกครั้งที่เชื่อมต่อกับเซิร์ฟเวอร์ exit IP ไม่ได้เปลี่ยนแบบสุ่ม และถูกเลือกแบบกำหนดแน่นอนจากคีย์ WireGuard
  • คีย์ WireGuard จะหมุนเปลี่ยนทุก 1~30 วัน แต่ในไคลเอนต์ของบุคคลที่สามจะไม่มีการหมุนเปลี่ยน
  • หากมีการกำหนด exit IP แบบคงที่อย่างเป็นอิสระในแต่ละเซิร์ฟเวอร์ ก็อาจใช้เพียงชุด IP จากไม่กี่เซิร์ฟเวอร์เพื่อแยกผู้ใช้ออกจากผู้ใช้ Mullvad คนอื่นได้

ชุดค่าผสมของ exit IP ที่สังเกตได้จาก 9 เซิร์ฟเวอร์

  • มีการรันสคริปต์เก็บ exit IP จาก 9 เซิร์ฟเวอร์ตลอดคืนโดย เปลี่ยน pubkey ซ้ำ ๆ จนได้ข้อมูล pubkey 3,650 จุด
  • ช่วงของ exit IP ในแต่ละเซิร์ฟเวอร์ที่สังเกตได้มีดังนี้
Hostname Start IP End IP # IPs
au-syd-wg-101 103.136.147.5 103.136.147.64 60
cl-scl-wg-001 149.88.104.4 149.88.104.14 11
de-ber-wg-007 193.32.248.245 193.32.248.252 8
dk-cph-wg-002 45.129.56.196 45.129.56.226 31
fi-hel-wg-201 185.65.133.10 185.65.133.75 66
us-lax-wg-001 23.234.72.36 23.234.72.126 91
us-nyc-wg-602 146.70.168.132 146.70.168.190 59
us-sjc-wg-302 142.147.89.212 142.147.89.224 13
za-jnb-wg-002 154.47.30.145 154.47.30.155 11
  • เมื่อนำขนาดพูลของเซิร์ฟเวอร์เหล่านี้มาคูณกัน จะดูเหมือนว่ามีชุดค่าผสมของ exit IP ที่เป็นไปได้ มากกว่า 8.2 ล้านล้านชุด
  • แต่ pubkey ทุกตัวที่ทดสอบจริงกลับถูกจัดสรรอยู่เพียงหนึ่งใน284 ชุดค่าผสมเท่านั้น
  • จำนวนชุดค่าผสมที่สังเกตได้มีน้อยมากเมื่อเทียบกับจำนวนที่เป็นไปได้ จึงเป็นเบาะแสว่าการเลือก IP ของแต่ละเซิร์ฟเวอร์ไม่ได้เป็นอิสระต่อกัน

รูปแบบที่ IP ต่างกันไปอยู่ในเปอร์เซ็นไทล์เดียวกัน

  • exit IP สามารถคำนวณ ตำแหน่งเชิงตัวเลข ได้จากระยะห่างจาก IP เริ่มต้นของพูล
  • ตัวอย่างเช่น ใน au-syd-wg-101 ค่า 103.136.147.53 จะมีดัชนีแบบ 1-based เท่ากับ 49 เมื่อนับจาก 103.136.147.5
  • เมื่อนำตำแหน่ง IP ของชุดค่าผสมที่สังเกตได้ไปหารด้วยขนาดพูลของแต่ละเซิร์ฟเวอร์ จะเห็น สัดส่วน ที่แทบจะเท่ากันแม้อยู่คนละเซิร์ฟเวอร์
Server IP Position Pool size Ratio
au-syd-wg-101 103.136.147.53 49 60 0.816
cl-scl-wg-001 149.88.104.12 9 11 0.818
de-ber-wg-007 193.32.248.251 7 8 0.875
dk-cph-wg-002 45.129.56.220 25 31 0.806
fi-hel-wg-201 185.65.133.63 54 66 0.818
us-lax-wg-001 23.234.72.109 74 91 0.813
us-nyc-wg-602 146.70.168.179 48 59 0.813
us-sjc-wg-302 142.147.89.222 11 13 0.846
za-jnb-wg-002 154.47.30.153 9 11 0.818
  • IP แต่ละตัวจะไปอยู่ในเปอร์เซ็นไทล์ใกล้เคียงกันของพูลนั้น ๆ และตัวอย่างข้างต้นโดยรวมอยู่แถว เปอร์เซ็นไทล์ที่ 81
  • ด้วยรูปแบบนี้ Mullvad จึงดูเหมือนกำหนด exit IP ที่อยู่ในตำแหน่งใกล้เคียงกันบนทุกเซิร์ฟเวอร์เท่านั้น

สาเหตุที่ดูเหมือนมาจากการสุ่มแบบอิง seed

  • cl-scl-wg-001 และ za-jnb-wg-002 ใช้ดัชนี IP เดียวกันเสมอในทั้ง 284 ชุดค่าผสมของ IP ที่สังเกตได้
  • จุดร่วมของทั้งสองเซิร์ฟเวอร์คือมี ขนาดพูล 11 ซึ่งสอดคล้องกับโครงสร้างที่การเรียกสุ่มด้วย seed เดียวกันและ bounds เดียวกันให้ผลลัพธ์เดียวกัน
  • หากเริ่มต้น RNG ด้วย seed แบบคงที่แล้วสุ่มในช่วงเดียวกัน ก็จะได้ผลลัพธ์เดิมซ้ำ ๆ
  • Mullvad จึงดูเหมือนเลือกดัชนี exit IP ด้วย RNG ที่อิง seed โดยใช้ pubkey หรือที่อยู่ท่อสัญญาณเป็น seed และใส่ขนาดพูลเป็นค่าสูงสุด
  • แม้ bounds จะเปลี่ยนไป entropy pool ของ RNG ก็ไม่ได้รับผล และใน Rust ก็สอดคล้องกับลักษณะที่การเรียกครั้งแรกสร้าง float ค่าเดิมแล้วนำไปคูณกับ bounds
  • พฤติกรรมนี้อาจอธิบายแบบย่อได้ว่า min + round((max - min) * float) แม้นี่อาจเป็นการลดทอนรายละเอียดมากเกินไป
  • ด้วยคุณสมบัตินี้ แม้ขนาดพูลต่างกัน float ที่ได้จาก seed เดียวกันก็ยังถูกแมปไปยังจุดที่มีสัดส่วนใกล้เคียงกันในพูลของแต่ละเซิร์ฟเวอร์
  • ไคลเอนต์ Mullvad เขียนด้วย Rust จึงอาจเป็นไปได้ว่าแบ็กเอนด์ก็ใช้ Rust เช่นกัน แต่ข้อสรุปนี้อิงจากการติดตั้งฝั่งไคลเอนต์เท่านั้น
  • การคาดเดาอย่างแม่นยำว่า random_range ทำงานอย่างไรเมื่อ bounds เปลี่ยนไปนั้นทำได้ยาก และอาจเผลอคิดว่าการเพิ่ม bounds จะผสมกับ entropy แล้วสร้างเลขอื่น แต่สิ่งที่สังเกตจริงไม่เป็นเช่นนั้น

ความเสี่ยงต่อการไม่เปิดเผยตัวตนจากการเชื่อมโยงบันทึก IP

  • มีเครื่องมือชื่อ mullvad-seed-estimator สำหรับประมาณค่า float ต่ำสุดและสูงสุดที่เป็นไปได้จากชุดค่าผสม IP หนึ่งชุด
  • ชุด IP เฉพาะในภาพหน้าจอถูกตีความว่าเป็นค่า float ระหว่าง 0.2909~0.2943 ซึ่งต่างกัน 0.0034
  • นั่นหมายความว่าในบรรดาผู้ใช้ Mullvad จะมี 0.34% ที่ใช้ IP ชุดนี้ร่วมกัน และหากประเมินคร่าว ๆ ว่ามีผู้ใช้ที่ใช้งานอยู่ 100,000 คน ก็จะเท่ากับ 340 คน
  • แม้จะไม่ได้มีเอกลักษณ์สูงเท่าที่คาดไว้ตอนแรก แต่ความแม่นยำระดับ มากกว่า 99% ก็ยังไม่ต่ำ
  • ตัวอย่างเช่น เมื่อผู้ดูแลฟอรัมต้องการตรวจสอบว่าบัญชีใหม่เป็น sockpuppet ของผู้ใช้ที่ถูกแบนเมื่อวันก่อนหรือไม่ แม้ทั้งสองบัญชีจะใช้เซิร์ฟเวอร์ Mullvad คนละตัว หากบันทึก IP ของทั้งคู่มีช่วง float ซ้อนทับกัน เช่น 0.4334 - 0.4428 และ 0.4358 - 0.4423 ก็มีความเป็นไปได้เกิน 99% ว่าเป็นคนเดียวกัน
  • หากนำความสัมพันธ์แบบเดียวกันนี้ไปใช้กับบันทึก IP ที่ได้มาจากข้อมูลรั่วไหลหรือกระบวนการทางกฎหมาย ผู้ใช้ที่อยู่หลัง VPN ก็อาจสูญเสียความไม่เปิดเผยตัวตนได้

วิธีป้องกัน

  • แนะนำว่า หนึ่ง pubkey ไม่ควรเปลี่ยนเซิร์ฟเวอร์มากกว่าหนึ่งครั้ง
  • สามารถออกจากระบบในแอป Mullvad เพื่อ บังคับหมุนเปลี่ยน pubkey ได้

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • เป็นผู้ร่วมก่อตั้งและ co-CEO ที่ทำงานอยู่ที่ Mullvad ความพฤติกรรมบางส่วนที่บทความพูดถึงนั้นตั้งใจให้เป็นเช่นนั้น และบางส่วนก็ไม่ใช่ โดยสาเหตุก็ไม่ตรงกับคำอธิบายในบล็อกโพสต์เสียทีเดียว
    ในส่วนของมาตรการบรรเทา ตอนนี้มีการทดสอบแพตช์สำหรับพฤติกรรมที่ไม่ได้ตั้งใจอยู่แล้วในบางส่วนของโครงสร้างพื้นฐาน ดังนั้นถ้าลองทำซ้ำวันนี้ ผลลัพธ์อาจทำให้สับสนได้
    ส่วนพฤติกรรมที่ตั้งใจไว้ก็จะนำกลับมาประเมินอีกครั้งว่ายังยอมรับได้หรือไม่ ซึ่งมีการแลกเปลี่ยนกันระหว่างองค์ประกอบด้านความเป็นส่วนตัวหลายอย่างกับประสบการณ์ผู้ใช้
    ความเข้าใจนี้เป็นการประเมินปัจจุบันที่ได้มาหลังเพิ่งทราบเรื่องเมื่อหนึ่งชั่วโมงก่อน แล้วรีบคุยกับทีมปฏิบัติการและสรุปออกมาเป็นความเห็นนี้ จึงอาจเปลี่ยนแปลงได้
    หากทำงานวิจัยด้านความปลอดภัย เมื่อพบปัญหาด้านความปลอดภัยหรือความเป็นส่วนตัว แม้วางแผนจะเปิดเผยทันที ก็ควรแจ้งผู้ดูแลหรือผู้ขายก่อน

    • ไคลเอนต์ Mullvad โดยปกติแล้วรอบการหมุนคีย์น่าจะเป็น 72 ชั่วโมง และไคลเอนต์ CLI ก็สามารถปรับแต่งเล็กน้อยให้ใช้งานได้ในสถานการณ์ส่วนใหญ่ที่ใช้ WireGuard แบบเนทีฟ
      ตรวจสอบได้ด้วย mullvad tunnel get และเปลี่ยนได้ด้วย mullvad tunnel set rotation-interval ซึ่งก็เป็นวิธีบรรเทาที่บทความนั้นชอบด้วย
      ส่วนตัวแล้วมองว่า IP กึ่งคงที่ไม่ใช่ปัญหาใหญ่ เป้าหมายคือป้องกันการสอดส่องระดับเครือข่ายจาก ISP และรัฐบาล และบางผู้ให้บริการก็ขาย IPv4 แบบคงที่เป็นฟีเจอร์ด้วยซ้ำ
      สำหรับ VPN ที่เน้นความเป็นส่วนตัว ยิ่งพื้นที่ IP เล็ก ก็ยิ่งมีผู้ใช้จำนวนมากปะปนอยู่หลัง IP เดียวที่มองเห็นจากภายนอกได้ ซึ่งก็มีข้อดีอยู่เหมือนกัน เมื่อรวมกับเทคนิคอย่าง DAITA ที่ใส่ทราฟฟิกหลอกในท่อสัญญาณ และจุดเข้าแบบ multihop ผมคิดว่ามันทำให้ผู้สอดส่องที่คอยดู netflow ทั้งวันทำงานยากขึ้นจริง
    • ผมคือ Carl, CEO ของ Obscura และเป็นหนึ่งในพาร์ตเนอร์ของ Mullvad นี่เป็นการค้นพบที่น่าสนใจ แต่ตามที่ kfreds บอก ถ้าแจ้งผู้ขายก่อนเผยแพร่ก็คงดีกว่านี้
      การค้นพบหลักคือความสัมพันธ์ของตำแหน่งภายในพูล IPข้ามเซิร์ฟเวอร์ ซึ่งดูเหมือนว่าจะมีพฤติกรรมที่ไม่ได้ตั้งใจรวมอยู่จริง และจากประสบการณ์ที่เคยทำงานกับทีม Mullvad ก็คาดว่าน่าจะจัดการได้ในไม่ช้า
      ถ้าต้องการ “ตัวตน” ที่แตกต่างกัน ก็ต้องหมุนคีย์ WireGuard หรือใช้คีย์คนละชุด
      บทความบอกว่า “ทุกครั้งที่เชื่อมต่อกับเซิร์ฟเวอร์ IP ขาออกจะไม่ได้สุ่ม แต่ถูกเลือกแบบกำหนดแน่นอนจากคีย์ WireGuard และคีย์นั้นจะถูกหมุนทุก 1~30 วัน ถ้าใช้ไคลเอนต์ third-party จะไม่ถูกหมุน” แต่ WireGuard เป็นโปรโตคอลแบบไม่ต้องมีการเชื่อมต่อตามการออกแบบhttps://www.wireguard.com/protocol/ จึงไม่มีแนวคิดเรื่องการเชื่อมต่อ มีเพียงการทำ rekeying handshake ทุก 2~3 นาทีเมื่อมีทราฟฟิกไหลผ่านเท่านั้น
      ถ้าภายใต้คีย์ WireGuard เดียวกัน IP ขาออกเปลี่ยนทุกครั้งที่ “เชื่อมต่อ” เช่น ทุกครั้งที่ rekeying handshake หรือทุก 15 นาที ที่ชั้น transport การเชื่อมต่อภายในท่อสัญญาณแทบทั้งหมดนอกจาก QUIC จะหลุดและต้องสร้างใหม่ และที่ชั้นแอปพลิเคชัน บริการที่สงสัย “คุกกี้เดิม แต่ IP ใหม่” ก็จะบังคับออกจากระบบ แสดง CAPTCHA หรือเพิ่มคะแนนความเสี่ยง
      ทั้งสองแบบเป็นประสบการณ์ผู้ใช้ที่แย่ และที่แย่กว่านั้นคืออาจทำให้ผู้ใช้มีลายนิ้วมือเฉพาะตัวมากขึ้น เช่น “คนนี้เชื่อมต่อใหม่จากหลาย IP ตลอด งั้นน่าจะเป็นผู้ใช้ Mullvad”

  • ตัวอย่างที่ว่า “ผู้ดูแลฟอรัมสงสัยว่าบัญชีหนึ่งเป็นบัญชีรองของผู้ใช้ที่ถูกแบนเมื่อวันก่อน จึงดูล็อก IP แล้วพบว่าแม้จะใช้เซิร์ฟเวอร์ Mullvad คนละตัว แต่ทั้งสองบัญชีกลับแมปไปยังช่วงเลขทศนิยมที่ทับซ้อนกันคือ 0.4334~0.4428 และ 0.4358~0.4423 จึงมองได้ว่ามีโอกาสเกิน 99% ว่าเป็นคนเดียวกัน” ให้ความรู้สึกเหมือนถ้าหน่วยข่าวกรองจะออกแบบ VPN ก็คงทำแบบนี้

    • ไม่รู้เหมือนกันว่าทำไมถึงคิดแบบนั้น ถ้าหน่วยข่าวกรองจะออกแบบ VPN พวกเขาคงไม่พึ่งสถิติของ exit node แต่จะบันทึกล็อก IP ทุกตัวที่เชื่อมต่อเข้า VPN ตรง ๆ มากกว่า
      อีกอย่าง วิธีนี้ยังขึ้นกับการที่ผู้ใช้เลือกเซิร์ฟเวอร์ต่างกัน จึงยิ่งไม่มีเหตุผลจะทำแบบนั้น
    • สักวันหนึ่งก็คงมีการเปิดเผยว่า Cloudflare ก็เกี่ยวข้องกับหน่วยข่าวกรองเหมือนกัน ถ้าวิธีแก้ “DDoS ที่เกิดขึ้นกะทันหัน” คือเอาเว็บไปไว้หลัง Cloudflare ก็อดสงสัยไม่ได้ว่าใครกันแน่ที่ทำการโจมตีแบบกะทันหันเหล่านั้นได้
    • ถึงอย่างนั้นก็ยังมีรายละเอียดเล็ก ๆ เรื่องการไม่เก็บล็อกอยู่
      สำหรับผม นี่เป็นปัญหาใหญ่ และมันเปิดให้ทำการวิเคราะห์ความสัมพันธ์ระหว่าง exit node ของ VPN หลายตัวได้ แต่นอกเหนือจากนั้นก็ไม่มีอะไร มันไม่ได้ทำให้ระบุตัวผู้ใช้ได้โดยอัตโนมัติ
      อย่างไรก็ตาม มันลดความยากในการระบุตัวลงมาก แม้เงื่อนไขที่ต้องมีจะยังสูงอยู่ ก็ควรแก้ให้เร็ว
      ยังไม่น่าเชื่อว่าความผิดพลาดแนว “เอาค่าละเอียดอ่อนอย่างแฮชมาใช้” จะยังเกิดขึ้นอยู่ แถมเกิดกับ Mullvad อีก ทำไมไม่สุ่มไปเลย
    • Mullvad มีมาก่อนการเปิดโปงของ Snowden หลายปี และไม่ปรากฏอยู่ในเอกสารเหล่านั้นเลย
      แน่นอนว่ายังมีหน่วยข่าวกรองอื่น ๆ แต่ที่น่ากังวลที่สุดก็คือฝั่งนั้น เพราะอาจจะเป็นผู้ดำเนินการเอง หรือรู้แนวคิดนี้แล้วทำตาม หรือมีสิทธิ์เข้าถึงบริการที่หน่วยงานพันธมิตรเป็นผู้ดำเนินการ ไม่อย่างนั้นก็ไม่ใช่ภัยคุกคามต่อผม
      อีกทั้งก็ยังไม่มีกรณีสาธารณะที่ผู้ใช้ Mullvad ถูกลดความเป็นนิรนามผ่าน VPN โดยตรง มีแต่กรณีที่ถูกพบเพราะความล้มเหลวด้าน operational security แบบอื่นแทน ถ้าหน่วยข่าวกรองมีความสามารถนี้จริง ก็คงหมายความว่ามีข้อมูลอยู่เกือบ 20 ปีแต่ไม่เคยใช้ ซึ่งเชื่อได้ยาก
    • ถ้าหน่วยข่าวกรองควบคุม VPN ได้ พวกเขาก็แค่เฝ้าดูทราฟฟิกโดยตรงได้เลย ไม่มีแรงจูงใจจะทำให้ผู้สังเกตการณ์ภายนอกเดาได้ง่ายขึ้นว่าผู้ใช้คนไหนออกมาทาง exit IP ไหน

  • ดูจากตัวเลขในบทความอย่างเดียว ผมไม่เข้าใจว่าได้ “ความน่าจะเป็นเกิน 99%” มายังไง ต่อให้สมมติแรงมากว่าซีดของ IP ที่ถูกแบนตัวแรกและซีดตัวที่สองอยู่ในช่วง 0.4423~0.4358 ทั้งคู่ ก็แปลเพียงว่าช่วงนี้ครอบคลุมผู้ใช้ Mullvad ทั้งหมด 0.65% เท่านั้น
    ถ้ามีผู้ใช้ 100,000 คน ก็คือ 650 คน เป็นการตัด “ผู้ต้องสงสัย” ออกไปได้เกิน 99% ก็จริง แต่ไม่ใช่การระบุตัวบุคคลหนึ่งคนข้ามหลาย exit IP ได้ด้วยความแม่นยำเกิน 99%
    มองแบบเบย์ส การทับซ้อนของซีดที่เป็นไปได้เป็นหลักฐานหนักแน่นว่าทั้งสอง IP เป็นคนเดียวกัน หรืออย่างน้อยก็เป็นบัญชี Mullvad เดียวกัน แต่สิ่งที่ผู้เขียนพูดดูเหมือนจะไม่ใช่แบบนั้น

    • ถ้าฟอรัมค่อนข้างใหญ่ มีผู้ใช้ประจำ 1,000 คน และมีคนสมัครใหม่วันละ 1 คน ก็ชวนคิดว่าหลังจากมีคนถูกแบน วันถัดมาจะมีโอกาสแค่ไหนที่คนที่ใช้ VPN นี้จะมาสมัครแล้วมี IP อยู่ในช่วงใกล้เคียงกัน
      สำหรับเว็บไซต์เล็ก ๆ ส่วนใหญ่ นั่นก็ถือเป็นหลักฐานที่ค่อนข้างหนักแน่น

  • เป้าหมายของ VPN ไม่ได้รวมถึงการทำให้ผู้ใช้ไม่สามารถถูกระบุตัวได้จากเว็บไซต์ที่เข้าใช้งาน ดังนั้นจึงไม่น่าแปลกใจที่ Mullvad ไม่ได้บังคับให้มี exit IP ที่ไม่ซ้ำเฉพาะตัว ผู้ใช้ที่ต้องการความเป็นนิรนามควรใช้เครือข่ายอย่างTor

    • ไม่เข้าใจว่าทำไมจะเป็นไปไม่ได้ ไม่มีเหตุผลที่เป้าหมายของบริการ VPN บางเจ้าโดยเฉพาะจะเป็นแบบนั้นไม่ได้
    • Tor เป็นโครงการของรัฐบาลสหรัฐฯ และก็เคยมีการแสดงให้เห็นแล้วว่าสามารถลดความเป็นนิรนามได้ไม่ใช่หรือ?
    • นั่นแหละคือจุดประสงค์ของVPN สาธารณะ
      ถ้าใช้ VPN สาธารณะ ก็ย่อมอยากให้ไม่มีใครรู้ว่าใครเป็นคนส่งคำขอ รวมถึงไม่รู้ IP ปลายทางด้วย
      ถ้าตามตรรกะนั้น VPN ก็ไม่ควรใช้กับทอร์เรนต์ เพราะมันไม่ควรทำให้ไม่สามารถระบุตัวจาก IP ปลายทางได้ แต่ในความเป็นจริงมันกลับใช้กับทอร์เรนต์ได้ดีมาก
      ถ้าพูดถึง VPN ส่วนตัว Mullvad ก็ไม่ใช่แบบนั้น

  • ผมใช้ Mullvad มานานแล้ว และตราบใดที่ยังถูกกฎหมายในประเทศของผม ผมก็จะยังซื้อและใช้บริการ Mullvad VPN ต่อไปด้วยบัตรเครดิตที่เป็นชื่อของผมเอง
    VPN ไม่ได้นิรนาม 100% และก็ไม่ได้ถูกออกแบบมาให้เป็นแบบนั้น แต่มันถูกสร้างมาเพื่อมอบความเป็นส่วนตัวในระดับหนึ่งให้ผู้ใหญ่ที่ปฏิบัติตามกฎหมาย
    คนส่วนใหญ่น่าจะรู้สึกอึดอัดถ้าเพื่อนร่วมงานหรือเพื่อนบ้านรู้เรื่องชีวิตส่วนตัว สิ่งที่ชอบ สิ่งที่ซื้อ หรือสิ่งที่ทำของตัวเอง เพราะแบบนั้นคนส่วนใหญ่จึงควรใช้ VPN เพื่อปกป้องความเป็นส่วนตัว
    ตามนิยามแล้ว “คนส่วนใหญ่” ไม่ได้ต้องการหรือคาดหวังความเป็นนิรนาม 100% บนออนไลน์ แค่อยากได้ความเป็นส่วนตัวเล็กน้อยในชีวิตและความสัมพันธ์ส่วนตัวเท่านั้น
    VPN ไม่ได้ปกป้องอาชญากรที่ต้องการก่ออาชญากรรมออนไลน์แล้วซ่อนตัวจากรัฐบาลแบบ 100% และก็ไม่ได้มีเจตนาแบบนั้น ความแตกต่างนี้สำคัญ “คนส่วนใหญ่” ไม่ใช่อาชญากร และไม่ได้คาดหวังอย่างไม่สมจริงจาก Mullvad หรือผู้ให้บริการ VPN เจ้าอื่น

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

  • มีข้อมูลที่หายไป อยากรู้ว่าได้ติดต่อ Mullvad หรือเปล่า ถ้าได้เห็นว่าทีมความปลอดภัยตอบสนองอย่างไรก็คงน่าสนใจ

    • เท่าที่ผมรู้คือไม่มีการติดต่อ และผมตรวจสอบกับทั้งทีมปฏิบัติการและทีมซัพพอร์ตแล้ว ถ้าผมผิดจะอัปเดตความเห็นนี้
      พอมาย้อนดูทีหลังก็เสียดายที่เขียนความเห็นนี้ไป มันไม่จำเป็น แต่ถ้าลบตอนนี้ก็คงดูแปลก
    • ไม่ใช่แบบนั้น แต่ความเห็นยอดนิยมอันดับต้น ๆ ของโพสต์นี้ก็คือคำตอบจากผู้ร่วมก่อตั้ง Mullvad

  • รู้สึกแปลกใจที่คนคาดหวังว่า VPN จะคล้ายกับ Tor
    ถ้าอธิบายออกมาตรง ๆ มันก็ดูไม่สมเหตุสมผล และต้องคิดด้วยว่าถ้าควบคุม exit node ได้ ก็สามารถลดความเป็นนิรนามของแม้แต่ผู้ใช้ Tor ได้เช่นกัน

    • ก็ไม่แปลกนัก เพราะ VPN สำหรับผู้บริโภครายใหญ่จำนวนมากทำการตลาดเรื่อง “ความเป็นส่วนตัว” ให้สื่อความหมายเหมือนความเป็นนิรนาม
    • ไม่ใช่ว่าส่วนหนึ่งของการออกแบบ Tor คือการวิ่งผ่าน relay node หลายตัว จนแม้แต่ exit node ก็ไม่เห็น IP ต้นทางหรอกหรือ?
    • อาจไม่ใช่สิ่งที่คาดหวัง แต่ก็ทำให้รู้สึกว่าถ้าทำได้ ก็น่าจะพยายามทำในสิ่งที่ช่วยมอบความเป็นส่วนตัวให้ได้

  • ตรงที่ว่า “exit IP ไม่ได้ถูกสุ่มใหม่ทุกครั้งที่เชื่อมต่อ แต่ถูกเลือกแบบกำหนดแน่นอนตามคีย์ WireGuard และคีย์นี้จะหมุนทุก 1~30 วัน ถ้าใช้ไคลเอนต์ third-party จะไม่มีวันหมุน” ฟังดูสับสนเล็กน้อย
    ถ้ามีการอธิบายวิธีการไว้ละเอียดในรีโพซิทอรี ก็ไม่เข้าใจว่ามีอะไรไปขัดขวางไม่ให้ third-party ทำการหมุนคีย์ได้เหมือนแอปไคลเอนต์ทางการ

    • ไคลเอนต์ third-party รวมถึงสิ่งอย่างไดรเวอร์ WireGuardในเคอร์เนล Linux ด้วย ไม่มีทางให้ไดรเวอร์เครือข่ายต้องมารับผิดชอบบรรเทาการโจมตีต่อบริการเชิงพาณิชย์รายใดรายหนึ่งได้
    • หลัก ๆ คือถูกขัดขวางด้วยการไม่รู้ว่าต้องทำแบบนั้น

  • ผู้เขียนหาประเด็นนี้เจอได้ดีมาก และผมก็เชื่อได้เต็มที่ว่านี่เป็นความผิดพลาดของ Mullvad ที่เรื่องง่ายแบบนี้หลุดรอดไปได้ถือว่าน่าตกใจ แต่ผมเองก็น่าจะพลาดได้เหมือนกัน
    ถ้าตัดเรื่องความสัมพันธ์ของ IPข้ามหลายเซิร์ฟเวอร์ออกไป ตอนแรกผมก็สงสัยเหมือนกันว่าทำไมต้องทำให้ IP ของผู้ใช้คงที่ในเซิร์ฟเวอร์เดียว แต่เมื่อดูคำอธิบายของผู้เขียนที่บอกว่าเป็นการเลียนแบบ VPN อื่น ๆ ซึ่งมักมี IP ต่อเซิร์ฟเวอร์แค่ตัวเดียว มันก็สมเหตุสมผล
    ข้อดีคือถ้าผู้ใช้หาเซิร์ฟเวอร์ที่เข้าถึงบริการบางอย่างได้ พอกลับมาเชื่อมต่อเซิร์ฟเวอร์นั้นอีกครั้งก็มีโอกาสได้ IP เดิมและใช้งานได้อีก
    แต่ความสัมพันธ์ของ IP ข้ามหลายเซิร์ฟเวอร์ควรแก้ด้วยวิธีอย่าง rand.seed(user_pub_key + server_id)

    • ในทางกลับกัน ถ้าถูกบริการบางแห่งบล็อกเพราะเพื่อนบ้านร่วม IP ที่สร้างปัญหา แบบนี้ผู้ใช้ก็ไม่มีทางเลี่ยงไม่ใช่หรือ?

  • ผมทำงานอยู่ที่ IPinfo เราทำธุรกิจด้านการตรวจจับ VPN แต่พูดตามตรง ผมอยากมอง Mullvad ในแง่ดี
    Mullvad เป็นหนึ่งในสามผู้ให้บริการ VPN ที่ไม่เคยพยายามส่งข้อมูลพิกัดภูมิศาสตร์ที่ไม่ถูกต้องให้ผู้ให้บริการอย่างพวกเราในด้านตำแหน่งที่ตั้ง IP ผมมั่นใจว่าเรื่องนี้ก็คงจะแก้ไขเช่นกัน

    • อีกสองเจ้าคือที่ไหน?