AWS เปิดบริการ AWS Certificate Manager ทำให้ลูกค้าที่ใช้ Elastic Load Balancing และ CloudFront สามารถให้บริการเว็บเข้ารหัสได้โดยไม่ต้องเสียเงินค่าใบรับรองเพิ่มเติมอีก

เมื่อปีที่แล้วอเมซอนยื่นเรื่องขอเป็น root CA ในฐานข้อมูลของมอซิลล่าและแอนดรอยด์ แต่ระหว่างนี้ใบรับรองจะได้รับการรับรองโดย "Amazon Root CA 1" ที่ถูกรับรองโดย "Starfield Services Root Certificate Authority - G2" ต่อมาอีกที

ทีมวิจัยจากสถาบันวิจัย INRIA ในฝรั่งเศสนำเสนอช่องโหว่ใหม่ในมาตรฐาน TLS 1.2 ที่รองรับกระบวนการเซ็นลายเซ็นรับรองข้อความแบบ RSA-MD5 จากเดิมที่ TLS 1.1 ลงไปจะบังคับให้ใช้แฮช MD5 ต่อกับ SHA1 เท่านั้น

มาตรฐาน TLS 1.2 เปิดให้เซิร์ฟเวอร์สามารถเซ็นด้วยแฮชใดๆ ก็ได้เพื่อเปิดช่องทางให้เซิร์ฟเวอร์สามารถเลือกกระบวนการแฮชที่แข็งแรงขึ้นเช่น SHA-256 หรือ SHA-512 แต่การออกแบบเช่นนี้ก็ทำให้เซิร์ฟเวอร์เปิดรองรับกระบวนการเซ็นด้วย MD5 ไปด้วย

โครงการใบรับรองดิจิตอลฟรี Let's Encrypt เพิ่งเปิดให้บริการต่อสาธารณะไม่กี่วัน กลุ่มอำนาจเก่าผู้เสียผลประโยชน์ อย่าง GoDaddy และ Namecheap ก็ออกมาเคลื่อนไหว

