Chrome ประกาศแผนการบล็อคไม่ให้ดาวน์โหลดไฟล์ผ่าน HTTP แบบไม่เข้ารหัส โดยจะเริ่มจาก Chrome 82 ที่ออกช่วงเดือนเมษายน 2020

ปัจจุบัน Chrome ยอมให้เราเข้าเว็บที่เป็น HTTPS แล้วดาวน์โหลดบางไฟล์ผ่านโปรโตคอล HTTP (mixed content download) ซึ่งกูเกิลมองว่าไฟล์อาจถูกยัดไส้เป็นมัลแวร์ หรือโดนดักข้อมูลระหว่างทางได้ (เช่น ดาวน์โหลดไฟล์สรุปข้อมูลการเงินจากเว็บไซต์ธนาคาร)

Chrome 82 จะเริ่มแจ้งเตือนผู้ใช้หากดาวน์โหลดไฟล์ .exe ผ่านโปรโตคอล HTTP ที่ไม่ปลอดภัย จากนั้นจะค่อยๆ ยกระดับการแจ้งเตือนไปยังไฟล์ชนิดอื่นๆ เช่น .zip, .pdf, .doc, .png จนถึง Chrome 86 จะบล็อคการดาวน์โหลดไฟล์ทุกประเภทผ่าน HTTP (ดูตารางประกอบ)

ข่าวเทคนิคที่น่าสนใจในช่วงไม่นานนี้คือ Cloudflare, Chrome, Firefox ร่วมมือกันรองรับ HTTP/3 หรือที่เราเคยรู้จักกันในชื่อ QUIC ที่กูเกิลเคยเสนอมาตั้งแต่ปี 2015

หลายคนอาจสงสัยว่าแล้ว HTTP/1, HTTP/2 (หรือ SPDY) และ HTTP/3 (QUIC) แตกต่างกันอย่างไร บทความนี้จะอธิบายวิวัฒนาการของเทคโนโลยี HTTP ให้เข้าใจกันแบบง่ายๆ ครับ

Google ประกาศเตรียมบล็อคคอนเทนต์ที่เป็น HTTP ภายใต้หน้าเว็บที่เป็น HTTPS เป็นค่าเริ่มต้น ซึ่งจะช่วยเพิ่มความปลอดภัยและความเป็นส่วนตัวให้ผู้ใช้มากยิ่งขึ้น รวมถึงสามารถแสดง UX ที่ชัดเจนกับผู้ใช้ได้ด้วยว่าหน้าเว็บนี้ปลอดภัยจริงหรือไม่

ปัจจุบัน เว็บไซต์กว่า 90% ได้ปรับเปลี่ยนเป็น HTTPS แล้ว และผู้ใช้ Chrome ก็ใช้เวลากว่า 90% ใช้งานเว็บ HTTPS บนแพลตฟอร์มหลักทุกแพลตฟอร์ม แต่ก็ยังมีประเด็นเรื่องคอนเทนต์ภายในหน้าเว็บที่ยังเป็น HTTP ผสมอยู่บ้าง แม้ว่า Chrome จะบล็อคคอนเทนต์ประเภทบางอย่างเช่นสคริปต์หรือ iframe แล้ว แต่ภาพ, เสียง หรือวิดีโอยังคงโหลดได้อยู่ ซึ่งเป็นประเด็นเพราะหน้าเว็บก็ไม่ได้ปลอดภัยเต็มที่

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

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

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

Chrome ผลักดันการใช้งาน HTTPS แทน HTTP มาโดยตลอด ซึ่งที่ผ่านมาจะขึ้นข้อความเตือนว่าไม่ปลอดภัย (Not Secure) หากเว็บนั้นมีแบบฟอร์มกรอกข้อความ หรือเป็นการเชื่อมต่อผ่าน FTP แต่ประกาศล่าสุดนี้จะมีผลกับ HTTP ทุกกรณีแล้ว

โดยกูเกิลประกาศว่า Chrome 68 ซึ่งมีกำหนดออกมาในเดือนกรกฎาคมปีนี้ จะขึ้นแสดงข้อความว่าเว็บนี้ ไม่ปลอดภัย (Not Secure) สำหรับ HTTP ทุกกรณี

