HTTP Strict Transport Security ( HSTS ) เป็นกลไกนโยบายที่ช่วยปกป้องเว็บไซต์จากการโจมตีแบบ man-in-the-middleเช่นการโจมตีแบบ protocol downgrade ^{[ 1 ]}และการขโมยคุกกี้โดยอนุญาตให้เว็บเซิร์ฟเวอร์ประกาศว่าเว็บเบราว์เซอร์ (หรือตัวแทนผู้ใช้ ที่ปฏิบัติตาม ) ควรโต้ตอบกับเว็บเซิร์ฟเวอร์โดยอัตโนมัติโดยใช้เฉพาะ การเชื่อมต่อ HTTPSซึ่งให้ความปลอดภัยของเลเยอร์การขนส่ง (TLS/SSL) ซึ่งแตกต่างจาก HTTPที่ไม่ปลอดภัยที่ใช้เพียงอย่างเดียว HSTS เป็น โปรโตคอล มาตรฐานของ IETF และ ระบุไว้ในRFC 6797 

นโยบาย HSTS จะถูกสื่อสารโดยเซิร์ฟเวอร์ไปยังเอเจนต์ผู้ใช้ผ่าน ฟิลด์ ส่วนหัว การตอบสนอง HTTP ที่ชื่อว่าStrict-Transport-Securityนโยบาย HSTS ระบุช่วงเวลาที่เอเจนต์ผู้ใช้ควรเข้าถึงเซิร์ฟเวอร์ในลักษณะที่ปลอดภัยเท่านั้น^{[ 2 ] : §5.2} เว็บไซต์ที่ใช้ HSTS มักจะไม่ยอมรับ HTTP แบบข้อความธรรมดา ไม่ว่าจะโดยการปฏิเสธการเชื่อมต่อผ่าน HTTP หรือการเปลี่ยนเส้นทางผู้ใช้ไปยัง HTTPS อย่างเป็นระบบ (แม้ว่าสิ่งนี้จะไม่ใช่ข้อกำหนดในข้อกำหนดก็ตาม) ผลที่ตามมาคือเอเจนต์ผู้ใช้ที่ไม่สามารถทำ TLS ได้จะไม่สามารถเชื่อมต่อกับเว็บไซต์ได้

โดยปกติแล้ว การป้องกันจะมีผลก็ต่อเมื่อผู้ใช้เคยเข้าชมเว็บไซต์อย่างน้อยหนึ่งครั้ง โดยอาศัยหลักการ " เชื่อถือเมื่อใช้งานครั้งแรก " วิธีการทำงานของการป้องกันนี้คือ เมื่อผู้ใช้ป้อนหรือเลือก URL ของเว็บไซต์ที่เป็น HTTP (ไม่ใช่ HTTPS) ไคลเอนต์ เช่น เว็บเบราว์เซอร์ จะอัปเกรดเป็น HTTPS โดยอัตโนมัติโดยไม่ต้องส่งคำขอ HTTP ซึ่งจะป้องกันการโจมตีแบบ man-in-the-middle ผ่าน HTTP ได้ เพื่อแก้ไขปัญหานี้Google Chrome และ เว็บเบราว์เซอร์หลักอื่นๆ จึง ได้จัดทำรายการ HSTS preload ไว้ หากโดเมนอยู่ในรายการนี้ เบราว์เซอร์จะข้ามคำขอเริ่มต้นและเข้ารหัสการสื่อสารทั้งหมดทันที^{[ 3 ]}สามารถลงทะเบียนโดเมนเพิ่มเติมได้โดยไม่มีค่าใช้จ่าย^{[ 4 ​​]}

ข้อกำหนด HSTS ได้รับการเผยแพร่เป็น RFC 6797 เมื่อวันที่ 19 พฤศจิกายน 2012 หลังจากได้รับการอนุมัติเมื่อวันที่ 2 ตุลาคม 2012 โดยIESGให้เผยแพร่เป็นProposed Standard RFC ^{[ 5 ]}ผู้เขียนได้ส่งเอกสารนี้เป็นInternet Draftเมื่อวันที่ 17 มิถุนายน 2010 เมื่อมีการแปลงเป็น Internet Draft ชื่อของข้อกำหนดจึงเปลี่ยนจาก "Strict Transport Security" (STS) เป็น "HTTP Strict Transport Security" เนื่องจากข้อกำหนดนี้ใช้ได้กับHTTPเท่านั้น^{[ 6 ]}อย่างไรก็ตาม ฟิลด์ส่วนหัวการตอบสนอง HTTP ที่กำหนดไว้ในข้อกำหนด HSTS ยังคงมีชื่อว่า "Strict-Transport-Security"

