คุณอยู่ในร้านกาแฟที่เอสเปรสโซดีแต่ Wi-Fi น่าสงสัย และต้องใช้เดสก์ท็อปที่บ้าน การเชื่อมต่อปลอดภัยไหม? ขึ้นอยู่กับการเข้ารหัสของการขนส่งทั้งหมด — เซสชันที่เข้ารหัสแบบ end-to-end ปลอดภัยบนเครือข่ายที่น่าสงสัยที่สุดในเมือง และโปรโตคอลแบบเดิมที่ไม่เข้ารหัสไม่ปลอดภัยแม้บนเครือข่ายที่ดีที่สุด นี่คือโมเดลภัยคุกคามด้วยภาษาธรรมดา โปรโตคอลที่เรียงตามสิ่งที่รั่ว และเช็กลิสต์สำหรับครั้งต่อไปที่คุณเชื่อมต่อจากที่ที่คุณควบคุมไม่ได้
Wi-Fi สาธารณะเห็นอะไรได้จริง
บนเครือข่ายที่คุณควบคุมไม่ได้ มีสองฝ่ายที่อยู่ในตำแหน่งสังเกตทราฟฟิกของคุณได้ ฝ่ายแรกคือผู้ดำเนินการ — ผู้ที่ดูแลแอคเซสพอยต์และเราเตอร์ที่อยู่เบื้องหลัง ซึ่งบน Wi-Fi สาธารณะหมายถึงสถานที่ ผู้รับเหมาเครือข่ายของสถานที่ หรือใครก็ตามที่ตั้งแอคเซสพอยต์เงียบ ๆ ด้วยชื่อของสถานที่นั้น ฝ่ายที่สองคืออุปกรณ์อื่นที่อยู่ใกล้: บนเครือข่ายที่ไม่มีการแยกไคลเอนต์ แล็ปท็อปที่อยู่ห่างไปสองโต๊ะจับทราฟฟิกที่เคลื่อนที่รอบ ๆ ได้ "สังเกต" หมายถึงบันทึกแพ็กเก็ตที่คุณส่งและรับ คำถามทั้งหมดคือแพ็กเก็ตเหล่านั้นมีอะไร
- ถ้าโปรโตคอลไม่เข้ารหัส แพ็กเก็ตมีเนื้อหา สำหรับรีโมทเดสก์ท็อป แย่เท่าที่ฟังดู: เฟรมหน้าจอ ทุกการกดแป้นที่คุณส่ง — รวมถึงรหัสผ่านที่พิมพ์ลงบนเครื่องระยะไกล — และในกรณีโปรโตคอลเก่าที่แย่ที่สุด ข้อมูลรับรองที่แลกเปลี่ยนตอนเชื่อมต่อ
- ถ้าโปรโตคอลเข้ารหัสอย่างถูกต้อง แพ็กเก็ตมีแต่ไซเฟอร์เท็กซ์ การสังเกตเหลือแค่เมตาดาตา: คุณแลกเปลี่ยนทราฟฟิกกับปลายทางใด เมื่อไร และมากแค่ไหน พอที่จะอนุมานได้ว่าคุณใช้แอปรีโมทเดสก์ท็อป แต่ไม่มีประโยชน์ในการกู้คืนว่าเกิดอะไรขึ้นภายในเซสชัน
ควรปรับความเข้าใจกับความเป็นจริงปัจจุบัน ไม่ใช่เรื่องสยองขวัญปี 2010 ทราฟฟิกส่วนใหญ่ที่แล็ปท็อปสร้างวันนี้เข้ารหัสอยู่แล้ว — HTTPS เอาความตื่นเต้นของการดักฟังร้านกาแฟแบบสบาย ๆ ออกไป ภัยคุกคามที่เหลือในความเป็นจริงคือการสังเกตเมตาดาตาและแอคเซสพอยต์ปลอม: ผู้โจมตีกระจายชื่อเครือข่ายของสถานที่เพื่อวางตัวเองบนเส้นทาง หวังจะจับสิ่งที่เจรจาแบบอ่อน — โปรโตคอลเก่า การแจ้งเตือนใบรับรองที่ไม่ระวัง อุปกรณ์ที่เข้าร่วมชื่อคุ้นเคยอัตโนมัติ นั่นไม่ใช่เหตุผลให้กลัวเครือข่าย แต่เป็นคำอธิบายที่แม่นยำว่าควรนำเครื่องมืออะไรไป: เครื่องมือที่ไม่เจรจาแบบอ่อน
โปรโตคอล เรียงตามสิ่งที่รั่ว
ชื่อผลิตภัณฑ์สำคัญน้อยกว่าการตั้งค่า — ซอฟต์แวร์เดียวกันอาจปกติหรือน่ากลัวขึ้นกับเวอร์ชันและการตั้งค่า ลำดับด้านล่างจึงเรียงตามการตั้งค่า แย่ที่สุดก่อน
- RDP ธรรมดาที่ไม่มี TLS หรือ NLA (แบบเดิม) ชั้นความปลอดภัยดั้งเดิมของ RDP มีมาก่อนความปลอดภัยการขนส่งสมัยใหม่ และไคลเอนต์ที่ยอมเจรจามันอาจถูกคนกลางพาถอยไปที่ชั้นนั้นได้ Windows รุ่นปัจจุบันตั้งต้นที่ TLS พร้อม Network Level Authentication ดังนั้นส่วนใหญ่นี่หมายถึงโฮสต์เก่า ไคลเอนต์เก่า และนโยบายกลุ่มที่ผ่อนปรนเพื่อความเข้ากันได้ — แต่บนเครือข่ายที่ไม่เป็นมิตร เซสชันที่ถูกลดระดับได้ควรถือว่าอ่านได้
- VNC ที่ไม่เข้ารหัส โปรโตคอล VNC แบบคลาสสิกส่ง framebuffer — หน้าจอจริงของคุณ — แบบชัดแจ้ง และการล็อกอินแบบ challenge-response ดั้งเดิมอ่อนตามมาตรฐานสมัยใหม่ โดยรหัสผ่านมักจำกัดที่แปดตัวอักษร เซิร์ฟเวอร์และไคลเอนต์บางตัวซ้อน TLS หรือรันผ่าน SSH การตั้งค่ารวดเร็วหลายแบบไม่ทำ VNC ที่ไม่เข้ารหัสบน Wi-Fi ที่ใช้ร่วมกันรั่วสิ่งที่อยู่บนหน้าจอให้ทุกคนที่บันทึกแพ็กเก็ต
- RDP พร้อม TLS และ NLA ค่าเริ่มต้นสมัยใหม่ และบนสายก็ไว้ใจได้: เซสชันเข้ารหัสการขนส่งจากไคลเอนต์ของคุณถึงโฮสต์หรือเกตเวย์ และ NLA ต้องการการยืนยันตัวตนก่อนสร้างเซสชันด้วยซ้ำ บน Wi-Fi สาธารณะ จุดอ่อนเชิงปฏิบัติคือมนุษย์ — ใบรับรองที่ลงนามเองทำให้การแจ้งเตือนเป็นเรื่องปกติ และผู้ใช้ที่ถูกฝึกให้คลิกผ่านคือสิ่งที่แอคเซสพอยต์ปลอมหวัง การเข้ารหัสการขนส่งก็ไม่ได้บอกอะไรเรื่องการเปิดเผย: พอร์ต 3389 ที่เปิดสู่อินเทอร์เน็ตเป็นความผิดพลาดอีกแบบที่มีเอกสารชัดเจนไม่ว่าคุณจะเชื่อมต่อจากที่ไหน
- แอปเข้ารหัสแบบ end-to-end สมัยใหม่ เซสชันถูกเข้ารหัสจากอุปกรณ์ถึงอุปกรณ์ก่อนที่เครือข่ายใดจะแตะ เครือข่ายโรงแรม — และทุกอย่างที่เลยไป — เห็นเมตาดาตาการเชื่อมต่อ: ไซเฟอร์เท็กซ์ที่ไหลระหว่างปลายทาง พร้อมจังหวะเวลาและปริมาณ ไม่เห็นพิกเซล ไม่เห็นการกดแป้น ไม่เห็นข้อมูลรับรอง เพราะไม่มีข้อมูลรับรองของโปรโตคอลให้ขโมย
| การตั้งค่า | สิ่งที่ผู้สังเกตบนเครือข่ายได้ | คำตัดสินบน Wi-Fi สาธารณะ |
|---|---|---|
| RDP ธรรมดา ไม่มี TLS/NLA | เนื้อหาเซสชันในที่ที่การลดระดับสำเร็จ ข้อมูลรับรองเสี่ยง | ห้ามใช้ — ถือว่าอ่านได้ |
| VNC ที่ไม่เข้ารหัส | เนื้อหาหน้าจอแบบชัดแจ้ง การจับมือล็อกอินอ่อน | ห้ามใช้ |
| RDP พร้อม TLS + NLA | ไซเฟอร์เท็กซ์ระหว่างทาง การแจ้งเตือนใบรับรองคือจุดอ่อน | ยอมรับได้ผ่านอุโมงค์ ห้ามเปิด 3389 |
| แอป E2EE สมัยใหม่ | ไซเฟอร์เท็กซ์และเมตาดาตาการเชื่อมต่อเท่านั้น | สร้างมาเพื่อสิ่งนี้โดยเฉพาะ |
ทำไม E2EE เปลี่ยนคำตอบ
การเข้ารหัสการขนส่งปกป้องหนึ่งฮอป การเข้ารหัสแบบ end-to-end ปกป้องบทสนทนา ความต่างฟังดูเป็นวิชาการจนกว่าคุณจะไล่ว่าใครอยู่ระหว่างร้านกาแฟกับเดสก์ท็อปที่บ้านของคุณ: แอคเซสพอยต์ของสถานที่ ISP ของมัน ISP ของคุณ อาจมีเซิร์ฟเวอร์รีเลย์ของผู้ให้บริการ ด้วยการเข้ารหัสแบบ end-to-end กุญแจตกลงกันโดยตรงระหว่างสองอุปกรณ์ของคุณ และเฟรมถูกเข้ารหัสก่อนที่จะออกจากอุปกรณ์ ทุกฝ่ายในรายการนั้น — รวมถึงโครงสร้างพื้นฐานของผู้ให้บริการเอง — ส่งต่อไซเฟอร์เท็กซ์ที่ไม่มีกุญแจ
Remio สร้างบนโมเดลนี้พอดี จึงเป็นตัวอย่างที่ใช้งานจริง ความไว้วางใจเกิดขึ้นเมื่อคุณจับคู่สองอุปกรณ์ด้วย QR code หรือ Device ID และ PIN ที่อ่านจากหน้าจอของโฮสต์ — ไม่มีบัญชี จึงไม่มีรหัสผ่านให้ฟิชชิงที่ร้านกาแฟและไม่มีฐานข้อมูลข้อมูลรับรองที่ใดให้เจาะ กุญแจเซสชันถูกเจรจาโดยตรงระหว่างอุปกรณ์ที่จับคู่แล้วทุกการเชื่อมต่อ และทุกเฟรม การกดแป้น การซิงก์คลิปบอร์ด และการถ่ายโอนไฟล์ถูกเข้ารหัสแบบ end-to-end เมื่อเครือข่ายที่เข้มงวดบังคับให้เซสชันผ่านรีเลย์ที่เข้ารหัส รีเลย์ส่งต่อเฟรมที่เข้ารหัสซึ่งมันอ่านไม่ได้ — โมเดลความปลอดภัยเหมือนกันไม่ว่าเส้นทางจะตรงหรือผ่านรีเลย์ การออกแบบทั้งหมดอยู่ในหน้าความปลอดภัย
เป้าหมายไม่ใช่การหา Wi-Fi ที่น่าเชื่อถือ แต่คือการทำให้ความน่าเชื่อถือของ Wi-Fi ไม่เกี่ยวข้อง
ขอบเขตที่ซื่อตรงข้อหนึ่ง: การเข้ารหัสแบบ end-to-end ปกป้องเซสชันระหว่างทาง และไม่มีอะไรอื่น ถ้าแล็ปท็อปในร้านกาแฟถูกเจาะ หรือโฮสต์ที่บ้านถูกเจาะ ไซเฟอร์ที่แข็งแรงที่สุดระหว่างสองเครื่องก็ไม่เปลี่ยนอะไร — ผู้โจมตีอยู่ภายในปลายทาง อ่านสิ่งที่คุณอ่าน สุขอนามัยของปลายทาง ประวัติการถูกเจาะของผู้ให้บริการ และภาพรวมการเสริมความแข็งแกร่งที่เหลือเป็นบทความอื่น และเราเขียนไว้แล้ว: คู่มือความปลอดภัยของรีโมทเดสก์ท็อป บทความนี้อยู่ที่เครือข่าย
เช็กลิสต์สำหรับร้านกาแฟ
หกข้อ เรียงตามลำดับที่คุ้มค่า
- เลือกแอปรีโมทเดสก์ท็อปที่เข้ารหัสแบบ end-to-end มันตัดสินคำถามเรื่อง Wi-Fi สาธารณะด้วยการออกแบบ ไม่ใช่ด้วยวินัย — เครือข่ายขนไซเฟอร์เท็กซ์ไม่ว่าคุณจะทำข้ออื่นในรายการนี้ถูกหรือไม่
- ถ้าคุณจำเป็นต้องใช้ RDP อย่าเปิดพอร์ต 3389 เข้าถึงผ่าน VPN หรืออุโมงค์เข้ารหัสอื่นแทนการทำ port forward ที่เราเตอร์ ทางเลือกอื่น รวมถึงแอปที่เชื่อมต่อออกอย่างเดียวและไม่ต้องเปลี่ยนเราเตอร์เลย อยู่ในคู่มือเรื่องรีโมทเดสก์ท็อปโดยไม่ต้อง port forwarding
- ให้ไฟร์วอลล์ของระบบปฏิบัติการถือว่าเครือข่ายเป็นสาธารณะ เมื่อ macOS หรือ Windows ถามว่าคุณเข้าร่วมเครือข่ายประเภทใด โปรไฟล์สาธารณะคือคำตอบที่ถูก — ช่วยไม่ให้การแชร์ไฟล์ การค้นพบ และบริการที่ฟังอยู่อื่น ๆ มองเห็นได้โดยคนแปลกหน้าบนเครือข่ายเดียวกัน
- อัปเดตไคลเอนต์อยู่เสมอ ไคลเอนต์รีโมทเดสก์ท็อปแยกวิเคราะห์ข้อมูลซับซ้อนที่มาจากเครือข่ายที่คุณตัดสินใจแล้วว่าไม่ไว้ใจ แพตช์มีอยู่ด้วยเหตุผล บนเครื่องที่เดินทาง การอัปเดตอัตโนมัติคือการตั้งค่าที่ถูกต้อง
- ตรวจสอบว่าคุณอยู่บนเครือข่ายจริงของสถานที่ ถามชื่อเครือข่ายที่แน่นอนและเมินชื่อที่ลอกเลียน — แอคเซสพอยต์กระจายชื่อใดก็ได้ที่เจ้าของพิมพ์ การสั่งให้แล็ปท็อปลืมเครือข่ายเมื่อคุณออกก็ป้องกันไม่ให้มันเข้าร่วมของปลอมโดยอัตโนมัติในเดือนหน้า
- ถือว่าตัวเซสชันเองเป็นสิ่งที่อ่อนไหว คุณกำลังควบคุมเครื่องที่บ้านหรือที่ทำงานจากห้องสาธารณะ: ระวังว่าใครมองเห็นหน้าจอคุณ และล็อกโฮสต์ระยะไกลเมื่อตัดการเชื่อมต่อเพื่อไม่ให้ทิ้งเดสก์ท็อปที่เปิดอยู่ไว้ข้างหลัง
แล้ว VPN ซ้อนด้านบนล่ะ?
VPN เข้ารหัสทุกอย่างระหว่างอุปกรณ์ของคุณกับเซิร์ฟเวอร์ VPN และบน Wi-Fi ที่ไม่น่าไว้ใจ มีประโยชน์จริง — ปกป้องการค้นหา DNS การคุยเบื้องหลังของแอป และทราฟฟิกที่ไม่เข้ารหัสหลุดมาจากเครือข่ายภายใน ถ้าคุณจะรันมันที่สนามบินอยู่แล้ว ไม่มีอะไรเกี่ยวกับรีโมทเดสก์ท็อปที่คัดค้าน
แต่สำหรับเซสชันรีโมทเดสก์ท็อปโดยเฉพาะ ตรรกะแคบกว่าและมีสองด้าน VPN ไม่จำเป็นสำหรับเซสชันที่เข้ารหัสแบบ end-to-end: ทราฟฟิกเป็นไซเฟอร์เท็กซ์อยู่แล้วก่อนถึงอุโมงค์ VPN จึงเพิ่มหนึ่งฮอป (และมักมีความหน่วงบ้าง) โดยไม่เพิ่มความลับที่เซสชันขาด และไม่เพียงพอสำหรับเซสชันที่ไม่เข้ารหัส: VPN เชิงพาณิชย์ปกป้องเส้นทางไปถึงเซิร์ฟเวอร์ทางออกของ VPN จากนั้นทราฟฟิกไปต่อที่โฮสต์ในสภาพเปิดเผยเหมือนตอนเริ่ม ข้อยกเว้นที่พิสูจน์กฎคืออุโมงค์ที่สิ้นสุดภายในเครือข่ายปลายทางเอง — เซิร์ฟเวอร์ WireGuard บนเราเตอร์ที่บ้าน VPN องค์กรเข้าออฟฟิศ — ซึ่งครอบคลุมเส้นทางทั้งหมดและเป็นวิธีมาตรฐานในการใช้ RDP จากระยะไกล ถ้าคุณกำลังชั่งใจระหว่าง VPN กับแอปรีโมทเดสก์ท็อปในฐานะวิธีเข้าถึงเอง นั่นเป็นการเปรียบเทียบอีกแบบ และมีบทความของตัวเอง: รีโมทเดสก์ท็อปเทียบ VPN
โรงแรม สนามบิน มหาวิทยาลัย: ความแปลกของเครือข่ายที่ทำให้การเชื่อมต่อพัง
นอกจากเรื่องความปลอดภัย เครือข่ายสาธารณะยังมีนิสัยอีกอย่าง: ทำให้การเชื่อมต่อพังในแบบที่เครือข่ายบ้านไม่ทำ สามความแปลกอธิบายส่วนใหญ่
- Captive portal จนกว่าคุณจะเปิดเบราว์เซอร์และยอมรับข้อกำหนด เครือข่ายจะทิ้งทุกอย่าง — แอปรีโมทเดสก์ท็อปจะนั่งล้มเหลวโดยไม่มีเหตุผลที่เห็นได้ ผ่านพอร์ทัลก่อน และถ้าเซสชันที่ใช้ได้ทั้งบ่ายตายในชั่วโมงที่สาม ให้สงสัยพอร์ทัลที่ยืนยันตัวตนใหม่ตามตัวจับเวลา
- การแยกไคลเอนต์ โรงแรมและมหาวิทยาลัยมักบล็อกทราฟฟิกระหว่างอุปกรณ์ภายในเครือข่าย อุปกรณ์สองเครื่องของคุณในห้องเดียวกันจึงอาจมองไม่เห็นกันบน LAN แอป P2P ที่เชื่อมต่อออกอย่างเดียวยังเชื่อมต่อได้ — ทั้งสองอุปกรณ์โทรออกและพบกันข้ามอินเทอร์เน็ต — แต่เส้นทางอาจยาวกว่าห้องที่คุณนั่ง
- การบล็อก UDP เครือข่ายแขกที่เข้มงวดบางครั้งอนุญาตแทบไม่มีอะไรนอกจาก TCP บนพอร์ตเว็บ โปรโตคอลเรียลไทม์ชอบ UDP ตรงนี้คือที่ที่แอปต่างกัน: แอปที่มี TCP และรีเลย์สำรองเชื่อมต่อได้ต่อไป โดยเสียความหน่วงบ้าง ขณะที่การตั้งค่า UDP อย่างเดียวติดขัด กลไก — การค้นหาที่อยู่ hole punching และสิ่งที่สำรองเมื่อไร — อยู่ในคำอธิบาย NAT traversalของเรา และพอร์ตกับโปรโตคอลที่เซสชันใช้อยู่ในเอกสารไฟร์วอลล์และ NAT
คำถามที่พบบ่อย
ใช้รีโมทเดสก์ท็อปบน Wi-Fi โรงแรมปลอดภัยไหม?
ปลอดภัย ถ้าเซสชันเข้ารหัสแบบ end-to-end ด้วยแอปรีโมทเดสก์ท็อป E2EE สมัยใหม่ เครือข่ายโรงแรมขนแค่ไซเฟอร์เท็กซ์ ทั้งผู้ดำเนินการและแขกคนอื่นจึงกู้คืนหน้าจอ การกดแป้น หรือไฟล์ของคุณไม่ได้ การตั้งค่าแบบเดิมคือกรณีเสี่ยง: RDP ที่ไม่มี TLS และ NLA หรือ VNC ที่ไม่เข้ารหัส อาจเปิดเผยเนื้อหาเซสชันและข้อมูลรับรองให้เครือข่าย และไม่ควรใช้บน Wi-Fi โรงแรมโดยไม่มีอุโมงค์เข้ารหัส
คนบน Wi-Fi เดียวกันเห็นหน้าจอระยะไกลของฉันได้ไหม?
ไม่ได้ ถ้าเซสชันเข้ารหัสแบบ end-to-end คนบนเครือข่ายเดียวกันจับแพ็กเก็ตของคุณได้ แต่กับ E2EE แพ็กเก็ตเหล่านั้นเป็นไซเฟอร์เท็กซ์ และกุญแจมีอยู่เฉพาะบนสองอุปกรณ์ของคุณ เนื้อหาหน้าจอจึงกู้คืนจากการจับไม่ได้ สิ่งที่ผู้สังเกตบนเครือข่ายเดียวกันยังเห็นได้คือเมตาดาตา — ว่ามีการเชื่อมต่อ เมื่อไรที่มันทำงาน และมันเคลื่อนข้อมูลประมาณเท่าไร
ต้องใช้ VPN เพื่อใช้ Remio บน Wi-Fi สาธารณะไหม?
ไม่ เซสชัน Remio เข้ารหัสแบบ end-to-end อยู่แล้ว — กุญแจถูกเจรจาโดยตรงระหว่างอุปกรณ์ของคุณทุกเซสชัน — เซสชันจึงไม่ขึ้นกับว่าเครือข่ายน่าเชื่อถือหรือไม่ VPN ยังเพิ่มความเป็นส่วนตัวให้ทราฟฟิกส่วนที่เหลือของคุณ เช่นการค้นหา DNS และแอปอื่น และการรัน Remio ผ่านมันก็ไม่มีปัญหา เป็นทางเลือกเกี่ยวกับทราฟฟิกอื่นของคุณ ไม่ใช่ข้อกำหนดของเซสชัน
RDP ปลอดภัยบน Wi-Fi สาธารณะไหม?
ด้วย TLS และ Network Level Authentication — ค่าเริ่มต้นสมัยใหม่ของ Windows — เซสชันเข้ารหัสการขนส่ง ผู้ดักฟังบนเครือข่ายร้านกาแฟจึงเห็นไซเฟอร์เท็กซ์ กฎที่ใช้ตลอดเกี่ยวกับการเปิดเผย ไม่ใช่สถานที่: อย่าเปิดพอร์ต 3389 ตรงสู่อินเทอร์เน็ต เข้าถึง RDP ผ่าน VPN หรืออุโมงค์เข้ารหัสอื่นแทน การตั้งค่าเก่าที่ถูกเจรจาลดระดับเป็นความปลอดภัย RDP แบบเดิมที่ไม่มี TLS ได้ ควรถือว่าไม่ปลอดภัยบนเครือข่ายที่ไม่น่าไว้ใจทุกแห่ง
ผู้ดำเนินการ Wi-Fi ยังรู้อะไรบ้าง?
เมตาดาตาการเชื่อมต่อ แม้เซสชันจะเข้ารหัสแบบ end-to-end เต็มรูปแบบ ผู้ดำเนินการเครือข่ายยังสังเกตจังหวะเวลา ปริมาณทราฟฟิก และปลายทางที่คุณแลกเปลี่ยนแพ็กเก็ตด้วย — พอที่จะอนุมานว่ามีเซสชันรีโมทเดสก์ท็อปเกิดขึ้นและนานเท่าไร สิ่งที่กู้คืนไม่ได้คือเนื้อหา: ไม่มีเฟรมหน้าจอ ไม่มีการกดแป้น ไม่มีไฟล์ ไม่มีคลิปบอร์ด
ด้ายที่ร้อยทั้งหมดไว้: สถานที่ไม่ได้ตัดสินว่าเซสชันของคุณปลอดภัยหรือไม่ — การเข้ารหัสตัดสิน ถ้าอยากได้เวอร์ชันที่ไม่ต้องมีเช็กลิสต์เลย ติดตั้ง Remioบนทั้งสองเครื่อง จับคู่ด้วย QR code หรือ Device ID และ PIN แล้วเชื่อมต่อจากเครือข่ายใดก็ตามที่วันนั้นหยิบยื่นให้ เซสชันเข้ารหัสแบบ end-to-end ไม่ว่าอย่างไร หน้าวิธีการทำงานแสดงสิ่งที่เกิดขึ้นเบื้องหลัง