บทนำ
โฮสติ้งเสมือนจริง เป็นการฝึกให้บริการหลายเว็บไซต์ใน เซิร์ฟเวอร์เดียวกัน. แม้ว่าจะเป็นบรรทัดฐานในปัจจุบัน แต่ก็เป็นไปไม่ได้ในยุคแรก ๆ ของ HTTP (เวอร์ชันก่อนหน้า 1.1)
ในขั้นต้นเซิร์ฟเวอร์สามารถโฮสต์เว็บไซต์ได้หลายเว็บไซต์ในเครื่องเดียวกัน (เช่นภายใต้ที่อยู่ IP เดียวกัน) โดยที่แต่ละเว็บไซต์จะได้รับมอบหมายพอร์ตเฉพาะ นี่ไม่ใช่ทางออกที่ดีเพราะเบราว์เซอร์เริ่มต้นที่พอร์ต 80 สำหรับ HTTP ยกเว้นว่าผู้ใช้ระบุคนอื่น ดังนั้นเจ้าของเว็บไซต์ส่วนใหญ่เลือกใช้เซิร์ฟเวอร์เฉพาะเพื่อหลีกเลี่ยงความเสี่ยงของผู้ใช้ที่ไม่จดจำหมายเลขพอร์ตที่ถูกต้องและสิ้นสุดในเว็บไซต์อื่น
อย่างไรก็ตามเมื่อผู้ใช้เข้าร่วมกับเว็บมากขึ้นและอุปกรณ์เครือข่ายเริ่มปรากฏขึ้นออนไลน์จำนวนที่อยู่ IP ที่พร้อมใช้งานเริ่มลดลงในอัตราที่น่าตกใจ การลดลงนี้คาดว่าจะเรียกว่า การหมดช่วงของที่อยู่ IPv4ได้ผลักดันอุตสาหกรรมให้ออกแบบและใช้มาตรการตอบโต้ต่างๆเช่น IPv6 (ตัวตายตัวแทนของ IPv4) ซึ่งสามารถรองรับ ที่อยู่มากกว่าที่เราต้องการ. น่าเสียดายที่แม้ว่า IPv6 เป็นโซลูชั่นที่ใช้งานได้ แต่การยอมรับก็ค่อนข้างช้า ตามที่ สถิติ IPv6 ของ Googleในขณะที่เขียนนี้มีเพียง 25% ของอุปกรณ์อินเทอร์เน็ตที่ใช้งานผ่าน IPv6
โฮสติ้งเสมือนจริงนั้นได้ถูกนำมาใช้เพื่อลดปัญหาความอ่อนเพลียในช่วงแรกด้วยการเปิดตัว Host ส่วนหัวใน HTTP 1.1 ขณะนี้เบราว์เซอร์ที่สื่อสารผ่าน HTTP 1.1 สามารถเชื่อมต่อกับพอร์ตของเซิร์ฟเวอร์ได้แล้ว 80 และรวมถึงชื่อโดเมน (เช่น www.ssl.com) ของเว็บไซต์ที่พวกเขาต้องการเยี่ยมชมใน Host หัวข้อ. ไม่ว่าไซต์จะโฮสต์เซิร์ฟเวอร์บนพอร์ตเดียวกันจำนวนเท่าใดก็สามารถใช้ข้อมูลนี้เพื่อระบุเว็บไซต์ที่ถูกต้องและส่งคืนเนื้อหา
HTTPS และโฮสติ้งเสมือนจริง
รายงานที่เผยแพร่จำนวนมากเกี่ยวกับช่องโหว่ของเครือข่ายและการโจมตีผู้ใช้เว็บได้สร้างแรงบันดาลใจให้อุตสาหกรรม เริ่มย้ายออกจาก HTTP ที่ไม่ปลอดภัยไปยัง HTTPS ทางเลือกที่ปลอดภัยยิ่งขึ้น. การยอมรับอย่างกว้างขวางของ HTTPS ได้ปรับปรุงความปลอดภัยของผู้ใช้โดยรวม อย่างไรก็ตามการปรับปรุงเพิ่มเติมได้เพิ่มความซับซ้อนโดยทั่วไปของการสื่อสารทางเว็บ
โดยหลักการแล้ว HTTPS ค่อนข้างคล้ายกับ HTTP ยกเว้นว่าการสื่อสาร HTTPS ระหว่างเบราว์เซอร์และเซิร์ฟเวอร์จะถูกเข้ารหัส กล่าวโดยย่อ HTTPS ต้องการเซิร์ฟเวอร์เพื่อให้เบราว์เซอร์มีใบรับรอง SSL ที่ถูกต้องซึ่งออกโดยสาธารณชนที่เชื่อถือได้ ผู้ออกใบรับรอง (CA) เช่น SSL.com. เบราว์เซอร์สามารถใช้คีย์สาธารณะที่มีอยู่ในใบรับรองเพื่อ สร้างช่องทางการสื่อสารที่เข้ารหัสไว้กับเซิร์ฟเวอร์. นอกจากนี้ยังมีการออกใบรับรองสำหรับชื่อโดเมนเฉพาะซึ่งเบราว์เซอร์จะตรวจสอบว่าตรงกับโดเมนที่ผู้ใช้ต้องการเข้าชม ดังนั้นไม่ว่าเซิร์ฟเวอร์จะโฮสต์เว็บไซต์จำนวนเท่าใดเบราว์เซอร์ก็คาดหวังว่าจะพบใบรับรอง SSL ที่ถูกต้องสำหรับเว็บไซต์ที่พวกเขาร้องขอ
ผู้อ่านที่เอาใจใส่อาจรู้สึกถึงปัญหาแล้ว: เบราว์เซอร์ต้องการใบรับรองของเว็บไซต์ที่ถูกต้องเพื่อสร้างช่องทางเข้ารหัสและส่ง Host ส่วนหัวในขณะที่เซิร์ฟเวอร์ต้องการ Host ส่วนหัวเพื่อค้นหาใบรับรองของไซต์ที่ถูกต้อง นี่คือปัญหาไก่กับไข่แบบคลาสสิก
เห็นได้ชัดว่าโฮสติ้งเสมือนจริงที่ถูกสร้างขึ้นสำหรับ HTTP ไม่ทำงานกับ HTTPS เนื่องจากการควบคุมความปลอดภัยป้องกันเบราว์เซอร์ไม่ให้ส่ง Host ข้อมูลไปยังเซิร์ฟเวอร์ อย่างไรก็ตามด้วยปัญหาความเหนื่อยล้าของ IPv4 ยังคงไม่ได้รับการแก้ไขและการใช้เทคโนโลยีคลาวด์ที่เพิ่มขึ้นเรื่อย ๆ ในอุตสาหกรรม (ซึ่งต้องใช้การปรับสมดุลโหลดและเซิร์ฟเวอร์แบ็กเอนด์ที่ล้มเหลวหลายครั้ง) โฮสติ้งเสมือนยังคงเป็นสิ่งจำเป็น
สิ่งที่เกี่ยวกับใบรับรองหลายโดเมน
วิธีแก้ปัญหาที่เสนอมาสำหรับปัญหานี้คือการใช้หลายโดเมนหรือ ใบรับรอง SAN. ใบรับรอง SAN ใบเดียวสามารถรักษาความปลอดภัยของชื่อโดเมนต่างๆได้หลายร้อยชื่อและเบราว์เซอร์จะไม่บ่นหากพบชื่อโดเมนที่พวกเขาพยายามเยี่ยมชมภายในรายการโดเมนของใบรับรอง SAN หลังจากกำหนดค่าช่องสัญญาณที่เข้ารหัสแล้วเบราว์เซอร์จะสามารถส่งไฟล์ Host ส่วนหัวไปยังเซิร์ฟเวอร์และดำเนินการต่อเหมือนในกรณีอื่น ๆ นี่เป็นแนวคิดที่ยอดเยี่ยมที่ใช้เทคโนโลยีที่มีอยู่แล้วและพร้อมใช้งาน แต่กลไกเดียวกันที่รับรองความปลอดภัยของใบรับรอง SAN ได้นำเสนอผลข้างเคียงที่อาจไม่พึงปรารถนาบางประการ:
ใบรับรอง SAN เป็นเครื่องมือที่ดีสำหรับการรักษาความปลอดภัยหลายโดเมนที่เป็นเจ้าของโดยเอนทิตีเดียวกัน (บุคคล บริษัท หรือองค์กร) แต่พวกเขาค่อนข้างจะทำไม่ได้ที่จะใช้ในพื้นที่สาธารณะที่ใช้ร่วมกัน; เมื่อใดก็ตามที่โดเมนใหม่พร้อมที่จะเพิ่มหรือลบออกจากใบรับรองใบรับรองใหม่ที่มีรายชื่อโดเมนล่าสุดจะต้องออกโดย CA และปรับใช้ใหม่ในโดเมนทั้งหมด
นอกจากนี้ใบรับรอง SAN สามารถออกได้เป็นเท่านั้น ตรวจสอบองค์กร (OV) หรือ Extended Validated (EV) if ทั้งหมด โดเมนอยู่ในองค์กรเดียวกัน ระดับการตรวจสอบความถูกต้องเหล่านี้อ้างถึง จำนวนและประเภทของข้อมูลเจ้าของใบรับรองที่คาดว่าจะได้รับการตรวจสอบโดย CA ก่อนที่จะออกใบรับรอง แสดงให้เห็นว่ายิ่งระดับการตรวจสอบความถูกต้องสูงขึ้นเท่าใดผู้ใช้ที่ไว้วางใจในเว็บไซต์ก็ยิ่งมีความน่าเชื่อถือมากขึ้นเท่านั้น
ในที่สุดมันเป็นเรื่องธรรมดาในสภาพแวดล้อมเว็บโฮสติ้งที่ใช้ร่วมกันสำหรับ บริษัท ที่จะแบ่งปันเซิร์ฟเวอร์กับธุรกิจหรือองค์กรอื่น ๆ (แม้จะมีคู่แข่ง) เนื่องจากโดเมนในใบรับรอง SAN แสดงต่อสาธารณะเจ้าของธุรกิจอาจลังเลที่จะแบ่งปันใบรับรองเดียวกันกับ บริษัท บุคคลที่สาม
แม้ว่าใบรับรอง SAN จะเป็นเครื่องมือที่มีประสิทธิภาพและหลากหลายพร้อมกับแอปพลิเคชันมากมาย แต่ปัญหาเหล่านี้ได้กระตุ้นให้ IETF ซึ่งเป็นหน่วยงานกำกับดูแลมาตรฐานอินเทอร์เน็ตค้นหาแนวทางที่เหมาะสมกับปัญหาเฉพาะของเว็บไซต์ HTTPS ที่โฮสต์แบบเสมือนจริง
ชื่อเซิร์ฟเวอร์บ่งบอกถึงการช่วยเหลือ
การแก้ปัญหาได้ดำเนินการในรูปแบบของ บ่งชี้ชื่อเซิร์ฟเวอร์ (SNI) ส่วนขยายของ TLS โปรโตคอล (ส่วนหนึ่งของ HTTPS ที่เกี่ยวข้องกับการเข้ารหัส)
SNI เปิดใช้งานเบราว์เซอร์เพื่อระบุชื่อโดเมนที่พวกเขาต้องการเชื่อมต่อระหว่าง TLS การจับมือกัน (การเจรจาใบรับรองเริ่มต้นกับเซิร์ฟเวอร์) ด้วยเหตุนี้เว็บไซต์จึงสามารถใช้ใบรับรอง SSL ของตนเองได้ในขณะที่ยังโฮสต์อยู่บนที่อยู่ IP และพอร์ตที่ใช้ร่วมกันเนื่องจากเซิร์ฟเวอร์ HTTPS สามารถใช้ข้อมูล SNI เพื่อระบุห่วงโซ่ใบรับรองที่เหมาะสมซึ่งจำเป็นในการสร้างการเชื่อมต่อ
หลังจากนั้นเมื่อมีการกำหนดค่าช่องทางการสื่อสารที่เข้ารหัสเบราว์เซอร์สามารถดำเนินการเพื่อรวมชื่อโดเมนของเว็บไซต์ใน Host ส่วนหัวและดำเนินการต่อตามปกติ โดยพื้นฐานแล้ว SNI จะทำหน้าที่เช่นเดียวกับ HTTP Host ส่วนหัวในระหว่างการสร้างการเชื่อมต่อที่เข้ารหัส
ในที่สุดเคล็ดลับง่ายๆนี้อนุญาตให้เซิร์ฟเวอร์โฮสต์เว็บไซต์ HTTPS หลายแห่งบนพอร์ตเดียวกัน อย่างไรก็ตามเช่นเดียวกับเทคโนโลยีอินเทอร์เน็ตส่วนใหญ่ SNI มีข้อ จำกัด บางประการ
ข้อกังวลเกี่ยวกับการสนับสนุน SNI
แม้ว่า SNI จะค่อนข้างครบวงจรนับตั้งแต่มีการร่างครั้งแรกในปี 1999 แต่ก็ยังมีเบราว์เซอร์เดิม (IE บน Windows XP) และระบบปฏิบัติการ (เวอร์ชัน Android <= 2.3) ที่ไม่รองรับ สำหรับรายการเบราว์เซอร์และระบบปฏิบัติการทั้งหมดที่รองรับ SNI โปรดดูที่ ตารางนี้.
แม้ว่าส่วนแบ่งการตลาดของเบราว์เซอร์ที่ไม่รองรับ SNI (และโดยการขยายการเกิดเหตุการณ์นี้) จะมีขนาดเล็กเมื่อเทียบกับเบราว์เซอร์สมัยใหม่หากเบราว์เซอร์ไม่รู้จัก SNI จะกลับไปใช้ใบรับรอง SSL เริ่มต้นและอาจสร้าง ข้อผิดพลาดชื่อสามัญไม่ตรงกัน.
บริษัท หลายแห่งเช่น Google ใช้ SNI สำหรับลูกค้าที่สนับสนุนและถอยกลับไปใช้ใบรับรอง SAN สำหรับกรณีที่ไม่ค่อยเกิดขึ้น ตามธรรมชาติแล้วปัญหานี้คาดว่าจะลดน้อยลงเนื่องจากผู้ใช้และเจ้าของธุรกิจเพิ่มมากขึ้นเพื่ออัพเกรดระบบเป็นเทคโนโลยีที่ทันสมัย
ข้อกังวลเกี่ยวกับความเป็นส่วนตัวของ SNI
รุ่นที่เสถียรในปัจจุบันของ TLS (เวอร์ชัน 1.2) ส่งส่วนเริ่มต้นของการจับมือและโดยข้อมูล SNI ส่วนขยายไม่ได้เข้ารหัส ดังนั้นผู้โจมตีเครือข่ายสามารถค้นพบประวัติเว็บของผู้ใช้ได้แม้ว่าการสื่อสารทางเว็บจะเข้ารหัสอย่างสมบูรณ์ก็ตาม
ผู้ให้บริการคลาวด์หลายรายเช่น Amazon หรือ Google ได้อนุญาตให้มีวิธีแก้ปัญหา (สกปรก) ที่รู้จักกันในชื่อ การจดโดเมน. การบังหน้าโดเมนสามารถป้องกันการเปิดเผยประวัติเว็บได้เนื่องจากข้อมูล SNI ทำให้ข้อมูลยุ่งเหยิงโดยใช้ชื่อโฮสต์ของผู้ให้บริการคลาวด์ใน TLS การเจรจาและไซต์เป้าหมายอยู่ในส่วนหัว HTTP อย่างไรก็ตามวิธีนี้ใช้ไม่ได้อีกต่อไปเนื่องจาก Google และ Amazon ได้แจ้งต่อสาธารณะว่าพวกเขา ปิดการใช้งานการรองรับการจดโดเมน ในการให้บริการของพวกเขา ณ เดือนเมษายน 2018
โชคดีที่มีการเสนอโซลูชันที่เป็นระบบมากขึ้นเป็นไฟล์ ร่างทดลอง รายละเอียด เข้ารหัส SNI (เอสนี่) ส่วนขยายใหม่ล่าสุด TLS เวอร์ชั่น 1.3 ESNI เข้ารหัสข้อมูล SNI ดังนั้นจึงช่วยลดข้อกังวลด้านความเป็นส่วนตัวทั้งหมด น่าเสียดาย, TLS 1.3 ยังไม่ได้รับการยอมรับอย่างกว้างขวางในอุตสาหกรรมแม้ว่า TLS 1.3 กำลังกลายเป็นโปรโตคอลความปลอดภัยเครือข่ายอย่างช้าๆ. จับตาดูบทความในอนาคตจากเราเกี่ยวกับสถานะของ ESNI และความเป็นส่วนตัวของ HTTPS และ TLS.
สรุป
โดยสรุปด้วย SNI คุณสามารถโฮสต์เว็บไซต์ HTTPS นับล้านบนเซิร์ฟเวอร์เดียว อย่างไรก็ตามขึ้นอยู่กับแต่ละกรณีใบรับรอง SAN อาจทำงานได้ดีขึ้นสำหรับคุณ ความกังวลเกี่ยวกับความเป็นส่วนตัวเกี่ยวกับ SNI ยังคงมีอยู่แม้ว่าจะมีโซลูชันที่อาจเกิดขึ้นกับ ESNI ไม่ว่าในกรณีใดการใช้หนึ่งหรือการรวมกันของสองวิธีนี้คุณสามารถใช้โฮสติ้งเสมือนจริงสำหรับเว็บไซต์ทั้งหมดของคุณได้อย่างง่ายดาย
หากคุณมีคำถามเพิ่มเติมเกี่ยวกับ SNI หรือไม่ทราบว่าจะเลือกอย่างไรระหว่าง SAN กับ SNI เรายินดีที่จะตอบคำถามทั้งหมดของลูกค้าเกี่ยวกับพวกเขา PKI จำเป็น เพียงแค่ส่งอีเมลถึงเราที่ support@ssl.com และผู้เชี่ยวชาญจะช่วยคุณ
