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]

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, через складність розгортання та своєрідну  критику ^[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].