Clear
Lead Graphic Papers

Fall of SSL???

ผู้เขียน: ไพชยนต์ วิมุกตะนันทน์ และ สรณันท์ จิวะสุรัตน์
วันที่เผยแพร่: 22 ก.ย. 2554
ปรับปรุงล่าสุด: 23 ก.ย. 2554

Share on Facebook Share on Twitter Share on Google+

หลายคนคงจะทราบดีอยู่แล้วว่าเทคโนโลยี SSL (Secure Sockets Layer) [1] มีประโยชน์ในการรักษาความมั่นคงปลอดภัย (Security) ของข้อมูลที่ส่งผ่านระบบเครือข่าย โดยเฉพาะบนเครือข่ายอินเทอร์เน็ต ซึ่งการสื่อสารข้อมูลระหว่างผู้ใช้งานบนเครือข่ายอินเทอร์เน็ตและเครื่องแม่ข่ายปลายทาง (เช่น Web Server) จำเป็นที่จะต้องส่งต่อผ่านเครือข่ายอินเทอร์เน็ตสาธารณะหลายเครือข่ายกว่าข้อมูลจะถึงปลายทาง

ในรูปแบบการสื่อสารผ่านเครือข่ายอินเทอร์เน็ตนี้ ภัยคุกคาม (Threat) ที่อาจจะเกิดขึ้นจากผู้ไม่ประสงค์ดีคือ "การถูกดักฟัง(อ่าน)ข้อมูล" (Eavesdropping) ดังนั้น SSL จึงเป็นเทคโนโลยีที่ถูกพัฒนาขึ้นมาใช้จัดการกับภัยคุกคามชนิดนี้โดยตรง เพราะด้วยความสามารถในการเข้ารหัสลับข้อมูล (Encrypt) ก่อนที่จะถูกส่งผ่านเครือข่ายไปถึงผู้รับปลายทาง ถึงแม้ผู้ใช้งานบางส่วนจะไม่เข้าใจหลักการทำงานของเทคโนโลยี SSL เท่าใดนัก แต่ผู้ใช้ส่วนใหญ่มักจะรับทราบว่า หากเว็บไซต์ปลายทางใช้โพรโทคอล HTTPS แทนที่จะเป็นโพรโทคอล HTTP ตามปกติแล้ว แสดงว่าข้อมูลที่สื่อสารกันอยู่นั้นถูกเข้ารหัสลับเอาไว้ ซึ่งเป็นความเข้าใจที่ถูกต้อง เพียงแต่ว่าตามหลักการเข้ารหัสลับทุกชนิดนั้น ข้อมูลจะยังคงเป็นความลับและมีความมั่นคงปลอดภัยจากการถูกปลอมแปลงหรือดักอ่านข้อมูลได้ ก็ต่อเมื่อกุญแจ (Key) ที่ใช้เข้ารหัสลับนั้นไม่รั่วไหลหรือถูกเปิดเผยกับผู้อื่นที่ไม่ใช่คู่สนทนา เพื่อให้เกิดความเข้าใจในเรื่องนี้ จึงจำเป็นจะต้องเข้าใจกลไกของ SSL ในเบื้องต้นก่อน

กลไกของ SSL มีการทำงานสองขั้นตอน โดยขั้นตอนแรกอาจจะเรียกว่า ขั้นตอน Hand-shaking คือเป็นการตรวจสอบข้อกำหนดระหว่าง Client กับ Server ว่าจะยอมสื่อสารข้อมูลกันหรือไม่ ซึ่งตามกลไกของ SSL จะเป็นการตรวจสอบข้างเดียว คือ Client ซึ่งในที่นี้คือ Web Browser จะเป็นผู้ตรวจสอบใบรับรอง SSL (SSL Certificate) ที่ Web Server ส่งมาให้ และตรวจสอบการตั้งค่าสำหรับการเข้ารหัสลับข้อมูลต่างๆ (Encryption specification) ของ Web Server ว่าถูกต้องเหมาะสมหรือไม่ จากนั้น Client จะเป็นผู้สร้าง Key สำหรับการเข้ารหัสลับข้อมูลแบบกุญแจสมมาตร (Symmetric Key Cryptography) แล้วส่งไปให้ Server ใช้ในการเข้ารหัสลับข้อมูลเพื่อสื่อสารกับ Client ในขั้นตอนที่ 2 ของ SSL ต่อไป [1]

