เมื่อไม่กี่วันที่ผ่านมา วงการเว็บโดยเฉพาะผู้ที่ทำเว็บแบบเข้ารหัส HTTPS ทั้งหลายอาจจะได้อ่านข่าวเล็กๆ ข่าวหนึ่ง คือ Chrome กำลังจะประกาศว่าใบรับรองดิจิตอลที่ยืนยันความถูกต้องด้วย SHA-1 จะถือว่าไม่ปลอดภัยอีกต่อไป ความโหดร้ายของกูเกิลคือทางกูเกิลประกาศมาโดยให้เวลาเพียงไม่กี่วันก่อนที่จะเริ่มบังคับใช้กฎใหม่นี้ ดังนั้นภายในสิ้นเดือนนี้เราอาจจะพบว่าเว็บที่เข้ารหัสได้รับผลกระทบกันเป็นวงกว้าง
บทความนี้เขียนขึ้นเพื่อแบ่งปัน "ผู้ดูแลระบบ" ทุกท่านที่ต้องดูแลเว็บที่เข้ารหัสอยู่ ว่าทำไมท่านนั่งอยู่ดีๆ ถึงได้งานเข้า (เหมือนทีมงาน Blognone ที่นั่งแก้ใบรับรองกันในวันนี้)
ก่อนที่จะพูดถึงกระบวนการลดการใช้งาน SHA-1 ของกูเกิล เราจะมาพูดถึงกระบวนการที่เบราว์เซอร์จะ "เชื่อถือ" เว็บสักเว็บหนึ่งกันก่อน เว็บที่เข้ารหัส HTTPS นั้นมีข้อบังคับอย่างหนึ่งคือนอกจากการเชื่อมต่อระหว่างเบราว์เซอร์และเซิร์ฟเวอร์จะเข้ารหัสแล้ว เบราว์เซอร์ยังต้องตรวจสอบได้ว่าเซิร์ฟเวอร์ที่กำลังคุยด้วยอยู่นั้น เป็นเซิร์ฟเวอร์ของโดเมนนั้นๆ จริง
กระบวนการเข้าเว็บโดยทั่วไปไม่ได้รับรองว่าเรากำลังเข้าเว็บโดยตรง เช่น เพราะสิ่งที่เราดาวน์โหลดมาจำนวนมากอาจจะมาจากพรอกซี่ในองค์กรของเราเอง การยืนยันว่าเรากำลังเชื่อมต่อแบบเข้ารหัสกับเซิร์ฟเวอร์ที่ระบุนั้น เบราว์เซอร์ของเราจะเชื่อถือ องค์กรจำนวนหนึ่งเรียกว่า Certification Authority (CA) ให้ตรวจสอบและรับรองเซิร์ฟเวอร์อื่นๆ ในโลกว่าเป็นตัวจริงหรือไม่ เบราว์เซอร์บางตัวเลือกจะเชื่อตามที่ "ระบบปฎิบัติการ" เชื่อถือ เช่น Chrome ส่วนบางเบราว์เซอร์ก็มีรายชื่อองค์กรที่เชื่อถือของตัวเอง เช่น Firefox
เมื่อระบบปฎิบัติการหรือเบราว์เซอร์เชื่อถือองค์กรใดๆ ให้ไปรับรองเว็บอื่นๆ ได้แล้ว สิ่งที่ต้องทำต่อมาคือการรับเอาใบรับรองขององค์กรนั้นๆ เข้ามาในระบบ อย่างตัวอย่างในภาพข้างบนเป็นหน้าจอของ Chrome OS ที่มีใบรับรองของบริษัท A-Trust อยู่ในระบบ ดังนั้นหากบริษัท A-Trust เชื่อถือใครก็ตาม Chrome จะถือว่าเว็บนั้นๆ ที่กำลังเชื่อมต่ออยู่น่าจะเป็นตัวจริง และแสดงรูปกุญแจสีเขียวๆ มาให้เราอุ่นใจ
ในใบรับรองดิจิตอลนั้น ข้อมูลที่เป็นหัวใจสำคัญได้แก่
กระบวนการขอใบรับรองนั้นเว็บที่ต้องการใบรับรองจะต้องไปหาองค์กรที่เบราว์เซอร์ส่วนใหญ่เชื่อถือ และขอให้องค์กรเหล่านั้นช่วยรับรองให้ กรณีของ 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 ล้านบาทหลายเท่าตัว ที่สำคัญคือค่าใช้จ่ายนี้จะถูกลงเรื่อยๆ อย่างรวดเร็ว ประมาณค่าใช้จ่ายแล้ว
ค่าใช้จ่ายเหล่านี้ "ถูกเกินไป" ที่เราจะหวังไม่มีใครรวยพอที่จะปลอมใบรับรองเพื่อดักฟังระหว่างเรากับคนอื่นๆ ที่ต้องการความปลอดภัยสูง องค์กรระดับรัฐอาจจะทุ่มงบประมาณเพื่อปลอมใบรับรองเป็นวงกว้าง การออกแบบฮาร์ดแวร์เฉพาะด้วยความเชี่ยวชาญสูงอาจจะทำให้ต้นทุนถูกลงกว่านี้ได้อีกหลายเท่าตัว พลังประมวลผลขนาดใหญ่มากทุกวันนี้สามารถซื้อได้จาก Amazon EC2, Google Compute Engine, หรือการซื้อการ์ดกราฟิกล็อตใหญ่ๆ สักล็อต
NIST เองระบุว่าหน่วยงานรัฐบาลสหรัฐฯ ไม่ควรใช้ SHA-1 ตั้งแต่สิ้นปี 2013 เป็นต้นไป
ไมโครซอฟท์ออกมาระบุกระบวนการเลิกรองรับ SHA-1 มาตั้งแต่ปลายปีที่แล้ว โดยจะมีผลกับ Windows Vista ขึ้นไป (เพราะ Windows XP ไม่มีการอัพเดตอีกแล้ว) โดยระบุกฎ ได้แก่
กรนีของไมโครซอฟท์ถือว่า "ใจดี" อย่างมากเพราะประกาศล่วงหน้าสองปีเต็มๆ
กรณีของกูเกิลเพิ่งออกมาประกาศเมื่อสัปดาห์ที่แล้ว กูเกิลเลือกแนวทาง "ค่อยเป็นค่อยไป" แทนที่จะเป็นการประกาศวันที่ห้ามใช้ใบรับรองที่ใช้ SHA-1 กูเกิลประกาศโทษสามระดับสำหรับเว็บที่ใช้ SHA-1 คือ เริ่มเตือนว่ามีปัญหาเล็กน้อย (minor error), ไม่ถือว่าปลอดภัย (lacking security), และยืนยันว่าไม่ปลอดภัย (affirmatively insecure) โดยแบ่งตามช่วงเวลาที่ใบรับรองหมดอายุ มีสามระดับได้แก่ใบรับรองที่หมดอายุตั้งแต่ปี 2017 เป็นต้นปี, ใบรับรองที่หมดอายุภายในสิ้นปี 2016, และใบรับรองที่หมดอายุหลังปี 2015
ด้วยแนวทางนี้ถ้าใครต่ออายุใบรับรองแบบปีต่อปี ก็ยินดีกับทุกท่านครับ ท่าจะไม่มีปัญหาอะไรในปีนี้จนกว่าจะต่ออายุใบรับรองในปีหน้า สิ่งที่ท่านต้องเตรียมก็มีเพียงว่าปีหน้าควรจะขอใบรับรองแบบ SHA-2 ได้แล้ว
แต่สำหรับคนที่ต่อใบรับรองไว้เกินสองปี จะเริ่มมีปัญหาในเร็วๆ นี้ โดยไม่ว่าจะคอนฟิกถูกต้องแค่ไหน เว็บของท่านจะเริ่มถูกเตือนว่าคอนฟิกผิดพลาดเล็กน้อย ตั้งแต่วันที่ 29 กันยายนนี้เป็นต้นไป ส่วนคนอื่นๆ ที่ต่ออายุใบรับรองนี้เอาไว้เกินหนึ่งปี จะเริ่มมีปัญหาในปีหน้า เมื่อ Chrome 41 ปล่อยให้อัพเดต
สิ่งที่ควรทำระหว่างนี้
-sha256 เพื่อระบุกับองค์กรรับรองว่าต้องการใบรับรองแบบ SHA-2 เช่น openssl req -new -sha256 -key blognone.key -nodes -out blognone.csr โดยอาจจะใช้ SHA-384 หรือ SHA-512 ได้ตามชอบใจ แต่บาง CA อาจจะไม่รองรับ เช่น Comodo นั้นรองรับ SHA-256 เท่านั้น