การโจมตี DDoS แบบ HTTP/2 'Rapid Reset' รูปแบบใหม่

 (cloud.google.com)
1 คะแนน โดย GN⁺ 2023-10-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การโจมตี Layer 7 DDoS บนพื้นฐาน HTTP/2 ที่มุ่งเป้าไปยังบริการของ Google และลูกค้า Google Cloud พุ่งถึงจุดสูงสุดในเดือนสิงหาคม 2023 โดยเกิน 398 ล้านคำขอต่อวินาที
  • การโจมตีส่วนใหญ่ถูกบล็อกไว้ที่ โครงสร้างพื้นฐาน Global Load Balancing ของ Google จึงไม่ลุกลามเป็นเหตุขัดข้อง และหลังจากนั้นได้มีการเพิ่มมาตรการป้องกันเพื่อบรรเทาการโจมตีลักษณะคล้ายกัน
  • Rapid Reset อาศัยการยกเลิกเฉพาะสตรีมทันทีหลังส่งคำขอด้วย เฟรม RST_STREAM โดยยังคงการเชื่อมต่อไว้ ทำให้สามารถหลบข้อจำกัดจำนวนสตรีมพร้อมกันและสร้างคำขอซ้ำได้ต่อเนื่อง
  • แม้คำขอจะถูกยกเลิก เซิร์ฟเวอร์ก็อาจยังต้องทำงานอย่างการคลายการบีบอัดเฮดเดอร์ การแมป URL และ reverse proxy ไปยังแบ็กเอนด์ ทำให้เกิด ความไม่สมดุลของต้นทุน อย่างมาก
  • ผู้ดูแลระบบ HTTP/2 ควรตรวจสอบการเปิดรับความเสี่ยงและติดตั้งแพตช์ โดยเมื่อพบการใช้งานในทางที่ผิด มาตรการบรรเทาหลักคือ ยุติการเชื่อมต่อ TCP ทั้งเส้น มากกว่าปิดกั้นเฉพาะคำขอแต่ละรายการ

ขนาดของการโจมตีและการตอบสนองของ Google

  • บริการของ Google และลูกค้า Cloud ตกเป็นเป้าของ การโจมตี Layer 7 DDoS บนพื้นฐาน HTTP/2 ที่พุ่งสูงสุดในเดือนสิงหาคม 2023
  • การโจมตีสูงสุดเกิน 398 ล้านคำขอต่อวินาที ซึ่งมีขนาดใหญ่กว่าการโจมตี Layer 7 ที่เคยมีรายงานก่อนหน้านี้มาก
  • โครงสร้างพื้นฐาน Global Load Balancing ของ Google บล็อกการโจมตีส่วนใหญ่ไว้ที่ขอบเครือข่าย
    • ไม่เกิดเหตุขัดข้อง
    • ผลกระทบอยู่ในวงจำกัด
  • Google DDoS Response Team ตรวจสอบการโจมตีแล้วนำมาตรการป้องกันเพิ่มเติมมาใช้เพื่อลดการโจมตีลักษณะเดียวกัน
  • Google ร่วมกับพันธมิตรในอุตสาหกรรมเป็นผู้นำ กระบวนการเปิดเผยแบบประสานงาน เพื่อรับมือเวกเตอร์การโจมตี HTTP/2 รูปแบบใหม่นี้

