การระบุชื่อเซิร์ฟเวอร์ ( SNI ) เป็นส่วนขยายของTransport Layer Security (TLS) ซึ่งไคลเอ็นต์จะระบุชื่อโฮสต์ที่พยายามเชื่อมต่อในตอนเริ่มต้นของกระบวนการจับมือ^{[ 1 ]}ส่วนขยายนี้อนุญาตให้เซิร์ฟเวอร์นำเสนอใบรับรอง ที่เป็นไปได้หลายใบใน ที่อยู่ IPและหมายเลขพอร์ตเดียวกัน ทำให้สามารถให้ บริการหลาย บริการ (รวมถึง เว็บไซต์ HTTPS ) โดยใช้ที่อยู่ IP เดียวกันได้โดยไม่ต้องใช้ใบรับรองเดียว สำหรับ HTTPS นั้น ถือเป็นแนวคิดที่เทียบเท่ากับการโฮสต์เสมือน ของ HTTP/1.1 ในข้อกำหนดดั้งเดิม ชื่อโฮสต์ไม่ได้ถูกเข้ารหัส ข้อกำหนด Encrypted Client Hello ในภายหลัง ได้แก้ไขปัญหานี้ ส่วนขยาย SNI ได้รับการกำหนดไว้ในปี 2003 ใน RFC  3546

ก่อนที่จะมี SNI เมื่อทำการเชื่อมต่อ TLS ไคลเอนต์ไม่มีวิธีระบุว่ากำลังพยายามเชื่อมต่อกับเว็บไซต์ใด ดังนั้น หากเซิร์ฟเวอร์หนึ่งโฮสต์หลายเว็บไซต์บน Listener เดียวกัน เซิร์ฟเวอร์ก็จะไม่รู้ว่าควรใช้ใบรับรองใดในโปรโตคอล TLS โดยละเอียดแล้ว เมื่อทำการเชื่อมต่อ TLS ไคลเอนต์จะขอใบรับรองดิจิทัลจากเว็บเซิร์ฟเวอร์ เมื่อเซิร์ฟเวอร์ส่งใบรับรองแล้ว ไคลเอนต์จะตรวจสอบและเปรียบเทียบชื่อที่พยายามเชื่อมต่อกับชื่อที่อยู่ในใบรับรอง หากตรงกัน การเชื่อมต่อจะดำเนินต่อไปตามปกติ หากไม่พบการตรงกัน ผู้ใช้อาจได้รับการแจ้งเตือนถึงความไม่ตรงกัน และการเชื่อมต่ออาจถูกยกเลิก เนื่องจากความไม่ตรงกันอาจบ่งชี้ถึงการพยายามโจมตีแบบ Man-in-the-Middle อย่างไรก็ตาม บางแอปพลิเคชันอนุญาตให้ผู้ใช้ข้ามการแจ้งเตือนเพื่อดำเนินการเชื่อมต่อต่อไป โดยผู้ใช้ต้องรับผิดชอบในการเชื่อถือใบรับรองและโดยนัยแล้ว การเชื่อมต่อด้วย

อย่างไรก็ตาม อาจเป็นเรื่องยาก หรืออาจเป็นไปไม่ได้เลย เนื่องจากไม่มีรายชื่อชื่อทั้งหมดล่วงหน้า ที่จะได้รับใบรับรองเดียวที่ครอบคลุมชื่อทั้งหมดที่เซิร์ฟเวอร์จะต้องรับผิดชอบ เซิร์ฟเวอร์ที่รับผิดชอบโฮสต์เนมหลายชื่อ มักจะต้องแสดงใบรับรองที่แตกต่างกันสำหรับแต่ละชื่อ (หรือกลุ่มชื่อเล็กๆ) เป็นไปได้ที่จะใช้subjectAltNameเพื่อรวมโดเมนหลายโดเมนที่ควบคุมโดยบุคคลคนเดียว^{[ 2 ]}ไว้ในใบรับรองเดียว ใบรับรอง "การสื่อสารแบบรวม" ดังกล่าวจะต้องออกใหม่ทุกครั้งที่รายชื่อโดเมนเปลี่ยนแปลง

