Я знаю, что 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-Talk Список Вопросы-Ответы; существует несколько копий этого документа, но большинство ссылок (на netscape.com) устарели.
TLS использует очень похожие сообщения (достаточно разные, чтобы протоколы были несовместимы, хотя можно договориться об общей версии). В TLS 1.0, 1.1 и 1.2 ClientHello сообщения используют (3,1), (3,2), (3,3) чтобы указать номер версии, который ясно показывает продолжение от SSL.
Более подробную информацию о различиях протоколов можно найти в этот ответ.
Когда я использую что? Когда я не использую что?
Если возможно, используйте максимально возможную версию. На практике, как поставщику услуг, это потребует от ваших пользователей наличия клиентов, поддерживающих эти версии. Как обычно, это всегда упражнение по оценке рисков (желательно, при необходимости, с бизнес-обоснованием). При этом все равно отключите SSLv2.
Кроме того, обратите внимание, что безопасность, обеспечиваемая SSL / TLS, касается не только того, какую версию вы используете, но и правильной конфигурации: безусловно, предпочтительнее использовать SSLv3 с надежным набором шифров, чем TLSv1.0 со слабым (или анонимное / нулевое шифрование) набор шифров. Некоторые наборы шифров, считавшиеся слишком слабыми, были явно запрещены новыми версиями TLS. Таблицы в провайдере Java 7 SunJSSE (и их сноски) может быть интересно, если вы хотите более подробную информацию.
Было бы предпочтительнее использовать как минимум TLS 1.1, но, к сожалению, не все клиенты их поддерживают (например, Java 6). При использовании версии ниже 1.1 обязательно стоит изучить снижение уязвимости BEAST.
Я обычно рекомендую Книга Эрика Рескорла - SSL и TLS: проектирование и создание безопасных систем, Addison-Wesley, 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), а затем выдает CONNECT HTTP-команду и, если ответ был успешным, инициирует квитирование 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 FAQ кладет это, "Хотя механизм разработан для использования с 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-подобная команда. Так же, как браузер не должен перенаправляться с https:// к http://, клиент для протокола, который поддерживает STARTTLS перед продолжением необходимо убедиться, что ответ был положительным и что соединение SSL / TLS было включено. В противном случае активный злоумышленник MITM мог бы легко понизить рейтинг любого соединения.
Например, в более старых версиях Thunderbird для этого был плохой вариант под названием «Использовать TLS, если он доступен»., что, по сути, означало, что если злоумышленник MITM мог изменить сообщения сервера так, чтобы он не объявлял о поддержке STARTTLS, клиент молча позволил себе перейти на соединение с открытым текстом. (Этот небезопасный вариант больше не доступен в Thunderbird.)
TLS - более новый протокол, чем SSL (но, AFAIK, он совместим с SSL v3). Обычно есть только одно отличие, о котором нужно беспокоиться:
Протокол SSL обычно имеет отдельный порт - например, 80 для HTTP и 443 для HTTPS (HTTP / SSL). Когда вы подключаетесь к порту SSL, весь сеанс шифруется.
TLS новее, чем SSL, и для него не требуется отдельный порт - вместо этого он должен согласовываться с клиентом. Например, вы можете запустить IMAP на порту 143, и если и почтовый сервер, и клиент поддерживают TLS, клиент пришлет STARTTLS команду и только потом включите шифрование. Таким образом, вам не понадобится отдельный порт только для SSL, но при этом вы останетесь совместимыми с приложениями без SSL.
Резюме:
SSL: Немного старше. Раздельные порты для простых и зашифрованных соединений. Весь трафик через порт SSL всегда зашифрован.
TLS: Один порт для простых и зашифрованных соединений. Шифрование включается только после того, как клиент выдает STARTTLS команда.
TLS - это просто более новая версия SSL. По возможности используйте TLS. Больше, как обычно, на Википедия.
Из этого База знаний Университета Индианы статья:
SSL расшифровывается как Secure Sockets Layer. Netscape изначально разработал этот протокол для конфиденциальной передачи информации, обеспечения целостности сообщений и гарантии идентичности сервера. SSL работает в основном с использованием шифрования данных с открытым / закрытым ключом. Он обычно используется в веб-браузерах, но SSL также может использоваться с почтовыми серверами или любыми типами транзакций клиент-сервер. Например, некоторые серверы обмена мгновенными сообщениями используют SSL для защиты разговоров.
TLS означает безопасность транспортного уровня. Инженерная группа Интернета (IETF) создала TLS в качестве преемника SSL. Чаще всего он используется в качестве параметра в программах электронной почты, но, как и SSL, TLS может играть роль в любой транзакции клиент-сервер.
Различия между двумя протоколами очень незначительны и очень технические, но это разные стандарты. TLS использует более надежные алгоритмы шифрования и может работать на разных портах. Кроме того, TLS версии 1.0 не взаимодействует с SSL версии 3.0.
TLS - это более новая версия SSL. Хотя в некоторых местах эти слова могут означать нечто иное, чем просто протоколы, поэтому просьба пояснить свой вопрос.