คลังเก็บป้ายกำกับ: IETF

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

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

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

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

ที่มา – RFC8962

No Description

Topics: 

from:https://www.blognone.com/node/122010

IETF ประกาศ TLS 1.0/1.1 หมดอายุในเอกสาร RFC8996

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 บิต เปิดทางให้คนร้ายสามารถสร้างข้อความปลอมที่แฮชตรงกันได้

TLS 1.0 นั้นออกมาตรฐานมาตั้งแต่ปี 1999 ส่วน TLS 1.1 ออกมาในปี 2006 นับว่าถูกใช้งานมายาวนานมากแล้ว และเดิมมาตรฐานใหม่ๆ หลายตัวก็แนะนำให้ผู้อิมพลีเมนต์อย่ารองรับโปรโตคอลเก่าทั้งสองตัวนี้ แต่จากนี้จะอัพเดตมาตรฐานให้ห้ามรองรับโปรโตคอลทั้งสองตัว

ที่มา – IETF

No Description

Topics: 

from:https://www.blognone.com/node/121907

IETF รองรับ HTTP/3 เข้าเป็นมาตรฐานเสนอแนะ (Proposed Standard)

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

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

Proposed Standard เป็นขั้นแรกของการเข้าสู่มาตรฐานอินเทอร์เน็ต (Internet Standard) ของ IETF โดยตัวมาตรฐานต้องได้รับการยอมรับ มีการอิมพลีเมนต์ตามมาตรฐาน ส่วนการเลื่อนขั้นเป็น Internet Standard จะต้องมีการอิมพลีเมนต์อย่างน้อยสองชุดแยกจากกันและทำงานร่วมกันได้จริง ส่วนคุณภาพของตัวมาตรฐานจะต้องไม่มีข้อบกพร่องจนการอิมพลีเมนต์ตามมาตรฐานไม่สามารถทำงานร่วมกับอิมพลีเมนต์อื่นได้ ตลอดจนตัวมาตรฐานต้องไม่ผูกขาดอยู่กับสิทธิบัตรของผู้ผลิตรายใดรายหนึ่ง

จุดเด่นของ HTTP/3 คือมันไม่บังคับการเชื่อมต่อว่าต้องเป็นการเชื่อมต่อแบบเชื่อถือได้ (ส่งข้อมูลซ้ำหากมีข้อมูลหาย) ทำให้สามารถเปลี่ยนกระบวนการส่งข้อมูลให้เป็นแบบไม่รับประกันความน่าเชื่อถือสำหรับข้อมูลเช่นวิดีโอและเสียง ร่างมาตรฐาน draft-ietf-quic-datagram-02 ที่เขียนโดยแอปเปิลและกูเกิลก็กำลังวางมาตรฐานการส่งข้อมูลแบบนี้เช่นกัน

ที่มา – IETF

No Description

Topics: 

from:https://www.blognone.com/node/121307

เฟซบุ๊กใช้ HTTP/3 เกิน 75% แล้ว แอปหน่วงน้อยลง, วิดีโอโหลดเร็วขึ้น

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

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

หลังจากนั้นเฟซบุ๊กเริ่มเปิด HTTP/3 สำหรับการดาวน์โหลดวิดีโอ ทำให้ระยะเวลาโหลดบัฟเฟอร์ลดลง 22%, อัตราโหลดไม่สำเร็จลดลง 8%, อัตราวิดีโอกระตุกลดลง 20% แต่ก็มีช่วงหนึ่งที่แอปคาดการณ์แบนวิดท์ผิดพลาดเนื่องจากพฤติกรรมการเชื่อมต่อต่างจาก TCP ปกติ ทำให้แอปเลือกวิดีโอคุณภาพสูงเกินกว่าที่เน็ตเวิร์ครองรับไหว

ตอนนี้เฟซบุ๊กใช้ HTTP/3 กับแอปเฟซบุ๊กและอินสตาแกรมแล้วทั้งบน iOS และ Android โดยสุดท้ายแล้ว HTTP/3 จะกลายเป็นการเชื่อมต่อหลักแบบเดียวที่เฟซบุ๊กใช้เชื่อมต่ออินเทอร์เน็ต

ที่มา – Facebook

No Description

โลโก้มาตรฐาน QUIC (HTTP/3) และ mvfast ไลบรารี HTTP/3 ของเฟซบุ๊กเอง

Topics: 

from:https://www.blognone.com/node/119159

Chrome เริ่มปลด QUIC ของตัวเอง หันไปใช้ HTTP/3 และ IETF QUIC

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

