IETF ประกาศรองรับมาตรฐาน Messaging Layer Security (MLS) สำหรับการส่งข้อมูลเข้ารหัสแบบ end-to-end ที่ได้รับความนิยมกันในหมู่โปรแกรมแชตต่างๆ เช่น Signal แต่ MLS จะเปิดทางให้แอปต่างๆ ที่อาจเคยต้องพัฒนาโปรโตคอลของตัวเองสามารถใช้โปรโตคอลกลางได้ รวมถึงแอปพลิเคชั่นแบบอื่นๆ ที่ไม่ใช่แชตเช่นกัน

กระบวนการเชื่อมต่อแบบเข้ารหัสแบบ end-to-end นั้นมีองค์ประกอบสำคัญคือ ตัวกลางยืนยันตัวตน (Authentication Service - AS) และตัวกลางส่งข้อมูล (Delivery Service - DS) สำหรับ MLS นั้นจะถือว่า AS เชื่อถือได้ไม่ได้โดนแฮก แต่ DS นั้นไม่จำเป็นต้องน่าเชื่อถือ

HTTP/3 หรือ HTTP/QUIC ออกเป็นมาตรฐานจริง RFC 9114 หลังจาก ประกาศชื่อมาตั้งแต่ปี 2018 นับเป็นมาตรฐานตัวสำคัญที่จะทำให้การเชื่อมต่อ HTTP ผ่าน โปรโตคอล QUIC มีมาตรฐานกลางเต็มรูปแบบ

นอกจาก HTTP/3 แล้ว เอกสารอื่นๆ เกี่ยวกับ HTTP ที่ออกมาใกล้ๆ กันเพื่ออัพเดตเอกสารเดิมก็มีอีกหลายตัว ได้แก่

IETF ผ่านมาตรฐาน RFC9116 กำหนดฟอร์แมตของการแจ้งช่องโหว่ซอฟต์แวร์ หรือไฟล์ security.txt ไว้เป็นระบบเดียวกันเพื่อให้ง่ายต่อนักวิจัยในการติดต่อ

ไฟล์ security.txt แจ้งข้อมูลการเปิดเผยช่องโหว่ โดยระบุ URL สำหรับการแสดงความขอบคุณ, ช่องทางติดต่อแจ้งช่องโหว่, กุญแจเข้ารหัสก่อนแจ้งช่องโหว่, นโยบายการเปิดเผยข้อมูลช่องโหว่, ภาษาที่ใช้ติดต่อ, และ URL สำหรับการรับสมัครงาน

ตัวไฟล์ต้องวางไว้ใน /.well-known/security.txt และมาตรฐานเปิดให้มีลายเซ็นดิจิทัลกำกับ ป้องกันในกรณีที่คนร้ายแฮกเว็บได้แล้วและแก้ไขไฟล์เสีย

IETF ออกเอกสาร RFC9225 เตือนถึงอันตรายของบั๊กในซอฟต์แวร์และเรียกร้องให้โปรแกรมเมอร์อย่าสร้างบั๊ก พร้อมกับอธิบายถึงเหตุการณ์ที่บั๊กในซอฟต์แวร์สร้างความเสียหายได้เป็นวงกว้างหลายครั้ง เช่น จรวด ARIANE ยิงไม่สำเร็จเพราะบั๊กแปลงตัวเลขทศนิยมเป็นเลขจำนวนเต็ม หรือระบบเตือนขีปนาวุธของรัสเซียเคยจรวจจับเมฆแล้วคิดว่าเป็นขีปนาวุธ

แนวทางที่ RFC9225 แนะนำ ได้แก่

โปรโตคอล QUIC เป็นกระบวนการเชื่อมต่อสำหรับเว็บที่ กูเกิลเสนอมาตั้งแต่ปี 2015 เพื่อเร่งความเร็วเริ่มต้น โดยเฉพาะการเชื่อมต่อแบบเข้ารหัสที่ปกติต้องส่งข้อมูลไปมาหลายครั้งก่อนจะเชื่อมต่อได้ ที่ผ่านมาโปรโตคอลมีการปรับแต่งหลายครั้งและแต่ละเวอร์ชั่นทำงานร่วมกันไม่ได้ วันนี้ทาง IETF ก็ประกาศมาตรฐานกลาง QUIC เป็น เอกสาร RFC9000

