StartTLS Opportunistic TLS англ Transport Layer Security стосується розширень у протоколах комунікації для простого текс

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, хоча пізніше воно було застарілим. FTP використовує команду "AUTH TLS", визначену в RFC 4217, а LDAP визначає (OID) розширення протоколу RFC 2830. HTTP використовує заголовок оновлення .

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

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

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

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

 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 . . .

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

SSL порти

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

Протокол	призначення	Нормальний порт	Варіант 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 року було виявлено, що два інтернет-провайдери в Таїланді робили це зі своїми клієнтами . У жовтні 2014 року було виявлено, що Cricket Wireless, дочірня компанія , робить це зі своїми клієнтами. Така поведінка почалася ще у вересні 2013 року Aio Wireless, яка пізніше об’єдналася з Cricket, де ця практика продовжилася .

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

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

 220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp ehlo a 250-smtp.gmail.com at your service, [REDACTED SERVICE] 250-SIZE 35882577 250-8BITMIME # The STARTTLS command is stripped here 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8

 220 smtp.gmail.com ESMTP - gsmtp ehlo a 250-smtp.gmail.com at your service 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8

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

Примітки

tls Extension. IRCv3 Working Group. 2012. Процитовано 6 April 2024.
Tim Dierks; Eric Rescorla (August 2008). The Transport Layer Security (TLS) Protocol. . Процитовано 8 October 2009.
Paul Hoffman (February 2002). SMTP Service Extension for Secure SMTP over Transport Layer Security. . Процитовано 8 October 2009.
The last line in the example added for clarity. See e.g. the thread started by Paul Smith (26 January 2009). STARTTLS & EHLO. ietf-smtp mailing list. . Процитовано 16 September 2015.
(Dovecot) SSL documentation: http://wiki2.dovecot.org/SSL
Hoffman-Andrews, Jacob (11 November 2014). ISPs Removing Their Customers' Email Encryption. Electronic Frontier Foundation. Процитовано 19 January 2019.
Google, Yahoo SMTP email servers hit in Thailand. 12 September 2014. Процитовано 31 July 2015.
The FCC Must Prevent ISPs From Blocking Encryption. 4 November 2014. Процитовано 31 July 2015.
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.
Who's That Knocking at my door? Understanding Surveillance in Thailand (PDF). Privacy International: 21. January 2017. Процитовано 7 February 2020.
Thomas Ptacek (18 March 2016). Against DNSSEC.
Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark. SMTP MTA Strict Transport Security (MTA-STS). tools.ietf.org (англ.). Процитовано 22 лютого 2019.
Peterson, Andrea (12 August 2014). Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic. The Washington Post. Процитовано 2 November 2014.
Cohen, David (19 August 2014). Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment. allfacebook.com. оригіналу за 22 September 2014.

Посилання

Secure Email Tests and Tools verify STARTTLS in real-time dialog like example above
Margolis, Daniel; Risher, Mark; Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet. SMTP MTA Strict Transport Security (MTA-STS). IETF. A mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections.

[1] tls Extension. IRCv3 Working Group. 2012. Процитовано 6 April 2024.

[2] Tim Dierks; Eric Rescorla (August 2008). The Transport Layer Security (TLS) Protocol. . Процитовано 8 October 2009.

[3] Paul Hoffman (February 2002). SMTP Service Extension for Secure SMTP over Transport Layer Security. . Процитовано 8 October 2009.

[4] The last line in the example added for clarity. See e.g. the thread started by Paul Smith (26 January 2009). STARTTLS & EHLO. ietf-smtp mailing list. . Процитовано 16 September 2015.

[5] (Dovecot) SSL documentation: http://wiki2.dovecot.org/SSL

[eff-isp-removing-encryption-6] Hoffman-Andrews, Jacob (11 November 2014). ISPs Removing Their Customers' Email Encryption. Electronic Frontier Foundation. Процитовано 19 January 2019.

[7] Google, Yahoo SMTP email servers hit in Thailand. 12 September 2014. Процитовано 31 July 2015.

[8] The FCC Must Prevent ISPs From Blocking Encryption. 4 November 2014. Процитовано 31 July 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 February 2020.

[11] Thomas Ptacek (18 March 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 August 2014). Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic. The Washington Post. Процитовано 2 November 2014.

[14] Cohen, David (19 August 2014). Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment. allfacebook.com. оригіналу за 22 September 2014.