StartTLS

StartTLS, Opportunistic TLS (англ. Transport Layer Security) стосується розширень у протоколах комунікації для простого тексту, які пропонують спосіб покращити передачу інформації у вигляді простого тексту до зашифрованого ( TLS або SSL ) замість використання окремого порту для зашифрованих комунікацій. Кілька протоколів використовують для цієї мети команду під назвою «STARTTLS». Це одна з форм опортуністичних шифрувань і в першу чергу призначена як протидія пасивному моніторингу .

Команда STARTTLS для IMAP і POP3 визначена в RFC 2595, для SMTP в RFC 3207, для XMPP в RFC 6120 і для NNTP в RFC 4642. Для IRC робоча група IRCv3 визначила розширення STARTTLS, хоча пізніше воно було застарілим[1]. FTP використовує команду "AUTH TLS", визначену в RFC 4217, а LDAP визначає OID розширення протоколу RFC 2830. HTTP використовує заголовок оновлення .

Багатошаровість

TLS не залежить від застосунку; словами в RFC 5246 :

Однією з переваг TLS є те, що він не залежить від протоколу застосунку. Протоколи вищого рівня можуть прозоро накладатися поверх протоколу TLS. Стандарт TLS, однак, не визначає, як протоколи додають захист за допомогою TLS; Рішення про те, як ініціювати встановлення зв’язку TLS і як інтерпретувати обмін сертифікатами автентифікації, залишаються на розсуд розробників і розробників протоколів, які працюють поверх TLS. [2]

Стиль, який використовується для визначення як використовувати TLS, відповідає тому самому розрізненню рівнів, яке також зручно підтримується кількома бібліотечними реалізаціями TLS. Наприклад,RFC 3207 розширення SMTP ілюструє наступний діалогі, як клієнт і сервер можуть почати безпечний сеанс: [3] 

  S: <waits for connection on TCP port 25>
  C: <opens connection>
  S: 220 mail.example.org ESMTP service ready
  C: EHLO client.example.org
  S: 250-mail.example.org offers a warm hug of welcome
  S: 250 STARTTLS
  C: STARTTLS
  S: 220 Go ahead
  C: <starts TLS negotiation>
  C & S: <negotiate a TLS session>
  C & S: <check result of negotiation>
  C: EHLO client.example.org[4]
  . . .

Остання команда EHLO, наведена вище, надана через безпечний канал. Зауважте, що автентифікація є необов’язковою для SMTP, і пропущена відповідь сервера тепер може безпечно пропонувати розширення SMTP AUTH PLAIN, якого немає у відповіді у вигляді простого тексту.

SSL порти

Крім використання оппортуністичного TLS, було визначено ряд TCP-портів для захищених SSL версій відомих протоколів. Вони встановлюють безпечний зв’язок, а потім представляють комунікаційний потік, ідентичний старому незашифрованому протоколу. Окремі порти SSL дають перевагу в меншій кількості часу затримки ; також менше метаданих передається в незашифрованому вигляді [5]. Деякі приклади:

Протокол призначення Нормальний порт Варіант SSL порт SSL
SMTP Відправити лист 25/587 SMTPS 465
POP3 Отримати електронну пошту 110 POP3S 995
IMAP Прочитайте електронну пошту 143 IMAPS 993
NNTP Читач новин 119/433 NNTPS 563
LDAP Доступ до каталогу 389 LDAPS 636
FTP Передача файлів 21 FTPS 990

Принаймні для протоколів електронної пошти,RFC 8314 надає перевагу окремим портам SSL замість STARTTLS.

Слабкі сторони та пом'якшення

Opportunistic TLS – це опортуністичний механізм шифрування. Оскільки початковий обмін (handshaking) відбувається у вигляді простого тексту, зловмисник, який контролює мережу, може змінити повідомлення сервера за допомогою атаки "людина посередині", щоб створити враження, що TLS недоступний (називається атакою STRIPTLS ). Більшість SMTP-клієнтів потім надсилають електронні листи та, можливо, паролі у вигляді простого тексту, часто без сповіщення користувача. Зокрема, багато SMTP-з’єднань виникають між поштовими серверами, де сповіщення користувачів не реально.

У вересні 2014 року було виявлено, що два інтернет-провайдери в Таїланді робили це зі своїми клієнтами [6] [7]. У жовтні 2014 року було виявлено, що Cricket Wireless, дочірня компанія AT&T, робить це зі своїми клієнтами. Така поведінка почалася ще у вересні 2013 року Aio Wireless, яка пізніше об’єдналася з Cricket, де ця практика продовжилася [8] [6].

