ยืนยันพบช่องโหว่ในระบบ E2EE Letter Sealing ของ LINE app จากสถาบัน Aarhus University ครับ
ผมเห็นข่าวนี้แล้วไม่อยากแชร์ต่อเฉย ๆ เลยไปไล่อ่านต้นทางเองก่อน ทั้งหน้าเว็บของทีมวิจัย ตัวเปเปอร์ฉบับเต็ม และจดหมายตอบกลับจาก LY Corporation (บริษัทเจ้าของ LINE) บทความนี้เลยแยกให้ชัดว่า “ทีมวิจัยบอกว่าอะไร” กับ “LINE ตอบว่าอะไร” และท้ายบทความมีวิธีปรับการใช้งานที่ไม่ต้องเลิกใช้ LINE ครับ
งานวิจัยชื่อ LINE-Break: Cryptanalysis and Reverse Engineering of Letter Sealing โดย Diego F. Aranha, Adam Blatchley Hansen และ Thomas Kingo T. Mogensen จาก Aarhus University ประเทศเดนมาร์ก ตีพิมพ์ในงาน ASIACCS’26 (ACM Asia Conference on Computer and Communications Security)

Letter Sealing คืออะไร
Letter Sealing คือระบบเข้ารหัสแบบ end-to-end (E2EE) ของ LINE ที่ใช้ปกป้องข้อความแชท ตัวที่งานวิจัยนี้วิเคราะห์คือ Letter Sealing v2 ครับ
แนวคิดของ E2EE คือมีแค่คนส่งกับคนรับที่อ่านเนื้อหาได้ แม้แต่เซิร์ฟเวอร์ตรงกลางก็ไม่ควรอ่านได้ ทีนี้ทีมวิจัยถามต่อว่า ถ้าเซิร์ฟเวอร์ไม่ซื่อสัตย์ หรือมีคนดักกลางทางได้ ระบบยังรักษาความถูกต้องของแชทได้ไหม ซึ่งเป็นโจทย์หลักของ E2EE ที่ดีครับ
ทีมวิจัยพบอะไรบ้าง
สรุปตามที่ทีมวิจัยรายงานไว้ (ผมสรุปเป็นภาษาไทย ถ้าอยากดูถ้อยคำจริงดูภาพประกอบหรือเปเปอร์ได้เลยครับ)
1. ข้อความถูกเล่นซ้ำ สลับลำดับ หรือถูกบล็อกได้ โดยผู้ใช้ไม่รู้ตัว
ทีมวิจัยบอกว่าตัวโปรโตคอลเป็นแบบ stateless เลยเปิดช่องให้เซิร์ฟเวอร์ที่ไม่หวังดี หรือผู้โจมตีที่ดักกลางทางได้ ส่งข้อความเก่าซ้ำ สลับลำดับ หรือทำให้ข้อความไม่ถึงปลายทาง โดยทั้งสองฝั่งไม่ถูกแจ้งเตือน

2. ปลอมสถานะ “อ่านแล้ว” ได้
เปเปอร์อธิบายว่า read receipt ของ LINE เป็นแค่ timestamp ที่เซิร์ฟเวอร์ใส่ให้ ผู้โจมตีที่คุมเซิร์ฟเวอร์ได้จึงบล็อกข้อความไว้ แล้วปลอมว่าอีกฝั่งอ่านแล้ว ผู้ส่งก็จะเข้าใจว่าข้อความถึงและถูกอ่านเรียบร้อย ทั้งที่จริงไม่ถึงครับ
3. ปลอมว่าใครเป็นคนส่งข้อความ (impersonation)
ถ้ามีผู้ใช้ในแชทร่วมมือกับผู้โจมตี ทีมวิจัยบอกว่าสามารถปลอมให้ข้อความดูเหมือนมาจากคนอื่นได้ ทั้งในแชทตัวต่อตัวและแชทกลุ่ม สาเหตุคือวิธีสร้างและจัดการกุญแจของกลุ่ม กับการที่ระบบไม่ได้ยืนยันต้นทางของข้อความ
4. สติกเกอร์และ URL preview ทำให้ข้อมูลรั่ว
ตอนพิมพ์ข้อความ LINE จะแนะนำสติกเกอร์ที่เกี่ยวข้อง และต้องดึงสติกเกอร์บางชุดจากเซิร์ฟเวอร์ ทีมวิจัยชี้ว่าเซิร์ฟเวอร์จึงเดาได้ว่าเรากำลังพิมพ์เรื่องอะไร นอกจากนี้ตัวสติกเกอร์เองก็ไม่ได้เข้ารหัสด้วย Letter Sealing ส่วน URL preview ก็ทำให้เซิร์ฟเวอร์เห็นลิงก์ที่ส่งในแชท ทีมวิจัยสรุปว่าสองฟีเจอร์นี้เผยข้อมูลมากกว่าที่เอกสารสาธารณะของ LINE ระบุไว้
ทดสอบยังไง
ทีมวิจัยทดสอบด้วยการตั้ง Machine-in-the-Middle บน iOS โดยติดตั้ง rogue root certificate เพื่อให้แก้ไข metadata ของโปรโตคอลได้เหมือนเซิร์ฟเวอร์ที่ไม่หวังดี แล้วทดลองกับแอป LINE ตัวจริง และกับ LINEJS ซึ่งเป็น client ที่เขียนขึ้นเองแบบอิสระ การทดลองใช้บัญชีและอุปกรณ์ของทีมวิจัยเอง ไม่มีผู้ใช้จริงได้รับผลกระทบ
ขอบเขตที่ควรรู้
เปเปอร์ระบุว่ากลุ่มที่มีสมาชิกเยอะกว่า 50 คน Letter Sealing ไม่ได้ถูกใช้อยู่แล้ว และมีกรณีอื่นที่ไม่ครอบคลุม เช่น แชทกับ official account และตัวสติกเกอร์ครับ