มาตรฐานของ QUIC จริงๆ จะออกเป็นชุด ตอนนี้มีเอกสาร RFC ออกมาแล้ว ได้แก่

IETF ประกาศ RFC8962 ก่อตั้งตำรวจโปรโตคอลตรวจจับการอิมพลีเมนต์โปรโตคอลผิดมาตรฐาน ทำให้เน็ตเวิร์คทำงานร่วมกันไม่ได้

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

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

ที่มา - RFC8962

IETF ผู้วางมาตรฐานอินเทอร์เน็ต ออกเอกสาร RFC8996 ให้มาตรฐาน TLS 1.0/1.1 รวมถึง DTLS 1.0 หมดอายุการใช้งาน (deprecated) อย่างเป็นทางการ หลังจากมีรายงานถึงการโจมตีกระบวนการเข้ารหัสของ TLS ทั้งสองเวอร์ชั่นได้หลายครั้ง

ช่องโหว่ของ TLS 1.0 เช่น กระบวนการเข้ารหัสแบบ cipher block chaining (CBC) อาจถูกโจมตี แม้จะแก้ไขไปแล้วแต่ทั้ง TLS 1.0/1.1 ก็ยังรองรับการแฮชแบบ SHA-1 ที่ตอนนี้เหลือระดับความยุ่งเหยิงเพียง 77 บิต เปิดทางให้คนร้ายสามารถสร้างข้อความปลอมที่แฮชตรงกันได้

IETF รองรับร่างมาตรฐาน draft-ietf-quic-http-34.txt หรือ HTTP/3 เข้าเป็นมาตรฐานเสนอแนะ (Proposed Standard) หลังจากแก้ไขมาหลายสิบครั้งตั้งแต่ปี 2016

มาตรฐาน HTTP/3 ปรับปรุงการทำงานหลายส่วน โดยเปลี่ยนไปใช้ UDP และบังคับเข้ารหัสการเชื่อมต่อด้วย TLS 1.3 รองรับการบีบอัดส่วนหัวของการเชื่อมต่อ (HTTP header) และรองรับการส่งข้อมูลหลายสตรีมในการเชื่อมต่อเดียวกัน

เฟซบุ๊กรายงานถึงการย้ายโปรโตคอลไปยัง HTTP/3 หรือ QUIC ระบุว่าตอนนี้ทราฟิกของเฟซบุ๊กที่เชื่อมต่อผ่านอินเทอร์เน็ตเป็น HTTP/3 มากกว่า 75% แล้ว หลังจากเฟซบุ๊กย้ายแอปให้เชื่อมต่อผ่าน HTTP/3 แทน

เฟซบุ๊กระบุว่าการโยกย้ายมายัง HTTP/3 เริ่มจากเซิร์ฟเวอร์ GraphQL ก่อน ความเร็วที่เพิ่มขึ้นทำให้อัตราการโหลดไม่สำเร็จลดลง 6% ระยะเวลาหน่วง (latency) ลดลง 20%, และขนาด header ลดลง 5% เทียบกับ HTTP/2 อย่างไรก็ดีตัวแอปเฟซบุ๊กนั้นพยายามคำนวณการดาวน์โหลดรูปจากความเร็วในการดาวน์โหลดข้อมูล ทำให้มีช่วงหนึ่งที่แอปพยายามดาวน์โหลดรูปมากเกินไปเพราะดาวน์โหลดข้อมูลได้เร็ว แต่เซิร์ฟเวอร์ดาวน์โหลดรูปยังคงเป็น HTTP แบบ TCP อยู่ ทำให้แอปโดยรวมช้าลง