Google ปล่อยอัพเดต Chrome 62 แล้ว โดยฟีเจอร์ใหม่ ๆ ในการอัพเดตรอบนี้ อย่างเช่น

• รองรับฟอนต์ OpenType variable fonts โหลดฟอนต์จากไฟล์เดียว แทนที่จะต้องโหลดฟอนต์แบบเดียวกันมาเป็นชุด ๆ ที่ต่างกันแค่ความหนา, ความเอียง, ฯลฯ ให้ใช้ CSS ปรับแต่งแทน
• แจ้งเตือนไม่ปลอดภัยเมื่อใช้เว็บไซต์ HTTP ที่เรียกให้กรอกข้อมูลในโหมดปกติ และเว็บไซต์ HTTP ทั่วไปในโหมด Incognito เป็นแผนระยะยาวของ Chrome ที่จะบีบให้เว็บไซต์ไปใช้ HTTPS

กระบวนการรับรอง SSL/TLS Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์” (ต่อไปจะเรียกว่า TLS Certificate) จะผ่านทาง Certificate Authority หรือ “ผู้ออกใบรับรองอิเล็กทรอนิกส์” (CA)

โดยเว็บเบราว์เซอร์หรือระบบปฏิบัติการ (ต่อไปจะเรียกว่า client) จะมีรายการที่เรียกว่า Trusted Root Certification Authorities หรือ “รายการใบรับรองอิเล็กทรอนิกส์ของผู้ออกใบรับรองอิเล็กทรอนิกส์สำหรับผู้อื่น” อยู่ภายใน โดยมากมักอ้างอิงกับตัวระบบปฏิบัติการเป็นหลัก ซึ่งจะบรรจุ Root Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์ลำดับชั้นบนสุด” เพื่อให้ client สามารถเชื่อใบรับรองอิเล็กทรอนิกส์ที่ได้รับรองจาก Certificate Authority เหล่านั้น (Trust any certificates issued by the Certificate Authorities)

ฟีเจอร์หนึ่งของ HTTP/2 คือ Server Push ที่เปิดให้เซิร์ฟเวอร์สามารถส่งไฟล์ตามจากไฟล์แรกไปได้โดยที่ไม่ต้องรอเบราว์เซอร์อ่านไฟล์ HTML แล้วขอไฟล์อื่นๆ กลับมาเอง

ตัวอย่างไฟล์ที่ต้องส่งตามไปอยู่แล้ว เช่นไฟล์ CSS ที่ตามไปกับ HTML เสมอๆ แทนที่จะรอให้เบราว์เซอร์อ่าน HTML จนพบว่าต้องการ CSS เพิ่มเติมก็สามารถส่งไปให้เลยทันที

ตัวเว็บแอปพลิเคชั่นต้องรองรับฟีเจอร์นี้ และประกาศไฟล์ที่สามารถส่งต่อไปได้เลยไว้ใน HTTP header เป็นฟิลด์ Link

เดิมทีเราคุ้นเคยกับการที่ Chrome แสดงรูปกุญแจสีเขียวเพื่อบอกว่าเป็นการเชื่อมต่อแบบ HTTPS ส่วนการเชื่อมต่อแบบ HTTP ปกติจะแสดงรูปกระดาษเปล่าสีขาว (ถ้าเป็น Firefox เป็นรูปลูกโลก) แต่แผนใหม่ของ Chrome จะไปไกลกว่านั้นคือแสดงกากบาทสีแดงให้ผู้ใช้มองเห็นเด่นชัดไปเลย

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

ทิศทางของกูเกิลชัดเจนว่าต้องการผลักดัน HTTPS แทน HTTP โดยมีมาตรการกระตุ้นหลายอย่าง รวมถึงมีผลต่อ Google Search ด้วย

โพรโทคอล HTTP/2 ออกเป็นมาตรฐานของ IETF ตั้งแต่เดือนพฤษภาคมปีนี้ ตอนนี้ก็เริ่มได้เวลาที่หน่วยงานหลายแห่งจะเริ่มรองรับ HTTP/2 กันแล้ว

บริษัท CloudFlare ผู้ให้บริการ CDN รายใหญ่ของโลก ประกาศว่าลูกค้าของตัวเอง (ทั้งแบบฟรีและเสียเงิน) สามารถใช้ HTTP/2 ได้ทันทีโดยไม่ต้องทำอะไรเพิ่ม เพราะ CloudFlare เปิดให้ใช้งานเป็นค่าดีฟอลต์ ส่วนลูกค้าแบบองค์กรสามารถเลือกได้ว่าจะเปิดใช้งานหรือไม่