ทีมวิจัยแจ้ง LINE ยังไง และ LINE ตอบว่าอะไร
ทีมวิจัยระบุว่าแจ้งผลการวิเคราะห์ให้ทีม Computer Security Incident Response Team ของ LY Corporation ในเดือนมิถุนายน 2025 และทีม Letter Sealing ยืนยันรับทราบ พร้อมส่งจดหมายชี้แจงมา ซึ่งทีมวิจัยเผยแพร่ไว้บนเว็บของตัวเองครับ
ใจความหลักในจดหมายของ LY Corporation (ผมสรุปเป็นภาษาไทย)
- ปัญหา replay / บล็อก / สลับลำดับข้อความ, ปลอม read receipt และ impersonation เป็นข้อจำกัดที่มาจากดีไซน์ของโปรโตคอล ซึ่งทางบริษัทรู้อยู่ก่อนแล้ว แต่ขอบคุณที่ทีมวิจัยตรวจสอบอิสระและให้ข้อมูลเพิ่ม
- เรื่องลำดับข้อความ บริษัทบอกว่าเลือกใช้เวลาที่เซิร์ฟเวอร์ได้รับข้อความแทนเวลาจากเครื่องผู้ใช้ เพราะให้น้ำหนักกับประสบการณ์ใช้งาน (เวลาจากเครื่องที่ตั้งผิดหรือเน็ตมีปัญหา อาจทำให้ข้อความใหม่ไปแทรกอยู่กลางข้อความเก่าจนมองไม่เห็น)
- เรื่อง read receipt บริษัทบอกว่าเคยมองเป็น metadata ที่ไม่ sensitive แต่งานวิจัยนี้ทำให้เห็นว่าอาจถูกนำไปใช้ในทางที่ผิดได้ จึงกำลังปรับทั้ง threat model และ encryption report
- เรื่อง impersonation บริษัทบอกว่ามีการตรวจสอบที่ฝั่งเซิร์ฟเวอร์กันข้อความปลอมอยู่ แต่เข้าใจว่าไม่เพียงพอเมื่อมองจาก threat model ของ E2EE
- เรื่องสติกเกอร์ บริษัทบอกว่าหลีกเลี่ยงยาก เพราะมีสติกเกอร์เยอะเกินกว่าจะเก็บไว้ในเครื่องทั้งหมด จึงต้องโหลดตามที่ใช้
- เรื่อง URL preview บริษัทเลือกสร้าง preview ฝั่งเซิร์ฟเวอร์ เพราะอีกวิธีหนึ่งจะทำให้ IP ของฝั่งที่สร้าง preview ถูกเปิดเผย ผู้ใช้ปิดฟีเจอร์นี้ได้ที่ Settings → Chats → URL previews
- บริษัทบอกว่าให้ความสำคัญกับ confidentiality และ integrity และกำลังประเมินแนวทางเพิ่ม security property ในระดับโปรโตคอล รวมถึงพิจารณาปรับปรุงโปรโตคอลเข้ารหัสต่อไป

พูดง่าย ๆ คือทั้งสองฝ่ายเห็นตรงกันว่าสิ่งเหล่านี้เกิดขึ้นได้จากดีไซน์ ต่างกันที่มุมมอง ทีมวิจัยวัดด้วยมาตรฐานของ E2EE ที่ดี ส่วน LINE บอกว่าเลือกสมดุลกับการใช้งานจริง และบอกว่ากำลังดูทางปรับปรุงครับ
แล้วอาการที่อาจเจอเป็นยังไง
ก่อนอื่นขอพูดให้ชัดว่า ไม่ได้มีรายงานว่าเกิดกับผู้ใช้จริง งานนี้ทดสอบในเครือข่ายและอุปกรณ์ของทีมวิจัยเอง และการโจมตีเหล่านี้ต้องอาศัยเซิร์ฟเวอร์ที่ถูกควบคุม หรือผู้โจมตีที่ดักทราฟฟิกได้ แต่ถ้าสถานการณ์แบบนั้นเกิดขึ้นจริง อาการที่ตรงกับสิ่งที่งานวิจัยอธิบายคือ