กูเกิลนับเป็นบริษัทที่สนับสนุนแนวทางการสร้างโปรโตคอลใหม่มาทดแทน HTTP บน TCP มายาวนาน นับแต่ SPDY ตั้งแต่ปี 2009 และ QUIC ในปี 2012 แม้ที่ผ่านมา IETF จะมีแนวทาง ยอมรับ QUIC ให้เป็นส่วนหนึ่งของ HTTP/3 แต่ตัวโปรโตคอลก็มีการแก้ไขหลายส่วน ทำให้ไม่สามารถใช้งานร่วมกับ Google QUIC ที่กูเกิลพัฒนาและใช้งานเองระหว่างเซิร์ฟเวอร์ของกูเกิลและ Chrome ล่าสุดกูเกิลก็ประกาศจะย้ายผู้ใช้ Chrome จำนวน 25% ของทั้งหมด หันมาใช้ IETF QUIC แล้ว

มาตรฐาน ESNI เป็นส่วนหนึ่งของ TLS 1.3 มาตั้งแต่ปี 2018 และเริ่มมีการใช้งานมากขึ้นเรื่อยๆ จากฝั่งเซิร์ฟเวอร์และเบราว์เซอร์ ซึ่งจะทำให้ผู้ให้บริการอินเทอร์เน็ตไม่สามารถมองเห็นได้ว่าผู้ใช้กำลังเชื่อมต่อกับเซิร์ฟเวอร์โดเมนอะไร และรายงานล่าสุดก็พบว่าระบบบล็อกเว็บของจีนหรือ The Great Firewall บล็อค ESNI แล้วตั้งแต่ปลายเดือนกรกฎาคมที่ผ่านมา

ESNI เข้ารหัสข้อมูล SNI (server name indication) ที่เปิดเผยว่าการเชื่อมต่อเข้ารหัสต้องการเชื่อมต่อกับโดเมนใด ที่ผ่านมา SNI ไม่เข้ารหัสทำให้ไฟร์วอลล์สามารถอ่านค่าโดเมนจากการเชื่อมต่อได้ ESNI ปิดช่องโหว่นี้ด้วยการเข้ารหัสชื่อโดเมนทำให้ไฟร์วอลล์มองไม่เห็นว่าการเชื่อมต่อเป็นการต่อกับโดเมนใด

ไมโครซอฟท์ประกาศโอเพนซอร์สไลบรารี MsQuic สำหรับการอิมพลีเมนต์ โปรโตคอล HTTP/3 หรือ QUIC โดยระบุว่าเป็นไลบรารีเดียวกับที่ไมโครซอฟท์จะใช้งานเอง

MsQuic กำลังถูกใช้งานภายในไมโครซอฟท์หลายส่วน ทั้ง Microsoft 365 ที่เริ่มรองรับ HTTP/3, ไลบรารีใน .NET Core 5.0, และ SMB ในวินโดวส์ที่กำลังทดสอบการรองรับ QUIC เช่นกัน โดยการรองรับ SMB บน QUIC นับเป็นการทดสอบสำคัญเพราะจะแสดงให้เห็นว่า QUIC สามารถใช้งานทั่วไปได้ ไม่ต้องเป็นเว็บ โดย QUIC มีความได้เปรียบที่การส่งข้อมูลเริ่มได้ทันทีตั้งแต่การส่งแพ็กเก็ตแรก (0-RTT) ทำให้ระยะเวลาหน่วงในการใช้งานแอปพลิเคชั่นลดลง และสามารถปรับเปลี่ยนกระบวนการจัดการเมื่อปริมาณข้อมูลเต็มแบนวิดท์ (congestion control) ได้ ทำให้ทดสอบและใช้งานเทคนิคใหม่ๆ ได้เร็วขึ้นเทียบกับ TCP ที่ต้องรอระบบปฎิบัติการอัพเดต

