SSL Intercept – แน่ใจหรือเปล่าว่าใช่?

ในกระบวนการการสื่อสารด้วย SSL เรามั่นใจได้ว่าข้อมูลที่เราสื่อสารไปนั้นยังเป็นความลับอยู่
แต่ความลับนั้นอยู่ได้นานแค่ไหน? คำตอบคือตราบใดที่ “ลูกศรร่วม” (Symmetric key) ยังเป็นความลับในกระบวนการการแลกเปลี่ยนคีย์

ความลับในกระบวนการการแลกเปลี่ยน Symmetric Key (ลูกศรสีม่วง) คือการที่ server ส่ง “ลูกศรสีเขียว” (private key) ให้กับเครื่อง client ก่อนที่ client จะทำการสร้างลูกศรร่วม (กำหนด key ร่วม) มา เอาไปแปลงด้วยลูกศรเขียว (เข้ารหัสด้วย public key) ก่อนที่จะให้ server ถอดด้วยลูกศรแดง ซึ่งคู่กับลูกศรเขียว (private key)
ทุกอย่างสรุปได้ตามภาพนี้

encryption.023

โอเค สวยงามมาก

แต่โลกไม่ได้สวยงามเสมอไป ความรักไม่ได้งดงามเหมือนวันแรกเจอ คนกลางไม่ได้ซื่อสัตย์เหมือนที่เราคาดหวังให้เป็น
ทุกครั้งที่เราส่งข้อมูลผ่านอินเทอร์เน็ต เราไม่ได้คุยกับเว็บที่เราต้องการคุยโดยตรง แต่ผ่านคนกลางหลายคน

encryption.024

จะเห็นว่า ในการถอดรหัส สิ่งที่ต้องมีคือลูกศรสีม่วง ซึ่งตอนเราส่งลูกศรม่วงให้ server เราเอาลูกศรม่วงไปเข้ารหัสด้วย private key (ผ่านลูกศรเขียว) ได้ออกมาเป็นลูกศรเหลืองเน่า ที่ใช้ไม่ได้จนกว่าจะเอาไปถอดรหัส

แล้วถ้าคนกลางตุกติกล่ะ?

แน่นอน คนกลางพยายามหาทางทำยังไงก็ได้ที่จะทำให้สามารถถอดรหัสให้ได้ลูกศรร่วมได้ แต่การที่จะถอดรหัสได้ คนกลางต้องมีลูกศรแดง (private key) ของ server
ซึ่ง วิธีการเดียวที่จะได้มาซึ่งลูกศรแดง คือปล้น server

แต่ในทางจริงมันทำไม่ได้ ดังนั้นคนกลางจึงมีแผนชั่ว คือการแอบเปลี่ยนลูกศร

encryption.025

(ขอบคุณบอส กรมทรัพย์สินทางปัญญา)

คนกลางทำการสร้างคู่ลูกศรวิเศษเขียวแดงปลอมขึ้นมาอันนึง ก่อนที่จะใช้มันในการสับเปลี่ยนข้อมูลตามนี้

encryption.026

แทนที่จะส่งลูกศรเขียวของจริง ให้ client เอาลูกศรร่วมไปเข้ารหัส ก็ส่งลูกศรเขียวของปลอมให้ พอได้ข้อมูลก็เอาลูกศรแดงปลอมที่ตัวเองมีมาถอดรหัส รู้ความลับเพิ่มมาอีกหนึ่งคน

encryption.027

แล้วถามว่าฝั่ง server จะได้ลูกศรเข้ารหัสยังไง? ก็ไม่ยาก ในเมื่อ server พยายามส่งลูกศรเขียวของแท้มา ทางคนกลางก็ต้องมีลูกศรนี้เช่นกัน
วิธีการก็แค่เอาลูกศรแดงปลอมถอดรหัส ได้ข้อมูลดิบ ก่อนเอาข้อมูลดิบเข้ารหัสด้วยลูกศรเขียวจริง ส่งต่อไปเนียนๆ


encryption.028

ขณะนี้ก็จะกลายเป็นว่านอกจากฝั่ง client และ server จะมีความลับร่วมแล้ว ก็กลายเป็นคนกลางที่จะมีความลับร่วมด้วยเช่นกัน