ระหว่างนี้ Chrome จะรองรับทั้ง IETF QUIC เวอร์ชั่นดราฟท์ 29 (ดราฟท์ 30 และ 31 ไม่มีจุดที่เข้ากันไม่ได้) ไปพร้อมๆ กับ Google QUIC Q050 (เวอร์ชั่น 50) เพื่อให้เซิร์ฟเวอร์ต่างๆ ที่รับ Google QUIC อยู่มีเวลาปรับตัว กูเกิลแนะนำว่าหากมาตรฐาน IETF QUIC ไม่มีการแก้ไขใดจนเข้ากันไม่ได้ เซิร์ฟเวอร์ก็ควรรองรับดราฟท์ 29 ไปเรื่อยๆ จนกระทั่งออกมาตรฐานจริง

การใช้ IETF QUIC ทำให้มีโอกาสเจอเซิร์ฟเวอร์รองรับจำนวนมากกว่ามาก เพราะบริการ CDN อย่าง Cloudflare ก็รองรับ IETF QUIC

ที่มา – Chromium Blog


ภาพการนำเสนอชื่อ HTTP/3 ในงาน IETF103

Topics: 

from:https://www.blognone.com/node/118893

IETF ออกมาตรฐาน Network Time Security (RFC8915)

The Internet Engineering Task Force (IETF) ได้ประกาศออกมาตรฐานใหม่ด้านความมั่นคงปลอดภัยให้ Network Time Protocol (NTP)

Credit: IETF

NTP คือโปรโตคอลที่ช่วยซิงค์โครไนซ์เวลาให้ระบบคอมพิวเตอร์ต่างๆ ผ่านทาง Packet Switch ให้มีเวลาได้ตรงกันกับเวลากลางที่ให้บริการโดยเซิร์ฟเวอร์ โดยเป็นโปรโตคอลที่เก่าแก่และสำคัญที่สุดตัวหนึ่ง อย่างไรก็ดีในช่วงหลังก็ได้พบปัญหาช่องโหว่อยู่หลายส่วนอาทิเช่น DDoS Amplification, Packet Manipulation และ Reply Attack ทำให้ในที่สุดก็เกิดมาตรฐานสำหรับด้านความมั่นคงปลอดภัยขึ้นมาแล้ว

IETF ใช้เวลาออกแบบมาตรฐาน Network Time Security หรือ RFC8915 กว่า 5 ปี ไอเดียคือส่วนของปัญหา Packet Manipulation และ Reply Attack มาจากการถูกโจมตีแบบ Man-in-the-Middle (MiTM) ดังนั้นจึงนำ Asymmetric Cryptography เข้ามาใช้ให้เกิดการ Authentication เพื่อช่วยป้องกันการโจมตีแบบ MiTM ทั้งนี้แม้ว่ากระบวนการอาจช้ากว่าการทำ Symmetric Encryption จนอาจนำไปสู่การโจมตี DDoS กับ NTP Server 

แต่ใน RFC8915 ระบุว่า “แม้จะทำ DDoS ได้สำเร็จกับเซิร์ฟเวอร์ NTS-KE แต่การที่เซิร์ฟเวอร์ถูกแยกออกมา ทำให้การโจมตีไม่ส่งผลกระทบกับผู้ใช้งานที่เริ่มการพิสูจน์ตัวตนไปแล้ว อาจจะด้วยการแลกเปลี่ยนคีย์หรือ Cookies” อย่างไรก็ดีมาตรฐานยังระบุอีกว่า NTS ไม่สามารถป้องกันการโจมตีจากคนร้ายในเส้นทางได้อย่างสมบูรณ์เพราะก็ยังส่งแพ็กเก็ตปลอมแปลง Kiss-o-Death กลับไปยังการร้องของ NTP ได้อยู่ดี

ในส่วนของการป้องกัน DDoS ตัว NTS จะกำกับให้แน่ใจว่าการตอบของเซิร์ฟเวอร์นั้นมีขนาดเดียวกับ Field ที่ส่งมาจากไคลเอนต์ แม้ว่าอาจจะแย้งกับ RFC7822 ก็ตามที่ต้องมีการทำ Padding ให้ครบ 4 Octet แต่ IETF ชี้ว่ามาตรฐานใหม่น่าจะพอที่จะใช้แก้ปัญหาได้อยู่ ซึ่งทั้งหมดนี้เป็นเพียงมาตรฐานอ้างอิงเท่านั้น ส่วนระดับการ Implement ก็คงเกิดการสร้างให้ใช้งานได้ในเร็วๆนี้ครับ