HTTP/3 ได้ชื่อเป็นทางการใน การประชุม IETF103 ที่กรุงเทพฯ วันนี้ทาง Cloudflare ก็ประกาศรองรับโปรโตคอลใหม่แล้ว เว็บที่ใช้ Cloudflare จะเริ่มได้รับตัวเลือกเปิดใช้งานและสามารถเข้าเว็บผ่าน HTTP/3 ผ่านทาง Chrome Canary, curl รุ่นล่าสุด, หรือ http3-client ของทาง Cloudflare เอง

คนสายทำเว็บคงรู้จักไฟล์ robots.txt ที่ใช้บอกบ็อตของเครื่องมือค้นหาว่า เพจไหนบ้างที่ไม่ต้องอ่านข้อมูลไปทำดัชนีค้นหา

ฟอร์แมตของไฟล์ robots.txt เรียกว่า Robots Exclusion Protocol (REP) ใช้งานกันแพร่หลายมายาวนาน (de facto) แต่สถานะของมันไม่เคยถูกยกระดับขึ้นเป็นมาตรฐานอินเทอร์เน็ตที่มีองค์กรกลางรับรองมาตลอด 25 ปี (ถูกคิดขึ้นในปี 1994)

ล่าสุดกูเกิลประกาศผลักดัน REP ให้เป็นมาตรฐานอินเทอร์เน็ตภายใต้การดูแลของ Internet Engineering Task Force (IETF) ซึ่งเป็นผู้ดูแลมาตรฐานหลายๆ ตัวที่ใช้กันในปัจจุบัน เช่น OAuth สถานะตอนนี้คือกูเกิลส่งร่างมาตรฐานไปยัง IETF แล้ว และอยู่ในช่วงรับฟังความคิดเห็นตามกระบวนการออกมาตรฐานปกติ

กูเกิลประกาศว่า Gmail ได้เป็นผู้ให้บริการอีเมลรายใหญ่รายแรก ที่สนับสนุนมาตรฐานความปลอดภัยใหม่ 2 รายการ คือ SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 และ SMTP TLS Reporting RFC 8460 ซึ่งกูเกิลร่วมกับผู้ให้บริการอีเมลรายใหญ่ ผลักดัน มาตรฐานนี้ผ่านองค์กร IETF ตั้งแต่ 3 ปีที่แล้ว

อย่างไรก็ตามแม้ Gmail จะประกาศรองรับมาตรฐานใหม่นี้ก่อน แต่หากโดเมนอีเมลของผู้ให้บริการรายอื่นยังไม่รองรับ อีเมลที่ส่งออกไปก็ไม่มีการเข้ารหัสบนมาตรฐานใหม่นี้อยู่ดี กูเกิลจึงหวังว่าผู้ให้บริการอื่นจะรองรับมาตรฐานความปลอดภัยนี้เช่นกัน

ทั้งนี้การร่วมผลักดันมาตรฐานดังกล่าวตั้งแต่ 3 ปีก่อน นอกจากกูเกิล ก็มี ไมโครซอฟท์ และยาฮู ร่วมด้วย

เมื่อวันที่ 7 เมษายนที่ผ่านมา เป็นวันครบรอบเอกสาร RFC หรือ "เอกสารขอความคิดเห็น" ที่เริ่มฉบับแรกเมื่อวันที่ 7 เมษายน 1969 หรือ 12 ปีก่อนอินเทอร์เน็ตที่เริ่มจริงจังในยุค IPv4 ( RFC791 ) ในปี 1981 โดยตัว RFC เกิดขึ้นในยุค ARPANET

DARPA (ชื่อ ARPA ในยุคนั้น) ต้องการสั่งซื้ออุปกรณ์เครือข่ายแบบ packet-switching โดยเรียกว่า Interface Message Processors (IMP) หลังจากนักวิจัยได้รับงานจาก DARPA ก็มาออกแบบโปรโตคอลว่าควรมีหน้าตาอย่างไร กระบวนการออกแบบมีการถกเถียงในหมู่นักวิจัยจนกลายเป็นเอกสาร RFC ออกมา