Symmetric Key ที่ Client ส่งไปให้ Server จะถูกเข้ารหัสลับเพื่อป้องกันไม่ให้ถูกลักลอบอ่านได้ด้วยรูปแบบการเข้ารหัสลับข้อมูลแบบกุญแจอสมมาตร (Asymmetric Cryptography) เพื่อป้องกันไม่ให้ผู้อื่นนอกเหนือจาก Server ซึ่งเป็นผู้เดียวที่มี Private Key ของ SSL Certificate นั้นใช้ถอดรหัสลับข้อมูลเพื่ออ่าน Symmetric Key ที่ Client ส่งมาให้ ซึ่งกลไกนี้ได้รับการยอมรับว่าเป็นกลไกที่มีความมั่นคงปลอดภัยและสมบูรณ์แบบอยู่แล้ว [2] เพียงแต่ความสำคัญของกลไกนี้อยู่ที่ขั้นตอนแรกของกลไก SSL ที่ Client จะรับ SSL Certificate มาเพื่อตรวจสอบ ในขั้นนี้ Client จะต้องแน่ใจว่า SSL Certificate ที่ได้รับนั้น เป็น SSL Certificate ของ Server ที่กำลังติดต่ออยู่จริง โดยปกติ Web Browser จะทำการตรวจสอบ SSL Certificate โดยอัตโนมัติ หาก Web Browser พบว่ามีความผิดปกติ เช่น ชื่อโดเมนเนมของเว็บไซต์ไม่ตรงกับ SSL Certificate ที่ใช้งานบน Server หรือ ผู้ให้บริการออกใบรับรอง CA (Certificate Authority) ที่ออก SSL Certificate ไม่เป็นที่รู้จัก (หรือไม่ได้รับความเชื่อถือจาก Web Browser) หรือ SSL Certificate หมดอายุการใช้งาน Web Browser จะขึ้นข้อความเตือนผู้ใช้ว่า เกิดความผิดปกติขึ้น

ถ้าผู้ใช้งานเลือกที่จะยอมรับ Certificate ที่ Web Browser พบว่าความผิดปกตินี้ กลไกการสื่อสารด้วย SSL ก็จะเข้าสู่ขั้นตอนการแลกเปลี่ยน Symmetric Key ที่จะใช้ในการสื่อสารข้อมูลระหว่าง Server กับ Client และเริ่มการสื่อสารข้อมูลต่อไปตามปกติ ซึ่งตามหลักการแล้ว ในเมื่อ SSL Certificate นั้นผิดปกติ อาจมีสาเหตุจากผู้ไม่ประสงค์ดี กำลังพยายามโจรกรรมข้อมูล (Traffic Hijacking) ในรูปแบบใดรูปแบบหนึ่งอยู่ เช่น การดักอ่านข้อมูล การปลอมแปลงข้อมูล เป็นต้น SSL Certificate ที่ผิดปกตินี้อาจ ถือเป็นสิ่งบอกเหตุแบบหนึ่งว่าการสื่อสารข้อมูลนี้กำลังถูกโจมตีอยู่ และตามหลักทฤษฎีของการใช้งานสารสนเทศอย่างมั่นคงปลอดภัยได้แนะนำให้ ผู้ใช้งานควรยกเลิกสื่อสารข้อมูลกับ Web Server นั้นต่อไป เพราะมีความเสี่ยงที่ข้อมูลที่สื่อสารกันอาจจะถูกดักอ่านหรือปลอมแปลงจากผู้ไม่ประสงค์ดีได้

untrusted-ssl.jpg