การโฮสต์เสมือนแบบใช้ชื่อ (Name-based virtual hosting) อนุญาตให้โฮสต์ชื่อโฮสต์ DNS หลายชื่อบนเซิร์ฟเวอร์เดียว (โดยปกติคือเว็บเซิร์ฟเวอร์) บนที่อยู่ IP เดียวกัน เพื่อให้บรรลุเป้าหมายนี้ เซิร์ฟเวอร์จะใช้ชื่อโฮสต์ที่ส่งมาจากไคลเอ็นต์เป็นส่วนหนึ่งของโปรโตคอล (สำหรับ HTTP ชื่อจะอยู่ในส่วนหัวของโฮสต์) อย่างไรก็ตาม เมื่อใช้ HTTPS การเชื่อมต่อ TLS จะเกิดขึ้นก่อนที่เซิร์ฟเวอร์จะเห็นส่วนหัว HTTP ใดๆ ดังนั้น เซิร์ฟเวอร์จึงไม่สามารถใช้ข้อมูลในส่วนหัวของโฮสต์ HTTP เพื่อตัดสินใจว่าจะใช้ใบรับรองใด และด้วยเหตุนี้จึงสามารถให้บริการได้เฉพาะชื่อที่อยู่ภายใต้ใบรับรองเดียวกันจากที่อยู่ IP เดียวกันเท่านั้น

ในทางปฏิบัติ หมายความว่า เซิร์ฟเวอร์ HTTPSสามารถให้บริการได้เพียงโดเมนเดียว (หรือกลุ่มโดเมนเล็กๆ) ต่อที่อยู่ IP หนึ่งตัว เพื่อการท่องเว็บที่ปลอดภัยและมีประสิทธิภาพ การกำหนดที่อยู่ IP แยกต่างหากสำหรับแต่ละเว็บไซต์จะเพิ่มต้นทุนในการโฮสติ้ง เนื่องจากต้องมีการชี้แจงเหตุผลในการขอที่อยู่ IP ต่อหน่วยงานที่ดูแลการลงทะเบียนอินเทอร์เน็ตในระดับภูมิภาค และที่อยู่ IPv4 ก็หมดลงแล้ว สำหรับIPv6นั้น จะเพิ่มภาระงานด้านการบริหารจัดการเนื่องจากมีที่อยู่ IP หลายตัวในเครื่องเดียว แม้ว่าพื้นที่ที่อยู่จะยังไม่หมดก็ตาม ผลที่ตามมาคือ เว็บไซต์จำนวนมากถูกจำกัดไม่ให้ใช้การสื่อสารที่ปลอดภัยอย่างมีประสิทธิภาพ

SNI แก้ไขปัญหานี้โดยให้ไคลเอ็นต์ส่งชื่อโดเมนเสมือนเป็นส่วนหนึ่งของข้อความClientHello ในการเจรจา TLS ^{[ 3 ]}ซึ่งช่วยให้เซิร์ฟเวอร์สามารถเลือกโดเมนเสมือนที่ถูกต้องได้ตั้งแต่เนิ่นๆ และแสดงใบรับรองที่มีชื่อที่ถูกต้องให้กับเบราว์เซอร์ ดังนั้น ด้วยไคลเอ็นต์และเซิร์ฟเวอร์ที่ใช้ SNI เซิร์ฟเวอร์ที่มีที่อยู่ IP เดียวสามารถให้บริการกลุ่มชื่อโดเมนซึ่งไม่สะดวกที่จะได้รับใบรับรองร่วมกัน

