STARTTLS менее безопасен, чем TLS / SSL?


45

В Thunderbird (и я полагаю, во многих других клиентах) у меня есть возможность выбора между «SSL / TLS» и «STARTTLS».

Насколько я понимаю, «STARTTLS» означает простыми словами «шифровать, если оба конца поддерживают TLS, в противном случае не шифровать передачу» . А «SSL / TLS» означает простыми словами «всегда шифровать или вообще не подключаться» . Это верно?

Или другими словами:

Является ли STARTTLS менее безопасным, чем SSL / TLS, потому что он может перейти на обычный текст без уведомления меня?

Ответы:


46

Ответ, основанный на RFC STARTTLS для SMTP ( RFC 3207 ):

STARTTLS менее безопасен, чем TLS.

Вместо того, чтобы говорить самому, я позволю RFC говорить за себя, с четырьмя соответствующими битами, выделенными жирным шрифтом :

Атаку «человек посередине» можно запустить, удалив ответ «250 STARTTLS» с сервера. Это приведет к тому, что клиент не будет пытаться запустить сеанс TLS. Другая атака «человек посередине» - позволить серверу объявить о своей возможности STARTTLS, но изменить запрос клиента на запуск TLS и ответ сервера. Чтобы защититься от таких атак, клиенты и серверы ДОЛЖНЫ быть настроены так, чтобы требовать успешного согласования TLS соответствующего набора шифров для выбранных хостов, прежде чем сообщения могут быть успешно переданы. ДОЛЖНА также быть предоставлена дополнительная возможность использования TLS, когда это возможно. Реализация МОЖЕТ предоставить возможность записывать, что TLS использовался при связи с данным узлом и генерировать предупреждение, если он не используется в более позднем сеансе.

Если согласование TLS не удается или клиент получает ответ 454, клиент должен решить, что делать дальше. Есть три основных варианта: продолжить оставшуюся часть SMTP-сессии , [...]

Как видите, сам RFC утверждает (не очень четко, но достаточно четко), что НИЧЕГО не требуется клиентам устанавливать безопасное соединение и информировать пользователей в случае сбоя безопасного соединения. Это явно дает клиентам возможность устанавливать молчащие текстовые соединения.


5
Ваша точка зрения, безусловно, верна, но из-за отсутствия какой-либо RFC или официальной спецификации, касающейся SMTPS (т. Е. SMTP + «неявный SSL / TLS», где сначала устанавливается SSL / TLS), клиенты SMTP / SMTPS также могут принять решение о переходе на простое соединение. если им не удается инициировать соединение SSL / TLS через порт 465. Это по-прежнему чисто вариант реализации.
Бруно

2
Существует множество RFC для установления соединений TLS. Нигде не существует «разрешить простое текстовое соединение» как вариант для соответствия RFC (по крайней мере, это было бы новостью для многих людей). Таким образом, SMTPS не требует, чтобы отдельный RFC был более безопасным, чем STARTTLS.
Грег

1
Существуют RFC о TLS (RFC 5246 и его предшественниках), PKI (RFC 5280), проверке имен (RFC 6125), но нет ничего, чтобы описать взаимодействие между SMTP и SSL / TLS в SMTPS официально AFAIK, не так, как вы получаете спецификация для HTTPS: RFC 2818. Кто-то может сказать «это очевидно, сначала просто установите соединение SSL / TLS», но не все в этом очевидно (в частности, аспект проверки идентичности, формализованный совсем недавно в RFC 6125).
Бруно

23

Нет никакой разницы в безопасности между этими двумя вариантами.

  • SSL / TLS сначала открывает соединение SSL / TLS, а затем начинает транзакцию SMTP. Это должно происходить на порте, на котором еще не запущен SMTP-сервер без SSL / TLS; из-за природы протоколов невозможно настроить один порт для обработки как простого текста, так и зашифрованных соединений.

  • STARTTLS запускает SMTP-транзакцию и ищет поддержку на другом конце для TLS в ответе на EHLO. Если клиент видит STARTTLS в списке поддерживаемых команд, он отправляет STARTTLS и начинает согласование для шифрования. Все это может (и обычно происходит) происходить на стандартном SMTP-порту 25, частично для обратной совместимости, но также и для обеспечения возможности произвольного шифрования между конечными точками, которые обе поддерживают его, но не обязательно требуют его.

Обычно SSL / TLS используется только между конечными клиентами и серверами. STARTTLS чаще используется между MTA для защиты межсерверного транспорта.

