что такое тип безопасности starttls
Является ли STARTTLS менее безопасным, чем TLS /SSL?
В Thunderbird (и я предполагаю, что у многих других клиентов тоже) у меня есть выбор между «SSL /TLS» и «STARTTLS».
Или другими словами:
Является ли STARTTLS менее безопасным, чем SSL /TLS, потому что он может вернуться к открытому тексту без уведомления?
7 ответов
Ответ на основе STARTTLS RFC для SMTP ( RFC 3207 ):
STARTTLS менее безопасен, чем TLS.
Вместо того, чтобы говорить сам, я позволю RFC говорить сам за себя, с четырьмя соответствующими битами, выделенными в BOLD :
Нет никакой разницы в безопасности между двумя параметрами.
SSL /TLS сначала открывает соединение SSL /TLS, затем начинает транзакцию SMTP. Это должно произойти на порту, который не имеет уже запущенного SMTP-сервера без SSL /TLS; невозможно настроить один порт для обработки как обычного текста, так и зашифрованных соединений из-за характера протоколов.
STARTTLS запускает транзакцию SMTP и ищет поддержку с другого конца для TLS в ответе на EHLO. Если клиент видит STARTTLS в списке поддерживаемых команд, он отправляет STARTTLS и начинает переговоры для шифрования. Все это может (и обычно происходит) на стандартном SMTP-порту 25, частично для обратной совместимости, но также для обеспечения оппортунистического шифрования между конечными точками, которые поддерживают его, но не обязательно требуют его.
Как правило, SSL /TLS используется только между конечными клиентами и серверами. STARTTLS чаще используется между MTA для обеспечения межсерверного транспорта.
Учитывая эти две реализации, STARTTLS может быть истолковано как небезопасное, если пользователь или администратор предполагают, что соединение зашифровано, но на самом деле не настроило его на необходимость шифрования. Тем не менее, используемое шифрование точно такое же, как SSL /TLS, и поэтому не более или менее уязвимо для атаки Man-in-the-middle за пределами этого типа ошибки конфигурации.
Вкратце, в этой заметке теперь рекомендуется:
В какой-то степени ответ зависит от того, что вы подразумеваете под «безопасным».
Во-первых, ваше резюме не совсем отражает разницу между SSL /TLS и STARTTLS.
Если клиент настроен на требование TLS, два подхода более или менее одинаково безопасны. Но есть некоторые тонкости о том, как STARTTLS необходимо использовать, чтобы сделать его безопасным, и для реализации STARTTLS немного сложнее получить эти данные.
Таким образом, простой ответ заключается в том, что если вы подключаетесь к серверу, который вы уже знаете, поддерживает TLS (как это должно быть в случае отправки или чтения электронной почты), вы должны использовать SSL /TLS. Если соединение атаковано, попытка подключения завершится неудачно, но ваш пароль и адрес электронной почты не будут скомпрометированы.
С другой стороны, если вы подключаетесь к какой-либо службе, которую вы не знаете, поддерживает ли она TLS, STARTTLS может быть немного лучше.
Когда был изобретен STARTTLS, «пассивные» атаки только для прослушивания были очень распространены, «активные» атаки, в которых злоумышленник вводил трафик, чтобы попытаться снизить уровень безопасности, были менее распространены. Через 20 или около того лет с тех пор активные атаки стали более осуществимыми и более распространенными.
Например, если вы пытаетесь использовать ноутбук в аэропорту или в каком-либо другом общественном месте и пытаетесь прочитать свою почту через Wi-Fi, который предоставляется там, вы не знаете, что делает сеть Wi-Fi с вашим трафиком. Для сетей Wi-Fi очень часто направлять определенные виды трафика на «прокси», которые вставляются между вашими клиентскими приложениями и серверами, с которыми они пытаются разговаривать. Для этих прокси-серверов тривиально отключить как STARTTLS, так и «попробовать один порт, а затем другой», чтобы заставить вашего клиента вернуться к cleartext. Да, это происходит, и это всего лишь один пример того, как ваш трафик может отслеживаться сетью. И такие атаки не ограничиваются трехбуквенными агентствами, поддерживающими государство, их можно снять подростком с компьютером за 35 долларов, который где-то скрыт в общественном месте.
Да, у вас есть основы правильно. И да, STARTTLS определенно менее безопасен. Мало того, что он может вернуться к открытому тексту без уведомления, а потому, что он подвержен атакам «человек-в-середине». Поскольку соединение начинается в режиме очистки, MitM может лишить команду STARTTLS и предотвратить распространение шифрования. Тем не менее, я считаю, что почтовые серверы могут указывать, что переводы происходят только после настройки зашифрованного туннеля. Поэтому вы можете обойти это.
Так почему же такая вещь существует? По соображениям совместимости. Если какая-либо из сторон не поддерживает шифрование, вы все равно можете получить правильное соединение.
Согласитесь с @Greg. Эти атаки возможны. Однако MTA могут быть сконфигурированы (в зависимости от MTA), чтобы использовать «обязательный TLS», а не «оппортунистический TLS». Это означает, что TLS и только TLS используются (это также включает STARTTLS) для транзакций электронной почты. Если удаленный MTA не поддерживает STARTTLS, письмо отскакивает.
Нет, это не менее безопасно, когда ваше приложение обрабатывает его правильно.
Есть четыре пути для обработки TLS, и многие программы позволяют вам выбирать:
Преимущество TLS на выделенном порту заключается в том, что вы можете быть уверены, что нет резервной копии при использовании той программы, которую вы еще не знаете или которая не раскрывает подробные настройки обработки ошибок в своем мастерском первого запуска.
Но в целом безопасность зависит от обработки ошибок безопасности. Программа может решить переключиться на открытый столбец, когда TLS на TLS-порту также терпит неудачу. Вам нужно знать, что он будет делать, и выбрать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.
Шифрование соединений OpenLDAP с помощью STARTTLS
OpenLDAP – это гибкий и простой в поддержке сервис каталогов LDAP. Однако из коробки сервер передает данные по незашифрованному соединению. В этом мануале вы узнаете, как шифровать соединения с OpenLDAP с помощью STARTTLS и перейти с обычных соединений на TLS на сервере Ubuntu 14.04.
Требования
Поддержка LDAP по SSL и по STARTTLS: в чем разница?
Существует два способа шифрования соединений LDAP по SSL/TLS.
Традиционно соединения LDAP, которые нужно зашифровать, обрабатывались по отдельном порту (обычно 636). Все соединение было защищено с помощью протокола SSL/ TLS. Этот процесс, LDAP по SSL, использует протокол ldaps://. Но этот метод шифрования устарел.
STARTTLS – альтернативный подход, который теперь является предпочтительным методом шифрования LDAP-соединений. STARTTLS защищает нешифрованное соединение по SSL/TLS после или во время подключения. Это позволяет обрабатывать незашифрованные и зашифрованные соединения по одному порту.
Настройка имени хоста и FQDN
Сначала нужно настроить сервер так, чтобы он правильно разрешал свое имя хоста и полное доменное имя (FQDN). Это необходимо, чтобы сертификаты были подтверждены клиентами. Предположим, сервер LDAP будет размещен на машине с доменным именем ldap.example.com.
Чтобы задать имя хоста во всех соответствующих местах на вашем сервере, используйте команду hostnamectl с параметром set-hostname. Задайте краткое имя хоста (без домена):
sudo hostnamectl set-hostname ldap
Теперь нужно установить FQDN в файле /etc/hosts:
sudo nano /etc/hosts
Найдите строку, которая отображает адрес 127.0.1.1. После этого IP-адреса укажите полное доменное имя сервера, а во втором поле – краткое имя хоста. Это должно выглядеть примерно так:
Сохраните и закройте файл.
Чтобы убедиться, что значения установлены правильно, введите:
Вы увидите краткое имя хоста:
Теперь запросите FQDN:
Установка сервера LDAP и пакета GnuTLS
Убедившись, что имя хоста установлено правильно, вы можете установить необходимое программное обеспечение. Если OpenLDAP у вас уже установлен и настроен, вы можете пропустить первый подраздел.
Установка сервера OpenLDAP
Если вы еще не установили OpenLDAP, пришло время сделать это. Обновите локальный индекс пакетов и установите пакет:
sudo apt-get update
sudo apt-get install slapd ldap-utils
Будет запрошен пароль администратора LDAP. Можете пропустить этот запрос и настроить пароль позже.
Чтобы получить доступ к остальным запросам информации, нужно переконфигурировать пакет после установки. Для этого введите:
sudo dpkg-reconfigure slapd
Теперь у программы появится много новых вопросов, которые будут заданы при прохождении этого процесса:
Установка SSL
После установки OpenLDAP можно продолжить установку пакетов, которые нужны для шифрования соединения. Пакет Ubuntu OpenLDAP скомпилирован на библиотеках SSL GnuTLS, поэтому для генерации учетных данных SSL нужно использовать GnuTLS:
sudo apt-get install gnutls-bin ssl-cert
Все необходимые инструменты установлены.
Создание шаблона сертификата
Чтобы зашифровать соединения, нужно настроить центр сертификации и использовать его для подписи ключей серверов LDAP в данной инфраструктуре. Поэтому для настройки одного сервера вам понадобятся два набора ключ-сертификат: один для центра сертификации и один для сервиса LDAP.
Чтобы создать необходимые сертификаты, подготовьте файлы шаблонов. Они будут содержать информацию, необходимую утилите certtool для создания сертификатов с соответствующими свойствами.
Создайте каталог для шаблонов:
sudo mkdir /etc/ssl/templates
Шаблон для ЦС
Сначала создайте шаблон для центра сертификации. Назовем этот файл ca_server.conf. Создайте и откройте файл в текстовом редакторе:
sudo nano /etc/ssl/templates/ca_server.conf
В файле нужно предоставить информацию для создания центра сертификации. Здесь вам нужно указать, что сертификат будет для CA (центра сертификации), добавив параметр ca. Также нужна опция cert_signing_key, чтобы дать сгенерированному сертификату возможность подписывать другие сертификаты. В cn можно выбрать любое описательное имя центра сертификации:
cn = LDAP Server CA
ca
cert_signing_key
Сохраните и закройте файл.
Шаблон для сервиса LDAP
Затем нужно создать шаблон для сертификата сервера LDAP по имени ldap_server.conf. Создайте и откройте файл в текстовом редакторе с правами sudo:
sudo nano /etc/ssl/templates/ldap_server.conf
Здесь также нужно предоставить данные о сервере. Укажите имя организации и задайте параметры tls_www_server, encryption_key и signature_key, чтобы наш сертификат имел базовую функциональность.
В данном случае в cn нужно указать FQDN сервера LDAP. Если это значение не соответствует домену, клиент отклонит сертификат сервера. Также нужно установить срок действия сертификата. Чтобы не менять его часто, создайте сертификат на 10 лет:
organization = «Example Inc»
cn = ldap.example.com
tls_www_server
encryption_key
signing_key
expiration_days = 3652
Сохраните и закройте файл.
Создание ключа и сертификата ЦС
Теперь, когда у вас есть шаблоны, вы можете создать две пары ключей и сертификатов. Сначала необходимо создать набор для ЦС.
Используйте программу certtool для создания закрытого ключа. Каталог /etc/ssl/private защищен от пользователей без прав root и является подходящим местом для хранения закрытых ключей. Можно сгенерировать закрытый ключ и записать его в файл ca_server.key в этом каталоге:
Теперь можно использовать закрытый ключ и файл шаблона для создания сертификата для ЦС. Запишите его в файл ca_server.pem в /etc/ssl/certs:
Теперь у вас есть пара из ключа и сертификата для центра сертификации. Вы можете использовать ее, чтобы подписать ключ, который будет применяться в шифровании LDAP.
Создание ключа и сертификата для сервиса LDAP
Затем нужно сгенерировать закрытый ключ для LDAP-сервера. Можно снова поместить его в каталог /etc/ssl/private (файл ldap_server.key) в целях безопасности.
Чтобы создать соответствующий ключ, введите:
Теперь у вас есть закрытый ключ для сервера LDAP и все необходимое для создания сертификата. Нужно задействовать почти все компоненты, которые вы создали до сих пор (сертификат и ключ CA, ключ и шаблон сервера LDAP).
Мы поместим сертификат в каталог /etc/ssl/certs в файл ldap_server.pem. Для этого нужна команда:
Доступ OpenLDAP к ключу LDAP
Теперь у вас есть все необходимые сертификаты и ключи. Однако в настоящее время процесс OpenLDAP не сможет получить доступ к своему собственному ключу.
Группа ssl-cert является владельцем каталога /etc/ssl/private. Вам нужно добавить пользователя, который запускает процесс OpenLDAP (здесь это openldap),в эту группу:
Теперь пользователь OpenLDAP имеет доступ к каталогу. Но вам все равно нужно предоставить группе права на файл ldap_server.key.
sudo chown :ssl-cert /etc/ssl/private/ldap_server.key
Теперь дайте группе ssl-cert право на чтение файла:
sudo chmod 640 /etc/ssl/private/ldap_server.key
Теперь процесс OpenSSL может получить доступ к ключу.
Настройка OpenLDAP для поддержки ключа и сертификата
Теперь у вас есть все файлы и правильно настроенный доступ к компонентам. Измените конфигурацию OpenLDAP, чтобы использовать файлы, которые вы создали. Для этого нужно создать файл LDIF с новыми конфигурациями и загрузить его в экземпляр LDAP.
Перейдите в домашний каталог и откройте файл addcerts.ldif.
Чтобы внести изменения в конфигурацию, нужно настроить таргетинг на запись cn=config DIT. Укажте, что атрибуты записи нужно изменить. Впоследствии нужно добавить атрибуты olcTLSCACertificateFile, olcCertificateFile и olcCertificateKeyFile и установить их в правильные расположения.
В итоге файл будет выглядеть так:
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca_server.pem
—
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap_server.pem
—
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_server.key
Сохраните и закройте файл.
С помощью команды ldapmodify обновите настройки OpenLDAP:
sudo service slapd force-reload
Теперь клиенты смогут шифровать соединения по порту ldap:// с помощью STARTTLS.
Настройка клиента
Чтобы подключиться к серверу LDAP и инициировать шифрование STARTTLS, клиенты должны иметь доступ к сертификату ЦС и запросить обновление.
Сервер OpenLDAP
Если вы взаимодействуете с OpenLDAP с самого сервера, вы можете настроить клиентские утилиты, скопировав сертификат ЦС и отредактировав конфигурации клиента.
Сначала скопируйте сертификат CA из каталога /etc/ssl/certs в файл в /etc/ldap. Назовите этот файл ca_certs.pem. Его можно использовать для хранения всех сертификатов ЦС, которые могут получить клиенты на этом компьютере. В данном случае он будет содержать только один сертификат:
sudo cp /etc/ssl/certs/ca_server.pem /etc/ldap/ca_certs.pem
Теперь можно настроить системный файл конфигурации для утилит OpenLDAP. Откройте файл в текстовом редакторе с правами sudo:
sudo nano /etc/ldap/ldap.conf
Измените значение TLS_CACERT на такое:
Сохраните и закройте файл.
Теперь все подключения будут принудительно использовать STARTTLS. Вы увидите:
Если вы что-то настроили не так, вы увидите ошибку:
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
Удаленные клиенты
Если вы подключаетесь к серверу OpenLDAP с удаленных серверов, вам нужно будет выполнить аналогичный процесс. Во-первых, вы должны скопировать сертификат CA на клиентскую машину. Вы можете легко справиться с этой задачей с помощью scp.
Перенаправление ключей SSH на клиент
Если вы подключаетесь к серверу OpenLDAP с помощью SSH-ключей, и клиентский компьютер у вас тоже удаленный, вам нужно будет добавить ключи на агент и переслать их при подключении к клиентской машине.
Для этого на локальном компьютере запустите агент SSH:
Добавьте SSH-ключ на агент:
Теперь вы можете перенаправить свои SSH-ключи при подключении к клиентской машине LDAP, добавив флаг –A:
Копирование сертификата ЦС
Подключившись к серверу OpenLDAP, вы можете скопировать сертификат ЦС:
Теперь добавьте скопированный сертификат в список сертификатов CA, о которых знает клиент. Это поместит сертификат в файл, если он уже существует, и создаст файл, если его еще нет:
Настройка клиента
Затем можно настроить глобальный конфигурационный файл для утилит LDAP и указать на файл ca_certs.pem. Откройте файл с привилегиями sudo:
sudo nano /etc/ldap/ldap.conf
Найдите опцию TLS_CACERT и укажите в ней файл ca_certs.pem.
Сохраните и закройте файл.
Проверьте обновление STARTTLS, набрав:
Если обновление STARTTLS прошло успешно, вы должны увидеть:
Принудительное направление соединений на TLS (опционально)
Вы успешно настроили сервер OpenLDAP, чтобы он мог легко обновлять обычные подключения LDAP до соединений TLS через STARTTLS. Однако сервер все еще поддерживает незашифрованные сеансы.
Во-первых, вам нужно найти соответствующую запись. Отобразите список всех DIT (это иерархии записей, которые обрабатывает сервер LDAP), о которых знает сервер OpenLDAP, а также все записи, которые настраивают каждый DIT.
На сервере OpenLDAP введите:
У вас может быть больше DIT и баз данных, если ваш сервер настроен на обработку более одного DIT. Здесь у нас есть один DIT с базовой записью dc=example,dc=com для домена example.com. Конфигурация DIT обрабатывается командой olcDatabase=<1>hdb,cn=config. Обратите внимание на DN DIT, для которых вы хотите принудительно включить шифрование.
Внесите изменения в файл LDIF. Создайте файл LDIF в домашнем каталоге и назовите его forcetls.ldif:
Внутри задайте DN, который должен обрабатываться только по TLS. В этом случае это будет dn: olcDatabase=<1>hdb,cn=config. Установите в changetype тип modify и добавьте атрибут olcSecurity. Задайте значение атрибута tls=1, чтобы включить принудительное шифрование TLS для этого DIT:
dn: olcDatabase=<1>hdb,cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1
Сохраните и закройте файл.
Чтобы применить новые параметры, введите:
sudo service slapd force-reload
Если вы попробуете найти DIT dc=example,dc=com, вы не сможете подключиться без флага –Z, который включает шифрование STARTTLS.
Убедитесь, что соединение STARTTLS работает правильно:
Основы HTTPS, TLS, SSL. Создание собственных x509 сертификатов. Пример настройки TLSv1.2 в Spring Boot
Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!
Что не так с HTTP?
Симметричное шифрование предполагает наличие общего ключа одновременно у отправителя и получателя, с помощью которого происходит шифровка и дешифровка данных. Данный тип не требователен к ресурсам, однако существенно страдает безопасность из-за опасности кражи ключа злоумышленником.
При использовании ассиметричного шифрования существует открытый ключ, который можно свободно распространять, и закрытый ключ, который держится в секрете у одной из сторон. Этот тип работает медленно, относительно симметричного шифрования, однако скомпрометировать закрытый ключ сложнее.
Что происходит на практике
Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Ys = 3 6 mod 17 = 15
Клиент случайно генерирует число 7 и возвращает серверу Yc = 3 7 mod 17 = 11
Сервер считает итоговое число 11 6 mod 17= 8, и клиент 15 7 mod 17 = 8
После этого соединение считается установленным, и происходит передача полезной информации
Двусторонний TLS
Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.
TLSv1.3
Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2018 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др. Интернет медленно но верно обновляется до TLSv1.3, однако все еще большинство сайтов работают по протоколу TLSv1.2. Поэтому информация в этой статье остается актуальной.
Выпускаем собственные сертификаты
Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем «password» длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:
Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:
Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.
Теперь у нас есть сертификат, которому в будущем будут доверять наши клиент и сервер. Похожим образом сделаем приватные ключи и запросы на подпись сертификата для них:
После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем «password»:
Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:
Для удобства, все описанные выше действия упакованы в bash script.
Настройка TLS в Spring Boot приложении
Основой для нашего проекта послужит шаблон с https://start.spring.io/ с одной лишь зависимостью Spring Web. Для включения TLS указываем в application.properties:
После этого указываем Spring тип keystore, путь к нему и пароль:
Для проверки доступа создадим минимальный контроллер:
Запускаем проект. Попробуем сделать запрос с помощью curl:
На этот раз все сработало, TLS в Spring Boot работает! Мы на этом не остановимся, добавим в приложение аутентификацию клиента (указываем truststore):
Запускаем и снова пытаемся выполнить запрос:
Очевидно, что сервер закрыл соединение, так как curl не предоставил никакого сертификата. Дополним запрос клиентским сертификатом и его закрытым ключом:
Итоги
В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!