StartTLS: відмінності між версіями

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Інтерактивний перегляд історії
[перевірена версія][очікує на перевірку]
← Попереднє редагування
Вилучено вміст Додано вміст
ВізуальнийВікірозмітка
Немає опису редагування
TohaomgBot (обговорення | внесок)
Боти
417 320 редагувань
м Перекладено дати в примітках з англійської (чи іншої іноземної мови) на українську
 
(Не показано 2 проміжні версії 2 користувачів)
Рядок 1: Рядок 1:
'''StartTLS''', '''Opportunistic TLS''' ({{lang-en|Transport Layer Security}}) стосується розширень у протоколах комунікації для простого тексту, які пропонують спосіб покращити передачу інформації у вигляді простого тексту до зашифрованого ( [[Transport Layer Security|TLS]] або [[Transport Layer Security|SSL]] ) замість використання окремого порту для зашифрованих комунікацій. Кілька протоколів використовують для цієї мети команду під назвою «'''STARTTLS'''». Це одна з форм [[Опортуністичне шифрування|опортуністичних шифрувань]] і в першу чергу призначена як протидія пасивному моніторингу .
{{без джерел|дата=січень 2018}}
'''STARTTLS''' це розширення протоколів обміну текстовою інформацією. На відміну від варіанту з окремим портом для обміну зашифрованою інформацією, STARTTLS пропонує спосіб обміну інформацією без залучення окремого порту.