จุดที่ HTTP/2 เอื้อต่อ DDoS

  • นับตั้งแต่ปลายปี 2021 การโจมตี Layer 7 DDoS จำนวนมากที่สังเกตพบในบริการ first-party ของ Google และโปรเจ็กต์ Google Cloud ที่ได้รับการป้องกันด้วย Cloud Armor เป็นการโจมตีบนพื้นฐาน HTTP/2
    • มีจำนวนมากทั้งในแง่จำนวนครั้งของการโจมตี
    • และสูงในแง่อัตราคำขอสูงสุด
  • ประสิทธิภาพของ HTTP/2 ไม่เพียงช่วยไคลเอนต์ที่ถูกต้องตามปกติ แต่ยังอาจเพิ่มประสิทธิภาพของการโจมตี DDoS ได้ด้วย

  • Stream multiplexing

    • HTTP/2 ส่งเฟรมระหว่างปลายทางผ่าน สตรีม (stream) ซึ่งเป็นนามธรรมแบบสองทิศทาง
    • ด้วย stream multiplexing จึงสามารถประมวลผลหลายคำขอพร้อมกันบนการเชื่อมต่อ TCP เดียวได้
    • ข้อจำกัดสำคัญของการโจมตี Layer 7 DoS คือจำนวนการเชื่อมต่อที่ส่งพร้อมกันได้
      • แต่ละการเชื่อมต่อใช้หน่วยความจำของระบบปฏิบัติการสำหรับ socket record และ buffer
      • TLS handshake ต้องใช้เวลา CPU
      • ต้องใช้ 4-tuple ที่ไม่ซ้ำกันซึ่งประกอบด้วยคู่ IP address และ port ของทั้งสองฝั่ง
    • HTTP/1.1 โดยทั่วไปประมวลผลคำขอแบบอนุกรม ทำให้อัตราคำขอบนการเชื่อมต่อเดียวใกล้เคียง 1 คำขอต่อหนึ่งรอบเวลาไป-กลับ
    • ใน HTTP/2 สามารถเปิดหลายสตรีมพร้อมกันบนการเชื่อมต่อ TCP เดียว และแต่ละสตรีมสอดคล้องกับคำขอ HTTP หนึ่งรายการ
    • ในสภาพแวดล้อมจริง ไคลเอนต์อาจเปิด 100 สตรีมต่อคำขอ และเซิร์ฟเวอร์ประมวลผลแบบขนานได้ ทำให้ throughput ที่มีผลจริงของการเชื่อมต่อเดียวเพิ่มขึ้นได้ถึงระดับ 100 คำขอต่อหนึ่งรอบเวลาไป-กลับ
    • ส่งผลให้อัตราการใช้ประโยชน์จากการเชื่อมต่อสูงกว่า HTTP/1.1 ได้เกือบ 100 เท่า

Rapid Reset ทำงานอย่างไร

  • HTTP/2 อนุญาตให้ไคลเอนต์ส่ง เฟรม RST_STREAM เพื่อแจ้งเซิร์ฟเวอร์ให้ยกเลิกสตรีมก่อนหน้าได้
  • การยกเลิกไม่ต้องอาศัยการประสานงานแยกต่างหากระหว่างไคลเอนต์กับเซิร์ฟเวอร์
    • ไคลเอนต์สามารถยกเลิกได้ฝ่ายเดียว
    • เมื่อเซิร์ฟเวอร์ได้รับเฟรม RST_STREAM ก็อาจถือว่าการยกเลิกมีผลก่อนข้อมูลอื่นบนการเชื่อมต่อ TCP เดียวกัน
  • Rapid Reset พึ่งพาการส่งเฟรม RST_STREAM ทันทีหลังส่งเฟรมคำขอ
    • ทำให้อีกฝั่งเริ่มทำงานก่อน แล้วรีเซ็ตคำขออย่างรวดเร็ว
    • คำขอถูกยกเลิก แต่การเชื่อมต่อ HTTP/2 ยังคงเปิดอยู่
  • ขั้นตอนการโจมตีมีความเรียบง่าย
    • เปิดสตรีมจำนวนมากพร้อมกันเหมือนการโจมตี HTTP/2 มาตรฐาน
    • ไม่รอการตอบกลับจากเซิร์ฟเวอร์หรือพร็อกซี
    • ยกเลิกแต่ละคำขอทันที
  • เมื่อรีเซ็ตได้ทันที แต่ละการเชื่อมต่อก็แทบจะทำให้มีคำขอจำนวนมากอยู่ในสถานะกำลังประมวลผลได้ไม่จำกัด
    • ผู้โจมตีไม่ได้ก้าวข้ามข้อจำกัดจำนวนสตรีมที่เปิดพร้อมกันอย่างชัดเจน
    • จำนวนคำขอที่อยู่ระหว่างประมวลผลจึงขึ้นกับแบนด์วิดท์เครือข่ายที่มี มากกว่าค่า RTT
  • การติดตั้งใช้งานเซิร์ฟเวอร์ HTTP/2 โดยทั่วไปอาจยังต้องทำงานกับคำขอที่ถูกยกเลิก
    • จัดสรรโครงสร้างข้อมูลสำหรับสตรีมใหม่
    • แยกวิเคราะห์ query
    • คลายการบีบอัดเฮดเดอร์
    • แมป URL ไปยังทรัพยากร
  • ในการติดตั้งใช้งาน reverse proxy คำขออาจถูกพร็อกซีไปยังเซิร์ฟเวอร์แบ็กเอนด์ก่อนที่เฟรม RST_STREAM จะถูกประมวลผล
  • เนื่องจากไคลเอนต์แทบไม่ต้องจ่ายต้นทุนในการส่งคำขอ จึงเกิด ความไม่สมดุลของต้นทุนที่ถูกนำไปใช้โจมตีได้ ระหว่างฝั่งไคลเอนต์กับเซิร์ฟเวอร์
  • หากคำขอถูกยกเลิกก่อนเริ่มสร้างการตอบกลับ เซิร์ฟเวอร์ reverse proxy จะไม่ส่งการตอบกลับ ทำให้ แบนด์วิดท์ downlink ที่ออกจากเซิร์ฟเวอร์หรือพร็อกซีไปยังผู้โจมตีก็ลดลงด้วย