QUIC โปรโตคอลระดับ transport ที่ กูเกิลเสนอมาตั้งแต่ปี 2015 เพื่อใช้งานแทน TCP+TLS อาจจะได้ชื่อใหม่เป็น HTTP/3 หลังข้อเสนอนี้ได้รับมติตอบรับในการประชุม IETF103 ที่กรุงเทพเมื่อวันที่ 8 พฤศจิกายนที่ผ่านมา

ก่อนหน้านี้ตัวโปรโตคอลมักเรียกกันว่า HTTP-over-QUIC หรือ HTTP/2 over QUIC แต่ตัวโปรโตคอลก็มีการดัดแปลงไปมาก ทำให้มันไม่ใช่ HTTP/2 อีกต่อไป การเสนอชื่อให้มันเป็น HTTP/3 ไปเลยจึงสมเหตุสมผลพอสมควร โดยกูเกิลเสนอ QUIC เพื่อให้การเชื่อมต่อเว็บทำได้รวดเร็ว การเชื่อมต่อแทบไม่ต้องการ round trip time ในกรณีที่เคยเชื่อมต่อมาก่อนแล้ว

มาตรฐาน DNS over HTTPS (DoH) ได้รับบรรจุเป็นเอกสาร rfc8484 แล้วเมื่อสัปดาห์ที่ผ่านมา หลังจากเริ่มมีการ เสนอมาตรฐานเมื่อเดือนพฤษภาคม 2017 หรือเพียงปีกว่าเท่านั้น

มาตรฐาน TLS 1.3 แก้ไขมานานและ ผ่านโหวตไปตั้งแต่เดือนมีนาคมที่ผ่านมา ตอนนี้ก็ได้เลข RFC เป็นทางการคือ RFC8446 นับเป็นเวลาสิบปีพอดีหลังจาก TLS 1.2 หรือ RFC5246

แม้ว่าตัวมาตรฐานจะเพิ่งออกเป็นทางการ แต่ในความปฎิบัติไลบรารีจำนวนมากรองรับฟีเจอร์ต่างๆ ของ TLS 1.3 อยู่ก่อนแล้ว เช่น Chrome นั้นรองรับมาตั้งแต่ Chrome 56 และเปิดใช้งานเป็นค่าเริ่มต้นมาตั้งแต่ Chrome 63

มาตรฐานการเชื่อมต่อแบบเข้ารหัส TLS 1.3 ผ่านโหวตเป็นที่เรียบร้อยหลังจากแก้ไขร่างมาถึง 28 รอบ รวมระยะเวลาพัฒนามาตรฐานสี่ปีเต็ม โดยมีการปรับปรุงหลายอย่าง เช่น

IETF ผ่านมาตรฐาน RFC 8314 กำหนดให้ผู้ให้บริการอีเมล (mail service provider - MSP) ต้องเปิดบริการเข้ารหัสสำหรับเชื่อมต่อไปยังไคลเอนต์ (mail user agent - MUA) ในทุกๆ ช่องทาง รวมถึงการเข้าถึงอีเมลผ่านเว็บ

ภายใต้มาตรฐานนี้ ผู้ให้บริการอีเมล "ต้อง" เปิดช่องทางการเชื่อมต่อเข้ามายังเซิร์ฟเวอร์แบบเข้ารหัส TLS ทั้งการเชื่อมต่อแบบ POP, IMAP, และการเชื่อมต่ออื่นๆ โดยเฉพาะอย่างยิ่งเมื่อมีการส่งชื่อผู้ใช้และรหัสผ่าน

มาตรฐานแนะนำให้ MSP ถอดการเชื่อมต่อแบบไม่เข้ารหัสออกไปทั้งหมดให้เร็วที่สุดเท่าที่เป็นไปได้ โดยการเชื่อมต่อควรเป็น TLS 1.2 ขึ้นไป และหากยังรองรับการเข้ารหัสที่อ่อนแอกว่านั้นก็ควรถอดออกด้วยเช่นกัน