- ข้อความเก่าโผล่ขึ้นมาใหม่ เช่น เคยตอบ “โอเค” เรื่องหนึ่ง แต่ไปโผล่เป็นคำตอบของอีกเรื่อง
- ลำดับแชทดูแปลก ๆ หรือขึ้นว่าอ่านแล้ว แต่อีกฝั่งบอกว่าไม่เคยได้รับ
- ในกลุ่ม มีข้อความที่ดูเหมือนเพื่อนส่ง แต่เพื่อนบอกว่าไม่ได้ส่ง
- ลิงก์ที่ส่งในแชท (รวมถึงลิงก์ที่มี token หรือลิงก์แชร์ไฟล์) ถูกส่งไปทำ preview ที่เซิร์ฟเวอร์
- สติกเกอร์ไม่ได้อยู่ในการเข้ารหัส E2EE
สามข้อแรกคืออาการที่ผู้ใช้อาจสังเกตเห็น ส่วนสองข้อหลังเป็นพฤติกรรมของฟีเจอร์ที่เกิดขึ้นอยู่แล้วตามดีไซน์ ไม่ต้องรอใครโจมตีครับ
ใช้ LINE ต่อได้ แค่ปรับนิดหน่อย
ผมไม่ได้จะบอกให้เลิกใช้ LINE ครับ แชทกับเพื่อนหรือครอบครัวทั่วไป ผมมองว่าไม่ต้องเครียดมาก แต่ถ้าปรับนิสัยการใช้ได้นิดหน่อย ก็ลดความเสี่ยงได้

- ปิด URL preview และ sticker suggestions ในการตั้งค่า (URL previews อยู่ที่ Settings → Chats → URL previews) ซึ่งตรงกับที่ทีมวิจัยแนะนำสำหรับคนที่ต้องการลดการรั่วไหล
- อย่าส่งลิงก์ที่มีรหัส token หรือลิงก์แชร์ไฟล์ลับผ่าน LINE
- เรื่องสำคัญ เช่น โอนเงิน อนุมัติงาน หรือเรื่องที่ต้องใช้เป็นหลักฐาน ให้โทรหรือเช็คอีกช่องทางก่อนทุกครั้ง
- ถ้าเห็นข้อความแปลก ๆ หรือข้อความเก่าโผล่ซ้ำ ให้ถามเพื่อนตรง ๆ ก่อนทำตาม
- กลุ่มที่คุยเรื่องสำคัญ ให้มีแต่คนที่ไว้ใจ (กลุ่มที่มีสมาชิกเกิน 50 คนไม่ได้ใช้ Letter Sealing)
- อย่าติดตั้ง profile หรือ certificate แปลก ๆ บนมือถือ และระวัง Wi-Fi สาธารณะที่ไม่รู้จัก
อีกเรื่องที่ควรพูดให้ครบ เปเปอร์ของทีมวิจัยเองก็ระบุว่า สำหรับคนที่ต้องสื่อสารให้ปลอดภัยและเชื่อถือได้แม้เจอผู้โจมตีระดับที่คุมเซิร์ฟเวอร์ได้ (เช่น นักข่าว นักเคลื่อนไหว หรือกลุ่มที่เสี่ยงสูง) ไม่ควรพึ่งโปรโตคอลของ LINE ถ้าไม่ได้อยู่ในกลุ่มนี้ การปรับตามข้างบนก็น่าจะพอเหมาะกับการใช้งานทั่วไปครับ
ปิดท้าย
สำหรับผม ประเด็นนี้ไม่ใช่เรื่องให้ตกใจ แต่เป็นเรื่องที่ควรรู้ขอบเขต คำว่า “end-to-end encryption” บนป้ายกับสิ่งที่ระบบรับประกันจริงอาจไม่เท่ากัน โดยเฉพาะเรื่องว่าข้อความถูกเล่นซ้ำ สลับ หรือถูกปลอมได้หรือเปล่า ซึ่ง LY Corporation เองก็บอกว่ากำลังดูทางปรับปรุง ผมจะตามอ่านต่อว่ามีอัปเดตอะไรไหมครับ
ถ้าพี่ ๆ ที่อ่านมีมุมมองหรือเจออะไรแปลก ๆ ในแชท LINE มาแชร์กันได้ครับ
แหล่งที่มา
- LINE-Break: Cryptanalysis and Reverse Engineering of Letter Sealing, Aarhus University (ASIACCS’26) — https://linebreak.info/ (มีเปเปอร์ฉบับเต็ม จดหมายชี้แจงของ LY Corporation และวิดีโอทดลอง)
- ACM DOI: https://doi.org/10.1145/3779208.3805983
หมายเหตุ: บทความนี้สรุปจากเว็บไซต์ของทีมวิจัย เปเปอร์ฉบับเต็ม และจดหมายชี้แจงของ LY Corporation เท่านั้น ไม่ใช่คำแนะนำด้านความปลอดภัยเฉพาะบุคคล
อ่านต่อ: สรุปแชตกลุ่ม LINE เป็น meeting notes ด้วย Nemotron Bolt · วิธีกู้คืนบัญชี Facebook ที่ถูกระงับ
One Comment
Comments are closed.






[…] LINE Letter Sealing ช่องโหว่ E2EE · รัน Local LLM บน Mac · Nim AI Pet บน […]