รูปแบบการโจมตีที่สังเกตพบ

  • ในช่วงหลายสัปดาห์หลังการโจมตี DDoS ครั้งแรก มีการสังเกตพบรูปแบบแปรผันของ Rapid Reset
  • แม้รูปแบบเหล่านี้จะไม่มีประสิทธิภาพเท่าวิธีดั้งเดิม แต่ก็ยังอาจมีประสิทธิภาพกว่าการโจมตี HTTP/2 DDoS แบบมาตรฐาน

  • รูปแบบยกเลิกแบบเป็นชุด

    • รูปแบบแรกไม่ยกเลิกสตรีมทันที แต่เปิดสตรีมเป็นชุด รอสักครู่ แล้วค่อยยกเลิกทั้งหมดพร้อมกัน
    • ทันทีหลังยกเลิกก็เปิดสตรีมชุดใหญ่ชุดใหม่อีกครั้งเพื่อโจมตีต่อ
    • วิธีนี้สามารถหลบเลี่ยงมาตรการบรรเทาที่อิงจากอัตราเฟรม RST_STREAM ขาเข้าเพียงอย่างเดียวได้
      • ตัวอย่าง: นโยบายที่อนุญาต RST_STREAM ได้ไม่เกิน 100 ครั้งต่อวินาทีต่อการเชื่อมต่อ และปิดการเชื่อมต่อเมื่อเกิน
    • เพราะไม่สามารถเพิ่มอัตราการใช้ประโยชน์ของการเชื่อมต่อได้สูงสุด ข้อได้เปรียบหลักของการโจมตีแบบยกเลิกจึงลดลง
    • ถึงอย่างนั้น ในเชิงการติดตั้งใช้งานก็ยังอาจมีประสิทธิภาพกว่าการโจมตี HTTP/2 DDoS แบบมาตรฐาน ทำให้การจำกัดเพียงอัตราการยกเลิกสตรีมยังต้องเข้มงวดมากจึงจะได้ผล

  • รูปแบบไม่ยกเลิก

    • รูปแบบที่สองไม่ยกเลิกสตรีมเลย
    • แต่พยายามเปิดสตรีมแบบมองโลกในแง่ดีให้มากกว่าจำนวนสตรีมพร้อมกันที่เซิร์ฟเวอร์ประกาศไว้
    • จึงสามารถเติม request pipeline ให้เต็มต่อเนื่องและลดคอขวด RTT ระหว่างไคลเอนต์กับพร็อกซีได้
    • หากมุ่งเป้าไปที่ทรัพยากรที่เซิร์ฟเวอร์ HTTP/2 ตอบกลับได้ทันที ก็สามารถตัดคอขวด RTT ระหว่างพร็อกซีกับเซิร์ฟเวอร์ได้ด้วย
    • RFC 9113 ซึ่งเป็น RFC ปัจจุบันของ HTTP/2 เสนอว่า เมื่อมีความพยายามเปิดสตรีมมากเกินไป ควรทำให้เป็นโมฆะเฉพาะสตรีมที่เกินขีดจำกัด ไม่ใช่ทั้งการเชื่อมต่อ
    • ในโครงสร้างของเซิร์ฟเวอร์ HTTP/2 ส่วนใหญ่ที่ไม่ได้ประมวลผลสตรีมส่วนเกิน จึงสามารถรับและประมวลผลสตรีมใหม่ได้แทบจะทันทีหลังตอบสนองสตรีมก่อนหน้า ทำให้เกิดรูปแบบไม่ยกเลิกนี้ได้

