Я знаю, що TLS по суті є новою версією SSL, і що він, як правило, підтримує перехід з'єднання з незахищеного до захищеного (зазвичай за допомогою команди STARTTLS).
Я не розумію, чому TLS важливий для ІТ-професіонала, і чому, даючи вибір, я обрав би один за іншим. Чи TLS справді лише новіша версія, і якщо так, то чи сумісний це протокол?
Як ІТ-професіонал: коли я можу використовувати який? Коли я не використовую який?
Відповіді:
Коротка відповідь:
SSL є попередником TLS. SSL був власницьким протоколом, розробленим Netscape Communications, пізніше стандартизованим в рамках IETF та перейменованим як TLS. Коротше кажучи, версії йдуть у такому порядку: SSLv2, SSLv3, TLSv1.0, TLSv1.1 та TLSv1.2.
На противагу відносно широко розповсюдженій думці, це зовсім не в тому, що потрібно запускати службу на окремому порту з SSL та мати можливість на тому ж порту, що і в текстовому варіанті з TLS. І SSL, і TLS можна використовувати для двох підходів. Йдеться про різницю між SSL / TLS після з'єднання (іноді їх називають "неявною SSL / TLS") і SSL / TLS після того, як команда була видана на рівні протоколу, як правило STARTTLS(іноді її називають "явною SSL / TLS") . Ключове слово в STARTTLS"СТАРТ", а не TLS. Це повідомлення на рівні протоколу програми, яке вказує на необхідність переходу на SSL / TLS, якщо воно не було ініційоване перед обміном протоколів додатків.
Використання будь-яких режимів повинно бути рівнозначним, за умови, що клієнт налаштований так чи інакше очікувати SSL / TLS, щоб не переходити до простого тексту.
Більш довга відповідь:
Наскільки мені відомо, SSLv1 ніколи не виходив з лабораторій. SSLv2 і SSLv3 були протоколами, розробленими Netscape. SSLv2 деякий час вважався незахищеним, оскільки він схильний знижувати атаки. SSLv3 використовує внутрішньо (3,0)як свій номер версії (всередині ClientHelloповідомлення).
TLS є результатом стандартизації як більш відкритого протоколу всередині IETF. (Я думаю, я десь читав, можливо, у книзі Е. Рескорли, що ім'я було обрано таким чином, що всі учасники були однаково незадоволені цим, щоб не надавати перевагу конкретній компанії: це досить звична практика у стандартах body.) Ті, хто цікавиться тим, як було здійснено перехід, можуть ознайомитись із поширеними запитаннями про список SSL-розмов ; є кілька копій цього документа навколо, але більшість посилань (на ) застарілі.netscape.com
TLS використовує дуже схожі повідомлення (достатньо різні, щоб зробити протоколи несумісними, хоча можна узгодити загальну версію ). У TLS 1.0 , 1.1 і 1.2 ClientHello повідомлення використовують (3,1), (3,2), (3,3)щоб вказати номер версії, яка ясно показує продовження з SSL.
Більш детально про відмінності протоколів у цій відповіді .
Коли я використовую який? Коли я не використовую який?
Використовуйте найвищу версію, яку ви можете, якщо це можливо. На практиці, як постачальник послуг, це вимагатиме від ваших користувачів клієнтів, які підтримують ці версії. Як завжди, це завжди оцінювання ризику (бажано, якщо це доречно, підкріплене діловою справою). Це, як кажуть, все одно відрізає SSLv2.
Крім того, зауважте, що безпека, що надається SSL / TLS, стосується не лише тієї версії, яку ви використовуєте, а й належної конфігурації: звичайно краще використовувати SSLv3 із сильним набором шифрів, ніж TLSv1.0 із a зі слабким (або анонімне / нульове шифрування) набір шифрів. Деякі набори шифрів, які вважаються занадто слабкими, були явно заборонені новішими версіями TLS. Таблиці постачальника Java 7 SunJSSE (та їх виноски) можуть зацікавити, якщо ви хочете отримати більше деталей.
Краще використовувати принаймні TLS 1.1, але, на жаль, не всі клієнти підтримують їх (наприклад, Java 6). Під час використання версії під 1.1, безумовно, варто розглянути можливість пом'якшення вразливості BEAST .
Я, як правило, рекомендую книгу Еріка Рескорли - SSL та TLS: Проектування та побудова захищених систем, Аддісон-Веслі, 2001 ISBN 0-201-61598-3 людям, які дійсно хочуть отримати більше деталей.
Існує міф, що TLS дозволяє використовувати той же порт, тоді як SSL не може. Це просто неправда (і я залишу об'єднання портів для цієї дискусії). На жаль, цей міф, здається, розповсюджується серед користувачів тим, що деякі програми, такі як MS Outlook, іноді пропонують вибір між SSL та TLS у своїх параметрах конфігурації, коли вони насправді означають вибір між неявним та явним SSL / TLS. (У Microsoft є експерти SSL / TLS, але, схоже, вони не брали участь у інтерфейсі Outlook.)
Я думаю, що причина цього плутанини - через STARTTLSрежим. Деякі люди здаються, що зрозуміли це як STARTTLS= TLS, але це не так. Ключове слово в STARTTLS"СТАРТ", а не TLS. Чому цього не називали STARTSSLабо STARTSSLORTLSтому, що ці розширення були вказані в IETF, який використовував лише імена, що використовуються в його технічних характеристиках (припускаючи, що ім'я TLS зрештою буде єдиним стоячим).
В даний час більшість серверів HTTPS може обробляти TLS, але кілька років тому більшість людей використовували SSLv3 для HTTPS. HTTPS (строго кажучи, стандартизований як HTTP через TLS ) зазвичай встановлює з'єднання SSL / TLS після з'єднання TCP, а потім обмінюється повідомленням HTTP через рівень SSL / TLS. Існує виняток із цього при використанні проксі-сервера HTTP між ними. У цьому випадку клієнт чітко підключається до HTTP-проксі (як правило, на порт 3128), потім видає команду CONNECTHTTP і, за умови успішної відповіді, ініціює рукостискання SSL / TLS шляхом надсиланняClientHelloповідомлення. Все це відбувається на одному порті, що стосується зв’язку між браузером та проксі (очевидно, не між проксі та цільовим сервером: це навіть не одна машина). Це добре працює з SSLv3. Багато хто з нас у ситуаціях, що стоять за проксі-сервером, будуть використовувати це проти серверів, які не підтримували принаймні TLS 1.0.
Це явно поза специфікаціями, але на практиці часто працює. Власне кажучи, технічні характеристики говорять про перехід на TLS (не на SSL) після використання команди STARTTLS. На практиці часто працює і SSL (як і специфікація "HTTP через TLS", також включає використання SSL замість TLS). Ви можете спробувати самостійно. Якщо припустити, що у вас є сервер SMTP або IMAP, який підтримує STARTTLS, використовуйте Thunderbird, перейдіть до налаштувань, розширених параметрів, конфігураційного редактора та вимкніть security.enable_tls. Багато серверів все одно приймуть з'єднання просто тому, що їх реалізація делегує рівень SSL / TLS до бібліотеки SSL / TLS, яка, як правило, зможе обробляти SSL і TLS так само, якщо не буде налаштовано цього не робити. Як часто задається питанням OpenLDAP , "Хоча механізм розроблений для використання з TLSv1, більшість реалізацій при необхідності будуть відновлюватися до SSLv3 (і SSLv2). Якщо ви не впевнені, зверніться до інструменту типу Wireshark.
Багато клієнтів можуть використовувати TLS 1.0 (принаймні) для протоколів, де захищений варіант знаходиться на іншому порту. Очевидно, існує ряд браузерів та веб-серверів, які підтримують TLS 1.0 (або вище) для HTTPS. Аналогічно, SMTPS, IMAPS, POPS і LDAPS також можуть використовувати TLS. Вони не обмежені SSL.
Коли я використовую який? Коли я не використовую який?
Між явним та неявним SSL / TLS це насправді не має значення. Важливо те, що ваш клієнт знає, чого очікувати, і налаштований належним чином для цього. Що ще важливіше, він повинен бути налаштований на відхилення простого текстового з'єднання, коли він очікує з'єднання SSL / TLS, незалежно від того, чи це явне чи явне .
Основна відмінність явного та неявного SSL / TLS полягатиме в ясності параметрів конфігурації.
Наприклад, для LDAP, якщо клієнтом є сервер Apache Httpd ( mod_ldap- його документація, на жаль, неправильно позначає різницю між SSL та TLS), ви можете використовувати неявну SSL / TLS за допомогою ldaps://URL (наприклад AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) або використовувати явний SSL / TLS за допомогою додаткового параметра (наприклад AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).
Існує, можливо , взагалі кажучи , трохи менший ризик при вказівці протоколу безпеки в схемі URL ( https, ldaps, ...) , ніж коли очікує клієнта , щоб налаштувати додаткові параметри для включення SSL / TLS, тому що вони можуть забути. Це сперечається. Можуть також виникнути проблеми в правильності реалізації одного порівняно з іншим (наприклад, я думаю, що клієнт Java LDAP не підтримує перевірку імен хостів при використанні ldaps://, коли слід, тоді як він підтримується з ldap://+ StartTLS).
Поза сумнівом, і щоб бути сумісним з більшою кількістю клієнтів, можливо, не шкода пропонувати обидві послуги, коли сервер підтримує їх (ваш сервер буде прослуховувати одночасно на двох портах). Багато реалізацій серверів для протоколів, які можна використовувати в будь-якому режимі, підтримуватимуть обидва.
Клієнт несе відповідальність за те, щоб не допустити переходу до простого тексту. Як адміністратор сервера, ви нічого технічно не можете зробити на вашій стороні, щоб запобігти атакам з пониженням рівня (окрім того, що, можливо, не потрібен клієнтський сертифікат). Клієнт повинен перевірити, чи включений SSL / TLS, незалежно від того, чи це він після з'єднання або після STARTTLSкоманди -like. Так само, як браузер не повинен дозволяти собі перенаправлення з https://на http://, клієнт протоколу, який підтримує, STARTTLS
повинен переконатися, що реакція була позитивною, і з'єднання SSL / TLS було ввімкнено до подальшого продовження. Активний MITM-зловмисник може інакше легко знизити будь-яке з'єднання.
Наприклад, старіші версії Thunderbird мали поганий варіант для цього під назвою "Використовувати TLS, якщо він доступний" , що по суті означало, що якщо MITM-зловмисник змінює зміни серверних повідомлень, щоб він не рекламував підтримку STARTTLS, клієнт мовчки дозволив би перейти до простого тексту. (Ця небезпечна опція більше не доступна в Thunderbird.)
TLS - це новіший протокол, ніж SSL (але AFAIK, він сумісний із SSL v3). Зазвичай існує лише одна різниця, про яку потрібно турбуватися:
Протокол SSL'ed зазвичай має окремий порт - наприклад, 80 для HTTP і 443 для HTTPS (HTTP / SSL). Коли ви підключаєтесь до порту SSL, весь сеанс шифрується.
TLS новіший, ніж SSL, і він не потребує окремого порту - замість цього він повинен бути узгоджений клієнтом. Наприклад, ви можете запустити IMAP на порт 143, і якщо і поштовий сервер, і клієнт підтримують TLS, клієнт відправить STARTTLSкоманду і лише після цього включить шифрування. Таким чином, вам не потрібен окремий порт, лише для SSL, залишаючись сумісним із програмами, що не містять SSL.
Підсумок:
SSL : Трохи старший. Окремі порти для звичайних та зашифрованих з'єднань. Весь трафік на порту SSL завжди шифрується.
TLS : Єдиний порт як для простого, так і для зашифрованого з'єднання. Шифрування ввімкнено лише після того, як клієнт видає STARTTLSкоманду.
STARTTLSв деяких протоколах дозволяє перейти на TLS на одному і тому ж з'єднанні, не є різницею між SSL та TLS. Технічно ви могли перейти на SSLv3 таким же чином.
З цієї статті бази знань університету Індіани :
SSL розшифровується як шар захищених сокетів. Netscape спочатку розробив цей протокол для приватної передачі інформації, забезпечення цілісності повідомлень та гарантії ідентичності сервера. SSL працює в основному за допомогою використання шифрування відкритих / приватних ключів на даних. Він зазвичай використовується у веб-браузерах, але SSL також може використовуватися з серверами електронної пошти або будь-якими транзакціями клієнт-сервер. Наприклад, деякі сервери обміну миттєвими повідомленнями використовують SSL для захисту розмов.
TLS розшифровується як безпека транспортного шару. Робоча група Internet Engineering (IETF) створила TLS як наступник SSL. Він найчастіше використовується як налаштування в електронних програмах, але, як і SSL, TLS може мати роль у будь-якій транзакції клієнт-сервер.
Відмінності між двома протоколами дуже незначні та дуже технічні, але вони різні стандарти. TLS використовує більш сильні алгоритми шифрування і має можливість працювати в різних портах. Крім того, версія TLS 1.0 не взаємодіє з SSL версії 3.0.
TLS - це новіша версія SSL. Хоча в деяких місцях ці слова можуть означати щось інше, ніж просто протоколи, тому, будь ласка, уточніть своє запитання.