เมื่อไม่กี่วันที่ผ่านมา วงการเว็บโดยเฉพาะผู้ที่ทำเว็บแบบเข้ารหัส HTTPS ทั้งหลายอาจจะได้อ่านข่าวเล็กๆ ข่าวหนึ่ง คือ Chrome กำลังจะประกาศว่าใบรับรองดิจิตอลที่ยืนยันความถูกต้องด้วย SHA-1 จะถือว่าไม่ปลอดภัยอีกต่อไป ความโหดร้ายของกูเกิลคือทางกูเกิลประกาศมาโดยให้เวลาเพียงไม่กี่วันก่อนที่จะเริ่มบังคับใช้กฎใหม่นี้ ดังนั้นภายในสิ้นเดือนนี้เราอาจจะพบว่าเว็บที่เข้ารหัสได้รับผลกระทบกันเป็นวงกว้าง

บทความนี้เขียนขึ้นเพื่อแบ่งปัน "ผู้ดูแลระบบ" ทุกท่านที่ต้องดูแลเว็บที่เข้ารหัสอยู่ ว่าทำไมท่านนั่งอยู่ดีๆ ถึงได้งานเข้า (เหมือนทีมงาน Blognone ที่นั่งแก้ใบรับรองกันในวันนี้)

กระบวนการรับรอง SSL

ก่อนที่จะพูดถึงกระบวนการลดการใช้งาน SHA-1 ของกูเกิล เราจะมาพูดถึงกระบวนการที่เบราว์เซอร์จะ "เชื่อถือ" เว็บสักเว็บหนึ่งกันก่อน เว็บที่เข้ารหัส HTTPS นั้นมีข้อบังคับอย่างหนึ่งคือนอกจากการเชื่อมต่อระหว่างเบราว์เซอร์และเซิร์ฟเวอร์จะเข้ารหัสแล้ว เบราว์เซอร์ยังต้องตรวจสอบได้ว่าเซิร์ฟเวอร์ที่กำลังคุยด้วยอยู่นั้น เป็นเซิร์ฟเวอร์ของโดเมนนั้นๆ จริง

กระบวนการเข้าเว็บโดยทั่วไปไม่ได้รับรองว่าเรากำลังเข้าเว็บโดยตรง เช่น เพราะสิ่งที่เราดาวน์โหลดมาจำนวนมากอาจจะมาจากพรอกซี่ในองค์กรของเราเอง การยืนยันว่าเรากำลังเชื่อมต่อแบบเข้ารหัสกับเซิร์ฟเวอร์ที่ระบุนั้น เบราว์เซอร์ของเราจะเชื่อถือ องค์กรจำนวนหนึ่งเรียกว่า Certification Authority (CA) ให้ตรวจสอบและรับรองเซิร์ฟเวอร์อื่นๆ ในโลกว่าเป็นตัวจริงหรือไม่ เบราว์เซอร์บางตัวเลือกจะเชื่อตามที่ "ระบบปฎิบัติการ" เชื่อถือ เช่น Chrome ส่วนบางเบราว์เซอร์ก็มีรายชื่อองค์กรที่เชื่อถือของตัวเอง เช่น Firefox

เมื่อระบบปฎิบัติการหรือเบราว์เซอร์เชื่อถือองค์กรใดๆ ให้ไปรับรองเว็บอื่นๆ ได้แล้ว สิ่งที่ต้องทำต่อมาคือการรับเอาใบรับรองขององค์กรนั้นๆ เข้ามาในระบบ อย่างตัวอย่างในภาพข้างบนเป็นหน้าจอของ Chrome OS ที่มีใบรับรองของบริษัท A-Trust อยู่ในระบบ ดังนั้นหากบริษัท A-Trust เชื่อถือใครก็ตาม Chrome จะถือว่าเว็บนั้นๆ ที่กำลังเชื่อมต่ออยู่น่าจะเป็นตัวจริง และแสดงรูปกุญแจสีเขียวๆ มาให้เราอุ่นใจ

ลายเซ็นดิจิตอล

ในใบรับรองดิจิตอลนั้น ข้อมูลที่เป็นหัวใจสำคัญได้แก่