กลยุทธ์การบรรเทา

  • ตระกูลการโจมตีนี้ยากจะบรรเทาได้จริงด้วยการบล็อกเฉพาะคำขอรายรายการ
  • เมื่อตรวจพบการใช้งานในทางที่ผิด ควรปิด การเชื่อมต่อ TCP ทั้งหมด
  • HTTP/2 รองรับการยุติการเชื่อมต่อด้วยเฟรม GOAWAY
  • RFC กำหนดขั้นตอนปิดแบบค่อยเป็นค่อยไป โดยส่ง GOAWAY เชิงข้อมูลก่อนโดยยังไม่ตั้งข้อจำกัดการเปิดสตรีมใหม่ จากนั้นหลังหนึ่งรอบเวลาไป-กลับจึงส่ง GOAWAY ที่ห้ามเปิดสตรีมเพิ่มเติม
  • แต่ขั้นตอน GOAWAY แบบค่อยเป็นค่อยไปเช่นนี้มักไม่แข็งแรงพอสำหรับไคลเอนต์ที่เป็นอันตราย
    • ทำให้การเชื่อมต่อเปิดรับการโจมตี Rapid Reset นานเกินไป
    • ไม่สามารถหยุดคำขอขาเข้าได้
  • เพื่อการบรรเทา GOAWAY ควรถูกตั้งค่าให้ จำกัดการสร้างสตรีมทันที

  • การจำแนกการเชื่อมต่อที่เป็นการใช้งานในทางที่ผิด

    • การที่ไคลเอนต์ยกเลิกคำขอไม่ได้ถือเป็นการใช้งานในทางที่ผิดเสมอไป
    • ความสามารถในการยกเลิกของ HTTP/2 เป็นฟีเจอร์สำหรับจัดการการประมวลผลคำขอให้ดีขึ้น
      • กรณีผู้ใช้ออกจากหน้าเว็บและเบราว์เซอร์ไม่ต้องการทรัพยากรที่ร้องขออีกต่อไป
      • แอปพลิเคชันที่ใช้ long polling พร้อม client-side timeout
    • การบรรเทาจึงมุ่งไปที่การติดตามสถิติของการเชื่อมต่อและใช้หลายสัญญาณร่วมกับ business logic เพื่อตัดสินความมีประโยชน์ของแต่ละการเชื่อมต่อ
    • ตัวอย่างเช่น หากการเชื่อมต่อหนึ่งมีคำขอเกิน 100 รายการ และเกิน 50% ของนั้นถูกยกเลิก ก็อาจเป็นผู้สมัครสำหรับการบรรเทา
    • ขนาดและประเภทของการตอบสนองขึ้นอยู่กับความเสี่ยงของแต่ละแพลตฟอร์ม
      • บังคับส่งเฟรม GOAWAY
      • ยุติการเชื่อมต่อ TCP ทันที
    • เพื่อบรรเทารูปแบบไม่ยกเลิก แนะนำให้เซิร์ฟเวอร์ HTTP/2 ปิดการเชื่อมต่อที่เกินข้อจำกัดจำนวนสตรีมพร้อมกัน
      • อาจปิดทันที
      • หรือปิดหลังมีการละเมิดซ้ำจำนวนเล็กน้อย

ความเป็นไปได้กับ HTTP/3

  • Google มองว่าเนื่องจากความแตกต่างของโปรโตคอล วิธีโจมตีนี้ไม่สามารถนำไปใช้กับ HTTP/3 (QUIC) ได้โดยตรง
  • ปัจจุบัน Google ยังไม่พบสถานการณ์ที่ HTTP/3 ถูกใช้เป็นเวกเตอร์ DDoS ขนาดใหญ่
  • ถึงอย่างนั้น ก็แนะนำให้การติดตั้งใช้งานเซิร์ฟเวอร์ HTTP/3 มีการนำกลไกที่จำกัดปริมาณงานของการเชื่อมต่อส่งข้อมูลเดี่ยวมาใช้ล่วงหน้า
    • มีทิศทางคล้ายกับมาตรการบรรเทาของ HTTP/2 ที่กล่าวถึง

