У Thunderbird (і я припускаю, що і у багатьох інших клієнтів) у мене є можливість вибору між "SSL / TLS" та "STARTTLS".
Наскільки я розумію, "STARTTLS" означає простими словами "шифрувати, якщо обидва кінці підтримують TLS, інакше не шифруйте передачу" . А "SSL / TLS" означає простими словами "завжди шифрувати або взагалі не з'єднуватися" . Це правильно?
Або іншими словами:
Чи STARTTLS менш безпечний, ніж SSL / TLS, тому що він може повертатися до простого тексту без повідомлення мене?
Відповіді:
Відповідь, заснована на STARTTLS RFC для SMTP ( RFC 3207 ), така:
Замість того, щоб розмовляти сам, я дозволю RFC говорити сам за себе, чотири відповідні біти виділені BOLD :
Атака "посередник" може бути запущена, видаливши відповідь "250 STARTTLS" з сервера. Це призведе до того, що клієнт не намагається запустити сеанс TLS. Інша атака «посередника» - дозволити серверу оголосити про свою можливість STARTTLS, але змінити запит клієнта на запуск TLS та відповідь сервера. Для захисту від таких атак як клієнти, так і сервери ОБОВ'ЯЗКОВО мають бути налаштовані так, щоб вимагати успішного узгодження TLS відповідного набору шифрів для вибраних хостів, перш ніж повідомлення можна буде успішно перенести. Додатковий варіант використання TLS, коли це можливо, ДОЛЖЕН бути також наданий. Впровадження МОЖЕ надають можливість записувати, що TLS використовувався при спілкуванні з певним однолітком, і генеруючи попередження, якщо воно не використовується в подальшому сеансі.
Якщо узгодження TLS не вдається або якщо клієнт отримує відповідь 454, клієнт повинен вирішити, що робити далі. Є три основні варіанти: продовжуйте роботу з рештою сеансу SMTP , [...]
Як бачите, RFC сама заявляє (не дуже чітко, але досить чітко), що НІЧЕ не вимагає від клієнтів встановлення захищеного з'єднання та інформування користувачів, якщо захищене з'єднання не вдалося. Це явно дає клієнтам можливість беззвучно встановлювати текстові з'єднання.
Між двома варіантами в безпеці немає різниці.
SSL / TLS спочатку відкриває з'єднання SSL / TLS, потім починає транзакцію SMTP. Це має відбуватися на порту, на якому вже не запущений SMTP-сервер не-SSL / TLS; неможливо налаштувати єдиний порт для обробки як простого тексту, так і зашифрованого з'єднання через характер протоколів.
STARTTLS запускає транзакцію SMTP і шукає підтримки з іншого кінця для TLS у відповідь на EHLO. Якщо клієнт бачить STARTTLS у списку підтримуваних команд, він надсилає STARTTLS і починає узгодження для шифрування. Все це може (і, як правило, відбувається) на стандартному порту SMTP 25, частково для зворотної сумісності, а також для уможливлення умовно-патологічного шифрування між кінцевими точками, які обидва підтримують його, але не обов'язково вимагають цього.
Як правило, SSL / TLS використовується лише між кінцевими клієнтами та серверами. STARTTLS частіше використовується між MTA для забезпечення міжсерверного транспорту.
З огляду на ці дві реалізації, STARTTLS можна вважати незахищеними, якщо користувач або адміністратор припускають, що з'єднання зашифроване, але насправді не налаштували його на вимогу шифрування. Однак використовуване шифрування точно таке ж, як і SSL / TLS, і тому не більш-менш вразливе для атаки "Людина в середині" поза цією помилкою конфігурації.
Зокрема, для електронної пошти у січні 2018 року було випущено RFC 8314 , в якому явно рекомендується використовувати "Неявні TLS" у перевазі механізму STARTTLS для подання IMAP, POP3 та SMTP.
Якщо коротко, ця примітка тепер рекомендує:
- TLS версії 1.2 або новішої застосовується для всього трафіку між MUA та серверами подання пошти, а також між MUA та серверами доступу до пошти.
- MUAs та постачальники послуг поштового зв’язку (MSP) (a) перешкоджають використанню протоколів чіткого тексту для доступу до пошти та подання пошти та (b) припиняють використання протоколів чіткого тексту для цих цілей якнайшвидше.
- Підключення до серверів подання пошти та серверів доступу до пошти здійснюються за допомогою "Неявного TLS" (як визначено нижче), для переваги підключення до порту "очистити текст" та узгодження TLS за допомогою команди STARTTLS або подібної команди.
(наголос додано)
Відповідь певною мірою залежить від того, що ви маєте на увазі під "безпечним".
По-перше, ваше резюме не зовсім фіксує різницю між SSL / TLS та STARTTLS.
Якщо клієнт налаштований вимагати TLS, два підходи є більш-менш однаково безпечними. Але є деякі тонкощі того, як потрібно використовувати STARTTLS, щоб зробити його безпечним, і для впровадження STARTTLS трохи складніше виправити ці деталі.
З іншого боку, якщо клієнт налаштований використовувати TLS лише тоді, коли TLS доступний, і використовувати cleartext, коли TLS недоступний, що може зробити клієнт, спершу спробуйте підключитися до порту SSL, використовуваного протоколом, і якщо це не вдається, потім підключіться до порту очищення тексту та спробуйте використовувати STARTTLS, і, нарешті, поверніться до очищення тексту, якщо TLS недоступний в будь-якому випадку. Зловмисникові досить легко призвести до виходу з ладу підключення до порту SSL (все, що потрібно, - це декілька своєчасних пакетів TCP RST або блокування порту SSL). Трохи важче - але лише трохи - для зловмисника перемогти переговори щодо STARTTLS і змусити рух трафіку в чіткому тексті. І тоді зловмисник не тільки читає вашу електронну пошту, але й отримує захоплення вашого імені користувача / пароля для подальшого використання.
Тож проста відповідь - якщо ви підключаєтесь до сервера, який ви вже знаєте, підтримує TLS (як це має бути у випадку надсилання чи читання електронної пошти), ви повинні використовувати SSL / TLS. Якщо підключення атакується, спроба з'єднання не вдасться, але ваш пароль та електронна пошта не будуть порушені.
З іншого боку, якщо ви підключаєтесь до якоїсь служби, яка не знає, чи підтримує вона TLS, STARTTLS може бути незначно кращим.
Коли було придумано STARTTLS, "пасивні" атаки лише для прослуховування були дуже поширеними, "активні" атаки, в яких зловмисник вводив трафік, щоб спробувати знизити рівень безпеки, були менш поширеними. За 20 або більше років з того часу активні напади стали більш здійсненними та більш поширеними.
Наприклад, якщо ви намагаєтесь використовувати ноутбук в аеропорту чи іншому громадському місці і намагаєтесь прочитати вашу пошту через наданий там wifi, ви не маєте поняття, що ця мережа Wi-Fi робить з вашим трафіком. У мережах Wi-Fi дуже часто трафікувати певний тип трафіку на "проксі", які розміщуються між вашими клієнтськими програмами та серверами, з якими вони намагаються спілкуватися. Для цих проксі-серверів нереально вимкнути і STARTTLS, і "спробувати один порт, потім інший", намагаючись змусити вашого клієнта повернутися до ясного тексту. Так, це трапляється, і це лише один приклад того, як ваш трафік може шпигувати мережею. І такі напади не обмежуються трибуквенними державними агенціями,
Так, ви маєте основні права. І так, STARTTLS, безумовно, менш безпечний. Він може не тільки повернутись до простого тексту без повідомлення, але й тому, що він піддається атакам "людина-в-середині". Оскільки з'єднання починається в чистому режимі, MitM може викреслити команду STARTTLS і запобігти шифруванню будь-коли. Однак, я вважаю, що сервери пошти можуть вказати, що передача відбуватиметься лише після налаштування зашифрованого тунелю. Тож можна обійтися цим.
То чому ж таке взагалі існує? З міркувань сумісності. Якщо будь-яка із сторін не підтримує шифрування, можливо, ви все ще хочете, щоб з'єднання було належним чином завершено.
Погодьтеся з @Greg. Ці напади можливі. Однак MTA можуть бути налаштовані (залежно від MTA) для використання "обов'язкових TLS", а не "умовно-умовних TLS". Це означає, що для транзакцій електронною поштою використовується TLS та лише TLS (сюди також входить STARTTLS). Якщо віддалений MTA не підтримує STARTTLS, повідомлення електронної пошти відхиляється.
Ні, це не менш безпечно, коли ваша програма керує нею правильно.
Існує чотири шляхи для обробки TLS, і багато програм дозволяють вибрати:
starttls, використовує незашифроване з'єднання, коли він не працює)starttlsта виходить з ладу, якщо він не працює)Перевага TLS на виділеному порту полягає в тому, що ви можете бути впевнені, що немає резервного резерву, коли ви використовуєте програму, яку ви ще не знаєте, або яка не відкриває параметри деталей для роботи з помилками у своєму майстрі першого запуску.
Але в цілому безпека залежить від обробки помилок безпеки. Програма може вирішити переключитися на порт простого тексту, коли TLS на порту TLS також вийде з ладу. Вам потрібно знати, що це буде робити, і вибрати безпечні налаштування. І програми повинні використовувати безпечні настройки за замовчуванням.