อย่างไรก็ตามในทางปฏิบัติ ในบางสถานการณ์ Web Server ที่ใช้งาน SSL Certificate ที่ผิดปกติหรือไม่เป็นที่ยอมรับ อาจเกิดจากการที่ SSL Certificate นั้น ถูกสร้างขึ้นโดยใช้วิธีที่เรียกว่า Self-Sign [3] โดยเฉพาะ Web Server ที่ใช้ภายในองค์กรหลายแห่ง SSL Certificate ชนิดนี้ Web Browser จะถือว่าไม่ได้ถูกรับรองโดย CA ที่ Web Browser เชื่อถือ ทำให้ Web Browser ขึ้นข้อความเตือนผู้ใช้ว่าเป็น SSL Certificate ที่ผิดปกติ บางครั้ง SSL Certificate ที่ใช้กับ Server ภายในเหล่านี้อาจจะมีความผิดพลาดในการกำหนดค่าอื่นๆ อีกหลายอย่าง เนื่องจากการขาดความตระหนักของภัยคุกคามที่อาจจะเกิดขึ้นของผู้ดูแลระบบ เพราะคิดว่าเป็นเรื่องของ Server ที่ใช้งานภายในจึงไม่มีความจำเป็นจะต้องตั้งค่าติดตั้งต่างๆให้ถูกต้อง ทำให้ผู้ใช้งานในองค์กรเหล่านี้เกิดความเคยชินที่จะยอมรับ SSL Certificate ที่ผิดปกติ หรือมองว่าการตรวจสอบ Certificate เป็นเรื่องไม่จำเป็น

เมื่อผู้ใช้งานเคยชินที่จะยอมรับ SSL Certificate ที่ผิดปกติ ทำให้คุณสมบัติของการใช้งานเทคโนโลยี SSL ในการรักษาความมั่นคงปลอดภัยของข้อมูล ทั้งในด้านการพิสูจน์ความแท้จริง (Authenticity) และ การรักษาความลับ (Confidentiality) เสื่อมลง เพราะเมื่อไม่สามารถรับประกันได้ว่า SSL Certificate มาจาก Server ที่แท้จริง ก็ไม่สามารถรับประกันได้ว่า ข้อมูลที่สื่อสารภายใต้ SSL จะไม่รั่วไหลไปสู่ผู้อื่นที่ไม่ใช่คู่สนทนาเช่นกัน

แต่ถึงแม้ผู้ใช้งานจะมีความตระหนักในเรื่อง Security ที่ดี ไม่ยอมรับ SSL Certificate ที่ผิดปกติ ระบบการทำงานของ SSL ก็ยังมีช่องโหว่ที่สำคัญ นั่นคือ ช่องโหว่ในกลไกการทำงานของ SSL และ ความเชื่อถือของหน่วยงานกลางที่ทำหน้าที่ออกใบรับรอง ซึ่งในที่นี้คือ CA ที่มีหน้าที่รับรองความถูกต้องของ Server ปลายทางให้กับผู้ใช้งาน ในลักษณะเดียวกับการที่ลูกค้าให้ความเชื่อถือผลิตภัณท์ใดๆ เพราะผลิตภัณท์นั้นได้รับการรับรองจากหน่วยงานที่ลูกค้าเชื่อถือนั่นเอง

จะเกิดอะไรขึ้นหาก CA ที่ได้รับการยอมรับในระดับสากลมีกระบวนการทำงานที่หละหลวม ไม่มีการตรวจสอบผู้ขอ Certificate ให้แน่ชัดว่าเป็นเจ้าของ Server จริงหรือไม่ เช่น ผู้ไม่ประสงค์ดี ที่ต้องการดักข้อมูลของ Gmail มาขอให้ CA ออก Certificate ของ Gmail ถ้าหาก CA ไม่มีการตรวจสอบที่ดี ว่าผู้ขอเป็นผู้รับผิดชอบหรือเป็นเจ้าของ Gmail หรือไม่ แล้ว CA ออก Certificate ให้ไป Certificate นั้นก็จะสามารถนำไปใช้ดักข้อมูลของ Gmail ในลักษณะ Traffic Hijacking ได้อย่างแนบเนียน เพราะ Certificate ที่ออกมาจาก CA ที่ได้รับการยอมรับในระดับสากลโดยตรงแบบนี้ และเป็น CA ที่ Web Browser เชื่อถือ ก็จะไม่ทำให้ Web Browser แสดงข้อความเตือนแต่อย่างใด