Атаки STRIPTLS можна заблокувати, налаштувавши SMTP-клієнти вимагати TLS для вихідних з’єднань (наприклад, агент передачі повідомлень Exim може вимагати TLS через директиву «hosts_require_tls» [9] ). Однак, оскільки не кожен поштовий сервер підтримує TLS, не реально просто вимагати TLS для всіх з’єднань.

Приклад атаки типу STRIPTLS, що використовується в тайській технології масового стеження : [10]


Цю проблему вирішує автентифікація іменованих об’єктів на основі DNS (DANE), частина DNSSEC, і, зокрема,RFC 7672 для SMTP. DANE дозволяє пропонувати підтримку безпечного SMTP через запис TLSA. Це повідомляє клієнтам, які підключаються, що вони повинні вимагати TLS, таким чином запобігаючи атакам STRIPTLS. Подібним чином працює проект STARTTLS Everywhere від Electronic Frontier Foundation. Однак DNSSEC, через складність розгортання та своєрідну  критику [11], зіткнувся з низьким рівнем впровадження, і групою великих постачальників послуг електронної пошти, включаючи Microsoft, Google і Yahoo, був розроблений новий протокол під назвою SMTP MTA Strict Transport Security або MTA-STS [12]. MTA-STS не вимагає використання DNSSEC для автентифікації записів DANE TLSA, але покладається на систему центру сертифікації (CA) і підхід довіри при першому використанні (TOFU), щоб уникнути перехоплення. Модель TOFU зменшує складність, але без гарантій першого використання, які пропонує DNSSEC. Крім того, MTA-STS запроваджує механізм звітування про помилки та режим лише звітування, що забезпечує поступове розгортання та аудит на відповідність.

Популярність

Після викриття, зробленого Едвардом Сноуденом у світлі глобального скандалу з масовим стеженням, популярні постачальники послуг електронної пошти покращили захист електронної пошти, увімкнувши STARTTLS [13]. Facebook повідомив про це після ввімкнення STARTTLS і заохочення інших провайдерів  зробити те саме, поки Facebook не припинив свою службу електронної пошти в лютому 2014 року, 95% вихідної електронної пошти було зашифровано за допомогою Perfect Forward Secrecy і суворої перевірки сертифіката [14].

Примітки

  1. ↑ tls Extension. IRCv3 Working Group. 2012. Процитовано 6 квітня 2024.
  2. ↑ Tim Dierks; Eric Rescorla (August 2008). The Transport Layer Security (TLS) Protocol. RFC Editor. Процитовано 8 жовтня 2009.
  3. ↑ Paul Hoffman (February 2002). SMTP Service Extension for Secure SMTP over Transport Layer Security. RFC Editor. Процитовано 8 жовтня 2009.
  4. ↑ The last line in the example added for clarity. See e.g. the thread started by Paul Smith (26 січня 2009). STARTTLS & EHLO. ietf-smtp mailing list. Internet Mail Consortium. Процитовано 16 вересня 2015.
  5. ↑ Dovecot SSL documentation: http://wiki2.dovecot.org/SSL
  6. ↑ а б Hoffman-Andrews, Jacob (11 листопада 2014). ISPs Removing Their Customers' Email Encryption. Electronic Frontier Foundation. Процитовано 19 січня 2019.
  7. ↑ Google, Yahoo SMTP email servers hit in Thailand. 12 вересня 2014. Процитовано 31 липня 2015.
  8. ↑ The FCC Must Prevent ISPs From Blocking Encryption. 4 листопада 2014. Процитовано 31 липня 2015.
  9. ↑ Exim Internet Mailer - The smtp transport. exim.org. hosts_require_tls - Exim will insist on using a TLS session when delivering to any host that matches this list.
  10. ↑ Who's That Knocking at my door? Understanding Surveillance in Thailand (PDF). Privacy International: 21. January 2017. Процитовано 7 лютого 2020.
  11. ↑ Thomas Ptacek (18 березня 2016). Against DNSSEC.
  12. ↑ Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark. SMTP MTA Strict Transport Security (MTA-STS). tools.ietf.org (англ.). Процитовано 22 лютого 2019.
  13. ↑ Peterson, Andrea (12 серпня 2014). Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic. The Washington Post. Процитовано 2 листопада 2014.
  14. ↑ Cohen, David (19 серпня 2014). Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment. allfacebook.com. Архів оригіналу за 22 вересня 2014.

Посилання