• ชื่อที่ต้องการรับรอง สามารถเป็นได้หลายอย่าง เช่น อีเมล, โดเมน (ส่วนใหญ่ใช้อันนี้), และชื่อองค์กร (มักใช้กันในกรณีต้องการเซ็นเอกสารส่งราชการ)
• วันที่เริ่มใช้และวันหมดอายุ
• กุญแจสาธารณะ ทุกวันนี้เกือบทุกเว็บจะใช้กระบวนการเข้ารหัสแบบกุญแจอสมมาตร (asymmetric key)
• ลายเซ็นขององค์กรที่มารับรอง ประเด็นของบทความนี้อยู่ตรงนี้ มันคือค่าแฮช (hash) ที่เข้ารหัสด้วยกุญแจลับขององค์กรผู้เข้า

กระบวนการขอใบรับรองนั้นเว็บที่ต้องการใบรับรองจะต้องไปหาองค์กรที่เบราว์เซอร์ส่วนใหญ่เชื่อถือ และขอให้องค์กรเหล่านั้นช่วยรับรองให้ กรณีของ Blognone คือ Comodo ในภาพตัวอย่างตัดข้อมูลบางส่วนออก ไม่ตรงกับความจริงนัก แต่กระบวนการโดยทั่วไปก็คงหลักการเดียวกัน คือ Comodo จะต้องพิสูจน์ว่าคนที่มาขอใบรับรองของ www.blognone.com นั้นเป็นเจ้าของโดเมนจริง ส่วนใหญ่แล้วกระบวนการตรวจสอบคือการส่งอีเมลไปหาเจ้าของโดเมน เช่น admin@[โดเมน], root@[โดเมน], หรือ administrator@[โดเมน] คล้ายกับการสมัคร Blognone เองที่ผู้ใช้จะได้รับอีเมลและต้องไปกดลิงก์ยืนยันหนึ่งครั้งก่อนเสมอ

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

เนื่องจากข้อมูลที่ถอดรหัสจากกุญแจสาธารณะขององค์กรผู้รับรองได้จะต้องเข้ารหัสด้วยกุญแจลับขององค์กรซึ่งไม่มีใครล่วงรู้ ดังนั้นถ้าเบราว์เซอร์เชื่อองค์กรนั้นว่าตรวจสอบเว็บมาอย่างดี ก็สามารถเชื่อว่ากำลังเชื่อมต่อกับเว็บตัวจริงด้วยเช่นกัน

บางครั้งองค์กรที่เบราว์เซอร์เชื่อถือกลับทำผิดพลาด ถูกแฮก และออกใบรับรองให้กับคนอื่นๆ ที่ไม่ใช่เจ้าของโดเมนก็มีมาแล้ว เช่น เหตุการณ์ DigiNotar

แฮชชน ปัญหาหลักของความปลอดภัย

ระบบการเชื่อมต่อ SSL นั้นไม่ได้ระบุไว้ตายตัวว่าการตรวจสอบความถูกต้องของใบรับรองจะต้องใช้กระบวนการอะไร แต่เปิดให้ผู้รับรองและผู้ถูกรับรองสามารถเลือกใช้กระบวนการกันเองได้ ก่อนหน้านี้ไม่กี่ปีกระบวนวิธีแฮชที่ได้รับความนิยมสูง คือ MD5 ที่ทำงานได้เร็ว ปรากฎว่านักวิทยาการรหัสลับพบว่า เราสามารถสร้างข้อมูลที่มีค่าแฮชตรงกับข้อมูลอีกชุดหนึ่งได้ไม่ยากนัก

การที่ค่าแฮชจากข้อมูลที่ไม่เหมือนกันแต่กลับมีค่าแฮชตรงกันนี้เรียกว่า hash collision เนื่องจากใบรับรองนั้นตรวจสอบจากค่าแฮช หากเราสามารถสร้างใบรับรองที่ต่างจากใบรับรองจริง มีกุญแจสาธารณะต่างกัน แต่ลายเซ็นกลับเหมือนกันทุกประการ เมื่อเบราว์เซอร์ตรวจสอบแล้วก็จะเชื่อว่าใบรับรองปลอมนั้นเป็นของจริง ภาพตัวอย่างสมมติว่าใบรับรองของ Blognone ถูกปลอม

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

