- Mullvad มอบหมายให้บริษัทความปลอดภัยจากเนเธอร์แลนด์ Radically Open Security (RoS) ดำเนินการตรวจสอบโครงสร้างพื้นฐาน VPN ครั้งที่ 3 โดยตรวจสอบเซิร์ฟเวอร์ OpenVPN 1 เครื่องและเซิร์ฟเวอร์ WireGuard 1 เครื่องที่ทำงานอยู่บน RAM
- เซิร์ฟเวอร์ที่ใช้ในการตรวจสอบเป็นเซิร์ฟเวอร์ที่ใช้ Linux kernel 6.3.2 และระบบปฏิบัติการปรับแต่งเองที่อิงกับ Ubuntu 22.04 LTS โดยถูก deploy ในลักษณะเดียวกับเซิร์ฟเวอร์ใช้งานจริง แต่ไม่เคยถูกใช้สำหรับการเชื่อมต่อของลูกค้าจริง
- RoS ตรวจสอบการตั้งค่าเซิร์ฟเวอร์ทั้งภายในและภายนอก รวมถึง การบันทึกกิจกรรมของลูกค้า และไม่พบการบันทึกข้อมูลลูกค้าหรือการรั่วไหลของข้อมูล
- ในการทดสอบเจาะระบบพบ High 1 รายการ, Elevated 6 รายการ, Moderate 4 รายการ, Low 10 รายการ, info 4 รายการ โดยการแก้ไขหลักถูก deploy ในช่วงปลายเดือนมิถุนายน 2023 และมีการทดสอบซ้ำพร้อมตรวจสอบยืนยันในเดือนกรกฎาคม
- Mullvad ได้เสริมความเข้มงวดในการตรวจสอบการเข้าถึงของผู้ดูแลระบบผ่าน SSH, พิจารณาการถอด SSH ออก, และปรับปรุงการยืนยันตัวตนของ Telegraf โดยจะมีการ deploy การเปลี่ยนแปลงเพิ่มเติมบางส่วนในภายหลัง
ขอบเขตการตรวจสอบและรายงานสาธารณะ
- Mullvad ว่าจ้าง Radically Open Security ให้ทำ การตรวจสอบความปลอดภัยครั้งที่สาม สำหรับโครงสร้างพื้นฐาน VPN
- การตรวจสอบครั้งนี้มุ่งเน้นไปที่เซิร์ฟเวอร์ VPN 2 เครื่องที่ทำงานอยู่บน RAM
- เซิร์ฟเวอร์ OpenVPN 1 เครื่อง
- เซิร์ฟเวอร์ WireGuard 1 เครื่อง
- RoS ดำเนินการตรวจสอบเสร็จสิ้นในช่วงกลางเดือนมิถุนายน 2023 และมีการ deploy การแก้ไขจำนวนมากในช่วงปลายเดือนมิถุนายน 2023
- ในเดือนกรกฎาคม 2023 มีการดำเนินการ ทดสอบซ้ำและตรวจสอบยืนยัน เพิ่มเติม
- รายงานฉบับสมบูรณ์ถูกเผยแพร่ที่ ROS - Mullvad VPN 2023.pdf
การตั้งค่าเซิร์ฟเวอร์ทดสอบและหัวข้อที่ตรวจสอบ
- RoS ได้รับ สิทธิ์เข้าถึง SSH เต็มรูปแบบ สำหรับเซิร์ฟเวอร์ VPN 2 เครื่องที่ทำงานอยู่บน RAM
- เซิร์ฟเวอร์ที่ถูกตรวจสอบใช้ Linux kernel รุ่นล่าสุดแบบลดขนาด 6.3.2 และระบบปฏิบัติการปรับแต่งเองที่อิงกับ Ubuntu 22.04 LTS
- เซิร์ฟเวอร์เหล่านี้ถูก provision และ deploy ในแบบเดียวกับเซิร์ฟเวอร์ใช้งานจริงสำหรับลูกค้า แต่ไม่เคยถูกใช้งานสำหรับการเชื่อมต่อของลูกค้าจริง
- ขอบเขตการตรวจสอบสรุปได้เป็น 3 ส่วน
- ความปลอดภัยและการตั้งค่าภายในเซิร์ฟเวอร์
- ความปลอดภัยและการตั้งค่าภายนอกเซิร์ฟเวอร์
- การมีหรือไม่มีการบันทึกกิจกรรมของลูกค้า
- RoS ยังเสนอให้ตรวจสอบซอร์สโค้ดของไบนารีหลายตัวที่ทำงานอยู่ในระบบ และทบทวนความปลอดภัยในระดับฮาร์ดแวร์ แต่ Mullvad ตัดส่วนนี้ออก
- การตรวจสอบครั้งนี้จำกัดอยู่ที่สถานะ “หลังจากระบบกำลังทำงานและลูกค้าใช้งานแล้ว”
ผลลัพธ์โดยรวม
- RoS ไม่พบ การบันทึกข้อมูลลูกค้าหรือการรั่วไหลของข้อมูล
- Mullvad VPN relay ที่อยู่ในการทดสอบได้รับการประเมินว่ามี “สถาปัตยกรรมที่มีความสมบูรณ์สูง”
- ปัญหาที่พบจากการทดสอบเจาะระบบครั้งนี้มีทั้งหมด 25 รายการ
- High 1 รายการ
- Elevated 6 รายการ
- Moderate 4 รายการ
- Low 10 รายการ
- info 4 รายการ
MLL-024: ทราฟฟิก multihop ของระบบใช้งานจริงที่เปิดเผยต่อระบบทดสอบ
- MLL-024 ถูกจัดเป็นปัญหาระดับความรุนแรง High
- RoS เห็นว่าทราฟฟิกของผู้ใช้งานจริงอาจมองเห็นได้จากฝั่งผู้ใช้ที่ทำการทดสอบเจาะระบบ
- เซิร์ฟเวอร์ที่ใช้ตรวจสอบไม่ได้ถูกเปิดเผยสำหรับการเชื่อมต่อของลูกค้า ไม่ได้ถูกโฆษณาในรายการเซิร์ฟเวอร์ และไม่ได้ถูกนำเสนอให้ผู้ใช้ใช้งาน
- อย่างไรก็ตาม เซิร์ฟเวอร์เหล่านี้ยังเชื่อมต่ออยู่กับฟีเจอร์ WireGuard multihop
- หากลูกค้าสแกนหา IP ก็สามารถส่งทราฟฟิกมายังเซิร์ฟเวอร์ดังกล่าวผ่าน SOCKS5 proxy ขณะเชื่อมต่ออยู่กับเซิร์ฟเวอร์ VPN อื่นได้
- ไม่มีมาตรการใดที่ใช้ปิดกั้นสิ่งนี้
- สิ่งที่ RoS ยืนยันได้มีเพียง IP ของอินเทอร์เฟซภายในของ WireGuard
- อินเทอร์เฟซนี้ใช้สำหรับทราฟฟิก SOCKS5 multihop เท่านั้น
- ดังนั้นจึงสอดคล้องกับเซิร์ฟเวอร์ WireGuard ฝั่งทางเข้า
- Mullvad มองว่าหากไม่ได้จัดเตรียมเซิร์ฟเวอร์ใช้งานจริงไว้ การตรวจสอบเซิร์ฟเวอร์ใช้งานจริงก็คงไม่ถือว่าใช้ได้ และไม่มีวิธีที่จะป้องกันไม่ให้เห็นทราฟฟิกของลูกค้าบนเซิร์ฟเวอร์ดังกล่าว
MLL-019: การยกระดับสิทธิ์เป็น root ผ่าน systemd timer และสิทธิ์ของไดเรกทอรี
- MLL-019 ถูกจัดเป็นปัญหาระดับความรุนแรง Elevated
- บัญชีระบบที่มีสิทธิ์ต่ำสามารถ ยกระดับสิทธิ์เป็น root ได้หากแก้ไขเนื้อหาสคริปต์ของ systemd timer
- หลังหารือกับ RoS แล้ว Mullvad เห็นว่าสาเหตุหลักคือการใช้ home directory แบบซ้อนกันและการที่ผู้ใช้ผู้ดูแลระบบอยู่ในกลุ่ม
mad - โครงสร้างไดเรกทอรี
/home/madแบบซ้อนเป็น ร่องรอยตกค้างจากระบบเดิม ตั้งแต่ก่อนย้ายมาใช้เซิร์ฟเวอร์ VPN บน RAM - มาตรการระยะสั้นคือถอดผู้ใช้ผู้ดูแลระบบทั้งหมดออกจากกลุ่ม
mad - สคริปต์ที่เกี่ยวข้องถูกย้ายไปยัง
/opt/local_checksและ RoS ยอมรับว่าการเปลี่ยนแปลงนี้ช่วยแก้ปัญหาได้
MLL-045: การเข้าถึงเครื่องใช้งานจริงของผู้ดูแลระบบ
- MLL-045 ถูกจัดเป็นปัญหาระดับความรุนแรง Moderate
- เซิร์ฟเวอร์ VPN อนุญาตให้ผู้ดูแลระบบล็อกอินจากระยะไกลได้ ทำให้ในทางเทคนิคผู้ดูแลระบบสามารถดักจับทราฟฟิก VPN ของผู้ใช้งานจริงได้
- Mullvad รับรู้ปัญหานี้มาก่อนแล้ว และการหารือกับ RoS ก็เป็นการยืนยันแผนเดิมอีกครั้ง
- มาตรการที่วางแผนไว้มี 2 อย่าง
- ทำให้การล็อกอินที่ไม่ได้รับอนุญาตสามารถตรวจสอบย้อนหลังได้ และสร้างระบบที่บันทึกทุกคำสั่งที่ใช้บนเซิร์ฟเวอร์โดยไม่บันทึก argument
- ศึกษาแนวทางการถอดการรองรับ SSH ออกทั้งหมด
- หากถอด SSH ออก ผู้ดูแลระบบก็จะไม่สามารถเปิดใช้การบันทึกทราฟฟิกของลูกค้าผ่าน SSH ได้เช่นกัน
- แนวทางการถอด SSH ออกจะใช้เวลามากกว่าเพื่อดำเนินการให้ถูกต้อง
MLL-016: รหัสผ่าน Telegraf ที่ใช้ร่วมกันระหว่างเซิร์ฟเวอร์
- MLL-016 ถูกจัดเป็นปัญหาระดับความรุนแรง Low
- ข้อมูลรับรองฐานข้อมูล Influx ของ Telegraf ที่ใช้ร่วมกันทั่วทั้งเซิร์ฟเวอร์ VPN ทำให้สามารถแก้ไขตัวชี้วัดของเซิร์ฟเวอร์ทั่วระบบได้
- การใช้ CPU
- การใช้ดิสก์
- ตัวชี้วัดเครือข่าย
- Mullvad ได้นำ client certificate มาใช้สำหรับการยืนยันตัวตน โดยอาศัยโครงสร้างพื้นฐาน PKI ของ Hashicorp Vault
- มาตรการนี้ถูกนำไปใช้เรียบร้อยแล้ว
- Mullvad มีแผนจะพิจารณาการใช้ certificate ลักษณะนี้ในจุดอื่น ๆ ของโครงสร้างพื้นฐานด้วย
การเปลี่ยนแปลงหลังจากนี้
- ในการตรวจสอบครั้งนี้มีการสรุปเพียงบางกรณีที่น่าสนใจจากปัญหาที่ค้นพบ
- จะมีการ deploy การเปลี่ยนแปลงเพิ่มเติมอีกในอนาคตอันใกล้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมนับถือท่าทีของ Mullvad มากที่ยอมรับความเสียหายทางธุรกิจเพื่อมอบ ความปลอดภัยและเสถียรภาพเพิ่มเติม ให้ลูกค้าที่ยังอยู่
ครั้งแรกที่ผมรู้สึกแบบนั้นคือตอนที่พวกเขาปิดการต่ออายุอัตโนมัติผ่าน PayPal เพราะถ้าจะคงการต่ออายุอัตโนมัติไว้ ก็ต้องเก็บข้อมูลส่วนบุคคลไว้กับบัญชี
แต่สำหรับผม มีการเสียสละอย่างหนึ่งที่มากเกินไป นั่นคือพวกเขาปิดใช้งาน port forwarding เนื่องจากไม่เก็บข้อมูลติดต่อสำหรับเตือนลูกค้า อยู่มาวันหนึ่งการเชื่อมต่อจึงล้มเหลวทันที ทั้งที่ยังเหลือบริการแบบจ่ายล่วงหน้าอยู่อีกหลายเดือน
เรื่องนั้นทำให้รู้สึกขมขื่นอยู่บ้าง แต่ความรู้สึกดีที่สะสมมาจากงานเขียนเชิงเทคนิคและการตัดสินใจด้านความปลอดภัยของพวกเขามีมากพอ ผมเลยอยากให้เขาเก็บเงินนั้นไปเถอะ ขอให้ไปได้ดี เพราะเป็น VPN เจ้าเดียวที่ไม่ทำให้รู้สึกน่าสงสัย
https://mullvad.net/en/blog/2023/5/29/removing-the-support-f...
โดยทั่วไปแล้ว การแจ้งล่วงหน้าเพียง 30 วันก่อนถอดฟีเจอร์แบบนี้ ไม่ใช่วิธีดำเนินธุรกิจที่เราอยากทำ ลูกค้าที่พึ่งพาฟีเจอร์นี้คงผิดหวังทั้งกับการถอดฟีเจอร์เองและวิธีที่เราจัดการเรื่องนี้
ถึงอย่างนั้น นั่นก็เป็นการตัดสินใจที่ถูกต้อง ในช่วงไม่กี่เดือนที่ผ่านมา รูปแบบและขนาดของการนำไปใช้ในทางที่ผิดเพิ่มขึ้นมากจนเราไม่สามารถให้บริการต่อได้อีก ฟีเจอร์นี้ควรถูกถอดออกไปนานแล้ว พร้อมระยะผ่อนผันที่ยาวกว่านี้ การที่เราไม่ได้ทำเช่นนั้นเป็นความผิดพลาดของเรา และผู้ใช้บางส่วนรวมถึงคุณได้รับผลกระทบ
สำหรับบริการแบบจ่ายล่วงหน้าที่ไม่สามารถใช้งานได้แล้ว แน่นอนว่าคุณสามารถขอคืนเงินได้
หากคุณตั้งใจใช้ port forwarding เพื่อทำให้บริการบางอย่างเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ มีผู้ให้บริการโฮสติ้งดี ๆ มากมายที่ยินดีให้บริการ
หากเป้าหมายคือทำให้บริการเข้าถึงได้พร้อมกับรักษาความไม่ระบุตัวตนไว้ ผมขอแนะนำฟีเจอร์ onion service ของ Tor อย่างยิ่ง ฟีเจอร์นี้ถูกสร้างขึ้นโดยคำนึงถึงกรณีการใช้งานแบบนั้นโดยตรง
หากเป้าหมายคือทำให้บริการเข้าถึงได้จากอินเทอร์เน็ตสาธารณะและในขณะเดียวกันก็รักษาความไม่ระบุตัวตนไว้ด้วย เราไม่มีตัวเลือกดี ๆ ที่จะแนะนำได้
เราจำเป็นต้องถอด port forwarding ออกด้วย เหตุผลทางศีลธรรม เพราะมันกำลังเป็นอุปสรรคมากเกินไปต่อภารกิจหลักของเราในการทำให้การสอดส่องและการเซ็นเซอร์ในวงกว้างไร้ผล
แม้คำอธิบายนี้จะไม่อาจคลายความผิดหวังทั้งหมดได้ แต่อย่างน้อยก็หวังว่าจะช่วยให้เรื่องนี้ชัดเจนขึ้นบ้าง
Fredrik Stromberg, ผู้ร่วมก่อตั้ง Mullvad VPN
ตอนใช้ torrent ก็เคยตั้งค่า port forwarding ด้วย แต่ตอนนี้รู้แล้วว่าไม่มีมันก็ยังดาวน์โหลด Linux ISO ได้ ผมใช้ Mullvad ค่อนข้างเยอะ แต่ก็ไม่ได้ใส่ใจมากนัก
เลยสงสัยว่าถ้า port forwarding ถูกปิด จะเริ่มกระทบผมเมื่อไร หรือพูดอีกอย่างคือ use case แบบไหนที่จะใช้ไม่ได้
ถ้าผมย้ายจริง ๆ ก็คงตกอยู่ในสถานการณ์เดียวกัน คือมีบริการแบบจ่ายล่วงหน้าเหลืออยู่มาก แต่ใช้ตามที่ตั้งใจไม่ได้
ความเสียใจที่สุดในอาชีพของผมคือการไม่ได้ไปร่วมงานตอนที่ผู้ก่อตั้ง Mullvad ส่งอีเมลมา
ค่านิยมของพวกเขาหลายอย่างตรงกับค่านิยมของผม และคนรักเทคโนโลยีที่ให้ความสำคัญกับ เสรีภาพ มากกว่าความสะดวกสบายนั้นน่าเสียดายที่หาได้ยากมาก ดังนั้นพวกเราส่วนใหญ่จึงลงเอยด้วยการใช้ผู้ให้บริการคลาวด์รายใหญ่ที่อยู่ภายใต้อำนาจศาลของรัฐบาลสหรัฐฯ
ขอพูดไว้ก่อนว่า เรื่องนี้เป็นปัญหาจริงในอาชีพของผมด้วย ผู้ให้บริการคลาวด์ต้องปฏิบัติตามมาตรการคว่ำบาตรของสหรัฐฯ ดังนั้นถ้าคุณมาจากคิวบา อิหร่าน หรือไครเมีย คุณก็เล่นเกมที่ผมทำไม่ได้ ในรัสเซียและยูเครนสามารถซื้อเกมของเราได้อย่างถูกกฎหมาย แต่มันน่าหงุดหงิดที่ถ้าอยู่ในพื้นที่ยึดครองกลับเล่นไม่ได้
พูดออกนอกเรื่องไปหน่อย แต่จากมุมมองคนนอก การได้เห็นบริษัทที่ดูไม่น่าสงสัยและให้ความสำคัญกับเสรีภาพนั้นสดชื่นมากจริง ๆ
แม้แต่บางที่ที่มี ใบอนุญาต OFAC ที่ถูกต้อง ก็ยังปฏิเสธการเข้าถึง อาจเป็นเพราะ access control list ซับซ้อน และโดยรวมแล้วแต่ละที่ก็ไม่เหมือนกัน
ดังนั้น 95% ของเวลา ผมจึงเปิด VPN ห่วย ๆ ไว้ เพราะต้องหลบทั้งมาตรการคว่ำบาตรของสหรัฐฯ และระบบเซ็นเซอร์ของประเทศผมเอง
ผมพอเข้าใจอยู่บ้างว่าทำไมมาตรการคว่ำบาตรจึงเกิดขึ้นเมื่อหลายสิบปีก่อน แต่ไม่รู้ว่าเหตุผลนั้นยังใช้ได้อยู่หรือไม่ น่าเศร้าที่คนที่ได้รับผลกระทบมากที่สุดจากการคว่ำบาตรคือคนธรรมดาอย่างผม ไม่ใช่ชนชั้นนำผู้ปกครองเลย
ผมมองว่าบริการนั้นช่วยคนที่กำลังเริ่มธุรกิจเล็ก ๆ ได้ และอาจช่วยให้ชีวิตดีขึ้นด้วย
อย่างไรก็ตาม หลายคนมองว่ามาตรการคว่ำบาตรเป็นการกระทำสงคราม[0] ถ้าคิดแบบนั้น มันก็ย่อมเลวร้าย สงครามก็คือสงคราม และผลลัพธ์แบบสงครามก็มักทำให้คนที่อยู่หน้างานต้องเจ็บปวด
ถ้าเจ้านายสั่งให้ implement การบล็อกตามภูมิภาคเพราะมาตรการคว่ำบาตร ก็ควรทำเท่าที่จำเป็น และอย่าทำเกินเลยถึงขั้นบล็อกผู้ใช้ VPN ด้วย หมายความว่าอย่าละเมิดกฎหมาย แต่ก็อย่าทำให้คนที่อยู่หน้างานใช้ สิทธิในการเข้าถึงอินเทอร์เน็ต ได้ยากขึ้น
https://moderndiplomacy.eu/2022/06/29/economic-sanctions-as-...
ก่อนอื่นต้องบอกว่า Mullvad เป็นโซลูชัน VPN เชิงพาณิชย์ที่ดีที่สุด และผมคิดว่าพวกเขาทำได้ดีในการทำให้การปกป้องความเป็นส่วนตัวที่ดีเข้าถึงได้มากขึ้น
แต่คอมเมนต์จำนวนมากที่นี่ดูเหมือนจะยกย่อง VPN โดยทั่วไปว่าเป็นคำตอบของความเป็นส่วนตัวบนอินเทอร์เน็ต
ผมอยากย้ำว่า สิ่งที่ VPN ปกป้องได้จริง ๆ โดยพื้นฐานมีแค่สองอย่างคือ ผู้ให้บริการอินเทอร์เน็ต และ ปลายทาง เท่านั้น แถมยังต้องตั้งอยู่บนสมมติฐานว่าผู้ให้บริการอินเทอร์เน็ตไม่ได้ทำการวิเคราะห์ที่น่าสงสัยด้วย
ถึงอย่างนั้น การกำจัดสองอย่างนี้ออกไปก็ให้ประโยชน์ด้านความเป็นส่วนตัวอย่างมาก และแน่นอนว่าเป็นสิ่งที่ควรทำ
ในชื่อเรื่องขาดคำว่า Radically ไป “Open Security” ผมไม่รู้จัก แต่ “Radically Open Security” คือที่ที่ผมเคยเขียนรายงานไว้
แก้ไข: u/progbits เร็วกว่าผม 1 นาที https://news.ycombinator.com/item?id=37060828
แน่นอนว่าในระบบที่ผมรับผิดชอบ พวกเขาไม่พบอะไรนอกจากคอมเมนต์เล็กน้อยไม่กี่ข้อ คอมเมนต์พวกนั้นก็เป็นระดับที่เครื่องมือ static analysis ทำเครื่องหมายไว้ว่าเป็นจุดที่ควรปรับปรุง และพวกเราก็ใส่คอมเมนต์กำกับไว้อย่างชัดเจนแล้ว เช่น “ตรงนี้ตั้งชื่อตัวแปรให้ดีกว่านี้ได้”, “ใช้ guard clause แล้วทำให้ง่ายลงได้”
ถ้าเทียบกับการทำขึ้นมาภายใต้สถานการณ์สุดโต่งและแทบไม่ได้นอน ก็ถือว่าไม่แย่เลย เด็กทารก 6 เดือน, COVID, crunch, และเด็กเล็กซุกซนอีกสองคนมารวมกันนี่นรกชัด ๆ
Mullvad เป็น VPN กระแสหลักเพียงรายเดียว ที่ไม่มีปัญหาความน่าเชื่อถือที่น่าสงสัยอย่างรุนแรง
แม้แต่ Proton VPN ก็ไม่ได้โอเค คนที่ตามสืบพบว่ามันเป็นเพียงเวอร์ชัน white-label ของ NordVPN เท่านั้น
เพราะไม่มีทางเลือกอื่น ผมจึงขอบคุณที่ Mullvad ผลักดันคำมั่นด้านความซื่อตรงให้หนักแน่นยิ่งขึ้น
แก้ไข: ลองดูประวัติการโพสต์แล้ว ดูเหมือนคุณจะพูดข้อกล่าวหานี้มาหลายเดือนแต่ไม่เคยให้หลักฐานเลย น่าสงสัยนะ
ควรเป็น “by Radically Open Security” แต่การลบชื่ออัตโนมัติของ HN พังอีกแล้ว คนโพสต์ต้นฉบับช่วยแก้ชื่อเรื่องให้ชื่อบริษัทแสดงถูกต้องได้ไหม?
ดูเหมือนว่า audit ครั้งนี้ตรวจแค่ เซิร์ฟเวอร์ production สำหรับทดสอบ เท่านั้น
ลองรับบทเป็นฝ่ายค้านดู อะไรจะป้องกันไม่ให้ Mullvad ส่งเวอร์ชันที่เอาฟังก์ชัน logging ออกแล้วให้ทีม Open Security ตรวจ? ผมไม่อยากมองโลกในแง่ระแวงแบบนี้ แต่ถ้าเป็น audit จริง ๆ ไม่ควรตรวจเซิร์ฟเวอร์ที่ลูกค้าใช้เหรอ? แน่นอนว่าต้องมีขอบเขตเพื่อไม่ให้ auditor บันทึกข้อมูลได้
ถ้าผมเข้าใจผิดก็บอกได้ แต่ผมไม่มั่นใจว่าการทดสอบระดับนี้จะพิสูจน์คำกล่าวอ้างเรื่องไม่เก็บ log ของ Mullvad ได้
ต้องมีความเชื่อใจในระดับหนึ่งว่าผู้ถูก audit ไม่ได้จงใจหลอกหรือมีเจตนาร้าย ไม่อย่างนั้น audit ต้องทำแบบสุ่มได้ทุกเมื่อ
ผมคิดว่ามันเกี่ยวข้องกับ threat model ที่ผู้โจมตีเข้าถึงเซิร์ฟเวอร์ production ได้บางส่วน เช่น เรื่องไม่มีการ logging โดยไม่ตั้งใจ ในทางกลับกัน มันไม่ครอบคลุม threat model ที่ Mullvad ปล่อยโค้ดอันตรายเอง
ผมรู้สึกว่าเป็น audit ที่มีความหมาย แต่คงจะดีถ้าระบุประเด็นนี้ให้ชัดเจนกว่านี้
แน่นอนว่ามันไม่สมบูรณ์แบบ เพราะผู้ให้บริการ VPS ยังเห็นทราฟฟิกฝั่งหนึ่งได้ แต่ก็ลดความเสี่ยงได้
Mullvad เป็นจุดกึ่งกลางที่ดีสำหรับคนที่ไม่มีเวลาหรือไม่รู้วิธีทำ อย่างน้อยการที่พวกเขาพยายามรักษาภาพลักษณ์ไว้ก็ดูดี
จากนั้นอาจต่อยอดไปเป็นการ audit เซิร์ฟเวอร์ที่ใช้งานจริงได้
ถ้าจะ audit เซิร์ฟเวอร์ที่ลูกค้ากำลังใช้อยู่ จำเป็นต้องมีการควบคุมอย่างมากเพื่อไม่ให้ auditor บันทึกข้อมูลลูกค้าที่อาจมีอยู่ได้
ผมนึกภาพอนาคตที่ Mullvad จะลำบากได้ไม่ยาก เพราะบริษัทเทคโนโลยีขนาดใหญ่อาจบล็อกช่วงแบนด์ทั้งหมดของดาต้าเซ็นเตอร์ Mullvad ได้
ตอนนี้ก็มีเรื่องแบบนั้นอยู่บ้างแล้วระหว่าง Cloudflare กับผู้ดูแลระบบแต่ละราย และดูเหมือนว่าถ้าเชื่อมต่อผ่าน Mullvad ก็อาจถูกบล็อกไม่ให้ใช้ ChatGPT ได้ อย่างน้อยก็ดูมีความเกี่ยวข้องกัน
ท้ายที่สุด หากจะเข้าถึงหรือ scrape อะไรบางอย่าง อาจต้องใช้ พร็อกซีที่อยู่อาศัย ที่น่าสงสัย
VPS ที่โฮสต์เองก็อาจใช้ได้ หากบริษัทเล็กพอที่จะหลบการบล็อกแบบเหมารวมที่จะมาถึงในอนาคต แต่เวลาก็จะเป็นคำตอบ
ผมย้ายมาใช้ Mullvad หลังจากเคยอ่านใน HN ว่า Mullvad ไม่ได้เก็บ log และไม่มี log ให้ส่งมอบแก่ทางการ
ไม่มีลิงก์ แต่เป็นเรื่องที่น่าประทับใจ และ audit เหล่านี้ก็เป็นหลักฐานเพิ่มเติมว่าการตัดสินใจครั้งนั้นถูกต้อง
รายละเอียดดูได้จากลิงก์ แต่ขอยกคำกล่าวว่า “Rights Alliance และผู้เชี่ยวชาญด้านความปลอดภัยของพวกเขาไม่สามารถพิสูจน์ช่องโหว่ในระบบของ OVPN ที่หมายความว่า log อาจถูกจัดเก็บได้”
https://www.ovpn.com/en
https://www.ovpn.com/en/blog/ovpn-wins-court-order
เพิ่งรู้จัก Mullvad เมื่อไม่นานมานี้ รู้สึกว่าเคยทำสัญญากับ Mozilla ด้วย
อย่างไรก็ดี บริการยอดเยี่ยมมาก และน่าประหลาดใจที่การจ่ายเงินใช้บริการได้เลยโดยไม่ต้องผ่านขั้นตอนจุกจิกไร้สาระสารพัดแบบนี้กลับหาได้ยากมาก
ถ้าจะสร้างบัญชี ก็คลิกที่นี่ แล้วจากนั้นก็จ่ายเงินผ่านวิธีชำระเงินแบบใดแบบหนึ่งจากตัวเลือกมากมายได้เลย รวมถึงการส่งเงินสดทางไปรษณีย์ด้วย