การประสานงานในอุตสาหกรรมและ CVE

  • ตั้งแต่ช่วงต้นของการสืบสวนโดย Google DDoS Response Team ก็ชัดเจนว่าการโจมตีประเภทนี้อาจส่งผลกว้างต่อทุกบริการที่ให้บริการ HTTP/2
  • Google ใช้กลุ่มเปิดเผยช่องโหว่แบบประสานงานที่มีอยู่เดิมเพื่อนำ กระบวนการเปิดเผยช่องโหว่แบบประสานงาน
  • กระบวนการเปิดเผยมุ่งเน้นการแจ้งผู้พัฒนา implementation HTTP/2 รายใหญ่
    • บริษัทโครงสร้างพื้นฐาน
    • ผู้ให้บริการซอฟต์แวร์เซิร์ฟเวอร์
  • เป้าหมายของการแจ้งล่วงหน้าคือเพื่อพัฒนามาตรการบรรเทาและเตรียมพร้อมตามกำหนดการเปิดเผยแบบประสานงาน
  • ในอดีต แนวทางนี้นำไปสู่การใช้การป้องกันอย่างกว้างขวางโดยผู้ให้บริการ หรือการออกอัปเดตซอฟต์แวร์สำหรับหลายแพ็กเกจและโซลูชัน
  • ระหว่างกระบวนการเปิดเผยแบบประสานงาน มีการจอง CVE-2023-44487 ไว้เพื่อติดตามการแก้ไขใน implementation HTTP/2 หลายรายการ

สิ่งที่ผู้ให้บริการ HTTP/2 ควรทำ

  • การโจมตีนี้อาจส่งผลอย่างมีนัยสำคัญต่อบริการทุกขนาด
  • ผู้ให้บริการทุกแห่งที่ให้บริการ HTTP/2 ควรประเมินว่าระบบของตนเปิดรับประเด็นนี้หรือไม่
  • แพตช์ซอฟต์แวร์และอัปเดตสำหรับเว็บเซิร์ฟเวอร์ทั่วไปและภาษาโปรแกรมต่าง ๆ อาจมีให้ใช้งานแล้วในปัจจุบันหรือในอนาคตอันใกล้
  • แนะนำให้นำการแก้ไขที่มีให้ใช้งานไปใช้โดยเร็วที่สุดเท่าที่ทำได้
  • สำหรับลูกค้า Google Cloud แนะนำให้ใช้ Application Load Balancer และ Google Cloud Armor ร่วมกับการติดตั้งแพตช์ซอฟต์แวร์
    • Google Cloud Armor ได้ช่วยปกป้อง Google และผู้ใช้ Google Cloud Application Load Balancing ที่มีอยู่เดิมมาแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-11
