พบสัญญาณการดักทราฟฟิกเข้ารหัสของ Jabber.ru บน Hetzner และ Linode
(notes.valdikss.org.ru)- พบสัญญาณว่าการเชื่อมต่อ XMPP STARTTLS พอร์ต 5222 บนเซิร์ฟเวอร์ dedicated ของ Hetzner และ VPS ของ Linode ของบริการ XMPP รัสเซีย jabber.ru/xmpp.ru ถูกดักผ่านพร็อกซี MiTM แบบโปร่งใส
- ผู้โจมตีออก ใบรับรอง TLS หลายใบผ่าน Let’s Encrypt เพื่อยุติการเชื่อมต่อที่เข้ารหัสไว้กลางทาง และปัญหาถูกเปิดเผยเมื่อพอร์ต 5222 ของ jabber.ru บน Hetzner เริ่มส่งใบรับรองที่หมดอายุออกมา
- ไม่พบร่องรอยการบุกรุกเซิร์ฟเวอร์หรือ ARP spoofing ในเซกเมนต์เครือข่ายเดียวกัน ขณะที่อินสแตนซ์ Linode แสดงเส้นทางและ MAC ของเกตเวย์ที่ต่างจาก VM ทั่วไป ทำให้ความเป็นไปได้ของ การปรับโครงสร้างเครือข่ายโฮสติ้ง สูงขึ้น
- MiTM ได้รับการยืนยันอย่างน้อยตั้งแต่วันที่ 21 กรกฎาคมถึง 19 ตุลาคม 2023 และยังมีความเป็นไปได้ว่าเริ่มตั้งแต่วันที่ 18 เมษายน 2023 โดยการเชื่อมต่อพอร์ต 5222 ได้รับผลกระทบ 100% ส่วนพอร์ต 5223 ไม่ได้รับผลกระทบ
- การสื่อสารของ jabber.ru/xmpp.ru ในช่วงเวลาดังกล่าวควรถูกถือว่าถูกละเมิด และการเข้ารหัสแบบ end-to-end อย่าง OMEMO, OTR, PGP จะป้องกันได้ก็ต่อเมื่อทั้งสองฝ่ายตรวจสอบคีย์แล้วเท่านั้น
การดักทราฟฟิกที่ถูกเปิดเผยจากใบรับรองหมดอายุ
jabber.ruเป็นบริการ XMPP ของรัสเซียที่เริ่มต้นในปี 2000 และยังเป็นที่รู้จักในชื่อxmpp.ru- เมื่อเชื่อมต่อบริการเมื่อวันที่ 16 ตุลาคม 2023 มีข้อความ “Certificate has expired” ปรากฏขึ้น แต่ใบรับรองทั้งหมดที่ติดตั้งบนเซิร์ฟเวอร์ยังเป็นเวอร์ชันล่าสุด
- อาการผิดปกติเกิดขึ้นเฉพาะที่ พอร์ต 5222 สำหรับ XMPP STARTTLS เท่านั้น และไม่พบในพอร์ตอื่น เช่น พอร์ต 5223 สำหรับ XMPP TLS
- เซิร์ฟเวอร์ที่ได้รับผลกระทบคือเซิร์ฟเวอร์ dedicated ของ Hetzner ในเยอรมนี 1 เครื่อง และเซิร์ฟเวอร์เสมือนของ Linode 2 เครื่อง
- ในทราฟฟิกพอร์ต 5222 พบรูปแบบที่เซิร์ฟเวอร์ได้รับ ClientHello ที่ถูกแทนที่ ไม่ใช่ ClientHello ดั้งเดิมของไคลเอนต์
ผลการตรวจสอบการบุกรุกภายในเซิร์ฟเวอร์
- ขอบเขตการตรวจสอบคือความเป็นไปได้ที่เซิร์ฟเวอร์ถูกแฮ็ก และความเป็นไปได้ของการ spoofing ในเครือข่ายท้องถิ่น
- ฝั่งเซิร์ฟเวอร์ตรวจสอบรายการต่อไปนี้ แต่ไม่พบความผิดปกติ
- ล็อกโดยรวม
- เวลาแก้ไขของไฟล์ executable และไลบรารี
- โปรเซสที่กำลังทำงาน, memory map, dangling file descriptor
- การมีอยู่ของไลบรารี hijacking ใน user space แบบ
LD_PRELOADโดยใช้busyboxที่คอมไพล์แบบ static - การมีอยู่ของโมดูล hijacking ระดับเคอร์เนล โดย dump หน่วยความจำเคอร์เนลด้วย LiME และวิเคราะห์ด้วย volatility
- ในล็อกเคอร์เนลของเซิร์ฟเวอร์ dedicated ของ Hetzner พบข้อยกเว้นเพียงรายการเดียวคือบันทึกว่า physical network link หลุดเป็นเวลา 19 วินาที เมื่อวันที่ 18 กรกฎาคม 2023
- เซิร์ฟเวอร์ Linode ถูกใช้เป็นเพียง tunnel สำหรับเส้นทางสำรองไปยังเซิร์ฟเวอร์ Hetzner และรันเฉพาะบริการพื้นฐาน เช่น SSH, NTP
- ภายใน tunnel ระหว่าง Hetzner↔Linode เห็น ServerHello ปกติของเซิร์ฟเวอร์ Hetzner แต่ถูกเปลี่ยนเมื่อส่งจากอินเทอร์เฟซเครือข่ายของ Linode ไปยังไคลเอนต์
- กล่าวคือมีการดักการเชื่อมต่อเข้ารหัสลักษณะเดียวกันเกิดขึ้นทั้งฝั่ง Hetzner และ Linode
สัญญาณผิดปกติที่พบในเครือข่าย Linode
- จากมุมมองเครือข่าย มีการตรวจสอบรายการต่อไปนี้ แต่ไม่พบร่องรอยการ hijacking ในเครือข่ายรอบเซิร์ฟเวอร์
- การ ARP spoofing ของ MAC address ของเกตเวย์
- มี IP หนึ่งตอบกลับคำขอ ARP หลายครั้งในช่วง L2 หรือไม่
- กฎ routing ผิดปกติที่ถูก inject ผ่าน ICMP redirect เป็นต้น
- กฎ Netfilter
- การมีอยู่ของ tunnel ที่ตรวจพบได้ยาก เช่น IPsec
- เครื่อง Linode ที่ได้รับผลกระทบไม่สามารถค้นหา IP ข้างเคียงในเซกเมนต์เครือข่ายเดียวกันด้วย ARP หรือ ping ได้ แต่จากเครือข่ายภายนอก IP ข้างเคียงเหล่านั้นทำงานได้ปกติ
- Linode VM ของบุคคลที่สามที่ไม่ได้รับผลกระทบสามารถ ping โฮสต์ข้างเคียงได้ และเชื่อมต่อกับเราเตอร์ Cisco Systems
- ในทางกลับกัน VPS ที่ได้รับผลกระทบเชื่อมต่อกับเกตเวย์ที่มี MAC address ซึ่งไม่สามารถระบุผู้ผลิตได้
- ความแตกต่างนี้ทำให้ความเป็นไปได้สูงขึ้นว่า Linode VM ที่ได้รับผลกระทบมีการตั้งค่าเครือข่ายต่างจากอินสแตนซ์ Linode ทั่วไป หรือถูกแยกไว้ใน VLAN แยกต่างหาก
ใบรับรองปลอมและร่องรอย Certificate Transparency
- พบ rogue certificates ที่ไม่ได้ออกโดยเซิร์ฟเวอร์ jabber.ru ใน ฐานข้อมูล certificate transparency ของ crt.sh
- บริการ XMPP ปกติใช้ใบรับรองสองชนิด
xmpp.ru, *.xmpp.rujabber.ru, *.jabber.ru
- ใบรับรองที่ถูกออกโดยเจตนาร้ายมีโครงสร้างแตกต่างจากใบรับรองปกติเล็กน้อย
- ไม่มี wildcard Subject Alternative Name หรือ
- รวม
jabber.ru, xmpp.ruไว้ในใบรับรองเดียวกันแล้วออกใบรับรอง
- การตั้งค่า MiTM ฝั่ง Linode ที่ชี้ไปยังโดเมน
xmpp.ruมีบางส่วนตั้งค่าผิด- เซิร์ฟเวอร์เดิมถูกตั้งค่าให้ให้บริการทั้งใบรับรอง
jabber.ruและxmpp.ruตามโดเมน XMPP ที่ถูกร้องขอ - ฝั่ง MiTM ให้บริการเฉพาะใบรับรอง
xmpp.ru
- เซิร์ฟเวอร์เดิมถูกตั้งค่าให้ให้บริการทั้งใบรับรอง
- เวลาที่ออกใบรับรองในวันที่ 18 กรกฎาคม 2023 ใกล้เคียงอย่างมากกับเวลาที่ลิงก์เครือข่ายของเซิร์ฟเวอร์ Hetzner หลุดไปไม่กี่วินาที
- เครื่องสแกนเครือข่ายภายนอกยืนยันว่าเซิร์ฟเวอร์ Linode ให้บริการใบรับรอง
04:b7:85…บนพอร์ต 5222 อย่างน้อยตั้งแต่วันที่ 21 กรกฎาคม 2023 - เครื่องสแกนดังกล่าวไม่ได้ประมวลผลช่วงเครือข่ายของ Hetzner
อุปกรณ์หน้าพอร์ต 5222 และความแตกต่างของเส้นทาง
- มีการทดสอบเครือข่ายเพิ่มเติมจากภายนอกไปยัง Linode VPS
- โฮสต์ข้างเคียงในช่วง Linode เดียวกันสามารถเข้าถึงได้ที่ hop 13 จากการเชื่อมต่ออินเทอร์เน็ตของแล็ปท็อป
- พอร์ต 5222 ที่ถูกดัก ของเซิร์ฟเวอร์ Linode
dawn.jabber.ruก็เข้าถึงได้ที่ hop 13 เช่นกัน - แต่พอร์ตที่ไม่ถูกดัก เช่น SSH พอร์ต 22 ของเซิร์ฟเวอร์เดียวกัน เข้าถึงได้เฉพาะที่ hop 14 หลังผ่าน hop เพิ่มเติมที่ไม่เปิดเผย
- ผลลัพธ์นี้หมายความว่า IP address ของ Linode VM ถูกวางอยู่หลังอุปกรณ์เพิ่มเติม และอุปกรณ์นั้นจัดการ TCP พอร์ต 5222 โดยตรง ส่วนพอร์ตอื่นถูก route ไปยังปลายทางจริง
- ภายใน VPS ไม่สามารถสร้างการเชื่อมต่อใหม่ด้วย source port 5222 ได้
- เราเตอร์ไม่ตอบสนองต่อแพ็กเก็ตที่มาจาก source port ดังกล่าว
- และไม่ส่ง ICMP error หรือ Time-to-Live Exceeded สำหรับ outgoing packet ที่มี TTL=0 หรือ TTL=1
วิธีการยุติ STARTTLS และ fingerprint สำหรับตรวจจับ
- ผลการตรวจด้วย testssl.sh พบว่าพร็อกซีที่ดักทราฟฟิกอนุญาต anonymous ciphers ทั้งบน Linode
xmpp.ruและ Hetznerjabber.ru - นี่เป็นการตั้งค่าผิดที่พบได้ยาก และสามารถใช้เป็น fingerprint สำหรับตรวจจับ XMPP MiTM ได้
- ไลบรารี SSL/TLS ทั่วไปมักคอมไพล์มาโดยไม่รองรับ anonymous cipher และแม้จะอนุญาตอย่างชัดเจนในไฟล์ตั้งค่า ก็มักยากที่จะตั้งค่าบริการให้ใช้งานสิ่งนี้จริง
- เซิร์ฟเวอร์เดิมไม่ได้ตั้งค่า anonymous cipher ไว้
- เมื่อตรวจบริการ XMPP ยอดนิยมประมาณ 20 รายการด้วยคำสั่ง
testssl.shเดียวกัน ไม่พบสัญญาณผิดปกติอย่างการรองรับ Anonymous NULL Ciphers
ข้อสรุปที่ยืนยันแล้วและผลกระทบต่อผู้ใช้
- ผู้โจมตีออกใบรับรอง SSL/TLS หลายใบผ่าน Let’s Encrypt สำหรับโดเมน jabber.ru และ xmpp.ru ตั้งแต่วันที่ 18 เมษายน 2023
- การโจมตีแบบ Man-in-the-Middle เพื่อถอดรหัสทราฟฟิก XMPP ของไคลเอนต์ jabber.ru/xmpp.ru ได้รับการยืนยันอย่างน้อยตั้งแต่วันที่ 21 กรกฎาคมถึง 19 ตุลาคม 2023
- มีความเป็นไปได้ว่าเริ่มตั้งแต่วันที่ 18 เมษายน 2023 แต่ยังไม่ได้รับการยืนยัน
- ขอบเขตผลกระทบคือการเชื่อมต่อ XMPP STARTTLS พอร์ต 5222 จำนวน 100% และไม่รวมพอร์ต 5223
- ผู้โจมตีล้มเหลวในการออกใบรับรอง TLS ใหม่ และพร็อกซี MiTM บนพอร์ต 5222 ของ jabber.ru ที่ Hetzner เริ่มให้บริการใบรับรองที่หมดอายุ
- การโจมตี MiTM หยุดลงทันทีหลังการตรวจสอบและทดสอบเครือข่ายเมื่อวันที่ 18 ตุลาคม 2023 รวมถึงการส่ง ticket ไปยังฝ่ายสนับสนุนของ Hetzner และ Linode
- อย่างไรก็ตาม อย่างน้อยบนเซิร์ฟเวอร์ Linode หนึ่งเครื่องยังคงมี การดักฟังแบบ passive เหลืออยู่ในรูปแบบของ routing hop เพิ่มเติม
- ไม่พบร่องรอยว่าเซิร์ฟเวอร์ถูกแฮ็ก และดูเหมือนว่าเครือข่ายของ Hetzner และ Linode ถูกปรับโครงสร้างโดยเจาะจง IP address ของบริการ XMPP เพื่อรองรับการโจมตีนี้
- การสื่อสารของ jabber.ru/xmpp.ru ในช่วงเวลาดังกล่าวควรถูกถือว่าถูกละเมิด
- ผู้โจมตีสามารถทำตัวเหมือนดำเนินการจากบัญชีที่ผ่านการยืนยันแล้วได้ แม้ไม่รู้รหัสผ่านบัญชี
- สามารถดาวน์โหลด roster ของบัญชี เข้าถึงประวัติข้อความทั้งหมดฝั่งเซิร์ฟเวอร์ที่ไม่ได้เข้ารหัส ส่งข้อความใหม่ และแก้ไขข้อความแบบเรียลไทม์ได้
- การสื่อสารแบบ end-to-end encryption เช่น OMEMO, OTR, PGP จะได้รับการป้องกันจากการดักทราฟฟิกก็ต่อเมื่อทั้งสองฝ่ายตรวจสอบคีย์เข้ารหัสแล้วเท่านั้น
- ผู้ใช้ควรตรวจสอบว่ามีคีย์ OMEMO·PGP ใหม่ที่ยังไม่อนุมัติใน PEP storage หรือไม่ และควรเปลี่ยนรหัสผ่าน
การป้องกันและการมอนิเตอร์ที่ผู้ให้บริการทำได้
- การออกใบรับรองใหม่จะถูกบันทึกใน Certificate Transparency ดังนั้นสามารถตั้งค่า การมอนิเตอร์ Certificate Transparency ได้
- เช่น Cert Spotter, ซอร์สบน GitHub
- การใช้ CAA Record Extensions for Account URI and ACME Method Binding ใน RFC 8657 สามารถจำกัดวิธีออกใบรับรองและตัวระบุบัญชีที่ได้รับอนุญาตให้ออกใบรับรองได้
- สามารถมอนิเตอร์การเปลี่ยนแปลงใบรับรอง SSL/TLS ของทุกบริการผ่านบริการภายนอกได้
- สามารถเฝ้าดูการเปลี่ยนแปลงของ MAC address ของ default gateway ได้
- channel binding ของ XMPP สามารถตรวจจับ MiTM ได้แม้ฝ่ายที่ดักทราฟฟิกจะแสดงใบรับรองที่ถูกต้อง
- ทั้งไคลเอนต์และเซิร์ฟเวอร์ต้องรองรับกลไกการยืนยันตัวตน SCRAM PLUS
- ในช่วงที่เกิดการโจมตี jabber.ru ยังไม่ได้เปิดใช้งาน
- คำแนะนำเพิ่มเติมจาก Hugo Landau นักพัฒนา ACME สรุปไว้ที่ More recommendations from ACME developer Hugo Landau
คำตอบจาก Hetzner และ Linode
- ณ วันที่ 20 ตุลาคม 2023 ยังไม่ได้รับคำตอบที่เพียงพอจาก Hetzner และ Linode
- ในอัปเดตวันที่ 3 พฤศจิกายน 2023 ทั้งสองบริษัทก็ยังไม่ได้ให้คำตอบที่เหมาะสมต่อเหตุการณ์นี้
- Hetzner ตอบว่า สำหรับ dedicated root server และ Cloud server บริษัทให้บริการเฉพาะฮาร์ดแวร์ การเข้าถึงเครือข่าย และโครงสร้างพื้นฐานที่จำเป็น จึงไม่สามารถเสนอแนวทางแก้ไขเพิ่มเติมได้
- Linode ได้รับล็อกแล้ว แต่ระบุว่าไม่พบกิจกรรมผิดกฎหมายที่ส่งผลกระทบต่อบริการ และปิด ticket
- ฝ่ายผู้ให้บริการให้น้ำหนักกับความเป็นไปได้ว่า Hetzner และ Linode ถูกบังคับให้ตั้งค่าตามการดักฟังโดยชอบด้วยกฎหมายจากคำขอของตำรวจเยอรมัน
- อีกความเป็นไปได้คือมีการบุกรุกเครือข่ายภายในของทั้ง Hetzner และ Linode โดยเจาะจง jabber.ru แต่ยังคงเป็นสถานการณ์ที่น่าเชื่อน้อยกว่ามาก แม้จะไม่ใช่สิ่งที่เป็นไปไม่ได้โดยสิ้นเชิง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ดูมีความเป็นไปได้สูงมากว่าเกี่ยวข้องกับการสืบสวนอาชญากรรมไซเบอร์ของรัสเซีย ถ้าเคยอ่าน Krebs หรือเคยดูฟอรัมรัสเซียสายใต้ดินมากกว่านั้น ก็น่าจะคุ้นกับ xmpp.ru ซึ่งจริง ๆ แล้วมีบริบทแบบนั้นอยู่
ไม่ได้จะกล่าวหาอะไรผู้ดูแลระบบ แต่หมายถึงว่าถ้าให้บริการแบบไม่ระบุตัวตน มันก็มักจะมีลักษณะแบบนี้
https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
https://blog.talosintelligence.com/picking-apart-remcos/
https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
ตัวบทความเองน่าสนใจมาก และดูเหมือนเป็นตัวอย่างภาคสนามว่าทุกคนควรใช้บริการ ตรวจสอบ Certificate Transparency
เห็นด้วยกับข้อเสนอด้านการบรรเทาผลกระทบส่วนใหญ่ ถ้าเป็นเป้าหมายความเสี่ยงสูง ก็น่าพิจารณาซ้อนชั้นการยืนยันตัวตนเพิ่มที่ไม่ต้องพึ่งพา Certificate Authority ที่เชื่อถือได้ เช่น Tor onion services, SSH, WireGuard
เห็นด้วยว่าใบรับรอง SSL/TLS ทั้งหมดที่ออกมาจะอยู่ภายใต้ Certificate Transparency และ crt.sh ก็มี RSS feed ด้วย
การใช้ CAA โดยทั่วไปเป็นความคิดที่ดี แต่สงสัยว่าในกรณีนี้จะช่วยได้ไหม เพราะผู้โจมตีแค่ขอคอนฟิกใบรับรองที่ CAA อนุญาตไว้อย่างตรงตัวก็พอแล้ว และถ้าจำกัดวิธีการตรวจสอบบางแบบให้เข้มขึ้นได้ก็อาจช่วยได้
เห็นด้วยเช่นกันว่าควรตรวจสอบการเปลี่ยนแปลงใบรับรอง SSL/TLS ของทุกบริการด้วยบริการภายนอก เป้าหมายความเสี่ยงสูงควรรู้อยู่เสมอว่าใบรับรองใดถูกต้องและต้องตรวจสอบเรื่องนี้
ส่วนวิธีเฝ้าดูการเปลี่ยนแปลง MAC address ของ default gateway นั้น ถ้าเป็นการโจมตีที่ซับซ้อนกว่านี้ก็สามารถคง MAC address เดิมไว้ได้
เพิ่งรู้ว่า “channel binding” ของ XMPP สามารถตรวจจับการโจมตีแบบคนกลางที่นำเสนอใบรับรองที่ถูกต้องได้ด้วย
แน่นอนว่าต้องตั้งอยู่บนสมมติฐานว่า nameserver ได้รับการป้องกันด้วย DNSSEC ไม่อย่างนั้นคำขอ DNS ตอนที่ Certificate Authority ทำการ query ก็อาจถูกดักได้เช่นกัน
ดูข้อควรระวังด้านความปลอดภัยทั้งหมดได้ใน RFC 8657 RFC นี้ออกแบบมาให้อ่านง่ายกว่า RFC ทั่วไป
บล็อกโพสต์ของผมที่อธิบายพื้นหลัง: https://www.devever.net/~hl/acme-caa-live
ถ้าทำ การโจมตีแบบคนกลาง จริงได้อย่างสมบูรณ์แบบแล้วดันลืมต่ออายุใบรับรอง นั่นก็เป็นเรื่องแบบเยอรมันมาก ๆ :-)
หรือไม่ก็อาจเป็นคนที่ทำตามคำสั่งอย่างเคร่งครัดมาก มีคำสั่งให้ตั้งค่าใบรับรอง แต่ไม่ได้มีข้อกำหนดว่าต้องต่ออายุอัตโนมัติ :)
อาร์ไคฟ์: https://archive.ph/C0jYJ
ทฤษฎีต่าง ๆ น่าสนใจ และถ้าเป็นจริงก็อธิบายได้ว่าเขาได้ใบรับรองมาอย่างไร บทเรียนที่ได้อาจเป็นการวาง probe หลายตัวกับผู้ให้บริการหลายราย ตรวจสอบ TLS fingerprint ทั้งหมด และถ้ามี fingerprint ที่ไม่รู้จักปรากฏขึ้นก็รับการแจ้งเตือน รวมถึงตรวจสอบด้วยว่ามีอยู่ใน Certificate Transparency log หรือไม่
openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdinSHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16เนื่องจากใบรับรอง SSL/TLS ทั้งหมดที่ออกมาจะอยู่ภายใต้ Certificate Transparency จึงควรตั้งค่า การตรวจสอบ Certificate Transparency อย่าง Cert Spotter เพื่อรับอีเมลแจ้งเตือนเมื่อมีใบรับรองใหม่ออกให้โดเมน
หากจำกัดวิธีการตรวจสอบด้วยส่วนขยายระเบียน CAA ใน RFC 8657 คือ Account URI และ ACME Method Binding และระบุตัวระบุบัญชีที่แน่นอนซึ่งสามารถออกใบรับรองใหม่ได้ ก็จะป้องกันการออกใบรับรองโดเมนผ่าน Certificate Authority, บัญชี ACME หรือวิธีตรวจสอบอื่นได้
ควรเฝ้าดูการเปลี่ยนแปลงใบรับรอง SSL/TLS ของทุกบริการด้วยบริการภายนอก และเฝ้าดูการเปลี่ยนแปลง MAC address ของ default gateway ด้วย
รู้สึกสงสัยนิดหน่อยเพราะที่อยู่ MAC ไม่ใช่ที่อยู่แบบ local administered ดูเหมือนมีความเป็นไปได้ว่าใครบางคนจงใจเลือกช่วงที่อยู่นี้
https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
ถ้าค้นหา
"90:de:01" linodeและ"90:de:00" linodeจะเห็นว่าช่วงบล็อกนี้เหมือนเพิ่งถูกจัดสรรให้ VM อื่น ๆ ของ Linode ด้วย ตอนนี้ไม่มี Linode VM ให้เทียบโดยตรง แต่ดูเหมือนทราฟฟิกถูก route ไปยัง VM อื่นในโครงสร้างพื้นฐานของ Linodeเป็นการเดาแบบไม่มีหลักฐาน แต่คิดว่า Jabber ถูกเล็งเป้าเพราะเป็นที่รู้จักว่าถูกใช้ในการค้ายาเสพติดหรือกิจกรรมผิดกฎหมายอื่น ๆ ในตลาด darknet
เรื่องนี้แสดงให้เห็นว่าไม่ควรเชื่อแค่ว่า “เข้ารหัสแล้วก็ไม่เป็นไร” อย่างน้อยข้อความก็ควรเข้ารหัสด้วย PGP
สงสัยว่า PGP จะถูกคอมพิวเตอร์ควอนตัมเจาะได้หรือไม่ และในอนาคตจะมีการเสริมความแข็งแกร่งเพื่อรับมือการโจมตีแบบนั้นหรือเปล่า ถ้าข้อความในรูปแบบเข้ารหัสถูกเก็บรวบรวมไว้จำนวนมาก สุดท้ายการถอดรหัสก็คงเป็นแค่เรื่องของเวลา
และดูเหมือนว่าเรื่องแบบนี้กำลังเกิดกับเว็บทราฟฟิกแทบทั้งหมดที่พวกเขาเอื้อมถึงได้ ดู https://en.wikipedia.org/wiki/Utah_Data_Center
แน่นอนว่าการแลกเปลี่ยนคีย์อย่างปลอดภัยกับผู้ขายยาเสพติดนิรนามบนอินเทอร์เน็ตนั้นพลาดได้ง่าย
https://therecord.media/genesis-market-takedown-cybercrime
PGP มีปัญหาหลายอย่าง และมีหลายคนแนะนำให้หลีกเลี่ยง เช่น https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780
การสื่อสารที่เข้ารหัสแบบ end-to-end เช่น OMEMO, OTR, PGP จะป้องกันการดักฟังได้ก็ต่อเมื่อทั้งสองฝ่ายตรวจสอบคีย์เข้ารหัสแล้วเท่านั้น ผู้โจมตีต้องสร้างการโจมตีแบบ man-in-the-middle แยกต่างหากสำหรับ วิธีเข้ารหัสแบบ end-to-end แต่ละแบบที่ใช้
ไคลเอนต์ XMPP บางตัวที่ผมเคยเห็นจะไม่ให้ใช้งานถ้าไม่ได้แสดงว่าได้ตรวจสอบตัวตนด้านการเข้ารหัสนั้นอย่างชัดเจนแล้ว
ถึงอย่างนั้นก็เป็นการเตือนที่ดี หากคุณไม่เคยดูและจัดการกับตัวเลขที่ยาวมากจนน่าขันหรือค่าที่เทียบเท่า ก็ยากจะบอกได้ว่าการเข้ารหัสแบบ end-to-end เกิดขึ้นจริง
มีจุดหนึ่งในเรื่องนี้ที่ไม่เข้าใจ ถ้าเป็นการดักฟังโดยชอบด้วยกฎหมาย ทำไม Hetzner กับ Linode ถึงตั้งค่า การดักฟังแบบ man-in-the-middle ด้วยใบรับรองและคีย์ LE แยกต่างหาก
น่าจะดึง TLS private key ออกมาจาก RAM หรือที่จัดเก็บของ VPS ได้โดยตรงด้วยซ้ำ ต่อให้เป็นเซิร์ฟเวอร์ dedicated แบบกายภาพ ก็สามารถรีบูตโดยไม่แจ้งล่วงหน้าแล้ว dump RAM เพื่อดึง private key ออกมาได้
การดึง private key จะไม่โผล่ใน CT log จึงลับกว่าเยอะและแทบตรวจจับไม่ได้
อีกความเป็นไปได้คือ ฝั่งหนึ่งเป็น “การค้น” ส่วนอีกฝั่งเป็น “การดักฟัง” จึงอาจต้องมีระดับการอนุมัติต่างกัน แต่ก็ไม่ค่อยรู้สถานการณ์ทางกฎหมายของเยอรมนีในปัจจุบัน
ฟังดูเป็นวิธีที่เป็นมาตรฐานเกินไปสำหรับหน่วยงานบังคับใช้กฎหมาย จนเหมือนน่าจะมีอุปกรณ์สำเร็จรูปแบบนั้นอยู่แล้ว
มีผู้ใช้คนหนึ่งโพสต์เรื่องนี้บน Reddit ไปแล้วเมื่อ 3 วันก่อน: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...
สงสัยว่ามีวิธีทางกฎหมายที่จะบังคับให้ Hetzner/Linode ให้ความเห็นเกี่ยวกับสถานการณ์นี้ได้หรือไม่ ดูมีความเป็นไปได้สูงว่าผู้อยู่เบื้องหลังการดักฟังคือหน่วยงานรัฐหรือตำรวจบางแห่ง
ในทางกลับกัน ถ้าไม่ใช่การดักฟังโดยชอบด้วยกฎหมาย ก็ไม่น่าที่ Hetzner จะยอมให้ทำ เพราะนั่นก็ผิดกฎหมายเช่นกัน