Server Name Indication

Під час здійснення з'єднання з використанням TLS, клієнт здійснює запит цифрового сертифікату веб-сервера. Коли сертифікат отримано, клієнт порівнює ім'я (чи імена), закодоване у сертифікаті, з іменем хоста, до якого здійснюється з'єднання, і у випадку збігу продовжує роботу у нормальному режимі. Якщо збігу імен не виявлено, користувачеві як правило показується попередження, і з'єднання може бути перерване через можливість атаки «man-in-the-middle». Втім, деякі програми дозволяють користувачеві обійти попередження; при цьому неявно вважається, що користувач довіряє сертифікатам, і як наслідок — встановленому з'єднанню.

Отримати заздалегідь повний список імен хостів може бути складно (або взагалі неможливо). Як наслідок, складно або неможливо отримати і сертифікат, який містить у собі всі ці імена. Серверові, що обслуговує запити для кількох імен хостів, бажано мати окремий сертифікат для кожного такого імені (або для групи взаємопов'язаних імен). Починаючи приблизно з 2005 року, організація CAcert у експериментальному порядку пропонувала кілька методів з використання TLS на віртуальних серверах,[2] більшість з яких вважалися недостатньо опрацьованими чи непрактичними. Наприклад, розширення до протоколу X.509 під назвою Subject Alternative Name (SAN) дозволяє розмістити у одному сертифікаті інформацію про кілька доменів (тобто, імен), що керуються однією особою[3]. Такі «уніфіковані» сертифікати мають бути оновлені кожного разу, коли список доменів змінюється.

Механізм віртуального хостингу дозволяє HTTP-серверові видавати різний контент в залежності від того, до якого домену було звернення (при цьому сервер має лише одну IP-адресу). Це є можливим через те, що ім'я передається клієнтом як частина HTTP-заголовку. Але у випадку HTTPS, рукотискання протоколу TLS відбувається до того, як сервер приймає будь-які заголовки HTTP. Таким чином, сервер не може знати, який сертифікат видавати у відповідь.

Розширення SNI дозволяє вирішити дану проблему шляхом додавання імені хоста (домену) до протоколу TLS-рукотискання.[4] Сервер, знаючи, до якого саме домену буде запит, може таким чином надіслати сертифікат лише для цього домену.

Організація IETF додала SNI до своїх «запитів коментарів» (RFC). Документ RFC 3546 (червень 2003) має назву «Transport Layer Security (TLS) Extensions». Найбільш свіжа версія стандарту (станом на початок 2018 року) — RFC 6066.

Патч, що додає підтримку TLS/SNI до пакету OpenSSL, з'явився 2004 року, у рамках проекту EdelKey.[5] За два роки його було портовано до гілки розробників OpenSSL, а у 2007-му — портовано до OpenSSL 0.9.8 (вперше з'явився у складі 0.9.8f[6]).

Для підтримки SNI застосунком це розширення має бути реалізоване у бібліотеці TLS, нові функції якої приймають доменне ім'я, до якого буде здійснено запит.