Internet Engineering Task Force
IETF ผ่านมาตรฐาน RFC 10008 เพิ่มคำสั่ง HTTP QUERY เป็นคำสั่งที่ 9 ใช้สำหรับการดึงข้อมูลแบบเดียวกับ GET แต่สามารถรองรับคิวรีที่ซับซ้อน โดยเปลี่ยนจากการส่งค่าคิวรีใน URL ไปใส่ไว้ใน body แทน เพื่อลดความยาวของ URL
มาตรฐาน HTTP เป็นทางการครั้งแรกใน RFC 2068 เมื่อปี 1997 กำหนดคำสั่งไว้ 7 คำสั่ง ได้แก่ OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE ก่อนจะเพิ่มคำสั่ง CONNECT ใน RFC 2616 ในปี 1999 อย่างไรก็ดีมาตรฐานถูกปรับมาเรื่อยๆ โดยอัปเดตล่าสุดที่ RFC 9110 เมื่อปี 2022 แต่ไม่มีการเพิ่มคำสั่ง
IETF ปล่อยมาตรฐาน RFC9849 TLS Encrypted Client Hello ที่กลุ่มวิศวกรเสนอกันมาตั้งแต่ปี 2018 ปิดช่องทางสุดท้ายที่ไฟร์วอลล์ฝั่งผู้ใช้อินเทอร์เน็ตจะแอบส่องว่าผู้ใช้ภายในเน็ตเวิร์คกำลังเชื่อมต่อ "โดเมน" อะไรอยู่บ้าง
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 และมาตรฐานเปิดให้มีลายเซ็นดิจิทัลกำกับ ป้องกันในกรณีที่คนร้ายแฮกเว็บได้แล้วและแก้ไขไฟล์เสีย
/.well-known/security.txt
IETF ออกเอกสาร RFC9225 เตือนถึงอันตรายของบั๊กในซอฟต์แวร์และเรียกร้องให้โปรแกรมเมอร์อย่าสร้างบั๊ก พร้อมกับอธิบายถึงเหตุการณ์ที่บั๊กในซอฟต์แวร์สร้างความเสียหายได้เป็นวงกว้างหลายครั้ง เช่น จรวด ARIANE ยิงไม่สำเร็จเพราะบั๊กแปลงตัวเลขทศนิยมเป็นเลขจำนวนเต็ม หรือระบบเตือนขีปนาวุธของรัสเซียเคยจรวจจับเมฆแล้วคิดว่าเป็นขีปนาวุธ
แนวทางที่ RFC9225 แนะนำ ได้แก่
โปรโตคอล QUIC เป็นกระบวนการเชื่อมต่อสำหรับเว็บที่กูเกิลเสนอมาตั้งแต่ปี 2015 เพื่อเร่งความเร็วเริ่มต้น โดยเฉพาะการเชื่อมต่อแบบเข้ารหัสที่ปกติต้องส่งข้อมูลไปมาหลายครั้งก่อนจะเชื่อมต่อได้ ที่ผ่านมาโปรโตคอลมีการปรับแต่งหลายครั้งและแต่ละเวอร์ชั่นทำงานร่วมกันไม่ได้ วันนี้ทาง IETF ก็ประกาศมาตรฐานกลาง QUIC เป็นเอกสาร RFC9000
มาตรฐานของ QUIC จริงๆ จะออกเป็นชุด ตอนนี้มีเอกสาร RFC ออกมาแล้ว ได้แก่
IETF ประกาศ RFC8962 ก่อตั้งตำรวจโปรโตคอลตรวจจับการอิมพลีเมนต์โปรโตคอลผิดมาตรฐาน ทำให้เน็ตเวิร์คทำงานร่วมกันไม่ได้
ตำรวจโปรโตคอลจะรับแจ้งเหตุอิมพลีเมนต์ไม่ตรงมาตรฐานผ่านทาง /dev/null โดยตำรวจเหล่านี้มีอำนาจเข้าถึงเน็ตเวิร์คภายในแม้ไม่ได้เชื่อมต่อกับโลกภายนอก หรือคนในองค์กรเองอาจจะนำเบาะแสมแจ้งก็ได้
เมื่อตำรวจโปรโตคอลสอบสวนแล้วว่ามีความผิดจริง จะแจ้ง IANA ว่าไอพีใดเป็นผู้ละเมิดโปรโตคอล และทุกหน่วยงานที่ได้รับแจ้งจาก IANA จะตั้งไฟร์วอลล์ทิ้งแพ็กเก็ตจากเน็ตเวิร์คนั้นทั้งหมด กลายเป็นการจำคุกเน็ตเวิร์คไม่ให้ติดต่อกับใครในอินเทอร์เน็ตอีก
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
draft-ietf-quic-http-34.txt
มาตรฐาน HTTP/3 ปรับปรุงการทำงานหลายส่วน โดยเปลี่ยนไปใช้ UDP และบังคับเข้ารหัสการเชื่อมต่อด้วย TLS 1.3 รองรับการบีบอัดส่วนหัวของการเชื่อมต่อ (HTTP header) และรองรับการส่งข้อมูลหลายสตรีมในการเชื่อมต่อเดียวกัน
เฟซบุ๊กรายงานถึงการย้ายโปรโตคอลไปยัง HTTP/3 หรือ QUIC ระบุว่าตอนนี้ทราฟิกของเฟซบุ๊กที่เชื่อมต่อผ่านอินเทอร์เน็ตเป็น HTTP/3 มากกว่า 75% แล้ว หลังจากเฟซบุ๊กย้ายแอปให้เชื่อมต่อผ่าน HTTP/3 แทน
กูเกิลนับเป็นบริษัทที่สนับสนุนแนวทางการสร้างโปรโตคอลใหม่มาทดแทน 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 แล้วตั้งแต่ปลายเดือนกรกฎาคมที่ผ่านมา
ไมโครซอฟท์ประกาศโอเพนซอร์สไลบรารี 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)
กูเกิลประกาศว่า Gmail ได้เป็นผู้ให้บริการอีเมลรายใหญ่รายแรก ที่สนับสนุนมาตรฐานความปลอดภัยใหม่ 2 รายการ คือ SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 และ SMTP TLS Reporting RFC 8460 ซึ่งกูเกิลร่วมกับผู้ให้บริการอีเมลรายใหญ่ ผลักดันมาตรฐานนี้ผ่านองค์กร IETF ตั้งแต่ 3 ปีที่แล้ว
อย่างไรก็ตามแม้ Gmail จะประกาศรองรับมาตรฐานใหม่นี้ก่อน แต่หากโดเมนอีเมลของผู้ให้บริการรายอื่นยังไม่รองรับ อีเมลที่ส่งออกไปก็ไม่มีการเข้ารหัสบนมาตรฐานใหม่นี้อยู่ดี กูเกิลจึงหวังว่าผู้ให้บริการอื่นจะรองรับมาตรฐานความปลอดภัยนี้เช่นกัน
เมื่อวันที่ 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 พฤศจิกายนที่ผ่านมา
มาตรฐาน DNS over HTTPS (DoH) ได้รับบรรจุเป็นเอกสาร rfc8484 แล้วเมื่อสัปดาห์ที่ผ่านมา หลังจากเริ่มมีการเสนอมาตรฐานเมื่อเดือนพฤษภาคม 2017 หรือเพียงปีกว่าเท่านั้น
on
on