Richard Barnes หัวหน้าฝ่ายความปลอดภัยของไฟร์ฟอกซ์ ทวีตประกาศมาตรการความปลอดภัยล่าสุดในไฟร์ฟอกซ์เวอร์ชั่น 44 ที่จะเตือนผู้ใช้ว่าเว็บไม่ปลอดภัย หากหน้าเว็บนั้นๆ มีแบบฟอร์มรหัสผ่านอยู่ในเว็บ และตัวเว็บเชื่อมต่อแบบไม่เข้ารหัส

แนวทางนี้เป็นเพียงการทดสอบในรุ่น Nightly เท่านั้น รุ่นที่เราใช้งานกันทั่วไปยังเป็นรุ่น 41 และกว่ารุ่น 44 จะออกมาจริงยังต้องใช้เวลาอีกหลายเดือน และยังไม่มีการยืนยันว่าแนวทางนี้จะใช้งานในรุ่นจริง

เว็บเซิร์ฟเวอร์ยอดนิยมอย่าง nginx ออกรุ่นใหม่ในสายพัฒนาหลักเป็นรุ่น 1.9.5 แล้ว โดยเพิ่มการรองรับมาตรฐาน HTTP/2 อย่างเป็นทางการ โดยออกมาแทนที่โมดูล SPDY นอกจากนี้ก็เป็นการแก้ไขข้อผิดพลาดและปรับปรุงการทำงานทั่วไปครับ

ที่มา: nginx CHANGES

HTTP/2 เตรียมประกาศเป็นมาตรฐานมาตั้งแต่เดือนกุมภาพันธ์ เมื่อวานนี้ทาง IETF ก็เผยแพร่เอกสารเป็น rfc7540 เป็นทางการแล้ว

RFC หรือ request for comments เป็นเอกสารที่ไม่ได้ขอความเห็นตามชื่อของมันเท่าใดนัก เพราะเอกสารที่ประกาศเป็น RFC จะเป็นมาตรฐานขั้นสุดท้ายที่ไม่มีการแก้ไขอีก จะมีเฉพาะการประกาศ RFC ใหม่เพื่อทดแทน RFC เดิมเท่านั้น

ที่มา - The Register

ช่วงนี้มีเรื่องเป็นที่ชวนฉงนสงสัยของใครหลายคนที่ใช้ Internet บ้านของ True เหตุใดบางครั้ง มันถึงช้าจนใช้งานไม่ได้ แถมมาเจาะจงเป็นเฉพาะกับบริการของ Google
และ ถ้าเจาะจงมากกว่านั้น ทำไมมันมีปัญหากับเฉพาะ Google Chrome
บางคนได้ถามไปทางผู้ให้บริการแล้วได้คำตอบที่ไม่แน่ชัด แต่ละคนก็มีทฤษฎีตีความกันไปต่างๆ นาๆ แต่คนที่สรุปได้ว่าเป็นเพราะอะไร ไม่ได้ออกมาอธิบายให้รู้ทั่วกัน แถมตัวปัญหาก็ไม่ได้ใหญ่โตเกินแก้ เป็นไปได้หรือไม่ว่า วิศวกรผู้รับผิดชอบของบริษัทดังกล่าว จนบัดนี้ก็ยังไม่เข้าใจว่าเกิดอะไรขึ้น

Mozilla ออก Firefox 36 ทั้งบนพีซีและแอนดรอยด์ การเปลี่ยนแปลงที่สำคัญบนทุกแพลตฟอร์มคือรองรับโพรโทคอล HTTP/2 ที่เพิ่งเสร็จเป็นมาตรฐาน

ฝั่งพีซีเพิ่มฟีเจอร์เล็กๆ หนึ่งอย่างคือซิงก์เว็บที่ปักหมุดในหน้า New Tab ได้แล้ว ส่วนฝั่งแอนดรอยด์ปรับ UI กรณีใช้งานบนแท็บเล็ต โดยเพิ่มแท็บที่ขอบบนของหน้าจอ (เหมือนเวอร์ชันพีซี) ซึ่งต่างไปจากของเดิมที่ใช้ UI แบบมือถือที่ต้องกดปุ่มแสดงรายการแท็บก่อนแล้วค่อยเลือกแท็บ ช่วยลดขั้นตอนการเปลี่ยนแท็บลงเหลือเพียงแค่การจิ้มครั้งเดียว