ความคิดเห็นบน Hacker News

  • เธรดที่เกี่ยวข้องซึ่งกำลังดำเนินอยู่:
    การโจมตี DDoS ครั้งใหญ่ที่สุดจนถึงปัจจุบัน พุ่งสูงสุดมากกว่า 398 ล้านคำขอต่อวินาที - https://news.ycombinator.com/item?id=37831062
    ช่องโหว่ zero-day ของ HTTP/2 ทำให้เกิดการโจมตี DDoS ทำลายสถิติ - https://news.ycombinator.com/item?id=37830998

  • ดูดีที่ทีม HAProxy ดูเหมือนจะพบและบรรเทาปัญหาประเภทนี้ของ HTTP/2 ได้ตั้งแต่ปี 2018 แล้ว: https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...

    • ดีเลย ผมกำลังหาข้อมูลแบบนี้เกี่ยวกับ HAProxy อยู่พอดี และมันทำให้มั่นใจใน ฟีเจอร์ QUIC ใหม่มากขึ้น
    • ถ้ามีใครสงสัย Nginx มีช่องโหว่ต่อปัญหานี้
      https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...

  • ในการ implement เซิร์ฟเวอร์ HTTP/2 ทั่วไป แม้คำขอที่ถูกยกเลิกก็ยังต้องทำงานค่อนข้างมาก เช่น จัดสรรโครงสร้างข้อมูลสตรีมใหม่ แยกวิเคราะห์ query คลายการบีบอัด header และ map resource ของ URL
    ในการ implement reverse proxy คำขออาจถูก proxy ไปยัง backend server ก่อนที่เฟรม RST_STREAM จะถูกประมวลผลด้วยซ้ำ ในขณะที่ฝั่งไคลเอนต์แทบไม่เสียต้นทุนในการส่งคำขอ จึงเกิด ความไม่สมมาตรของต้นทุน ระหว่างเซิร์ฟเวอร์กับไคลเอนต์ที่ถูกนำไปใช้โจมตีได้
    น่าแปลกใจที่ตอนออกแบบ HTTP/2 ไม่ได้คาดการณ์เรื่องนี้ไว้ ทั้งที่ การโจมตีแบบขยายผล ในโปรโตคอลอื่นเป็นที่รู้จักกันดีอยู่แล้ว การที่การโจมตีนี้เพิ่งถูกเปิดเผยช้าขนาดนี้ก็น่าแปลกใจในทำนองเดียวกัน แต่อาจเป็นเพราะจนไม่นานมานี้ HTTP/2 ยังไม่ได้ถูก deploy กว้างพอจนเป็นเป้าหมายที่คุ้มค่า

    • พูดให้เคร่งครัด นี่ไม่ใช่ การโจมตีแบบขยายผล แค่ใกล้เคียงกับการใช้การเชื่อมต่อ TCP ให้มีประสิทธิภาพมากขึ้นมาก
    • ผมก็แปลกใจเหมือนกัน แต่ถ้าดู timeline แล้ว RST_STREAM มีอยู่ตั้งแต่ SPDY รุ่นแรก ๆ และ SPDY ดูเหมือนออกแบบโดยรวมราวปี 2009
      การโจมตีอย่าง Slowloris ก็ออกมาในช่วงใกล้เคียงกัน แต่ตอนนั้นยังไม่เป็นที่รู้จักแพร่หลาย ส่วน SYN cookies ถูกนำมาใช้ตั้งแต่ปี 1996 ดังนั้นการโจมตีแบบที่เหยื่อจ่ายต้นทุน Y ส่วนผู้โจมตีจ่าย X มีแบบอย่างทางประวัติศาสตร์ชัดเจนอยู่แล้ว
    • เรื่องแบบนี้ส่วนใหญ่มีความเป็นไปได้สูงว่าคนจำนวนมากที่ไม่ได้มีความสำคัญอะไรเคยรายงานและทดลองกันมาแล้ว
      เพียงแต่จุดที่พิเศษคือมีการลองทำอย่างจริงจังกับ Google

  • สรุปคือเราต้องมี HTTP/2 เพื่อส่งโฆษณา tracker และ frontend framework ที่บวมใหญ่ให้เร็วขึ้น ตอนนี้มันก็ส่ง การโจมตีได้เร็วขึ้น ด้วย

    • HTTP/2 ทำให้ประสบการณ์การท่องเว็บบน การเชื่อมต่อที่มี latency สูง พอทนได้มากขึ้นมาก โดยทั่วไปยังทำให้หน้าเว็บโหลดเร็วขึ้นด้วย
      โชคดีที่ HTTP/1.1 ยังใช้งานได้อยู่ ถ้าไม่ชอบโปรโตคอลนั้น คุณเปิดใช้ HTTP/1.1 ได้เสมอใน settings ของ browser และบน web server
    • หมายความว่าไม่จำเป็นต้องมี HTTP/2 งั้นหรือ? ถ้าอย่างนั้นทางเลือกที่เป็นจริงได้คืออะไร?

  • นี่เป็นอีกเหตุผลหนึ่งที่ควรรักษาโปรโตคอลพื้นฐานให้เล็กไว้ HTTP/2 ถ้ารวม SPDY ด้วยก็มีมานานกว่า 10 ปีแล้ว แต่การโจมตีรูปแบบนี้เพิ่งปรากฏเป็นครั้งแรก
    สงสัยว่าใน HTTP/3 และ QUIC จะมีเรื่องน่าประหลาดใจอะไรซ่อนอยู่อีก

    • DNS เป็นโปรโตคอลเล็ก ๆ แต่ก็ยังถูกผู้โจมตี DDoS ทั่วโลกนำไปใช้ใน การโจมตีผ่านตัวกลาง
    • QUIC ไม่ได้พิจารณา การโจมตีแบบขยายผล อย่างเหมาะสมในการออกแบบ และคนที่หยิบยกเรื่องนี้เป็นปัญหาตั้งแต่ช่วงแรกก็ถูกเมิน
    • HTTP/2 ถือว่าค่อนข้างเล็กนะ

  • ควรเพิ่ม “การยกเลิก” เข้าไปในรายการ “ปัญหาวิทยาการคอมพิวเตอร์ที่ยาก” ด้วย
    มันไม่ได้ยากมหาศาลจริง ๆ เหมือนบางอย่างในรายการนั้น เช่น off-by-one error หรือ cache invalidation แต่ถูกประเมินต่ำไปและถูกมองข้ามได้ง่าย ถ้าใช้เวลาในการออกแบบการทำลาย การ cleanup การรื้อถอน และการยกเลิกสักครึ่งหนึ่งของเวลาที่ใช้กับการสร้าง constructor และ initialization ก็น่าจะลด บั๊ก resource exhaustion ลงได้มากเป็นพิเศษ

    • async ของ Rust ดีมากตรงที่สามารถ ยกเลิก Future ได้ทันที ที่จุด await ใด ๆ โดยไม่ต้องอาศัยความร่วมมือจากแต่ละ call และยกเลิก call stack ทั้งหมดไปพร้อมกันได้
    • สำหรับ C library นี่เป็นเรื่องจริงแน่นอน การยกเลิก POSIX thread เป็นฟีเจอร์ชนิดที่แค่มีอยู่ ผลกระทบของมันก็แทรกซึมไปทุกที่แล้ว

  • อยากเตือนทุกคนว่า Google คือ บริษัทที่สร้าง HTTP/2
    ตอนนี้พวกเขาเล่าเหมือนกำลังกอบกู้เราจากปัญหาที่ตัวเองสร้างขึ้นอย่างกล้าหาญ แต่กลับไม่พูดถึงส่วนที่ตัวเองเป็นคนสร้าง ช่างหน้าด้านจริง ๆ บริษัทเทคโนโลยีพวกนี้ Microsoft ก็ทำแบบนี้มาหลายสิบปีแล้ว

    • พวกเขาพยายามแก้ปัญหาที่ไม่เคยมีอยู่

  • ใครช่วยอธิบายได้ไหมว่าในการโจมตีนี้ มีอะไรใหม่ที่ต่างจาก request flood ธรรมดา?

    • ขึ้นอยู่กับว่าคุณมองการโจมตีแบบ “request flood” ว่าคืออะไร
      ใน HTTP/1.1 คุณส่งคำขอได้หนึ่งรายการต่อ round-trip time[0] ใน multiplexing ของ HTTP/2 คุณส่งได้ 100 รายการต่อ round-trip time ส่วนในการโจมตีนี้ คุณส่งคำขอได้ในจำนวนแทบไม่จำกัดต่อ round-trip time หวังว่าแผนภาพในบทความนี้จะแสดงความแตกต่างได้ แต่ก็เป็นไปได้ว่าคุณอาจหมายถึงการโจมตีรูปแบบอื่นที่ต่างจากที่กล่าวข้างต้น
      [0] ถ้าพิจารณา HTTP/1.1 pipelining ก็ลดปัจจัย round-trip time ลงได้หนึ่งส่วน แต่ client จริงแทบไม่ใช้ HTTP/1.1 pipelining ดังนั้นการใช้มันเองจึงกลายเป็นสัญญาณที่ชัดมากว่าเป็น traffic ที่เป็นอันตราย
    • เทคนิคใหม่ที่อธิบายไว้นี้หลีกเลี่ยง ขีดจำกัดสูงสุด ของจำนวนคำขอต่อวินาทีต่อไคลเอนต์ที่ผู้โจมตีสามารถทำให้เซิร์ฟเวอร์ประมวลผลได้
      เมื่อส่งทั้งคำขอและการ reset stream ภายใน connection เดียวกัน ก็สามารถส่งคำขอต่อ connection/ต่อ client ได้มากกว่าเดิม ซึ่งอาจทำให้ต้นทุนการโจมตีถูกลงหรือบล็อกได้ยากขึ้น

  • header ของบล็อกเด้งออกมาเรื่อย ๆ จนอ่านหน้าเว็บไม่ได้