ที่ผ่านมา หลายคนคงจะจำได้ว่า มีรายงานข่าวกรณีเกี่ยวกับการโจมตี CA เพื่อลักลอบออก Certificate ปลอม ของเว็บไซต์ชื่อดังหลายแห่งมาแล้ว 2 ครั้ง อย่างในครั้งล่าสุดมีรายงานว่ามีการตรวจพบในช่วงเดือน ก.ค. ที่ผ่านมานี้เอง โดย Hacker ไม่ทราบกลุ่ม และจุดประสงค์ที่แน่ชัด ได้ทำการโจมตีระบบการออก Certificate ของ DigiNotar ซึ่งเป็น CA ระดับ Root CA ของประเทศ Netherland [4] ในรายงานการวิเคราะห์ที่เชื่อถือได้ พบว่า Hacker กลุ่มหรือบุคคลดังกล่าว ได้ออก Certificate ปลอมสำหรับเว็บไซต์ต่างๆ ไปมากกว่า 200 ใบ (บางรายงานอ้างว่ามากกว่า 500 ใบ) รวมถึงการออก Certificate ปลอมกับโดเมนเนมของ google.com ในกลุ่มผู้เชี่ยวชาญทางด้าน Security กล่าวว่ามีข้อมูลที่ไม่สามารถยืนยันแหล่งข่าวได้ ระบุว่า มีรัฐบาลของบางประเทศ พยายามลักลอบดูข้อมูลการใช้อีเมลของบุคคลที่รัฐบาลประเทศดังกล่าว เชื่อว่ามีแนวคิดในทางต่อต้านรัฐบาล โดยความพยายามดังกล่าว ได้มีมาต่อเนื่องเป็นระยะเวลาไม่ต่ำกว่า 1 ปีแล้ว

หากมีการตรวจพบการทุจริตหรือการโจมตีตามที่กล่าวข้างต้นในบริการการออกใบรับรอง CA สามารถยกเลิก (Revoke) Certificate ที่มีปัญหาได้ตลอดเวลาตามเงื่อนไขของการให้บริการ โดย CA อาจจะเผยแพร่รายการของ Certificate ที่ถูกยกเลิกออกมาตามระยะเวลาที่กำหนด (อาจเร็วกว่ากำหนดได้หากมีเหตุจำเป็นฉุกเฉิน) รายการนี้เรียกว่า CRL (Certificate Revocation List) ซึ่งมักจะมีอยู่ในเว็บไซต์ของ CA แต่ละราย หรือที่อื่นๆ ตามที่ CA กำหนด และ Client จะต้อง Update ข้อมูลนี้อย่างสม่ำเสมอเพื่อให้สามารถตรวจจับ Certificate ที่มีปัญหาได้อย่างทันท่วงที อีกวิธีคือ CA จะใช้กลไกที่เรียกว่า OCSP (Online Certificate Status Protocol) ซึ่งคล้ายกับ Directory service ที่ Client สามารถเข้ามาตรวจสอบสถานะของ Certificate ได้แบบ Real-time

แต่ในความเป็นจริงผู้ใช้งานส่วนมากไม่ได้ตั้งค่าให้ Web Browser ทำการติดต่อกับ CA เพื่อปรับปรุงข้อมูลของ CRL อยู่ตลอดเวลา หรือไม่ได้ตั้งค่าให้ทำการตรวจสอบกับ OCSP ทุกครั้งที่มีการเชื่อมต่อแบบ SSL ทำให้กว่าที่จะรู้ว่า Certificate ใดมีปัญหา ก็อาจสายเกินไป และถึงแม้ Web Browser จะรับรู้ว่า Certificate นี้ถูกยกเลิกแล้ว และขึ้นข้อความเตือนผู้ใช้ก็ตาม ก็ยังขึ้นอยู่กับผู้ใช้ว่า จะสนใจคำเตือนนั้นหรือไม่อีกขั้นหนึ่งด้วย

