ความปลอดภัยของเลเยอร์การขนส่ง (TLS) โปรโตคอลเป็นวิธีการหลักในการปกป้องเครือข่ายการสื่อสารผ่านอินเทอร์เน็ต บทความนี้เป็นคำแนะนำสั้น ๆ เพื่อช่วยคุณกำหนดค่าเซิร์ฟเวอร์ที่ปลอดภัยให้ตรงตามปัจจุบัน TLS มาตรฐาน
บริษัท
พื้นที่ ความปลอดภัยของเลเยอร์การขนส่ง (TLS) โปรโตคอลเป็นวิธีการหลักในการปกป้องเครือข่ายการสื่อสารผ่านอินเทอร์เน็ต มัน (และรุ่นก่อน Secure Sockets Layer หรือ SSL) ถูกนำมาใช้เป็นเวลาหลายสิบปีในหลาย ๆ แอปพลิเคชัน แต่ที่โดดเด่นที่สุดในเบราว์เซอร์เมื่อเข้าชม HTTPS เว็บไซต์ TLS มักจะทำงานอย่างเงียบ ๆ ในพื้นหลัง แต่ตรงกันข้ามกับสิ่งที่เราคิด TLS ไม่ใช่กล่องดำที่ใช้งานได้ ค่อนข้างปลอดภัย TLS ให้เกิดขึ้นจากความร่วมมือของอัลกอริทึมการเข้ารหัสลับต่างๆ ยิ่งไปกว่านั้น TLSเช่นเดียวกับ SSL ก่อนหน้านี้มีการพัฒนาอย่างต่อเนื่องพร้อมกับอุตสาหกรรมความปลอดภัย - เทคโนโลยีใหม่และข้อกำหนดทางธุรกิจต้องเป็นไปตามข้อกำหนดในขณะที่ภัยคุกคามด้านความปลอดภัยล่าสุดต้องได้รับการบรรเทา อัลกอริทึมอาจล้าสมัยเมื่อเวลาผ่านไปหรืออาจละทิ้งการปฏิบัติได้โดยการเปลี่ยนแปลงแต่ละครั้งจะส่งผลต่อความปลอดภัยโดยรวมของก TLS อินสแตนซ์ (เช่นอันที่ปกป้องการเชื่อมต่อของคุณตอนนี้)
ความผันผวนนี้ได้กระตุ้นให้องค์กรมาตรฐานต่างๆเผยแพร่เอกสารแนวทางเพื่อเป็นพื้นฐานขั้นต่ำสำหรับ TLS ความปลอดภัยสามารถกำหนดได้ในตลาดภาคหรือบริการโดยเฉพาะ น่าเสียดายที่มีมาตรฐานดังกล่าวจำนวนมากที่มีภาคส่วนต่าง ๆ ที่ต้องการการปฏิบัติตามเอกสารที่ใช้บังคับที่แตกต่างกันในขณะที่มาตรฐานเหล่านั้นเอง ด้วย วิวัฒนาการเมื่อเวลาผ่านไปรองรับการเปลี่ยนแปลงในส่วนที่ถูกออกแบบมาเพื่อปกป้อง
เข้าใจได้ว่าการนำทางผ่านมาตรฐานทะเลแห่งนี้เพื่อตั้งค่าความทันสมัย TLS อินสแตนซ์อาจเป็นเรื่องน่าปวดหัวสำหรับผู้ดูแลระบบ บทความนี้เป็นคำแนะนำสั้น ๆ เพื่อช่วยคุณกำหนดค่าเซิร์ฟเวอร์ที่ปลอดภัยให้เป็นไปตามที่คาดไว้ TLS มาตรฐานในปี 2021 (สำหรับความช่วยเหลือเพิ่มเติมเราได้ยกตัวอย่างการกำหนดค่าของโซลูชันเว็บเซิร์ฟเวอร์ที่ได้รับความนิยมมากที่สุดในไฟล์ ภาคผนวก.)
มาตรฐาน
มีหลายหน่วยงานที่รักษาแนวทางไว้ TLS เกี่ยวกับความปลอดภัยของเครือข่ายเช่นกระทรวงสาธารณสุขและบริการมนุษย์ของสหรัฐอเมริกา (HHS) หรือสถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) เพื่อความกระชับบทความนี้จะศึกษาเฉพาะเอกสารที่นำมาใช้มากที่สุดสามฉบับเท่านั้น:
- พื้นที่ พระราชบัญญัติการประกันสุขภาพแบบพกพาและความรับผิดชอบ (ฮิปป้า)
- ของ NIST แนวทาง SP 800-52r2
- พื้นที่ มาตรฐานความปลอดภัยของข้อมูลอุตสาหกรรมบัตรชำระเงิน (PCI-DSS)
HIPAA
HIPAA เป็นกฎหมายที่ออกโดยรัฐบาลสหรัฐอเมริกาในปี 1996 เกี่ยวกับการจัดการอย่างปลอดภัย ข้อมูลด้านสุขภาพที่ได้รับการคุ้มครอง (PHI). PHI หมายถึงข้อมูลผู้ป่วยดิจิทัลใด ๆ เช่นผลการทดสอบหรือการวินิจฉัย HIPAA เอกสารแนะนำ เผยแพร่ในปี 2013 ระบุดังต่อไปนี้:
กระบวนการเข้ารหัสที่ถูกต้องสำหรับข้อมูลที่กำลังเคลื่อนที่คือกระบวนการที่สอดคล้องกับความเหมาะสมกับ NIST Special Publications 800-52 แนวทางการเลือกและการใช้ Transport Layer Security (TLS) การดำเนินการ; 800-77, คำแนะนำเกี่ยวกับ IPsec VPNs; หรือ 800-113, คำแนะนำเกี่ยวกับ SSL VPNs หรืออื่น ๆ ที่ได้รับการตรวจสอบมาตรฐาน Federal Information Processing Standards (FIPS) 140-2
มาตรฐาน NIST
ในปี 2005 NIST ตีพิมพ์ Special Publication (SP) 800-52 โดยอธิบายขั้นตอนการปฏิบัติงานที่ถูกต้องเพื่อกำหนดค่าอย่างปลอดภัย TLS อินสแตนซ์สำหรับเซิร์ฟเวอร์ของรัฐบาล SP 800-52 ถูกแทนที่ด้วยเวอร์ชัน SP 800-52r1 (2014) และ SP 80052r2 (2019) บทความนี้เป็นไปตามแนวทางของ SP 800-52r2 ซึ่งปัจจุบันมีความเสถียร
PCI-DSS
PCI-DSS เป็นมาตรฐานการปฏิบัติตามซึ่งจัดทำโดยสภาความปลอดภัยมาตรฐานอุตสาหกรรมบัตรชำระเงิน (PCI) ซึ่งกำหนดวิธีการจัดการข้อมูลการชำระเงินและบัตรโดยเว็บไซต์อีคอมเมิร์ซ เกี่ยวกับการกำหนดค่าที่เหมาะสมของ TLS อินสแตนซ์สถานะ PCI-DSS:
"อ้างถึงมาตรฐานอุตสาหกรรมและแนวทางปฏิบัติที่ดีที่สุดสำหรับข้อมูลเกี่ยวกับการเข้ารหัสที่แข็งแกร่งและโปรโตคอลที่ปลอดภัย (เช่น NIST SP 800-52 และ SP 800-57, OWASP เป็นต้น)"
TLS มาตรฐาน: รวบรวมทั้งหมดเข้าด้วยกัน
ตอนนี้ควรสังเกตว่าแต่ละมาตรฐานมีผลต่อระบบที่แตกต่างกันโดยขึ้นอยู่กับหน้าที่และข้อมูลที่จัดการ ตัวอย่างเช่นเซิร์ฟเวอร์อีเมลของโรงพยาบาลอาจอยู่ภายใต้หลักเกณฑ์ของ HIPAA เนื่องจากข้อความที่แลกเปลี่ยนอาจมีข้อมูลผู้ป่วยในขณะที่ระบบ CRM ของโรงพยาบาลอาจอยู่ภายใต้ PCI-DSS เนื่องจากอาจมีข้อมูลบัตรเครดิตและข้อมูลลูกค้าอื่น ๆ การปฏิบัติตามมาตรฐานทั้งสามจะต้องใช้ร่วมกัน TLS พารามิเตอร์ที่มีอยู่ในเอกสารทั้งหมด
โชคดีที่เห็นได้ชัดว่ามาตรฐานทั้งหมดเป็นไปตามแนวทางของ NIST ในการคัดเลือก TLS พารามิเตอร์ ซึ่งหมายความว่าในขณะที่เขียนนี้การเข้ากันได้กับ SP 800-52r2 ควรทำให้เซิร์ฟเวอร์สอดคล้องกับ HIPAA และ PCI-DSS เช่นกัน (โอเคนี่ไม่ใช่ เผง จริง แต่สิ่งต่าง ๆ จะชัดเจนขึ้นในหัวข้อถัดไป)
ที่กำหนด TLS พารามิเตอร์
ระดับความปลอดภัยนั้น TLS ได้รับผลกระทบมากที่สุดจาก รุ่นโปรโตคอล (เช่น 1.0, 1.1, ฯลฯ ) และที่ได้รับอนุญาต ชุดรหัส. Ciphers เป็นอัลกอริทึมที่ทำการเข้ารหัสและถอดรหัส อย่างไรก็ตาม ชุดรหัส เป็นชุดของอัลกอริทึมรวมถึงรหัสอัลกอริทึมการแลกเปลี่ยนคีย์และอัลกอริทึมการแปลงแป้นพิมพ์ซึ่งใช้ร่วมกันเพื่อสร้างความปลอดภัย TLS สัมพันธ์ มากที่สุด TLS ไคลเอนต์และเซิร์ฟเวอร์รองรับหลายทางเลือกดังนั้นพวกเขาจะต้องเจรจาเมื่อสร้างการเชื่อมต่อที่ปลอดภัยเพื่อเลือกทั่วไป TLS รุ่นและชุดรหัส
TLS รุ่นโปรโตคอล
เกี่ยวกับ TLS การรองรับเวอร์ชัน NIST SP 800-52r2 ระบุสิ่งต่อไปนี้:
เซิร์ฟเวอร์ที่รองรับแอปพลิเคชันของรัฐบาลเท่านั้น จะต้อง ได้รับการกำหนดค่าให้ใช้ TLS 1.2 และ น่า ได้รับการกำหนดค่าให้ใช้ TLS 1.3 เช่นกัน. เซิร์ฟเวอร์เหล่านี้ ไม่ควร ได้รับการกำหนดค่าให้ใช้ TLS 1.1 และ จะไม่ ใช้ TLS 1.0, SSL 3.0 หรือ SSL 2.0
...
เซิร์ฟเวอร์ที่รองรับแอพพลิเคชั่นสำหรับพลเมืองหรือธุรกิจ (กล่าวคือไคลเอนต์ต้องไม่เป็นส่วนหนึ่งของระบบไอทีของรัฐบาล) จะต้อง ได้รับการกำหนดค่าให้เจรจา TLS 1.2 และ น่า ได้รับการกำหนดค่าให้เจรจา TLS 1.3. การใช้ TLS โดยทั่วไปไม่สนับสนุนเวอร์ชัน 1.1 และ 1.0 แต่เวอร์ชันเหล่านี้อาจได้รับการกำหนดค่าเมื่อจำเป็นเพื่อเปิดใช้งานการโต้ตอบกับพลเมืองและธุรกิจ ... เซิร์ฟเวอร์เหล่านี้ จะไม่ อนุญาตให้ใช้ SSL 2.0 หรือ SSL 3.0
หน่วยงาน จะต้อง สนับสนุน TLS 1.3 ภายในวันที่ 1 มกราคม 2024 หลังจากวันดังกล่าวเซิร์ฟเวอร์ จะต้อง สนับสนุน TLS 1.3 สำหรับแอปพลิเคชันทั้งภาครัฐและพลเมืองหรือธุรกิจ โดยทั่วไปเซิร์ฟเวอร์ที่รองรับ TLS 1.3 น่า ได้รับการกำหนดค่าให้ใช้ TLS 1.2 เช่นกัน. อย่างไรก็ตาม TLS 1.2 อาจถูกปิดใช้งานบนเซิร์ฟเวอร์ที่รองรับ TLS 1.3 หากมีการพิจารณาว่า TLS 1.2 ไม่จำเป็นสำหรับการทำงานร่วมกัน
ในขณะที่ TLS 1.0 เป็นสิ่งต้องห้ามและ TLS 1.1 ถูกคัดค้านสำหรับไซต์รัฐบาลแนวทาง NIST ระบุว่าสำหรับความเข้ากันได้กับบริการของบุคคลที่สามเซิร์ฟเวอร์ที่ควบคุมโดยรัฐบาล อาจ การดำเนินการ TLS 1.0 และ 1.1 เมื่อจำเป็น ภายใต้ PCI-DSS 3.2.1 (เวอร์ชันปัจจุบัน) เซิร์ฟเวอร์ที่รองรับ จะต้องวางการสนับสนุน for TLS 1.0 และ“ ย้ายข้อมูลให้น้อยที่สุด TLS 1.1 โดยเฉพาะอย่างยิ่ง TLS 1.2.” HIPAA ในทางเทคนิคอนุญาตให้ใช้ไฟล์ TLS. ดังนั้นขั้นต่ำที่รองรับโดยทั่วไป TLS เวอร์ชัน 1.1; อย่างไรก็ตาม PCI-DSS และ NIST ขอแนะนำให้ใช้ระบบที่ปลอดภัยยิ่งขึ้น TLS 1.2 (และตามที่แสดงไว้ด้านบน NIST แนะนำให้ใช้ TLS 1.3 และมีแผนที่จะต้องการการสนับสนุนภายในปี 2024)
ไซเฟอร์ สวีท
TLS 1.2 และก่อนหน้านี้
SP 800-52r2 ระบุชุดการเข้ารหัสที่ยอมรับได้สำหรับ TLS 1.2 ขึ้นไป มาตรฐานนี้ไม่ต้องการการสนับสนุนสำหรับชุดการเข้ารหัสใด ๆ แต่มีคำแนะนำในการเลือกชุดการเข้ารหัสที่แข็งแกร่งกว่า:
- ชอบคีย์ชั่วคราวมากกว่าคีย์แบบคงที่ (เช่นชอบ DHE มากกว่า DH และชอบ ECDHE มากกว่า ECDH) คีย์ชั่วคราวให้ความลับไปข้างหน้าอย่างสมบูรณ์แบบ
- ชอบโหมด GCM หรือ CCM มากกว่าโหมด CBC การใช้โหมดการเข้ารหัสที่พิสูจน์ตัวตนจะป้องกันการโจมตีหลายครั้ง (ดูหัวข้อ 3.3.2 [ของ SP 800-52r2] สำหรับข้อมูลเพิ่มเติม) โปรดทราบว่าสิ่งเหล่านี้ไม่มีในเวอร์ชันก่อนหน้านี้ TLS 1.2.
- ชอบ CCM มากกว่า CCM_8 ส่วนหลังมีแท็กการพิสูจน์ตัวตนที่สั้นกว่าซึ่งให้ความแข็งแกร่งในการพิสูจน์ตัวตนต่ำ
นอกจากนี้แม้ว่าจะเป็นไฟล์ ที่ได้รับอนุญาต ชุดรหัสถ้าคุณ TLS เซิร์ฟเวอร์ไม่ได้จัดการกับแพลตฟอร์มและไคลเอนต์ที่แตกต่างกันจำนวนมากขอแนะนำให้ใช้อัลกอริทึมเหล่านี้เพียงเล็กน้อยเท่านั้น การอนุญาตชุดรหัสเพิ่มเติมสามารถขยายพื้นผิวการโจมตีไปยังเซิร์ฟเวอร์ของคุณหาก (หรือเมื่อ) พบช่องโหว่ของโปรโตคอลใหม่
Cipher Suites สำหรับใบรับรอง ECDSA | ||
---|---|---|
TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x2B |
ECDHE-ECDSA-AES128-GCM-SHA256 |
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x2C |
ECDHE-ECDSA-AES256-GCM-SHA384 |
TLS_ECDHE_ECDSA_WITH_AES_128_CCM |
0xC0, 0xAC |
ECDHE-ECDSA-AES128-CCM |
TLS_ECDHE_ECDSA_WITH_AES_256_CCM |
0xC0, 0xAD |
ECDHE-ECDSA-AES256-CCM |
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 |
0xC0, 0xAE |
ECDHE-ECDSA-AES128-CCM8 |
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 |
0xC0, 0xAF |
ECDHE-ECDSA-AES256-CCM8 |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x23 |
ECDHE-ECDSA-AES128-SHA256 |
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x24 |
ECDHE-ECDSA-AES256-SHA384 |
TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
0xC0, 0x09 |
ECDHE-ECDSA-AES128-SHA |
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
0xC0, 0x0A |
ECDHE-ECDSA-AES256-SHA |
Cipher Suites สำหรับใบรับรอง RSA | ||
TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x2F |
ECDHE-RSA-AES128-GCM-SHA256 |
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x30 |
ECDHE-RSA-AES256-GCM-SHA384 |
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
0x00, 0x9E |
DHE-RSA-AES128-GCM-SHA256 |
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
0x00, 0x9F |
DHE-RSA-AES256-GCM-SHA384 |
TLS_DHE_RSA_WITH_AES_128_CCM |
0xC0, 0x9E |
DHE-RSA-AES128-CCM |
TLS_DHE_RSA_WITH_AES_256_CCM |
0xC0, 0x9F |
DHE-RSA-AES256-CCM |
TLS_DHE_RSA_WITH_AES_128_CCM_8 |
0xC0, 0xA2 |
DHE-RSA-AES128-CCM8 |
TLS_DHE_RSA_WITH_AES_256_CCM_8 |
0xC0, 0xA3 |
DHE-RSA-AES256-CCM8 |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x27 |
ECDHE-RSA-AES128-SHA256 |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x28 |
ECDHE-RSA-AES256-SHA384 |
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 |
0x00, 0x67 |
DHE-RSA-AES128-SHA256 |
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
0x00, 0x6B |
DHE-RSA-AES256-SHA256 |
TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
0xC0, 0x13 |
ECDHE-RSA-AES128-SHA |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
0xC0, 0x14 |
ECDHE-RSA-AES256-SHA |
TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
0x00, 0x33 |
DHE-RSA-AES128-SHA |
TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
0x00, 0x39 |
DHE-RSA-AES256-SHA |
Cipher Suites สำหรับใบรับรอง ECDSA | ||
TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 |
0x00, 0xA2 |
DHE-DSS-AES128-GCM-SHA256 |
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 |
0x00, 0xA3 |
DHE-DSS-AES256-GCM-SHA384 |
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
0x00, 0x40 |
DHE-DSS-AES128-SHA256 |
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
0x00, 0x6A |
DHE-DSS-AES256-SHA256 |
TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
0x00, 0x32 |
DHE-DSS-AES128-SHA |
TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
0x00, 0x38 |
DHE-DSS-AES256-SHA |
Cipher Suites สำหรับใบรับรอง DH | ||
ลงนาม DSA TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_DH_DSS_WITH_AES_128_GCM_SHA256 |
0x00, 0xA4 |
DH-DSS-AES128-GCM-SHA256 |
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 |
0x00, 0xA5 |
DH-DSS-AES256-GCM-SHA384 |
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 |
0x00, 0x3E |
DH-DSS-AES128-SHA256 |
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 |
0x00, 0x68 |
DH-DSS-AES256-SHA256 |
ลงนาม DSA TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_DH_DSS_WITH_AES_128_CBC_SHA |
0x00, 0x30 |
DH-DSS-AES128-SHA |
TLS_DH_DSS_WITH_AES_256_CBC_SHA |
0x00, 0x36 |
DH-DSS-AES256-SHA |
ลงนาม RSA TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 |
0x00, 0xA0 |
DH-RSA-AES128-GCM-SHA256 |
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 |
0x00, 0xA1 |
DH-RSA-AES256-GCM-SHA384 |
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 |
0x00, 0x3F |
DH-RSA-AES128-SHA256 |
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 |
0x00, 0x69 |
DH-RSA-AES256-SHA256 |
ลงนาม RSA TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_DH_RSA_WITH_AES_128_CBC_SHA |
0x00, 0x31 |
DH-RSA-AES128-SHA |
TLS_DH_RSA_WITH_AES_256_CBC_SHA |
0x00, 0x37 |
DH-RSA-AES256-SHA |
Cipher Suites สำหรับใบรับรอง ECDH | ||
ลงนาม ECDSA TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x2D |
ECDH-ECDSA-AES128-GCM-SHA256 |
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x2E |
ECDH-ECDSA-AES256-GCM-SHA384 |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x25 |
ECDH-ECDSA-AES128-SHA256 |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x26 |
ECDH-ECDSA-AES256-SHA384 |
ลงนาม ECDSA TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
0xC0, 0x04 |
ECDH-ECDSA-AES128-SHA |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
0xC0, 0x05 |
ECDH-ECDSA-AES256-SHA |
ลงนาม RSA TLS 1.2: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x31 |
ECDH-RSA-AES128-GCM-SHA256 |
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x32 |
ECDH-RSA-AES256-GCM-SHA384 |
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x29 |
ECDH-RSA-AES128-SHA256 |
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x2A |
ECDH-RSA-AES256-SHA384 |
ลงนาม RSA TLS 1.2, 1.1 หรือ 1.0: | ||
IANA | ความคุ้มค่า | OpenSSL |
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
0xC0, 0x0E |
ECDH-RSA-AES128-SHA |
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
0xC0, 0x0F |
ECDH-RSA-AES256-SHA |
TLS 1.3
TLS 1.3 มีรายการชุดการเข้ารหัสที่สั้นกว่ามาก:
TLS_AES_128_GCM_SHA256 (0x13, 0x01)
TLS_AES_256_GCM_SHA384 (0x13, 0x02)
TLS_AES_128_CCM_SHA256 (0x13, 0x04)
TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)
สรุป
เราหวังว่าคู่มือฉบับย่อนี้จะช่วยให้คุณเข้าใจเพิ่มเติมเกี่ยวกับ TLSและช่วยเหลือคุณเมื่อกำหนดค่า TLS บนเซิร์ฟเวอร์ของคุณเอง ในส่วนที่เกี่ยวกับมาตรฐานและคำแนะนำที่เราได้กล่าวถึงส่วนต่อไปนี้มีตัวอย่างการกำหนดค่าที่คุณควรจะสามารถนำไปใช้กับโซลูชันเว็บเซิร์ฟเวอร์ที่เป็นที่นิยม หากคุณมีคำถามใด ๆ เกี่ยวกับวิธีรักษาการปฏิบัติตามข้อกำหนดทางออนไลน์โปรดติดต่อเราทางอีเมล Support@SSL.com หรือคลิกปุ่มแชทสดที่ด้านล่างของหน้าจอนี้
ภาคผนวก: ตัวอย่าง TLS การกำหนดค่า
การรวบรวมกฎที่ระบุในเอกสารข้อกำหนดสามชุดเซิร์ฟเวอร์ที่ปลอดภัยทันสมัยควรนำไปใช้ TLS 1.2 และ / หรือ TLS 1.3 พร้อมรายการชุดการเข้ารหัสที่เลือกสั้น ๆ แต่มีความหลากหลาย เพื่อเป็นข้อมูลอ้างอิงโดยย่อตัวอย่างการกำหนดค่าสำหรับเว็บเซิร์ฟเวอร์ที่เป็นที่นิยมมากที่สุดในตลาดจะแสดงอยู่ด้านล่าง นี่คือการกำหนดค่า "ระดับกลาง" (วัตถุประสงค์ทั่วไป) ที่สร้างขึ้นด้วย Mozilla เครื่องมือสร้างการกำหนดค่า SSL:
เซิร์ฟเวอร์ Apache HTTP
... SSLProtocol ทั้งหมด -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384CD: POLY20: ECDHE-RSA-CHACHA1305-POLY20: DHE-RSA-AES1305-GCM-SHA128: DHE-RSA-AES256-GCM-SHA256 SSLHonorCipherOrder ปิด SSLSessionTickets off
Nginx
... ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off;
lighttpd
... ssl.openssl.ssl-conf-cmd = ("โปรโตคอล" => "ทั้งหมด, -SSLv2, -SSLv3, -TLSเวอร์ชัน 1, -TLSv1.1 ") ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-cipher-order =" disabled "
HAProxy
... ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ตัวเลือกเซิร์ฟเวอร์เริ่มต้น ssl ไม่มี sslv3 ไม่มี tlsv10 ไม่มี tlsv11 ไม่มี tls-tickets
AWS ELB
... นโยบาย: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType แอตทริบิวต์: - ชื่อ: โปรโตคอล -TLSv1.2 Value: true - Name: Server-Defined-Cipher-Order Value: false - Name: ECDHE-ECDSA-AES128-GCM-SHA256 Value: true - Name: ECDHE-RSA-AES128-GCM-SHA256 Value: true - ชื่อ: ECDHE-ECDSA-AES256-GCM-SHA384 ค่า: จริง - ชื่อ: ECDHE-RSA-AES256-GCM-SHA384 ค่า: จริง - ชื่อ: DHE-RSA-AES128-GCM-SHA256 ค่า: จริง - ชื่อ: DHE-RSA -AES256-GCM-SHA384 ค่า: จริง