encryption.029

นี่แหละคือสิ่งที่เรียกว่า single gateway และเป็นสิ่งที่รัฐเคยมีความพยายามในการทำ โดยอยู่ใน หลักการและเหตุผลแก้ไขมาตรา 20 ของพ.ร.บ.คอมพิวเตอร์ ที่ให้รัฐมนตรีสามารถออกประกาศกำหนดให้มีวิธีการในการปิดกั้นข้อมูลที่ถูกเข้ารหัสได้

ในหน้า 7 ของเอกสารนำเสนอดังกล่าว ระบุว่า “รัฐมนตรีอาจประกาศกำหนดหลักเกณฑ์ ระยะเวลาและแนวทางการปฏิบัติสำหรับการระงับการทำให้แพร่หลายหรือลบข้อมูลคอมพิวเตอร์ของผู้ให้บริการให้เป็นไปในแนวทางเดียวกันภายใต้พัฒนาการทางเทคโนโลยีที่เปลี่ยนไป เช่น ข้อมูลคอมพิวเตอร์ที่เข้ารหัสด้วยเทคโนโลยี SSL (Secure Socket Layer) ซึ่งถูกสร้างขึ้นมาเพื่อเพิ่มความปลอดภัยในการสื่อสารหรือส่งข้อมูลบนเครือข่ายอินเทอร์เน็ตที่มีการเข้ารหัสแบบ Public-key encryption นั้น จำเป็นต้องมีวิธีการและเครื่องมือพิเศษในการดำเนินการจึงจะสามารถกระทำได้สำเร็จ …”

– Thai Netizen Network

แต่ถ้ายังจำได้ ตอนที่ server ส่งลูกศรเขียวมาให้เรา พร้อมตกลงกันว่าจะหาทางคุยกันแบบลับๆ (กระบวนการ Handshaking) มันไม่ได้มีมาแค่นั้น

encryption.011

ข้อมูลที่ถูกส่งมา จริงๆ แล้ว เป็นข้อมูลที่มัดรวมกันเรียกว่า Certificate มีข้อมูลว่า

  • นี่กำลังคุยกับเว็บอะไร
  • เว็บนี้มีบริษัทน่าเชื่อถือๆ รับรองไหม
  • สรุปเราจะตกลงเข้ารหัสด้วยวิธีใด
  • จะใช้ลูกศรเขียวไหนเข้ารหัส

ข้อมูล Certificate นี้จะถูกมัดรวม ทำให้ไม่สามารถสับเปลี่ยนลูกศรเขียวโดยไม่ทำให้ข้อมูลถูกจับได้ว่าปลอมมาได้
ดังนั้นวิธีการเดียวที่จะปลอมได้ ก็คือสร้าง Certificate ใบใหม่

by default 2559-06-06 at 9.20.19 PM

อนิจจา การสร้าง Certificate นั้น เหมือนที่บอก คือใน Certificate จะมีบอกว่าเว็บนี้มีบริษัทน่าเชื่อถือๆ รับรองไหม (ในที่นี้ Certificate ของกูเกิล มีบริษัทของกูเกิลออกใบรับรองให้ โดยมีบริษัทใหญ่ชื่อ GeoTrust กำกับดูแล)
ข้อมูลตรงนี้ก็ไม่สามารถปลอมได้เช่นกัน และการที่บริษัทน่าเชื่อถือๆ จะออก Certificate ที่น่าเชื่อถือให้ ก็ต้องผ่านกระบวนการตรวจสอบ
ดังนั้นในเว็บที่ทำทุกอย่างถูกต้อง ลูกกุญแจเขียวจะโผล่

โดยปกติบริษัทที่ “น่าเชื่อถือๆ” นั้น จะมีแนบมาพร้อมกับ browser โดยที่ผู้ผลิตระบบปฏิบัติการ หรือ browser จะเป็นคนเลือกมา
บริษัทเหล่านี้คือบริษัทที่มีหน้าที่ออก Certificate เท่านั้น เรียกว่า Certificate Authority (CA)
สิ่งที่แนบมาเพื่อยืนยันความน่าเชื่อถือของบริษัท เรียกว่า Root Certificate