Команда STARTTLS для [[IMAP]] і [[Post Office Protocol|POP3]] визначена в {{IETF RFC|2595}}, для [[SMTP]] в {{IETF RFC|3207}}, для [[XMPP]] в {{IETF RFC|6120}} і для [[NNTP]] в {{IETF RFC|4642}}. Для [[IRC]] робоча група IRCv3 визначила розширення STARTTLS, хоча пізніше воно було застарілим<ref>{{Cite web|url=https://ircv3.net/specs/deprecated/tls|title=tls Extension|date=2012|publisher=IRCv3 Working Group|access-date=6 квітня 2024}}</ref>. [[FTP]] використовує команду "AUTH TLS", визначену в {{IETF RFC|4217}}, а [[LDAP]] визначає [[Ідентифікатор об'єкта|OID]] розширення протоколу {{IETF RFC|2830}}. [[HTTP]] використовує заголовок оновлення .
STARTTLS для [[IMAP]] та [[POP3]] описані в RFC 2595, для [[SMTP]] в RFC 2487, та в RFC 4642 для [[NNTP]].

== Багатошаровість ==
TLS не залежить від застосунку; словами в {{IETF RFC|5246}} :

: Однією з переваг TLS є те, що він не залежить від протоколу застосунку. Протоколи вищого рівня можуть прозоро накладатися поверх протоколу TLS. Стандарт TLS, однак, не визначає, як протоколи додають захист за допомогою TLS; Рішення про те, як ініціювати встановлення зв’язку TLS і як інтерпретувати обмін сертифікатами автентифікації, залишаються на розсуд розробників і розробників протоколів, які працюють поверх TLS. <ref>{{Cite web|url=http://tools.ietf.org/html/rfc5246|title=The Transport Layer Security (TLS) Protocol|last=Tim Dierks|last2=Eric Rescorla|date=August 2008|publisher=[[RFC Editor]]|access-date=8 жовтня 2009}}</ref>

Стиль, який використовується для визначення як використовувати TLS, відповідає тому самому розрізненню рівнів, яке також зручно підтримується кількома бібліотечними реалізаціями TLS. Наприклад,{{IETF RFC|3207}} розширення SMTP ілюструє наступний діалогі, як клієнт і сервер можуть почати безпечний сеанс: <ref>{{Cite web|url=http://tools.ietf.org/html/rfc3207|title=SMTP Service Extension for Secure SMTP over Transport Layer Security|last=Paul Hoffman|date=February 2002|publisher=[[RFC Editor]]|access-date=8 жовтня 2009}}</ref>

S: &lt;waits for connection on TCP port 25&gt;
C: &lt;opens connection&gt;
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: &lt;starts TLS negotiation&gt;
C & S: &lt;negotiate a TLS session&gt;
C & S: &lt;check result of negotiation&gt;
C: EHLO client.example.org<ref>The last line in the example added for clarity. See e.g. the thread started by {{Cite web |author=Paul Smith |title=STARTTLS & EHLO |url=http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg01818.html |work=ietf-smtp mailing list |publisher=[[Internet Mail Consortium]] |date=26 січня 2009 |access-date=16 вересня 2015}}</ref>
. . .

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

== SSL порти ==
Крім використання оппортуністичного TLS, було визначено ряд TCP-портів для захищених SSL версій відомих протоколів. Вони встановлюють безпечний зв’язок, а потім представляють комунікаційний потік, ідентичний старому незашифрованому протоколу. Окремі порти SSL дають перевагу в меншій кількості [[Час затримки (RTT)|часу затримки]] ; також менше [[Метадані|метаданих]] передається в незашифрованому вигляді <ref>[[Dovecot (software)|Dovecot]] SSL documentation: http://wiki2.dovecot.org/SSL</ref>. Деякі приклади:
{| class="wikitable"
!Протокол
! призначення
! Нормальний порт
! Варіант SSL
! порт SSL
|-
| [[SMTP]]
| Відправити лист
| 25/587
| SMTPS
| 465
|-
| [[Post Office Protocol|POP3]]
| Отримати електронну пошту
| 110
| [[Post Office Protocol|POP3S]]
| 995
|-
| [[IMAP]]
| Прочитайте електронну пошту
| 143
| [[IMAP|IMAPS]]
| 993
|-
| [[NNTP]]
| Читач новин
| 119/433
| [[NNTP|NNTPS]]
| 563
|-
| [[LDAP]]
| Доступ до каталогу
| 389
| [[LDAP|LDAPS]]
| 636
|-
| [[FTP]]
| Передача файлів
| 21
| FTPS
| 990
|}
Принаймні для протоколів електронної пошти,{{IETF RFC|8314}} надає перевагу окремим портам SSL замість STARTTLS.

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

У вересні 2014 року було виявлено, що два інтернет-провайдери в [[Таїланд|Таїланді]] робили це зі своїми клієнтами <ref name="eff-isp-removing-encryption">{{Cite news|url=https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks|title=ISPs Removing Their Customers' Email Encryption|last=Hoffman-Andrews|first=Jacob|date=11 листопада 2014|work=[[Electronic Frontier Foundation]]|access-date=19 січня 2019}}</ref> <ref>{{Cite news|url=http://www.telecomasia.net/content/google-yahoo-smtp-email-severs-hit-thailand|title=Google, Yahoo SMTP email servers hit in Thailand|date=12 вересня 2014|access-date=31 липня 2015}}</ref>. У жовтні 2014 року було виявлено, що Cricket Wireless, дочірня компанія [[AT&T]], робить це зі своїми клієнтами. Така поведінка почалася ще у вересні 2013 року Aio Wireless, яка пізніше об’єдналася з Cricket, де ця практика продовжилася <ref>{{Cite news|url=http://www.goldenfrog.com/blog/fcc-must-prevent-isps-blocking-encryption|title=The FCC Must Prevent ISPs From Blocking Encryption|date=4 листопада 2014|access-date=31 липня 2015}}</ref> <ref name="eff-isp-removing-encryption" />.

Атаки STRIPTLS можна заблокувати, налаштувавши SMTP-клієнти вимагати TLS для вихідних з’єднань (наприклад, [[Поштовий сервер|агент передачі повідомлень]] [[Exim]] може вимагати TLS через директиву «hosts_require_tls» <ref>{{Cite web|url=http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_smtp_transport.html|title=Exim Internet Mailer - The smtp transport|website=exim.org|quote=hosts_require_tls - Exim will insist on using a TLS session when delivering to any host that matches this list.}}</ref> ). Однак, оскільки не кожен поштовий сервер підтримує TLS, не реально просто вимагати TLS для всіх з’єднань.

Приклад атаки типу STRIPTLS, що використовується в тайській технології масового стеження : <ref>{{Cite journal|date=January 2017|title=Who's That Knocking at my door? Understanding Surveillance in Thailand|url=https://privacyinternational.org/sites/default/files/2017-10/thailand_2017_0.pdf|journal=Privacy International|pages=21|access-date=7 лютого 2020}}</ref>
{{col-begin}}
{{col-break}}
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
{{col-break}}
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
{{col-end}}


Цю проблему вирішує автентифікація іменованих об’єктів на основі DNS (DANE), частина [[DNSSEC]], і, зокрема,{{IETF RFC|7672}} для SMTP. DANE дозволяє пропонувати підтримку безпечного SMTP через запис TLSA. Це повідомляє клієнтам, які підключаються, що вони повинні вимагати TLS, таким чином запобігаючи атакам STRIPTLS. Подібним чином працює проект STARTTLS Everywhere від [[Electronic Frontier Foundation]]. Однак DNSSEC, через складність розгортання та своєрідну  критику <ref>{{Cite news|url=http://sockpuppet.org/blog/2015/01/15/against-dnssec/|title=Against DNSSEC|last=Thomas Ptacek|date=18 березня 2016}}</ref>, зіткнувся з низьким рівнем впровадження, і групою великих постачальників послуг електронної пошти, включаючи Microsoft, Google і Yahoo, був розроблений новий протокол під назвою SMTP MTA Strict Transport Security або MTA-STS <ref>{{Cite web|url=https://tools.ietf.org/html/rfc8461.html|title=SMTP MTA Strict Transport Security (MTA-STS)|last=Ramakrishnan|first=Binu|last2=Brotman|first2=Alexander|last3=Jones|first3=Janet|last4=Margolis|first4=Daniel|last5=Risher|first5=Mark|website=tools.ietf.org|language=en|access-date=2019-02-22}}</ref>. MTA-STS не вимагає використання DNSSEC для автентифікації записів DANE TLSA, але покладається на систему [[Акредитований центр сертифікації ключів|центру сертифікації]] (CA) і підхід довіри при першому використанні (TOFU), щоб уникнути перехоплення. Модель TOFU зменшує складність, але без гарантій першого використання, які пропонує DNSSEC. Крім того, MTA-STS запроваджує механізм звітування про помилки та режим лише звітування, що забезпечує поступове розгортання та аудит на відповідність.

== Популярність ==
Після викриття, зробленого [[Едвард Сноуден|Едвардом Сноуденом]] у світлі [[Викриття масового стеження у 2013 році|глобального скандалу з масовим стеженням]], популярні постачальники послуг електронної пошти покращили захист електронної пошти, увімкнувши STARTTLS <ref>{{Cite news|url=https://www.washingtonpost.com/blogs/the-switch/wp/2014/08/12/facebooks-security-chief-on-the-snowden-effect-the-messenger-app-backlash-and-staying-optimistic/|title=Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic|last=Peterson|first=Andrea|date=12 серпня 2014|work=[[The Washington Post]]|access-date=2 листопада 2014}}</ref>. [[Facebook]] повідомив про це після ввімкнення STARTTLS і заохочення інших провайдерів  зробити те саме, поки Facebook не припинив свою службу електронної пошти в лютому 2014 року, 95% вихідної електронної пошти було зашифровано за допомогою [[Пряма секретність|Perfect Forward Secrecy]] і суворої перевірки сертифіката <ref>{{Cite web|url=http://allfacebook.com/facebook-95-notification-emails-encrypted-thanks-providers-starttls-deployment_b134023|title=Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment|last=Cohen|first=David|date=19 серпня 2014|website=allfacebook.com|archive-url=https://web.archive.org/web/20140922222720/http://allfacebook.com/facebook-95-notification-emails-encrypted-thanks-providers-starttls-deployment_b134023|archive-date=22 вересня 2014|url-status=live|access-date=}}</ref>.

== Примітки ==
{{Reflist}}

== Посилання ==
* [https://www.checktls.com/TestReceiver Secure Email Tests and Tools] verify STARTTLS in real-time dialog like example above
* [https://web.archive.org/web/20140610053143/https://starttls.info/ Verify if a receiving domain has STARTTLS enabled for email and with which security level]
* {{cite web | url = https://tools.ietf.org/html/draft-ietf-uta-mta-sts | title = SMTP MTA Strict Transport Security (MTA-STS) | first1 = Daniel | last1 = Margolis | first2 = Mark | last2 = Risher | first3 = Binu | last3 = Ramakrishnan | first4 = Alexander | last4 = Brotman | first5 = Janet | last5 = Jones | publisher = IETF }} A mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections.


{{Compu-network-stub}}
{{TLS/SSL}}
{{TLS/SSL}}
[[Категорія:Протоколи електронної пошти]]
[[Категорія:Інтернет-протоколи]]
[[Категорія:Інтернет-протоколи]]
[[Категорія:Захист інформації]]
[[Категорія:Криптографічні протоколи]]

Поточна версія на 01:21, 4 вересня 2024

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

Примітки

[ред. | ред. код]
  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.

Посилання

[ред. | ред. код]
Отримано з https://uk.wikipedia.org/w/index.php?title=StartTLS&oldid=43424075