SNI ถูกเพิ่มเข้าไปในRFCของIETF สำหรับอินเทอร์เน็ต ในเดือนมิถุนายน 2003 ผ่านทาง RFC 3546 ซึ่งเป็นส่วนขยายของ Transport Layer Security (TLS)เวอร์ชันล่าสุดของมาตรฐานนี้คือ RFC 6066

เพย์โหลด Server Name Indication ไม่ได้รับการเข้ารหัส ดังนั้นชื่อโฮสต์ของเซิร์ฟเวอร์ที่ไคลเอนต์พยายามเชื่อมต่อจึงสามารถมองเห็นได้โดยผู้ดักฟังแบบพาสซีฟ จุดอ่อนของโปรโตคอลนี้ถูกใช้ประโยชน์โดยซอฟต์แวร์รักษาความปลอดภัยสำหรับการกรองและตรวจสอบเครือข่าย^{[ 4 ​​] [ 5 ] [ 6 ]}และรัฐบาลเพื่อดำเนินการเซ็นเซอร์^{[ 7 ]}

ปัจจุบัน มีเทคโนโลยีหลายอย่างที่พยายามซ่อนการระบุชื่อเซิร์ฟเวอร์ (Server Name Indication):

การใช้โดเมนฟรอนท์เป็นเทคนิคการแทนที่ชื่อโฮสต์ที่ต้องการใน SNI ด้วยชื่อโฮสต์อื่นที่โฮสต์โดยเซิร์ฟเวอร์เดียวกัน หรือบ่อยครั้งกว่านั้นคือเครือข่ายของเซิร์ฟเวอร์ที่เรียกว่าเครือข่ายการส่งมอบเนื้อหาเมื่อไคลเอนต์ใช้โดเมนฟรอนท์ มันจะแทนที่โดเมนของเซิร์ฟเวอร์ใน SNI (ที่ไม่ได้เข้ารหัส) แต่ยังคงอยู่ในส่วนหัวโฮสต์ของ HTTP (ซึ่งเข้ารหัสโดย TLS) เพื่อให้เซิร์ฟเวอร์สามารถให้บริการเนื้อหาที่ถูกต้องได้ การใช้โดเมนฟรอนท์ละเมิดมาตรฐานที่กำหนด SNI เอง ดังนั้นความเข้ากันได้จึงมีจำกัด (บริการจำนวนมากตรวจสอบว่าโฮสต์ SNI ตรงกับโฮสต์ในส่วนหัว HTTP และปฏิเสธการเชื่อมต่อที่มี SNI ที่ใช้โดเมนฟรอนท์ว่าไม่ถูกต้อง) ในขณะที่การใช้โดเมนฟรอนท์เคยถูกใช้ในอดีตเพื่อหลีกเลี่ยงการเซ็นเซอร์ของรัฐบาล^{[ 8 ]}ความนิยมของมันลดลงเนื่องจากผู้ให้บริการคลาวด์รายใหญ่ (Google, AWS ของ Amazon และ CloudFront) ห้ามใช้โดยชัดเจนในข้อกำหนดและเงื่อนไขการใช้งาน และมีข้อจำกัดทางเทคนิค^{[ 9 ]}

Encrypted Client Hello ( ECH ) เป็น ส่วนขยายของโปรโตคอล TLS 1.3ที่กำหนดไว้ในRFC 9849ในเดือนมีนาคม 2026 ซึ่งช่วยให้สามารถเข้ารหัสข้อความ Client Hello ทั้งหมด ซึ่งส่งในช่วงเริ่มต้นของการเจรจา TLS 1.3 ^{[ 10 ]} ECH เข้ารหัสเพย์โหลดด้วยคีย์สาธารณะที่ฝ่ายที่พึ่งพา (เว็บเบราว์เซอร์) จำเป็นต้องทราบล่วงหน้า ซึ่งหมายความว่า ECH จะมีประสิทธิภาพมากที่สุดกับCDN ขนาดใหญ่ การส่งคีย์สาธารณะและข้อมูลการกำหนดค่าผ่าน^HTTPSและระเบียน DNS SVCBได้รับการกำหนดไว้ในRFC 9848 [ ^{11 ]}  