กระบวนการเข้ารหัสเว็บ HTTPS ทุกวันเป็นการเข้ารหัสการเชื่อมต่อ ทำให้ตัวเว็บเซิร์ฟเวอร์จะอ่านเนื้อหาได้เสมอ หากเราต้องการส่งข้อมูลที่แม้แต่เว็บเซิร์ฟเวอร์อ่านไม่ได้ เราต้องอาศัยวิธีอื่นๆ เช่นส่งเมลเข้ารหัส PGP หรือส่งไฟล์ zip แบบมีรหัสผ่าน แต่ล่าสุด Martin Thomson จาก Mozilla ก็ผลักดันมาตรฐาน RFC 8188 ที่ทำให้การส่งข้อมูลเข้ารหัสเป็นมาตรฐานกลางแล้ว

มาตรฐานนี้กำหนดค่าสำหรับ "Content-Encoding" แบบใหม่ คือ "aes128gcm" ที่ระบุว่าข้อมูลถูกเข้ารหัสแบบ AEAD_AES_128_GCM เอาไว้ เมื่อประกาศ encoding แบบนี้แล้วข้อมูลส่วนแรกของเนื้อ HTTP จะกลายเป็นการประกาศกุญแจเข้ารหัส ตั้งแต่ค่า salt, ค่า record size สำหรับขนาดข้อมูล, ค่าหมายเลขประจำกุญแจเข้ารหัส

เหตุการณ์อินเทอร์เน็ตมีปัญหาที่เราได้ยินกันบ่อยๆ มักเป็นปัญหาสายเคเบิลขาดหรือเซิร์ฟเวอร์ล่ม แต่เหตุการณ์อีกประเภทที่เจอกันบ่อยๆ คือ route leak ที่ผู้ดูแลระบบคอนฟิกการประกาศ route ผ่านโปรโตคอล BGP (Border Gateway Protocol) ผิดพลาด ทำให้แพ็กเก็ตวิ่งผิดเส้นทางจนการเชื่อมต่อเกิดปัญหา ตอนนี้ IETF ก็ออกเอกสาร RFC 7908 มาจัดหมวดหมู่ปัญหา route leak เช่นนี้เพื่อให้อ้างอิงในอนาคตได้ง่ายขึ้น

วิศวกรจากหัวเหว่ยและ ISC เสนอ RFC7873 DNS Cookie ให้กระบวนการขอข้อมูล DNS จะต้องมีกระบวนการยืนยันตัวตนก่อน

กระบวนการนี้เมื่อไคลเอนต์ต้องการขอข้อมูล DNS จะต้องส่งค่าสุ่มเสมือน (pseudorandom) Client Cookie ไปยังเซิร์ฟเวอร์ก่อน จากนั้นเซิร์ฟเวอร์จะส่งค่า Server Cookie กลับมา และใช้ค่านี้ในการขอข้อมูล DNS ครั้งต่อๆ ไป

IETF ออกเอกสาร RFC7858 ระบุถึงการขอข้อมูล DNS แบบเข้ารหัสแล้ว โดยใช้การเชื่อมต่อแบบ TLS ผ่านพอร์ต 853 ที่ประกาศใหม่

โดยปกติแล้วการเข้ารหัส TLS เช่นการเชื่อมต่อเว็บ จะต้องยืนยันชื่อโดเมนของเครื่องปลายทาง (เช่นโดเมน www.blognone.com) แต่เนื่องจากเป็นการเชื่อมต่อกับเซิร์ฟเวอร์ DNS เอง RFC7858 จะเปิดให้เข้ารหัสการเชื่อมต่อแบบไม่ต้องยืนยันตัวตน (authenticate) ก็ได้ หรืออาจจะใช้กระบวน key-pinning เช่นเซิร์ฟเวอร์ DNS สาธารณะอาจจะเปิดเผยค่า fingerprint ของกุญแจสาธารณะให้คนทั่วไปได้คอนฟิกไว้ล่วงหน้า