ฝั่ง Namecheap นั้นออกมาเขียนบล็อกโจมตี ระบุข้อเสียของใบรับรองดิจิตอลฟรี ระบุว่าใบรับรองฟรีนั้นเพียงแค่เพิ่มการเข้ารหัสท่านั้น และไม่ได้ตรวจสอบผู้รับใบรับรองก่อนที่จะมอบใบรับรอง (ซึ่งไม่จริง เพราะ Let's Encrypt นั้นตรวจสอบผู้ถือครองโดเมน)

ขณะที่ GoDaddy ก็ออกหน้าเปรียบเทียบใบรับรอง และระบุว่าการทำเว็บเพื่อการค้านั้นต้องใช้ใบรับรองแบบ Extended Validation เท่านั้น

ประเด็นการยกเลิกรองรับใบรับรองดิจิตอลที่ตรวจสอบด้วย SHA-1 นับเป็นการย้ายมาตรฐานความปลอดภัยขนานใหญ่ที่สุดครั้งหนึ่งของโลกอินเทอร์เน็ต ภายในปีหน้าเว็บต่างๆ ทั่วโลกจะถูกกดดันให้ต้องรองรับ SHA-2 เช่น SHA-256 ขึ้นไปเท่านั้น ไม่เช่นนั้นเว็บเบราว์เซอร์จะเริ่มเตือนว่าไม่ปลอดภัยโดยไม่มีทางออกอื่น (ตอนนี้ยังมีทางออกเช่นขอใบรับรองที่อายุสั้นๆ ได้)

แต่ Alex Stamos จากเฟซบุ๊ก และ CloudFlare ก็ออกมาชี้ปัญหาที่กำลังจะเกิดขึ้นในอีกไม่กี่วันข้างหน้านี้ ว่าเว็บขนาดใหญ่ยังมีปัญหาเพราะผู้ใช้จำนวนถึง 3-7% ในแต่ละประเทศยังใช้เบราว์เซอร์ที่ไม่รองรับ SHA-2 อยู่

ศูนย์วิจัย Microsoft Research-Inria Joint Centre สร้างไลบรารี TLS ที่ตั้งเป้าหมายว่าจะตรวจสอบทางคณิตศาสตร์ได้ว่าไม่มีช่องโหว่ให้โจมตีได้ ใช้ชื่อว่า miTLS

ตัวไลบรารีเขียนด้วยภาษา F# และสร้างสเปคการตรวจสอบด้วยภาษา F7 และเวอร์ชั่นใหม่จะพัฒนาด้วยภาษา F*

Let's Encrypt เปิดตัวโครงการมาครบรอบหนึ่งปีพอดี กำหนดการเดิมที่จะปล่อยใบรับรองให้กับสาธารณะวันจันทร์นี้ก็เลื่อนไปเป็นวันที่ 3 ธันวาคมที่จะถึงนี้ แม้จะเปิดให้คนทั่วไปใช้งาน แต่ทางโครงการก็ยังระบุว่าเป็นช่วงทดสอบระบบ (เบต้า) เท่านั้น และยังมีงานต้องทำก่อนจะพร้อมใช้งานจริงสำหรับคนทั่วไป

จนตอนนี้ทาง Let's Encrypt ปล่อยใบรับรองให้กับผู้ที่เข้าร่วมโครงการเบต้าแล้วกว่า 11,000 ใบ

ที่มา - Let's Encrypt

ทีมวิจัยร่วมกันสามชาติ เนเธอร์แลนด์, ฝรั่งเศส, และสิงคโปร์ แถลงผลงานวิจัยการสร้างค่าที่มีค่าแฮช SHA1 ตรงกัน (SHA1 collision) ด้วยต้นทุนเพียง 75,000 ถึง 120,000 ดอลลาร์หากเช่าเครื่องจาก Amazon EC2 จากเดิมที่ Bruce Schneier เคยประมาณการณ์ว่าปี 2015 จะใช้ทุนประมาณ 700,000 ดอลลาร์

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

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

เงื่อนไขที่กูเกิลระบุมี 5 ข้อ ได้แก่

ทีมวิจัยจากมหาวิทยาลัยหลายแห่งและไมโครซอฟท์ประกาศช่องโหว่ของ TLS ที่ชื่อว่า Logjam สามารถเจาะการเชื่อมต่อทำให้การเชื่อมต่อไปใช้มาตรฐานการเชื่อมต่อ Diffie-Hellman ขนาด 512 บิต หรือ DHE_EXPORT และสามารถถอดรหัสได้โดยง่าย

ที่งาน RSA Conference วันนี้ Will Dormann นักวิจัยจาก CERT ที่มหาวิทยาลัย Carnegie Mellon รายงานถึงช่องโหว่การตรวจสอบใบรับรอง SSL ที่มีแอพจำนวนมากเขียนโค้ดอย่างหละหลวม ทำให้ตัวแอพไม่ตรวจสอบใบรับรองทำให้แฮกเกอร์สามารถดักฟังแบบ man-in-the-middle ได้

Dormann ระบุว่าทาง CERT ตรวจสอบแอพกว่าล้านรายการเมื่อต้นปีที่ผ่านมา และพบแอพที่มีช่องโหว่นี้มากถึง 23,667 แอพ ทางทีมงานได้ส่งอีเมลไปแจ้งผู้พัฒนา เกือบทั้งหมดไม่มีการตอบกลับใดๆ บางส่วนแสดงท่าทีว่าอีเมลแจ้งเตือนเป็นเรื่องแย่ มีอีเมลตอบกลับพร้อมแจ้งการแก้ปัญหาเพียง 0.1% เท่านั้น

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

กูเกิลออกประกาศเตือนว่ามีใบรับรอง SSL ปลอมออกโดย MCS Holdings หน่วยงานรับรองระหว่างกลาง (intermediate CA) ตั้งอยู่ในอียิปต์ ได้ออกใบรับรองโดเมนของกูเกิลหลายโดเมนทำให้มีความเสี่ยงว่าโดเมนเหล่านั้นจะถูกดักฟังโดยคนที่ได้รับกุญแจและใบรับรองเหล่านี้

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

Qualys ผู้ให้บริการ SSL Labs เปิดซอร์สโค้ดของโปรแกรม ssllabs-scan เพื่อให้ผู้ดูแลระบบสามารถเข้าถึง API ของ SSL Labs ได้ผ่าน command-line ทำให้ตั้งช่วงเวลาให้ตรวจสอบเซิร์ฟเวอร์เป็นระยะ และรายงานผลเป็นไฟล์ JSON ได้

ก่อนหน้านี้ Qualys เปิดหน้าเว็บ SSL Pulse แล้วตั้งการสแกนเว็บไซต์ประมาณ 200,000 เว็บแรกบนรายการ Alexa เพื่อรายงานสถานการณ์การคอนฟิก SSL อย่างถูกต้อง รายงานฉบับล่าสุดของเดือนนี้มีเว็บไซต์ที่คอนฟิกอย่างปลอดภัย (เกรด A- ขึ้นไป) อยู่ที่ 18.2% เท่านั้น

OpenSSL ประกาศบั๊กตามที่แจ้งไว้ล่วงหน้า แก้บั๊กความร้ายแรงสูงสองตัว ได้แก่ บั๊ก FREAK ที่เป็นข่าวไปเมื่อต้นเดือนที่ผ่านมา และบั๊กใหม่ที่ทำให้เซิร์ฟเวอร์ล่มได้จากการเชื่อมต่อจากภายนอก

หลังบั๊ก Heartbleed ที่ส่งผลกระทบเป็นวงกว้างต่อเซิร์ฟเวอร์จำนวนมากในเดือนเมษายนปีที่แล้ว บริษัทจำนวนมากระดมทุนเพื่อให้ OpenSSL มีทรัพยากรเพียงพอต่อการพัฒนา อีกส่วนหนึ่งก็จัดสรรมาให้โครงการ Open Crypto Audit เพื่อตรวจสอบโค้ดซอฟต์แวร์เข้ารหัส ตอนนี้ทาง OpenSSL และ Cryptography Services (CS) ผู้เข้าตรวจสอบก็พร้อมจะเริ่มกระบวนการตรวจสอบแล้ว

French Institute for Research in Computer Science and Automation (Inria) และ Microsoft ค้นพบช่องโหว่ของ SSL/TLS ที่เกิดขึ้นมาเป็นเวลานับ 10 ปี พบในไลบรารี OpenSSL เวอร์ชัน 1.01k หรือเก่ากว่า และ Secure Transport ของ Apple กระทบทั้งผู้ใช้ Apple และ Android หลายล้านคน รวมถึงเว็บไซต์ทางการของทำเนียบขาว, FBI หรือแม้แต่ NSA

กระบวนการรักษาความปลอดภัยเว็บในช่วงหลังๆ เราเห็นผลงานของฝั่งเบราว์เซอร์กันค่อนข้างชัดเจนจากการออกมาตรฐานใหม่ๆ มากมายและร่วมกันรองรับมาตรฐานในเวลาใกล้เคียงกัน แต่ฝั่งผู้รับรองหรือ Certification Authorities (CAs) เองก็เริ่มรายงานความคืบหน้าฝั่งตัวเองออกมากันแล้ว ผ่านทางกลุ่มของ CAs ออกมาจากกลุ่ม Certificate Authority Security Council (CASC) ที่ก่อตั้งเมื่อปี 2013

หลังรายงานโปรแกรมโฆษณา Superfish ถูกติดตั้งมากับโน้ตบุ๊กเลอโนโวหลายรุ่น โดย Superfish จะคั่นกลางเว็บทุกเว็บแม้แต่เว็บที่เข้ารหัส และแทรกโฆษณาเข้าไปในหน้าเว็บเหล่านั้น ตอนนี้ทุกเครื่องที่มี Superfish อยู่ในเครื่องเสี่ยงต่อการถูกดักฟังทั้งหมด

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

Venefi และ DigiCert บริษัทให้บริการรับรองตัวตน (Certification Authority - CA) ประกาศเข้าร่วมกับโครงการ Certificate Transparency ที่ก่อตั้งโดยกูเกิล ที่ชักชวนให้ CA ทั้งหลายเปิดเผยข้อมูลการออกใบรับรองสู่สาธารณะ

ทาง DigiCert ระบุว่าจะเปิดเผยเฉพาะใบรับรองระดับ EV (Extended Validation ที่มีชื่อบริษัทอยู่ในช่อง URL) แต่ไม่รวมถึงใบรับรองทั่วไป ส่วน Venafi ไม่ได้ระบุว่าจะเปิดเผยข้อมูลมากแค่ไหน

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

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

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

โครงการนี้เกิดจากความร่วมมือของ มอซิลล่า, ซิสโก้, Akamai, EFF, และกลุ่มนักวิจัย Internet Security Research Group (ISRG) ตัวโครงการจะดูแลโดย ISRG ที่เป็นองค์กรไม่แสวงหากำไรตามกฎหมายอยู่แล้ว

Let's Encrypt จะเป็นหน่วยงานออกใบรับรอง (Certification Authority - CA) ที่แจกใบรับรองฟรีหลังการตรวจสอบความเป็นเจ้าของโดเมนด้วยระบบอัตโนมัติ รายการใบรับรองทั้งหมดที่แจกออกไปจะเปิดเผยสู่สาธารณะ

กูเกิลโดยทีมแอนดรอยด์ปล่อยชุดทดสอบการเชื่อมต่อแบบ TLS/SSL ว่าปลอดภัยต่อช่องโหว่ที่รู้กันดีหรือไม่ ใช้ชื่อชุดทดสอบว่า nogotofail ล้อเลียนบั๊ก goto fail; ใน iOS เมื่อต้นปีนี้

nogotofail จะทดสอบช่องโหว่ TLS/SSL ที่พบบ่อยได้แก่ การไม่ตรวจสอบใบรับรอง, บั๊กต่างๆ ของไลบรารี HTTPS/TLS/SSL, SSL stripping, STARTTLS, และปัญหาอื่นๆ

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

นักวิจัยตีพิมพ์งานวิจัยช่องโหว่ใหม่ของ TLS ในโหมด CBC (Cipher Block Chaining) ที่ตั้งชื่อว่า "Lucky Thirteen" ที่เป็นช่องโหว่ที่อาศัยผลข้างเคียง (side-channel) คือเวลาในการประมวลผลของแต่ละเซสชั่น โดยข้อมูลที่ถูกต้องจะใช้เวลาประมวลผลโดยเฉลี่ยต่ำกว่าข้อมูลที่ผิด

เพียงไม่กี่วันหลังจากพบบั๊กในมาตรฐาน TLS นักศึกษาจากตุรกีก็สามารถอาศัยช่องโหว่ดังกล่าวในการขโมยข้อมูล Cookie และข้อมูลการล็อกอินไปจากเจ้าของข้อมูลได้แล้ว

การโจมตีดังกล่าวอาศัยการแทรกข้อมูล HTTP GET ลงไปก่อนหน้าข้อมูลจริงของเหยื่อ ทำให้สามารถโอนข้อมูลจาก URL และค่าบัญชีผู้ใช้ของเหยื่อไปยังบัญชีผู้ใช้ของผู้โจมตีได้

รายงานดังกล่าวโจมตีเว็บที่ใช้ HTTP Basic Auth เช่น Twitter โดยผู้โจมตีสามารถขโมยทั้งชื่อผู้ใช้และรหัสผ่านไปได้แม้จะใช้ HTTPS ก็ตามที

ระหว่างนี้ยังไม่มีมาตรการใดนอกจากการยกเลิกฟังก์ชั่น Renegotiating

เมื่อวันพฤหัสบดีที่ผ่านมามีการรายงานถึงปัญหาของมาตรฐาน TLS ทำให้เสี่ยงต่อการถูกโจมตี แบบ MITM (man-in-the-middle) ทำให้การเชื่อมต่อแม้จะเป็นแบบเข้ารหัสจะเสี่ยงต่อการแก้ไขข้อความที่ใช้ในการเชื่อมต่อ SSL ซึ่งสร้างความเสี่ยงอื่นๆ ตามมาในอนาคต

ปัญหานี้เกิดขึ้นจากความสามารถในการทำ Renegotiating ซึ่งมีระบุไว้ในมาตรฐาน TLS โดยกระบวนการโจมตีดังนี้