by default 2559-06-07 at 9.59.30 AM

ส่วนถ้าพยายามสร้าง Certificate เอง โดยไม่มีคนรับรองว่าเป็นเจ้าของเว็บนั้นจริงๆ ก็จะติดคำเตือนสีแดงๆ ตัวโตๆ แบบในหัวเว็บ

by default 2559-06-07 at 9.59.56 AM

จะเห็นว่าพอดู Certificate จะไม่มีชื่อบริษัทน่าเชื่อถือๆ เลย

เช่นเดียวกัน ถ้าหัวหมอ ขอ Certificate ของเว็บนึง แต่เอาไปใช้กับอีกเว็บนึง ก็จะขึ้นเตือนเหมือนกัน เพราะ browser จะเช็คว่าชื่อเว็บใน certificate ตรงกับที่คุยอยู่ด้วยไหม

แต่ก็อนิจจาเข้าไปอีก เพราะคำว่า “เว็บนี้มีบริษัทน่าเชื่อถือๆ รับรองไหม” ก็มีวิธีการ “เพิ่มชื่บริษัทน่าเชื่อถือๆ” เข้าไปในเครื่องด้วย
นั่นก็คือ การติดตั้ง Root Certificate เพิ่มเข้าไป

ดังนั้น เพื่อความปลอดภัย อย่าติดตั้ง Root Certificate ที่ไม่น่าเชื่อถือโดยเด็ดขาด เพราะ browser จะข้ามคำเตือนว่าเรามีโอกาสดักฟัง

มีข้อสันนิษฐานถึงการดักฟังด้วย Root Certificate ว่ารัฐอาจมีกลไกในการหลอกล่อให้ติดตั้ง Root Certificate เช่น เปลี่ยนไปใช้ใบรับรอง self-signed โดยหน่วยงานของรัฐทั้งหมด แล้วให้ผู้ใช้ที่ต้องใช้บริการของรัฐ (เช่นยื่นแบบภาษีเงินได้) ติดตั้ง Root Certificate

แต่ยังไงก็ดี บางเว็บ เช่นกูเกิล เฟซบุ๊ค ก็บังคับใช้มาตรการความปลอดภัยที่เรียกว่า HSTS ซึ่งมีกฏสองข้อว่าต้องใช้ HTTPS ตลอด และ Certificate ต้องใช้ได้ (ไม่แดง)
ถ้าผิดกฏหนึ่งในสองข้อนี้ ก็จะไม่ให้เข้าเว็บเลย

โอกาสที่จะเห็นหน้าจอนี้ตอนเดียวก็คือตอนพยายามใช้ไวไฟที่ต้องล็อกอิน แล้วเผลอเปิดกูเกิลหรือเฟซบุ๊คไว้
เพราะว่า server พยายามส่ง certificate ของตัวหน้าล็อกอินไวไฟมา ตัว browser ที่คิดว่ากำลังคุยกับหน้ากูเกิลหรือเฟซบุ๊คเลยขึ้นเตือนตัวโตๆ

ทั้งนี้ กลไก HSTS ตรวจสอบได้แค่ว่า Certificate นั้น “ไม่แดง” หรือไม่ ไม่ใช่ “ไม่แดง” เพราะเชื่อถืออยู่แล้ว หรือผู้ใช้ลง Root certificate เอง
เพราะฉะนั้นความไม่ปลอดภัยที่จะเกิดกรณีลง Root Certificate เองก็ยังมีอยู่

ทั้งหมดนี้คือเรื่องของ SSL เบื้องต้น ซึ่งควรรู้ไว้นั่นเอง


แต่อะไรนะ Certificate มันบอกว่าวิ่งไปเว็บอะไร แต่ไม่ได้บอกว่าใครเป็นเจ้าของ
งั้นถ้าเปิดเว็บเป็นชื่อแบงค์ แล้วตีเนียนขอ Certificate ในเมื่อมันไม่ได้เช็คว่าเราเป็บแบงค์จริงไหม ก็ปลอมเป็นแบงค์ได้ดิ :P

Leave a Reply

Your email address will not be published. Required fields are marked *