ทุกวันนี้ใบรับรองทั่วโลกกว่า 90% ตรวจสอบความถูกต้องด้วย SHA-1 ตามรายงานของ Netcraft เมื่อกลางปีที่ผ่านมา โดยปริมาณการใช้งาน SHA-2 ยังไม่ถึง 10%

SHA-1 ถูกออกแบบให้แข็งแกร่งมาตั้งแต่ปี 1995 แต่จากการตรวจสอบของนักวิทยาการรหัสลับก็พบว่ามันมีจุดอ่อนหลายอย่าง ทำให้ค่าแฮชที่ยาว 160 บิต มีความแข็งแกร่งเพียง 61 บิตเท่านั้น หมายความว่าแฮกเกอร์ลองสร้างข้อมูลไปประมาณ 2^61 ครั้งก็จะได้ข้อมูลชุดใหม่ที่มีค่าแฮช (และลายเซ็นดิจิตอล) ที่เหมือนเดิมทุกประการ สามารถทำไปหลอกคนอื่นได้ว่าเป็นใบรับรองจริง

ทุกวันนี้ยังไม่มีรายงานพบใบรับรองดิจิตอลที่ใช้ SHA-1 ปลอม แต่ Bruce Schneier เคยประมาณค่าใช้จ่าย ในปี 2012 ระบุว่าการสร้างใบรับรองปลอม อาจจะใช้เงินประมาณ 2.77 ล้านดอลลาร์ในปี 2012 หรือต่ำกว่า 100 ล้านบาท ขณะที่ความเสียหายหากแฮกเกอร์สามารถปลอมใบรับรองเหล่านี้ได้กับเว็บเช่นเว็บธนาคารได้ จะสูงกว่า 100 ล้านบาทหลายเท่าตัว ที่สำคัญคือค่าใช้จ่ายนี้จะถูกลงเรื่อยๆ อย่างรวดเร็ว ประมาณค่าใช้จ่ายแล้ว

• ในปี 2015 ค่าปลอมใบรับรองจะอยู่ที่ 700,000 ดอลลาร์
• ในปี 2018 ค่าปลอมใบรับรองจะอยู่ที่ 173,000 ดอลลาร์
• ในปี 2021 ค่าปลอมใบรับรองจะอยู่ที่ 43,000 ดอลลาร์

ค่าใช้จ่ายเหล่านี้ "ถูกเกินไป" ที่เราจะหวังไม่มีใครรวยพอที่จะปลอมใบรับรองเพื่อดักฟังระหว่างเรากับคนอื่นๆ ที่ต้องการความปลอดภัยสูง องค์กรระดับรัฐอาจจะทุ่มงบประมาณเพื่อปลอมใบรับรองเป็นวงกว้าง การออกแบบฮาร์ดแวร์เฉพาะด้วยความเชี่ยวชาญสูงอาจจะทำให้ต้นทุนถูกลงกว่านี้ได้อีกหลายเท่าตัว พลังประมวลผลขนาดใหญ่มากทุกวันนี้สามารถซื้อได้จาก Amazon EC2, Google Compute Engine, หรือการซื้อการ์ดกราฟิกล็อตใหญ่ๆ สักล็อต

NIST เองระบุว่าหน่วยงานรัฐบาลสหรัฐฯ ไม่ควรใช้ SHA-1 ตั้งแต่สิ้นปี 2013 เป็นต้นไป

ไมโครซอฟท์และกูเกิลเตรียมกระบวนการเลิกรับ SHA-1

ไมโครซอฟท์ออกมาระบุกระบวนการเลิกรองรับ SHA-1 มาตั้งแต่ปลายปีที่แล้ว โดยจะมีผลกับ Windows Vista ขึ้นไป (เพราะ Windows XP ไม่มีการอัพเดตอีกแล้ว) โดยระบุกฎ ได้แก่

• CA ทั้งหมดจะต้องเลิกออกใบรับรองด้วย SHA-1 ตั้งแต่วันที่ 1 มกราคม 2016 เป็นต้นไป
• ใบรับรองที่ยืนยันด้วย SHA-1 จะใช้งานไม่ได้อีกต่อไปหลังวันที่ 1 มกราคม 2017

กรนีของไมโครซอฟท์ถือว่า "ใจดี" อย่างมากเพราะประกาศล่วงหน้าสองปีเต็มๆ