ที่มา : https://www.securityweek.com/internet-engineering-task-force-proposes-standard-network-time-security

from:https://www.techtalkthai.com/ietf-launches-network-time-security-standard-rfc8915/

เดี๋ยวส่องไม่ได้ว่าเข้าเว็บอะไร พบจีนเริ่มบล็อค ESNI ที่ใช้เข้ารหัสโดเมนเมื่อเชื่อมต่อ TLS

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

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

รายงานการบล็อค ESNI พบว่าจีนบล็อค ESNI และการเชื่อมต่อที่ไม่ระบุ SNI เลย โดยบล็อคทุกพอร์ตไม่ได้จำกัดเฉพาะ 443 สำหรับ HTTPS เท่านั้น โดยบล็อคแม้แต่การเชื่อมต่อเข้าไปยังจีนจากภายนอก ตอนนี้ David Fifield ได้เขียนสคริปต์ทดสอบยืนยันว่าสามารถเชื่อมต่อเข้าจีนแบบเปิด ESNI แล้วจะถูกบล็อคไปยังไอพีปลายทางระยะเวลาหนึ่ง

ที่มา – ZDNet, IETF

from:https://www.blognone.com/node/117871

ไมโครซอฟท์โอเพนซอร์สไลบรารี MsQuic ใช้สร้างทั้งไคลเอนต์และเซิร์ฟเวอร์ HTTP/3 รองรับลินุกซ์ด้วย

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

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

ไลบรารีรองรับฟีเจอร์ของ IETF QUIC เกือบทั้งหมด แต่ยังไม่สมบูรณ์หลายส่วน เช่น 0-RTT, Client-side migration, Path MTU Discovery, Server Preferred Address สำหรับระบบปฎิบัติการนั้นรองรับทั้งวินโดวส์และลินุกซ์

ที่มา – Microsoft

No Description

แผนภาพการเชื่อมต่อ QUIC จาก Microsoft

from:https://www.blognone.com/node/116056

Cloudflare เริ่มรองรับ HTTP/3 ใช้กับ Chrome Canary และ curl พร้อมโอเพนซอร์สไลบรารีในภาษา Rust

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

HTTP/3 หรือชื่อเดิม HTTP/2-over-QUIC เลิกใช้ TCP สำหรับชั้น transport แต่ใช้ UDP แทนและเสริมด้วยโปรโตคอล QUIC ที่ทำงานในตัวแอปพลิเคชั่น (ทำให้ระบบปฎิบัติการไม่ต้องรองรับ QUIC เอง รองรับ UDP ก็พอ) กระบวนการเปิดการเชื่อมต่อของ QUIC รวมเข้ากับการเชื่อมต่อ TLS1.3 ทำให้ส่งข้อมูลเพียง 3 ครั้งก็เริ่มส่งข้อมูลได้ และ QUIC รองรับการส่งข้อมูลหลายสตรีมในการเชื่อมต่อครั้งเดียว

ตอนนี้ Chrome Canary และ curl รุ่นล่าสุดใน git รองรับ HTTP/3 แล้ว แต่ยังไม่ใช่โปรโตคอลมาตรฐาน ผู้ใช้ต้องเปิดการใช้งานด้วยตัวเอง ทางด้าน Cloudflare ก็ปล่อยไลบรารี quiche ที่อิมพลีเมนต์ด้วยภาษา Rust

ที่มา – Cloudflare

Topics: 

from:https://www.blognone.com/node/112209

กูเกิลโอเพนซอร์สตัวอ่านไฟล์ robots.txt, เตรียมผลักดันสเปกเป็นมาตรฐานอินเทอร์เน็ต

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

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

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

หนึ่งในวิธีการผลักดัน REP เป็นมาตรฐานเน็ต คือการเปิดซอร์สโค้ดของตัวอ่านไฟล์ robots.txt ที่ Google Search ใช้มาตั้งแต่ช่วงก่อตั้งบริษัท เพื่อให้นักพัฒนาภายนอกสามารถเข้ามาดูได้ว่า กูเกิลเขียนซอฟต์แวร์เพื่อจัดการกับไฟล์ robots.txt ได้อย่างไร ไลบรารีตัวนี้มีชื่อเรียกว่า Google Robots.txt Parser and Matcher Library เขียนด้วยภาษา C++ และตอนนี้เปิดโค้ดแล้วบน GitHub

ที่มา – Google, Google

No Description

from:https://www.blognone.com/node/110665