ส่วนขยายเวอร์ชันเริ่มต้นในปี 2018 นี้เรียกว่า Encrypted SNI (ESNI) ^{[ 12 ]}ในเดือนมีนาคม 2020 ESNI ได้รับการปรับปรุงใหม่เป็นส่วนขยาย ECH หลังจากที่การวิเคราะห์แสดงให้เห็นว่าการเข้ารหัสเฉพาะ SNI นั้นไม่เพียงพอ ตัวอย่างเช่น ข้อกำหนดอนุญาตให้ส่วนขยาย Pre-Shared Key มีข้อมูลใดๆ ก็ได้เพื่ออำนวยความสะดวกในการกลับมาใช้งานเซสชันอีกครั้ง แม้กระทั่งการส่งสำเนาข้อความธรรมดาของชื่อเซิร์ฟเวอร์เดียวกันกับที่เข้ารหัสโดย ESNI นอกจากนี้ การเข้ารหัสส่วนขยายทีละรายการจะต้องใช้ตัวแปรที่เข้ารหัสของทุกส่วนขยาย ซึ่งแต่ละตัวแปรอาจมีผลกระทบต่อความเป็นส่วนตัว และถึงกระนั้นก็ยังเปิดเผยชุดของส่วนขยายที่ประกาศไว้ สุดท้าย การใช้งานจริงของ ESNI ได้เปิดเผยข้อจำกัดด้านความสามารถในการทำงานร่วมกัน^{[ 13 ]}ชื่อย่อคือECHOในเดือนมีนาคม 2020 ^{[ 14 ]}และเปลี่ยนเป็นECHในเดือนพฤษภาคม 2020 ^{[ 15 ]}ในเดือนกรกฎาคม 2023 ในการ ประชุม IETF117สมาชิกที่ทำงานเกี่ยวกับ ECH แจ้งว่า Chrome และ Firefox กำลังทำการทดลองกับตัวอย่าง 1% และทีมงานคาดว่าจะส่งร่างสุดท้ายไปยัง การประเมินของ IESGภายในเดือนมกราคม 2024 ^{[ 16 ] [ 17 ]}

ในเดือนกันยายน พ.ศ. 2566 Cloudflare เริ่มให้การสนับสนุน ECH สำหรับโดเมนที่โฮสต์^{[ 18 ]}

ในเดือนกันยายน พ.ศ. 2566 Chromiumเวอร์ชัน 117 (ที่ใช้ในGoogle Chrome , Microsoft Edge , Samsung InternetและOpera ) เปิดใช้งาน ECH เป็นค่าเริ่มต้น และยังกำหนดให้ต้องติดตั้งคีย์ในระเบียนทรัพยากร HTTPSใน DNS ด้วย^{[ 19 ] [ 20 ]} ECH ถูกเปิดใช้งานใน Firefox เป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน 119 ที่วางจำหน่ายในเดือนตุลาคม พ.ศ. 2566 และ Mozilla แนะนำให้ใช้ร่วมกับDNS over HTTPS ^{[ 21 ]}

ในเดือนเมษายน พ.ศ. 2569 OpenSSL 4.0 ได้รวมการสนับสนุน ECH ไว้ด้วย^{[ 22 ]}นับตั้งแต่การเปิดตัวในเดือนธันวาคม พ.ศ. 2568 NGINXได้รองรับ ECH ด้วย OpenSSL 4.0 ^{[ 23 ]}