С учетом этих двух реализаций STARTTLS может быть истолкован как небезопасный, если пользователь или администратор предполагают, что соединение зашифровано, но на самом деле не настроили его для шифрования. Однако используемое шифрование точно такое же, как и для SSL / TLS, и, следовательно, не более или менее уязвимо для атаки «человек посередине» за пределами этого типа ошибки конфигурации.


2
Если соединение зашифровано, то SSL / TLS и STARTTLS одинаковы, да. Но это не то, что я спросил. Я имел в виду: если я использую STARTTLS, как я (как пользователь) узнаю, действительно ли мое соединение защищено? Если я пытаюсь использовать SSL / TLS, я просто не могу подключиться, если сервер не поддерживает его, но по крайней мере ничего не отправляется в виде открытого текста. Но если STARTTLS возвращается к открытому тексту, тогда моя почта отправляется в виде открытого текста, и я не знаю, что оно было отправлено в виде открытого текста (что заставляет меня думать, что я в безопасности, когда на самом деле я не нахожусь).
Foo Bar

6
Я не знаю, почему этот ответ был выбран как правильный. Это не правильно. Как указывает Кристофер, STARTTLS менее безопасен, чем TLS, поскольку он дает ложное чувство безопасности клиентам.
Грег

4
@greg нет ничего плохого в протоколе. Недостатком являются клиенты, которые не следуют rfc и не предупреждают пользователя, когда соединение не зашифровано.
Longneck

1
@ longneck, так что ... возможно, это семантика, но клиенты не могут "не следовать" протоколу TLS и получать электронную почту, точка. так что это значимая разница.
Грег

2
@Bruno "Это менее безопасно, если клиент плохо реализован" <= вы просто делаете мою точку зрения для меня. Если клиент может что-либо сделать, чтобы сделать соединение небезопасным, при этом все еще устанавливая работающее соединение, тогда STARTTLS менее безопасен, чем явный TLS (где это невозможно).
Грег

8

В частности, для электронной почты в январе 2018 года был выпущен RFC 8314 , который явно рекомендует использовать «неявный TLS» вместо механизма STARTTLS для отправки IMAP, POP3 и SMTP.

Вкратце, эта памятка теперь рекомендует, чтобы:

  • TLS версии 1.2 или выше должен использоваться для всего трафика между MUA и серверами отправки почты, а также между MUA и серверами доступа к почте.
  • MUA и поставщики почтовых услуг (MSP) (a) не рекомендуют использовать протоколы открытого текста для доступа к почте и отправки почты и (b) не рекомендуют использовать протоколы открытого текста для этих целей как можно скорее.
  • Соединения с серверами отправки почты и серверами доступа к почте выполняются с использованием «неявного TLS» (как определено ниже), предпочтительнее подключения к порту «открытый текст» и согласования TLS с помощью команды STARTTLS или аналогичной команды.

(выделение добавлено)


4

Ответ в некоторой степени зависит от того, что вы подразумеваете под «безопасным».

Во-первых, ваше резюме не совсем отражает разницу между SSL / TLS и STARTTLS.

  • При использовании SSL / TLS клиент открывает TCP-соединение с «портом SSL», назначенным протоколу приложения, которое он хочет использовать, и немедленно начинает говорить TLS.
  • С помощью STARTTLS клиент открывает TCP-соединение с «портом открытого текста», связанным с протоколом приложения, которое он хочет использовать, а затем спрашивает сервер «Какие расширения протокола вы поддерживаете?». Затем сервер отвечает списком расширений. Если одним из этих расширений является «STARTTLS», клиент может сказать «хорошо, давайте использовать TLS», и оба начнут говорить TLS.

Если клиент настроен на использование TLS, оба подхода более или менее одинаково безопасны. Но есть некоторые тонкости в том, как STARTTLS должен использоваться, чтобы сделать его безопасным, и для реализации STARTTLS немного сложнее понять эти детали правильно.

С другой стороны, если клиент настроен на использование TLS только при наличии TLS и при использовании открытого текста, когда TLS недоступен, клиент может сначала попытаться подключиться к порту SSL, используемому протоколом, и если это не удается, затем подключитесь к порту открытого текста и попробуйте использовать STARTTLS, и, наконец, вернитесь к открытому тексту, если TLS не доступен в любом случае. Для злоумышленника довольно легко вызвать сбой соединения через порт SSL (все, что требуется, - это своевременные пакеты TCP RST или блокировка порта SSL). Злоумышленнику немного сложнее - но только чуть-чуть - победить согласование STARTTLS и заставить трафик оставаться открытым текстом. И тогда злоумышленник не только читает вашу электронную почту, но и получает ваш логин / пароль для дальнейшего использования.