ข้อกำหนด "STS" เวอร์ชันชุมชน" ฉบับสุดท้ายที่กล่าวถึงนี้ได้รับการเผยแพร่เมื่อวันที่ 18 ธันวาคม พ.ศ. 2552 โดยมีการแก้ไขตามข้อเสนอแนะจากชุมชน^{[ 7 ]}

ข้อกำหนดฉบับร่างดั้งเดิมโดย Jeff Hodges จากPayPal , Collin Jackson และ Adam Barth ได้รับการเผยแพร่เมื่อวันที่ 18 กันยายน 2552 ^{[ 8 ]}

ข้อกำหนด HSTS อ้างอิงจากงานดั้งเดิมของ Jackson และ Barth ตามที่อธิบายไว้ในเอกสารของพวกเขาเรื่อง "ForceHTTPS: การปกป้องเว็บไซต์ที่มีความปลอดภัยสูงจากการโจมตีเครือข่าย" ^{[ 9 ]}

นอกจากนี้ HSTS ยังเป็นการตระหนักถึงแง่มุมหนึ่งของวิสัยทัศน์โดยรวมในการปรับปรุงความปลอดภัยของเว็บ ซึ่งนำเสนอโดย Jeff Hodges และ Andy Steingruebl ในบทความปี 2010 ของพวกเขาเรื่องThe Need for Coherent Web Security Policy Framework(s ) ^{[ 10 ]}

เซิร์ฟเวอร์ใช้ HSTS policy โดยการส่ง header ผ่านการเชื่อมต่อ HTTPS (HSTS header ผ่าน HTTP จะถูกละเลย) ^{[ 1 ]}ตัวอย่างเช่น เซิร์ฟเวอร์สามารถส่ง header เพื่อให้การร้องขอในอนาคตไปยังโดเมนในปีถัดไป (max-age ระบุเป็นวินาที; 31,536,000 เท่ากับหนึ่งปีที่ไม่ใช่ปีอธิกสุรทิน) ใช้ HTTPS เท่านั้น: Strict-Transport-Security: max-age=31536000.

เมื่อเว็บแอปพลิเคชันออกนโยบาย HSTS ให้กับเอเจนต์ผู้ใช้ เอเจนต์ผู้ใช้ที่สอดคล้องจะมีพฤติกรรมดังต่อไปนี้: ^{[ 2 ] : §5}