กรณีของกูเกิลเพิ่งออกมาประกาศเมื่อสัปดาห์ที่แล้ว กูเกิลเลือกแนวทาง "ค่อยเป็นค่อยไป" แทนที่จะเป็นการประกาศวันที่ห้ามใช้ใบรับรองที่ใช้ SHA-1 กูเกิลประกาศโทษสามระดับสำหรับเว็บที่ใช้ SHA-1 คือ เริ่มเตือนว่ามีปัญหาเล็กน้อย (minor error), ไม่ถือว่าปลอดภัย (lacking security), และยืนยันว่าไม่ปลอดภัย (affirmatively insecure) โดยแบ่งตามช่วงเวลาที่ใบรับรองหมดอายุ มีสามระดับได้แก่ใบรับรองที่หมดอายุตั้งแต่ปี 2017 เป็นต้นปี, ใบรับรองที่หมดอายุภายในสิ้นปี 2016, และใบรับรองที่หมดอายุหลังปี 2015

ด้วยแนวทางนี้ถ้าใครต่ออายุใบรับรองแบบปีต่อปี ก็ยินดีกับทุกท่านครับ ท่าจะไม่มีปัญหาอะไรในปีนี้จนกว่าจะต่ออายุใบรับรองในปีหน้า สิ่งที่ท่านต้องเตรียมก็มีเพียงว่าปีหน้าควรจะขอใบรับรองแบบ SHA-2 ได้แล้ว

แต่สำหรับคนที่ต่อใบรับรองไว้เกินสองปี จะเริ่มมีปัญหาในเร็วๆ นี้ โดยไม่ว่าจะคอนฟิกถูกต้องแค่ไหน เว็บของท่านจะเริ่มถูกเตือนว่าคอนฟิกผิดพลาดเล็กน้อย ตั้งแต่วันที่ 29 กันยายนนี้เป็นต้นไป ส่วนคนอื่นๆ ที่ต่ออายุใบรับรองนี้เอาไว้เกินหนึ่งปี จะเริ่มมีปัญหาในปีหน้า เมื่อ Chrome 41 ปล่อยให้อัพเดต

สิ่งที่ควรทำระหว่างนี้

• ตรวจสอบว่าผู้ให้บริการรับรองของท่านรองรับ SHA-2 หรือไม่ การรองรับหมายถึง immediate CA ทั้งหมดของผู้ให้บริการต้องรับรองด้วย SHA-2 ทั้งหมด ห้ามมีตัวใดตัวหนึ่งในสายเป็น SHA-1 ยกเว้นตัว root CA
• หากต่ออายุใบรับรองปีต่อปี เตรียมหาหน่วยงานรับรองที่รองรับ SHA-2 (ที่จริงน่าจะรองรับแทบทุกที่ แต่กระบวนการขอใบรับรองโดยระบุว่าต้องการ SHA-2 ต่างกันไป)
• หากต่ออายุใบรับรองไว้ยาวๆ เช่น 5 ปี (เหมือน Blognone) เตรียม reissue ใบรับรองโดยเร็ว โดยทั่วไปแล้วมักไม่เสียค่าใช้จ่าย
• สร้างไฟล์ขอใบรับรอง (CSR) ใหม่ โดยเพิ่มออปชั่น -sha256 เพื่อระบุกับองค์กรรับรองว่าต้องการใบรับรองแบบ SHA-2 เช่น openssl req -new -sha256 -key blognone.key -nodes -out blognone.csr โดยอาจจะใช้ SHA-384 หรือ SHA-512 ได้ตามชอบใจ แต่บาง CA อาจจะไม่รองรับ เช่น Comodo นั้นรองรับ SHA-256 เท่านั้น
• ตรวจสอบความเข้ากันได้ของผู้ใช้ ใน Windows XP นั้น รุ่นที่รองรับ SHA-2 จะต้องเป็น Service Pack 3 เท่านั้น หรือหากเป็นแอนดรอยด์จะต้องเป็น Android 2.3 ขึ้นไป กรณีเช่นนี้องค์กรจำเป็นต้องยกเลิกการให้บริการระบบปฎิบัติการที่ไม่ได้รับซํพพอร์ตเหล่านี้แล้ว (ตรวจสอบการรองรับ SHA-2 กับ Global Sign)