เมื่อวานนี้ (17 กุมภาพันธ์) ไมโครซอฟท์ประกาศออกมาว่า Internet Explorer รุ่นที่อยู่ใน Windows 10 Technical Preview ได้รองรับมาตรฐาน HSTS หรือ HTTP Strict Transport Security ที่ใช้บังคับให้เบราว์เซอร์ให้เชื่อมต่อกับเว็บไซต์แบบเข้ารหัสเสมอแล้ว

เมื่อวันที่ 17 กุมภาพันธ์ที่ผ่านมากลุ่มขับเคลื่อนวิศวกรรมอินเทอร์เน็ต หรือ IESG ซึ่งเป็นหน่วยงานย่อยที่ทำหน้าที่ผลักดันมาตรฐานบนอินเทอร์เน็ตได้อนุมัติการส่งร่างมาตรฐาน HTTP/2 ขึ้นประกาศเป็นมาตรฐานใหม่แล้วครับ

โพรโทคอล HTTP/2 (เดิมเรียกว่า HTTP/2.0) ถูกร่างขึ้นจากโพรโทคอล SPDY/2 ที่กูเกิลพัฒนามาระยะเวลาหนึ่งแล้ว ซึ่งมีการเปลี่ยนแปลงมาตรฐานจาก HTTP/1.1 ที่ถูกประกาศใช้งานเมื่อปี ค.ศ. 1999 เป็นจำนวนมาก โดยส่วนใหญ่เป็นการปรับปรุงประสิทธิภาพ ที่ทำให้ช่วยเพิ่มความเร็วการเชื่อมต่อ ปรับปรุงวิธีการเรียกใช้งานให้สามารถร้องขอข้อมูลหลายๆ ชิ้นได้ในครั้งเดียว ทำให้ลดภาระฝั่งนักพัฒนา เช่นการรวมไฟล์ css, js หรือการทำ css sprite ไปได้ด้วยครับ

โพรโทคอล HTTP 1.1 ที่เราใช้กันอยู่ทุกวันนี้ถูกใช้งานกันมาตั้งแต่ปี 1999 และยังไม่เคยปรับปรุงอีกเลย ส่งผลให้มันมีข้อจำกัดทางเทคนิคหลายจุดที่เริ่มล้าสมัย ในขณะที่กระบวนการออกมาตรฐาน HTTP รุ่นใหม่ก็ล่าช้าและใช้เวลานาน

กูเกิลเป็นบริษัทที่พยายามผลักดันการปรับปรุงมาตรฐาน HTTP โดยใช้วิธีทั้งเข้าร่วมกระบวนการออกมาตรฐาน แต่ในอีกทางก็พัฒนาสเปกส่วนขยายของตัวเองในชื่อ SPDY เพื่อเสนอเข้าเป็นส่วนหนึ่งของมาตรฐานด้วย ตอนแรกการรองรับ SPDY เริ่มจากเซิร์ฟเวอร์ของกูเกิลเองและ Chrome แต่ภายหลังก็มีหน่วยงานอีกหลายแห่งเริ่มรองรับ SPDY มากขึ้น

เฟซบุ๊กปล่อยไลบรารี Proxygen ที่เขียนด้วย C++ มีเป้าหมายว่าจะสร้างไลบรารีสำหรับเขียนเซิร์ฟเวอร์ HTTP, พรอกซี่, หรือไคลเอนต์ จุดเด่นของมันคือการรองรับมาตรฐานใหม่ๆ เช่น SPDY/3, SPDY/3.1 โดยโค้ดทั้งหมดมีสัญญาอนุญาตแบบ BSD ที่เปิดให้ใช้งานได้ง่าย (ใช้ในโครงการปิดซอร์สได้)

ในรุ่นแรกที่เฟซบุ๊กปล่อยออกมาจะมีตัวอย่างเฉพาะการทำเว็บเซิร์ฟเวอร์เป็นหลัก แต่รุ่นต่อๆ ไปจะมี API สำหรับการสร้างไคลเอนต์มาให้ ส่วน HTTP/2 นั้นกำลังอยู่ระหว่างการพัฒนา