1. แปลงลิงก์ที่ไม่ปลอดภัยที่อ้างอิงถึงเว็บแอปพลิเคชันให้เป็นลิงก์ที่ปลอดภัยโดยอัตโนมัติ (เช่นhttp://example.com/some/page/จะถูกแก้ไขhttps://example.com/some/page/ก่อนเข้าถึงเซิร์ฟเวอร์)
2. หากไม่สามารถรับประกันความปลอดภัยของการเชื่อมต่อได้ (เช่น ใบรับรองTLS ของเซิร์ฟเวอร์ไม่น่าเชื่อถือ) ตัวแทนผู้ใช้จะต้องยุติการเชื่อมต่อ^{[ 2 ] : §8.4} และไม่ควรอนุญาตให้ผู้ใช้เข้าถึงเว็บแอปพลิเคชัน^{[ 2 ] : §12.1}

สิ่งนี้ช่วยปกป้องผู้ใช้แอปพลิเคชันเว็บจากการโจมตี เครือข่ายแบบพาสซีฟ ( การดักฟัง ) และแบบแอ คทีฟบางประเภท ^{[ 2 ] : §2.4} ผู้โจมตีแบบ man-in-the-middle มีความสามารถในการ ดักฟังคำขอและการตอบสนองระหว่างผู้ใช้และเซิร์ฟเวอร์แอปพลิเคชันเว็บลดลงอย่างมากในขณะที่เบราว์เซอร์ของผู้ใช้มีนโยบาย HSTS ที่มีผลบังคับใช้สำหรับแอปพลิเคชันเว็บนั้น

ช่องโหว่ด้านความปลอดภัยที่สำคัญที่สุดที่ HSTS สามารถแก้ไขได้คือการโจมตีแบบ man-in-the-middle โดยการถอด SSL ซึ่ง Moxie Marlinspikeได้เปิดเผยต่อสาธารณะเป็นครั้งแรกในการบรรยาย BlackHat Federal ปี 2009 เรื่อง "New Tricks For Defeating SSL In Practice" ^{[ 11 ] [ 12 ]} การโจมตีโดยการถอด SSL (และTLS ) ทำงานโดยการแปลง การเชื่อมต่อ HTTPS ที่ปลอดภัย ให้เป็นการเชื่อมต่อ HTTP ธรรมดาอย่างโปร่งใส ผู้ใช้สามารถเห็นได้ว่าการเชื่อมต่อไม่ปลอดภัย แต่ที่สำคัญคือไม่มีวิธีใดที่จะรู้ได้ว่าการเชื่อมต่อควรจะปลอดภัยหรือไม่ ในช่วงเวลาที่ Marlinspike บรรยายนั้น เว็บไซต์จำนวนมากไม่ได้ใช้ TLS/SSL ดังนั้นจึงไม่มีวิธีใดที่จะรู้ได้ (หากไม่มีความรู้มาก่อน) ว่าการใช้ HTTP ธรรมดานั้นเกิดจากการโจมตีหรือเพียงเพราะเว็บไซต์ไม่ได้ใช้งาน TLS/SSL นอกจากนี้ ยังไม่มีคำเตือนใด ๆ แสดงต่อผู้ใช้ในระหว่างกระบวนการลดระดับ ทำให้การโจมตีค่อนข้างแนบเนียนสำหรับทุกคนยกเว้นผู้ที่ระมัดระวังที่สุด เครื่องมือ sslstrip ของ Marlinspike ซึ่งนำเสนอในงาน Black Hat DC 2009 จะทำการโจมตีโดยอัตโนมัติอย่างสมบูรณ์^{[ 13 ]}

HSTS แก้ไขปัญหานี้^{[ 2 ] : §2.4} โดยแจ้งให้เบราว์เซอร์ทราบว่าการเชื่อมต่อกับเว็บไซต์ควรใช้ TLS/SSL เสมอ ส่วนหัว HSTS สามารถถูกผู้โจมตีลบออกได้หากนี่เป็นการเข้าชมครั้งแรกของผู้ใช้Google Chrome , Mozilla Firefox , Internet ExplorerและMicrosoft Edgeพยายามจำกัดปัญหานี้โดยการรวมรายการเว็บไซต์ HSTS ที่ "โหลดไว้ล่วงหน้า" ^{[ 14 ] [ 15 ] [ 16 ]}น่าเสียดายที่วิธีแก้ปัญหานี้ไม่สามารถขยายขนาดเพื่อรวมเว็บไซต์ทั้งหมดบนอินเทอร์เน็ตได้ ดูข้อจำกัดด้านล่าง

HSTS ยังสามารถช่วยป้องกันไม่ให้ข้อมูลประจำตัวการเข้าสู่ระบบเว็บไซต์ที่ใช้คุกกี้ถูกขโมยโดยเครื่องมือที่หาได้ทั่วไป เช่นFiresheepได้ อีกด้วย ^{[ 17 ]}

เนื่องจาก HSTS มีเวลาจำกัด จึงไวต่อการโจมตีที่เกี่ยวข้องกับการเปลี่ยนเวลาของคอมพิวเตอร์ของเหยื่อ เช่น การใช้แพ็กเก็ตNTP ปลอม ^{[ 18 ]}

คำขอเริ่มต้นยังคงไม่ได้รับการปกป้องจากการโจมตีแบบแอคทีฟหากใช้โปรโตคอลที่ไม่ปลอดภัย เช่น HTTP ธรรมดา หรือหากURIสำหรับคำขอเริ่มต้นได้รับผ่าน ช่อง ทางที่ไม่ปลอดภัย^{[ 2 ] : §14.6} เช่นเดียวกันนี้ใช้กับคำขอแรกหลังจากช่วงเวลากิจกรรมที่ระบุไว้ในนโยบาย HSTS ที่ประกาศไว้max-age(เว็บไซต์ควรตั้งระยะเวลาหลายวันหรือหลายเดือนขึ้นอยู่กับกิจกรรมและพฤติกรรมของผู้ใช้)

Google Chrome , Mozilla FirefoxและInternet Explorer / Microsoft Edgeแก้ไขข้อจำกัดนี้โดยการใช้ "รายการ HSTS ที่โหลดไว้ล่วงหน้า" ซึ่งเป็นรายการที่มีเว็บไซต์ที่รู้จักซึ่งรองรับ HSTS ^{[ 19 ] [ 14 ] [ 15 ] [ 16 ]}รายการนี้จะถูกแจกจ่ายไปพร้อมกับเบราว์เซอร์เพื่อให้ใช้ HTTPS สำหรับการร้องขอครั้งแรกไปยังเว็บไซต์ที่อยู่ในรายการเช่นกัน ดังที่กล่าวไว้ก่อนหน้านี้ รายการที่โหลดไว้ล่วงหน้าเหล่านี้ไม่สามารถขยายขนาดเพื่อครอบคลุมเว็บทั้งหมดได้ วิธีแก้ปัญหาที่เป็นไปได้อาจทำได้โดยการใช้ ระเบียน DNSเพื่อประกาศนโยบาย HSTS และเข้าถึงอย่างปลอดภัยผ่านDNSSECโดยอาจมีการตรวจสอบความถูกต้องของใบรับรอง (ซึ่งต้องใช้ตัวแก้ไขที่ตรวจสอบความถูกต้องเพื่อหลีกเลี่ยง ปัญหา ในระยะสุดท้าย ) ^{[ 20 ]}

Junade Ali ตั้งข้อสังเกตว่า HSTS ไม่มีประสิทธิภาพในการป้องกันการใช้โดเมนปลอม โดยการใช้การโจมตีแบบ DNS ทำให้ผู้ดักจับข้อมูลแบบ man-in-the-middle สามารถให้บริการทราฟฟิกจากโดเมนเทียมที่ไม่อยู่ในรายการ HSTS Preload ได้^{[ 21 ]}ซึ่งสามารถทำได้โดยการโจมตีแบบ DNS Spoofing [ ^{22 ] หรือ}เพียงแค่ชื่อโดเมนที่คล้ายกับชื่อโดเมนจริงอย่างน่าเข้าใจผิด เช่นwww.example.orgแทนที่จะเป็นwww.example.com

ถึงแม้จะมีรายการ HSTS ที่โหลดไว้ล่วงหน้าแล้ว HSTS ก็ไม่สามารถป้องกันการโจมตีขั้นสูงต่อ TLS เองได้ เช่น การโจมตี BEASTหรือCRIMEที่คิดค้นโดย Juliano Rizzo และ Thai Duong การโจมตีต่อ TLS เองนั้นไม่เกี่ยวข้องกับการบังคับใช้นโยบายของ HSTS และไม่สามารถป้องกันการโจมตีบนเซิร์ฟเวอร์ได้เช่นกัน หากมีคนเจาะระบบได้ เซิร์ฟเวอร์ก็จะให้บริการเนื้อหาใดๆ ผ่าน TLS ได้อย่างไม่มีปัญหา

HSTS สามารถใช้เพื่อติดแท็กเบราว์เซอร์ที่เข้าชมด้วยข้อมูลระบุตัวตนที่กู้คืนได้ ( ซูเปอร์คุกกี้ ) ซึ่งสามารถคงอยู่ได้ทั้งในและนอกโหมดความเป็นส่วนตัว " ไม่ระบุตัวตน " ของเบราว์เซอร์ ตัวอย่างเช่น หากใช้การร้องขอเบราว์เซอร์ 20 ครั้งไปยัง 20 โดเมนที่แตกต่างกัน ในทางทฤษฎีแล้วจะสามารถแยกแยะผู้เข้าชมได้มากกว่าหนึ่งล้านคน (2 ²⁰ ) เนื่องจากการร้องขอที่มาถึงผ่าน HTTP เทียบกับ HTTPS โดยที่ HTTPS คือ "บิต" ไบนารีที่บันทึกไว้ก่อนหน้านี้ซึ่งกำหนดไว้ก่อนหน้านี้ผ่านส่วนหัว HSTS ^{[ 23 ]}

• ChromiumและGoogle Chromeตั้งแต่เวอร์ชัน 4.0.211.0 ^{[ 24 ] [ 25 ]}
• Firefoxตั้งแต่เวอร์ชัน 4; ^{[ 1 ]}ใน Firefox 17 Mozillaได้รวมรายการเว็บไซต์ที่รองรับ HSTS ไว้ด้วย^{[ 15 ]}
• Operaตั้งแต่เวอร์ชัน 12 ^{[ 26 ]}
• Safariตั้งแต่OS X Mavericks (เวอร์ชัน 10.9 ปลายปี 2013) ^{[ 27 ]}
• Internet Explorer 11บนWindows 8.1และWindows 7ที่ ติดตั้ง KB3058515 (เผยแพร่เป็นการอัปเดต Windows ในเดือนมิถุนายน 2015) ^{[ 28 ]}
• Microsoft EdgeและInternet Explorer 11บนWindows 10 ^{[ 29 ] [ 30 ]}
• เบราว์เซอร์ BlackBerry 10และWebViewตั้งแต่ BlackBerry OS 10.3.3 เป็นต้นไป

ขึ้นอยู่กับการใช้งานจริง อาจมีภัยคุกคามบางอย่าง (เช่น การโจมตีด้วยการแทรกคุกกี้) ที่สามารถหลีกเลี่ยงได้โดยการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด

• โฮสต์ HSTS ควรประกาศนโยบาย HSTS ที่ชื่อโดเมนระดับบนสุดของตน ตัวอย่างเช่น โฮสต์ HSTS ที่ https://sub.example.com ควรตอบกลับด้วยส่วนหัว HSTS ที่ https://example.com ด้วย ส่วนหัวควรระบุincludeSubDomainsคำสั่ง^{[ 2 ] : §6.1.2}
• นอกเหนือจากการใช้งาน HSTS แล้ว โฮสต์สำหรับ https://www.example.com ควรมีการร้องขอทรัพยากรจาก https://example.com เพื่อให้แน่ใจว่า HSTS สำหรับโดเมนหลักได้รับการตั้งค่าและปกป้องผู้ใช้จากการโจมตีการแทรกคุกกี้ที่อาจเกิดขึ้นโดย MITM ซึ่งจะแทรกการอ้างอิงไปยังโดเมนหลัก (หรือแม้แต่ http://nonexistentpeer.example.com) ซึ่งผู้โจมตีจะตอบกลับ^{[ 2 ] : §11.4}

• RFC  6797 - การอภิปรายเกี่ยวกับข้อควรพิจารณาด้านความปลอดภัยโดยรวมของ HSTS
• นโยบายความปลอดภัยของเนื้อหา
• .app TLD – โดเมนระดับบนสุดที่ดำเนินการโดย Google ซึ่งรวมอยู่ในรายการโหลดล่วงหน้าของ HSTS โดยค่าเริ่มต้น
• .dev TLD – โดเมนระดับบนสุดที่ดำเนินการโดย Google ซึ่งรวมอยู่ในรายการโหลดล่วงหน้าของ HSTS โดยค่าเริ่มต้น
• การตรึงคีย์สาธารณะ HTTP

• กลุ่มงาน IETF WebSec
• Security Now 262: มาตรการรักษาความปลอดภัยด้านการขนส่งที่เข้มงวด
• โครงการรักษาความปลอดภัยแอปพลิเคชันเว็บแบบเปิด (OWASP): คำอธิบาย HSTS
• การทดสอบ HSTS และการตรึงคีย์สาธารณะผ่านเบราว์เซอร์ออนไลน์
• การส่งข้อมูล HSTS Preloadสำหรับ Google Chrome, Mozilla Firefox, Safari, IE 11 และ Edge
• รายการโหลดล่วงหน้าของ Chromium HSTS
• Strict-Transport-SecurityบนMDN Web Docs