Поэтому простой ответ: если вы подключаетесь к серверу, который, как вы уже знаете, поддерживает TLS (как и в случае отправки или чтения электронной почты), вам следует использовать SSL / TLS. Если соединение атаковано, попытка соединения не удастся, но ваш пароль и адрес электронной почты не будут скомпрометированы.

С другой стороны, если вы подключаетесь к какой-либо службе, которая не знает, поддерживает ли она TLS, STARTTLS может быть немного лучше.

Когда был изобретен STARTTLS, «пассивные» атаки только для прослушивания были очень распространены, «активные» атаки, при которых злоумышленник вводил трафик, пытаясь снизить уровень безопасности, были менее распространенными. За 20 лет или около того, активные атаки стали более выполнимыми и более распространенными.

Например, если вы пытаетесь использовать ноутбук в аэропорту или каком-либо другом общественном месте и пытаетесь читать почту через предоставленный там wifi, вы не представляете, что эта сеть wifi делает с вашим трафиком. В сетях Wi-Fi очень распространено направление определенных видов трафика к «прокси», которые размещаются между вашими клиентскими приложениями и серверами, с которыми они пытаются общаться. Эти прокси-серверы тривиально отключают STARTTLS и «пробуют один порт, а затем другой», пытаясь заставить вашего клиента переключиться на открытый текст. Да, это происходит, и это только один пример того, как ваш трафик может отслеживаться сетью. И такие атаки не ограничиваются трехбуквенными государственными агентствами,


1

Да, вы правильно поняли основы. И да, STARTTLS определенно менее безопасен. Он может не только вернуться к незашифрованному тексту без уведомления, но и потому, что подвергается атакам типа «человек посередине». Поскольку соединение начинается в открытом виде, MitM может исключить команду STARTTLS и предотвратить шифрование. Однако я считаю, что почтовые серверы могут указывать, что передача происходит только после настройки зашифрованного туннеля. Так что вы можете обойти это.

Так почему же такая вещь существует? По причинам совместимости. Если какая-либо из сторон не поддерживает шифрование, вы все равно можете захотеть, чтобы соединение было установлено правильно.


Итак, сервер, поддерживающий STARTTLS, также всегда будет поддерживать SSL / TLS, верно? Так что всегда лучше сначала попробовать SSL / TLS и посмотреть, работает ли он?
Foo Bar

2
@FooBar нет, одно не означает, что другой доступен. фактически они могут быть настроены с совершенно разными доменами аутентификации.
longneck

3
STARTTLS не уязвим для MitM, если вы не проверяете сертификаты или не используете слабые. Сертификат по-прежнему представлен так же, как и всегда, и клиент может потребовать успешного обновления TLS, прежде чем продолжить. Стоит отметить, что это точно такая же ситуация, как SSL / TLS.
Сокол Момот

1
Не знаю, почему люди голосуют против вас, это правильный ответ, STARTTLS менее безопасен, чем TLS, и дает ложное чувство безопасности. Интернет-провайдеры могут просто оговорить это: arstechnica.com/tech-policy/2014/11/…
Грег

1
Что касается самого протокола, STARTTLS менее безопасен, чем TLS, потому что он явно разрешает обмен текстовыми сообщениями без предупреждения пользователя: serverfault.com/a/648282/207987
Грег

1

Согласитесь с @Greg. Эти атаки возможны. Однако MTA могут быть настроены (в зависимости от MTA) для использования «обязательного TLS», а не «условного TLS». Это означает, что для транзакций электронной почты используется TLS и только TLS (включая STARTTLS). Если удаленный адаптер MTA не поддерживает STARTTLS, электронная почта отклоняется.


0

Нет, это не менее безопасно, когда ваше приложение обрабатывает его правильно.

Существует четыре способа обработки TLS, и многие программы позволяют выбирать:

  • Нет TLS
  • TLS на выделенном порту (только пытается TLS)
  • Использовать TLS, если доступно (Пытается starttlsиспользовать незашифрованное соединение при сбое)
  • Всегда используйте TLS (использует starttlsи терпит неудачу, если он не работает)

Преимущество TLS на выделенном порте состоит в том, что вы можете быть уверены, что при использовании программы, которую вы еще не знаете или которая не предоставляет подробные настройки для обработки ошибок в мастере первого запуска, не существует запасного варианта.

Но в целом безопасность зависит от обработки ошибок безопасности. Программа может решить переключиться на порт открытого текста, когда TLS на TLS-Port также выходит из строя. Вы должны знать, что он будет делать, и выбирать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.