ยิ่งไปกว่านั้น ในงาน Ekoparty ซึ่งเป็นงานสัมมนาด้านความมั่นคงปลอดภัยสารสนเทศ ที่จะจัดขึ้นในประเทศอาร์เจนตินา ในวันที่ 23 ก.ย. 2554 จะมีการบรรยายและแสดงวิธีการโจมตีการเชื่อมต่อแบบ SSL (และ TLS ซึ่งเป็นรูปแบบที่ใหม่กว่า) ด้วยโปรแกรมซึ่งมีชื่อเรียกว่า BEAST (Browser Exploit Against SSL/TLS) โดยการโจมตีรูปแบบนี้ จะอาศัยการทำงานของ Malicious code ที่ทำงานอยู่บน Client เพื่อดักจับข้อมูลใน Web Browser ซึ่งผู้ที่ค้นพบรูปแบบการโจมตีนี้ระบุว่า ข้อมูลที่ดักจับมาได้นี้ สามารถช่วยให้การถอดรหัสข้อมูลที่ป้องกันด้วย SSL ของ Client ได้โดยไม่ต้องใช้ Key หรือไม่ต้องวุ่นวายกับการทำ Traffic Hijacking แต่อย่างใด [5]

ในความเป็นจริง รูปแบบการโจมตีนี้ไม่ใช่ของใหม่ เพราะเป็นการอาศัยจุดอ่อนในกลไกการเข้ารหัสลับข้อมูลของ SSL และ TLS รุ่นแรกที่ทราบกันมานานแล้ว[6] และแม้จะมีการพัฒนาและปรับปรุง TLS 1.1 และ 1.2 เพื่อแก้ไขจุดอ่อนดังกล่าว แต่เนื่องจากยังไม่มีการค้นพบว่ามีผู้สามารถใช้ประโยชน์จากจุดอ่อนนี้ได้ อย่างจริงจัง ทำให้ยังไม่มีการสนับสนุน TLS รุ่นใหม่เท่าที่ควร ทั้งในด้าน Server และ Client ซึ่งการค้นพบการโจมตีที่ใช้จุดอ่อนนี้ และมีการพิสูจน์ว่าสามารถใช้งานได้จริง น่าจะเป็นการกระตุ้นให้เกิดความตระหนักในภัยคุกคามของเทคโนโลยี SSL ในกลุ่มอุตสาหกรรม IT ได้อย่างจริงจัง หรือแม้กระทั่งเกิดผลกระทบทำให้ผู้ให้บริการธุรกรรมทางอิเล็กทรอนิกส์บางรายจำเป็นต้องหยุดให้บริการชั่วคราวเพื่อแก้ไขปัญหาดังกล่าว

ดังจะเห็นได้ว่า SSL เป็นกลไกในด้านความมั่นคงปลอดภัยที่ขึ้นอยู่กับปัจจัยภายนอกอย่างมาก ทั้งความน่าเชื่อถือของหน่วยงานกลางที่ทำหน้าที่ออกใบรับรอง (CA) และ ความตระหนักในภัยคุกคามที่เกี่ยวข้องกับการใช้งาน Certificate ที่ไม่ถูกต้องของผู้ใช้งาน หรือการใช้งานเทคโนโลยี SSL ในรุ่นแรกที่มีช่องโหว่ ซึ่งได้เห็นแล้วว่าปัจจัยภายนอกทั้งหลายนี้กำลังถูกท้าทายอย่างหนัก จนอาจจะเริ่มมีคำถามว่า ถึงเวลาหรือยังที่ผู้ที่เกี่ยวข้องจะต้องใส่ใจและให้ความตระหนักถึงภัยคุกคามที่เกิดกับเทคโนโลยี SSL อย่างจริงจังเพื่อการรักษาความมั่นคงปลอดภัยของการสื่อสารข้อมูลหรือบริการธุรกรรมทางอิเล็กทรอนิกส์บนเครือข่ายอินเทอร์เน็ต

อ้างอิง

[1] TLS, http://en.wikipedia.org/wiki/Secure_Sockets_Layer
[2] HTTP_Secure, http://en.wikipedia.org/wiki/HTTP_Secure
[3] Self-signed certificate, http://en.wikipedia.org/wiki/Self-signed_certificate
[4] ระวังภัย แฮ็กเกอร์ออกใบรับรองปลอมของ Google Yahoo! Mozilla และอื่นๆ , http://www.thaicert.or.th/alerts/home/2011/al2011ho0001.html
[5] Hackers break SSL encryption used by millions of sites, http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
[6] A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.5887

Clear