ส่วนขยายเวอร์ชันเริ่มต้นในปี 2018 นี้เรียกว่า Encrypted SNI (ESNI) ^{[ 12 ]}และการใช้งานได้รับการเผยแพร่ในลักษณะ "ทดลอง" เพื่อจัดการกับความเสี่ยงของการดักฟังโดเมน^{[ 24 ] [ 25 ] [ 26 ]}ในทางตรงกันข้ามกับ ECH, Encrypted SNI จะเข้ารหัสเฉพาะ SNI แทนที่จะเป็น Client Hello ทั้งหมด^{[ 14 ]}การสนับสนุนแบบเลือกใช้สำหรับเวอร์ชันนี้ได้รับการรวมเข้าใน Firefox ในเดือนตุลาคม 2018 ^{[ 27 ]}และจำเป็นต้องเปิดใช้งานDNS over HTTPS (DoH) ^{[ 28 ]}แต่ถูกลบออกในเดือนมกราคม 2021 พร้อมกับการเปิดตัว Firefox 85 ^{[ 29 ]}

ทั้ง ESNI และ ECH เข้ากันได้กับ TLS 1.3 เท่านั้น เนื่องจากอาศัย KeyShareEntry ซึ่งถูกกำหนดไว้ครั้งแรกใน TLS 1.3 ^{[ 30 ] [ 31 ]}

ในเดือนสิงหาคม พ.ศ. 2563 กำแพงไฟของจีนเริ่มปิดกั้นการรับส่งข้อมูล ESNI ในขณะที่ยังคงอนุญาตให้รับส่งข้อมูล ECH ได้^{[ 32 ]}

ในเดือนตุลาคม พ.ศ. 2563 ผู้ให้บริการอินเทอร์เน็ตของรัสเซียRostelecomและผู้ให้บริการโทรศัพท์มือถือTele2เริ่มบล็อกการรับส่งข้อมูล ESNI ^{[ 33 ]}ในเดือนกันยายนของปีเดียวกัน กระทรวงการเซ็นเซอร์ของรัสเซียRoscomnadzorวางแผนที่จะห้ามโปรโตคอลการเข้ารหัสหลายรายการ ซึ่งรวมถึง TLS 1.3 และ ESNI ซึ่งขัดขวางการเซ็นเซอร์การเข้าถึงเว็บไซต์^{[ 34 ] [ 35 ] [ 36 ]}

ในปี 2547 โครงการ EdelKey ได้สร้างแพตช์สำหรับเพิ่ม TLS/SNI ลงในOpenSSL ^{[ 37 ]}ในปี 2549 แพตช์นี้ได้ถูกพอร์ตไปยังสาขาการพัฒนาของ OpenSSL และในปี 2550 ก็ได้พอร์ตกลับไปยัง OpenSSL 0.9.8 (เปิดตัวครั้งแรกใน 0.9.8f ^{[ 38 ]} ) เว็บเบราว์เซอร์แรกที่รองรับ SNI ปรากฏขึ้นในปี 2549 (Mozilla Firefox 2.0, Internet Explorer 7) ส่วนเว็บเซิร์ฟเวอร์ตามมาในภายหลัง (Apache HTTP Server ในปี 2552, Microsoft IIS ในปี 2555)

เพื่อให้โปรแกรมแอปพลิเคชันสามารถใช้งาน SNI ได้ ไลบรารี TLS ที่โปรแกรมใช้ต้องรองรับ SNI และแอปพลิเคชันต้องส่งชื่อโฮสต์ไปยังไลบรารี TLS ยิ่งไปกว่านั้น ไลบรารี TLS อาจรวมอยู่ในโปรแกรมแอปพลิเคชันหรือเป็นส่วนประกอบของระบบปฏิบัติการพื้นฐานก็ได้ ด้วยเหตุนี้ เบราว์เซอร์บางตัวจึงใช้งาน SNI ได้เมื่อทำงานบนระบบปฏิบัติการใดๆ ก็ได้ ในขณะที่บางตัวใช้งาน SNI ได้เฉพาะเมื่อทำงานบนระบบปฏิบัติการบางระบบเท่านั้น

• RFC  6066 (แทนที่RFC  4366ซึ่งแทนที่RFC  3546 อีกที )
• Mozilla Wiki - Encrypted Client Hello (ECH)