เฟซบุ๊กเพิ่มโครงการ Proxygen นี้เข้าโครงการรับรางวัลจากการหาบั๊กความปลอดภัย พร้อมกับเตือนว่าหากพบบั๊กความปลอดภัยให้แจ้งผ่านโครงการอย่าโพสบั๊กปกติที่เปิดให้ทุกคนเห็น

ที่มา - GitHub

ทีมวิศวกรจาก AT&T ส่งร่างมาตรฐาน "Explicit Trusted Proxy in HTTP/2.0" เปิดทางให้ผู้ให้บริการอินเทอร์เน็ตสามารถดักฟังข้อมูลได้ทังหมดแม้จะเป็นข้อมูลเข้ารหัส HTTPS ก็ตาม

AT&T เป็นผู้ให้บริการอินเทอร์เน็ตรายใหญ่ในสหรัฐฯ เหตุผลการขอสิทธิ์เข้าถึงข้อมูลที่เข้ารหัสไว้ ก็เพื่อทำให้ผู้ให้บริการอินเทอร์เน็ตสามารถแคชข้อมูลไว้ในพรอกซี่ได้ เพื่อลดปริมาณข้อมูลที่ต้องส่งเข้าออกผ่านอัพลิงก์ที่มีราคาแพง

ร่างมาตรฐานระบุให้พรอกซี่ต้องขออนุญาตผู้ใช้เพื่อถอดรหัสอย่างเป็นทางการ

Mark Nottingham ประธานกลุ่มพัฒนามาตรฐาน HTTP/2 ของ IETF เขียนบล็อกระบุว่ามาตรฐาน HTTP/2 นั้นใกล้จะสมบูรณ์แล้ว เขาจึงมาตอบคำถามว่าหลังจากมี HTTP/2 แล้วจะมีอะไรเกิดขึ้นบ้าง

หลังจากงาน IETF-88 การโต้เถียงประเด็นความปลอดภัยของ HTTP 2.0 ยังคงไม่ได้ข้อสรุป โดยมีแนวทางสำคัญ การเข้ารหัสเท่าที่เป็นไปได้ และการบังคับเข้ารหัสเต็มรูปแบบ

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

Amazon Cloudfront คือผู้ให้บริการ Content Delivery Service รายใหญ่รายหนึ่งที่มีสตาร์ทอัพมากมายใช้บริการ เพื่อช่วยให้ฝั่งผู้ใช้สามารถเข้าถึง content จากภูมิภาคต่างๆได้เร็วขึ้น ยกตัวอย่าง เช่น การที่เราสามารถดาวน์โหลดรูปภาพ Instagram จากประเทศไทยผ่าน Amazon Cloudfront ของสิงคโปร์ ซึ่งทำให้เร็วกว่าการดาวน์โหลดจากเซิฟเวอร์ในอเมริกาโดยตรง เป็นต้น

โดยในวันนี้ Amazon Cloudfront ได้ประกาศรองรับ HTTP method เพิ่มเติม คือ POST, PUT, DELETE, OPTIONS และ PATCH ซึ่งจะทำให้สามารถใช้พัฒนาประสิทธิภาพของเว็บไซต์ที่มีการตอบสนองต่อผู้ใช้ได้หลายรูปแบบซึ่งรวมถึงการอัพโหลดผ่าน Amazon Cloudfront ได้โดยตรง จากแต่เดิมที่ต้องวางเซิฟเวอร์ไว้ตามภูมิภาคต่างๆ เองเพื่อรองรับการอัพโหลดจากผู้ใช้

ไมโครซอฟท์เปิดเว็บเซิร์ฟเวอร์ Katana ที่พัฒนาด้วยภาษา C# โดยจุดเด่นของเว็บเซิร์ฟเวอร์นี้คือมันรองรับมาตรฐาน HTTP 2.0 ให้ดาวน์โหลดไปคอมไพล์เล่นกันได้ที่ GitHub

ในตอนนี้ Katana รองรับฟีเจอร์บีบอัดเฮดเดอร์, stream multiplexing, ALPN (Application Layer Protocol Negotiation), และ HTTP Upgrade

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