Green-sell.info

Новые технологии
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Тип безопасности ssl tls

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Что такое технология DPI?

Что такое IPS, IDS, UTM?

Зачем нужен Shodan, когда есть Google?

Защита в публичных сетях: MITM атака

Как работает интернет-безопасность: TLS, SSL и CA

Что скрыто за замком?

Много раз в день вы посещаете веб-сайты, на которых вас просят войти под своим именем пользователя, адресом электронной почты и паролем. Банковские сайты, сайты социальных сетей, почтовые службы, сайты электронной коммерции и новостные сайты — это всего лишь несколько типов сайтов, использующих этот механизм.

Каждый раз, когда вы входите на один из этих сайтов, вы, по сути, говорите: «Да, я доверяю этому сайту, поэтому я хочу поделиться с ним своей личной информацией». Эти данные могут включать ваше имя, пол, физический адрес, адрес электронной почты, а иногда даже информацию о кредитной карте.

Но откуда вы знаете, что можете доверять определенному веб-сайту? Иными словами, что делает веб-сайт для защиты вашей транзакции, чтобы вы могли доверять ей?

Эта статья направлена на демистификацию механизмов, которые делают сайт безопасным. Мы начнем с обсуждения веб-протоколов HTTP и HTTPS и концепции безопасности транспортного уровня (TLS — Transport Layer Security), которая является одним из криптографических протоколов. Затем мы объясним центры сертификации (CA — Certificate Authorities) и самозаверяющие сертификаты и как они могут помочь защитить веб-сайт. Наконец, я представлю некоторые инструменты с открытым исходным кодом, которые вы можете использовать для создания и управления сертификатами.

Защита маршрутов через HTTPS

Самый простой способ понять защищенный веб-сайт — это увидеть его в действии. К счастью, сегодня найти защищенный веб-сайт гораздо проще, чем незащищенный веб-сайт в Интернете. Но, поскольку вы уже находитесь на сайте wiki.merionet.ru, будем использовать его в качестве примера. Независимо от того, какой браузер вы используете, вы должны увидеть значок, который выглядит как замок рядом с адресной строкой. Нажмите на значок замка, и вы должны увидеть что-то похожее на это.

По умолчанию веб-сайт не является безопасным, если он использует протокол HTTP. Добавление сертификата, настроенного через хост сайта, может преобразовать сайт из незащищенного сайта HTTP в защищенный сайт HTTPS. Значок замка обычно указывает, что сайт защищен через HTTPS.

Нажмите на сертификат, чтобы увидеть CA сайта. В зависимости от вашего браузера вам может понадобиться скачать сертификат, чтобы увидеть его.

Здесь вы можете узнать кое-что о сертификате, кем, кому и когда был выдан. Эта информация о сертификате позволяет конечному пользователю проверить, что сайт безопасен для посещения.

ВНИМАНИЕ: Если вы не видите знак сертификата на веб-сайте или если вы видите знак, указывающий на то, что веб-сайт не защищен, пожалуйста, не входите в систему и не выполняйте действия, требующие ваших личных данных. Это довольно опасно!

Если вы видите предупреждающий знак, который редко встречается на большинстве общедоступных веб-сайтов, это обычно означает, что срок действия сертификата истек или используется самозаверяющий сертификат вместо сертификата, выпущенного через доверенный CA.

Интернет-протоколы с TLS и SSL

TLS — это текущее поколение старого протокола Secure Socket Layer (SSL). Лучший способ понять его место — посмотреть на модель OSI.

Есть шесть уровней, которые составляют Интернет, каким мы его знаем сегодня: физический, данные, сеть, транспорт, безопасность и приложения. Физический уровень является базовой основой, и он наиболее близок к реальному оборудованию. Прикладной уровень является наиболее абстрактным и ближайшим к конечному пользователю. Уровень безопасности можно рассматривать как часть уровня приложений, а TLS и SSL, которые являются криптографическими протоколами, разработанными для обеспечения безопасности связи по компьютерной сети, находятся на уровне безопасности.

Основным вариантом использования TLS является шифрование связи между веб-приложениями и серверами, такими как веб-браузеры, загружающие веб-сайт. Протокол TLS также можно использовать для шифрования других сообщений, таких как электронная почта, обмен сообщениями и передача голоса по IP (VOIP).

Центры сертификации и самозаверяющие сертификаты

Центр Сертификации (CA) — это доверенная организация, которая может выдавать цифровой сертификат.

TLS и SSL могут сделать соединение безопасным, но для механизма шифрования необходим способ его проверки — это сертификат SSL/TLS. TLS использует механизм, называемый асимметричным шифрованием, который представляет собой пару ключей безопасности, называемых закрытым ключом (private key) и открытым ключом (public key). Важно знать, что центры сертификации, такие как GlobalSign, DigiCert и GoDaddy являются внешними доверенными поставщиками, которые выпускают сертификаты, которые используются для проверки сертификата TLS/SSL, используемого веб-сайтом. Этот сертификат импортируется на хост-сервер для защиты сайта.

Прежде чем какой-либо крупный веб-браузер, такой как Chrome, Firefox, Safari или Internet Explorer, подключится к вашему серверу по протоколу HTTPS, он уже имеет в своем распоряжении набор сертификатов, которые можно использовать для проверки цифровой подписи, найденной в сертификате вашего сервера. Эти цифровые сертификаты веб-браузера называются сертификатами CA. Если с сертификатом на сервере все ок, то мы попадаем на сайт, а если нет, то браузер покажет нам предупреждение. Закрытые ключи, используемые для подписи сертификатов сервера, уже имеют соответствующие пары открытых ключей в веб-браузерах пользователей.

Однако CA может быть слишком дорогим или сложным, когда вы просто пытаетесь протестировать веб-сайт или услугу в разработке. У вас должен быть доверенный ЦС для производственных целей, но разработчикам и администраторам веб-сайтов необходим более простой способ тестирования веб-сайтов, прежде чем они будут развернуты в рабочей среде — именно здесь приходят самозаверяющие сертификаты.

Самозаверяющий сертификат — это сертификат TLS/SSL, подписанный лицом, которое его создает, а не доверенным центром сертификации. Создать самозаверяющий сертификат на компьютере очень просто, и он может позволить вам протестировать защищенный веб-сайт, не покупая дорогой сертификат, подписанный СА, сразу. Хотя самозаверяющий сертификат определенно рискованно использовать в производственной среде, он является простым и гибким вариантом для разработки и тестирования на подготовительных этапах.

Инструменты с открытым исходным кодом для генерации сертификатов

Для управления сертификатами TLS/SSL доступно несколько инструментов с открытым исходным кодом. Наиболее известным из них является OpenSSL, который включен во многие дистрибутивы Linux и в macOS. Тем не менее, другие инструменты с открытым исходным кодом также доступны.

  • OpenSSL — Самый известный инструмент с открытым исходным кодом для реализации библиотек TLS и шифрования Apache
  • EasyRSA — Утилита командной строки для создания и управления PKI CA
  • CFSSL — PKI/TLS «Швейцарский нож» от Cloudflare
  • Lemur — Инструмент создания TLS от Netflix
  • TLS/SSL
  • Безопасность
  • Сертификаты
  • 118
  • 3

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Что Такое SSL/TLS И HTTPS? Установка Сертификата Безопасности

Что такое SSL? SSL является аббревиатурой для Secure Sockets Layer. Это тип цифровой безопасности, которая позволяет зашифровать связь между веб-сайтом и веб-браузером. Технология в настоящее время устарела и полностью заменена TLS.

Что такое TLS? Это означает Transport Layer Security и обеспечивает конфиденциальность данных так же, как и SSL. Поскольку SSL фактически больше не используется, это правильный термин, который люди должны начать использовать.

Что таоке HTTPS? Это безопасное расширение HTTP. Веб-сайты, устанавливающие и настраивающие SSL/TLS-сертификат, могут использовать протокол HTTPS для установления безопасного соединения с сервером.

  • Цель SSL/TLS — сделать соединение безопасным для передачи конфиденциальной информации, включая личные данные, информацию о платеже или регистрации.
  • Это альтернатива простой передаче текстовых данных, в которой ваше соединение с сервером не зашифровано, и это затрудняет мошенникам и хакерам отслеживание соединения и кражу ваших данных.
  • Большинство людей знают, что такое SSL/TLS. Это сертификаты, которые используются веб-мастерами для защиты своих веб-сайтов и обеспечения безопасного доступа для людей к транзакциям.
  • Вы можете определить, использует ли веб-сайт сертификат безопасности, потому что рядом с URL-адресом в адресной строке появится значок маленького замочка.

В этом руководстве вы узнаете:

Как работают сертификаты SSL/TLS?

Сертификаты SSL/TLS работают путём цифровой привязки криптографического ключа к идентифицирующей информации компании. Это позволяет им шифровать передачу данных таким образом, что они не могут быть расшифрованы третьими лицами.

SSL/TLS работает, имея как частный, так и открытый ключ, а также ключи сеанса для каждого уникального безопасного сеанса. Когда посетитель вводит защищённый SSL-адрес в свой веб-браузер или переходит на безопасную страницу, браузер и веб-сервер устанавливают соединение.

Во время первоначального подключения общедоступные и закрытые ключи будут использоваться для создания ключа сеанса, который затем будет использоваться для шифрования и дешифрования передаваемых данных. Этот ключ сеанса останется действительным в течение ограниченного времени и будет использоваться только для данного сеанса.

Вы можете определить, использует ли сайт SSL, по значку замочка или зелёной полосе в верхней части браузера. Вы можете щёлкнуть по этому значку, чтобы просмотреть информацию о том, кому принадлежит сертификат, и управлять настройками SSL.

Когда и почему SSL/TLS необходимы?

SSL/TLS является обязательным, когда передаётся конфиденциальная информация, такая как имена пользователей и пароли или информация о платёжной обработке.

Цель SSL/TLS состоит в том, чтобы убедиться, что только один человек — лицо или организация, утверждённое пользователем, может получить доступ к передаваемым данным. Это особенно важно, когда вы думаете о том, между сколькими устройствами и серверами передаются данные до того, как они достигнут своего пункта назначения.

Существует три основных варианта использования SSL/TLS для вашего веб-сайта:

  • Когда вам нужна аутентификация: любой сервер может претендовать на роль вашего сервера, захватив информацию, которую люди передают. SSL/TLS позволяет вам подтвердить личность вашего сервера, чтобы люди знали, что вы являетесь тем, кем вы говорите.
  • Чтобы внушить доверие: если вы используете сайт электронной коммерции или спрашиваете пользователей о том, какие данные важны для них, вы должны поддерживать чувство доверия. Использование сертификата SSL/TLS является видимым способом показать посетителям, что они могут вам доверять, и это намного эффективнее всего, что вы могли бы сказать о себе.
  • Когда вам нужно соблюдать отраслевые стандарты: в некоторых отраслях, таких как финансовая, вам необходимо будет поддерживать определённые базовые уровни безопасности. Существуют также правила в области платёжных карт (PCI), которых необходимо придерживаться, если вы хотите принять информацию о кредитной карте на своём веб-сайте. И одним из этих требований является использование сертификата SSL/TLS.
Читать еще:  Безопасный режим f8

Помните, что SSL можно использовать практически на любом устройстве, что также делает его универсальным выбором безопасности в современном мире. Преимущества использования SSL-сертификата перевешивают время и денежные средства, необходимые для их настройки, так что вам нечего терять.

Влияет ли SSL/TLS на SEO?

Короткий ответ: да.

Google внёс изменения в свой алгоритм еще в 2014 году, чтобы определить приоритеты веб-сайтов, которые использовали SSL-сертификат, и с тех пор они продолжают уделять особое внимание сертификатам SSL. Они официально заявили, что сайты со статистикой SSL обойдут сайты без таковой, чтобы все остальные факторы были равны, и хотя защищённые сайты составляют только 1% результатов, 40% запросов возвращают хотя бы один защищённый SSL сайт на первую страницу.

На практике SSL не слишком сильно влияет, когда дело доходит до SEO, и простая установка SSL-сертификата на ваш сайт будет иметь гораздо меньшее значение, чем создание регулярного свежего контента и создание сильного профиля входящей ссылки. Но это не значит, что вы должны совсем забыть о них.

Также важно помнить, что поисковые системы используют целый ряд различных показателей, чтобы определить, где находится сайт. Одним из таких показателей является то, как часто люди возвращаются с вашего сайта на страницу результатов, и наличие сертификата SSL может повлиять на разницу между теми, кто покупает у вас, а кто проходит мимо. Множество других показателей, которые используются для ранжирования сайтов, могут быть затронуты, когда вы выбираете, использовать ли SSL-сертификат или нет.

Настройка SSL-сертификата повлияет на производительность поисковой системы (англ) вашего сайта, но вы должны использовать его не только по этой причине. Вместо этого настройте SSL-сертификат, чтобы повысить доверие между вашими посетителями и улучшить SEO в качестве бонуса.

Какое отношение имеют SSL/TLS к HTTPS?

Когда вы устанавливаете SSL-сертификат, вы настраиваете его для передачи данных с помощью HTTPS. Эти две технологии идут рука об руку, и вы не можете использовать одно без другого.

URL-адресам предшествует либо HTTP (Hypertext Transfer Protocol), либо протокол HTTPS (Hypertext Transfer Protocol Secure). Это эффективно определяет, как передаются любые данные, которые вы отправляете и получаете.

SSL/TLS не требуют огромных затрат. Найдите доступные SSL-предложения с Hostinger!

Это означает, что другой способ определить, использует ли сайт сертификат SSL, — это проверить URL-адрес и посмотреть, содержит ли он HTTP или HTTPS. Это связано с тем, что для соединений HTTPS требуется сертификат безопасности SSL.

Chrome указывает, использует ли сайт SSL/TLS

В большинстве основных браузеров, включая Google Chrome, Firefox и Microsoft Edge, наличие безопасного соединения будет заметно отображаться при доступе пользователей к сайту. Например, в Chrome вы увидите значок зелёного замочка в адресной строке рядом с сообщением Безопасный. Пользователи могут просмотреть более подробную информацию о сертификате SSL, щёлкнув по нему.

Кроме того, с момента введения Chrome 68 (англ) в июле 2018 года веб-сайты без сертификата SSL/TLS отображают предупреждение Небезопасно.

Поскольку браузеры активно показывают, безопасны ли сайты, в ваших интересах как владелец веб-сайта использовать подсказку и защитить свой сайт. Таким образом, посетители могут сразу увидеть, что ваш сайт надёжен, как только они его посещают.

Как добавить SSL/TLS на свой сайт?

Добавление SSL/TLS-сертификата на ваш сайт может быть запутанным и должно быть предпринято только профессионалом. Вы должны знать, есть ли у вас статья в бюджете на того, кто в этом разбирается.

Первый шаг — включить SSH-доступ перед установкой клиента ACME. На этом этапе вы можете создать свой сертификат SSL/TLS и установить его через область администрирования вашего веб-хоста. Мы написали полное руководство о том, как это сделать, что должно помочь, если вы готовы начать работу самостоятельно.

Если вы ищете платного поставщика сертификатов SSL/TLS, обратите внимание на Hostinger. Мы предлагаем пожизненную защиту SSL/TLS за одноразовую оплату. Кроме того, бесплатный сертификат поставляется вместе с нашим ежегодным планом хостинга Бизнес.

После того, как ваш сертификат готов, вы можете активировать HTTPS, вставив фрагмент кода в ваш файл .htaccess.

Как добавить SSL/TLS на сайт WordPress?

Немного легче начать работу с SSL/TLS в WordPress. Он предлагает плагины, такие как Really Simple SSL (англ) и SSL Insecure Content Fixer (англ), которые обрабатывают техническую часть для вас. Однако вам всё равно придётся приобретать SSL-сертификат у поставщика.

После того, как ваш SSL-сертификат был приобретён и установлен, вам всё равно нужно будет изменять настройки на панели инструментов WordPress (или использовать один из вышеупомянутых плагинов).

Хорошей новостью является то, что всё, что вам нужно сделать, это войти в WordPress и перейти в Настройки>Общие. Прокрутите вниз до полей WordPress Address (URL) и Site Address (URL) и измените их с HTTP на HTTPS. Обязательно сохраните изменения и проверьте свой сайт, чтобы убедиться, что всё работает как нужно.

Вывод

Что такое SSL? Это означает Secure Sockets Layer (в то время как TLS поддерживает Transport Layer Security) и показывает посетителям, что они могут безопасно передавать конфиденциальную информацию на сервер и с сервера. Он шифрует все передачи данных таким образом, что они не могут быть расшифрованы третьими сторонами, такими как хакеры и мошенники.

Вы можете узнать, использует ли веб-сайт SSL/TLS по значку висячего замочка или зелёной полосе в верхней части браузера. Обычно вы можете щёлкнуть по значку в своём браузере, чтобы узнать, кому принадлежит сертификат.

SSL/TLS влияют на безопасность, оптимизацию в поисковых системах и могут помочь вашему сайту превосходить конкурентов. С учётом сказанного, это не какой-то мощный инструмент для SEO, сертификаты SSL/TLS должны использоваться потому, что они являются лучшей практикой в вопросах безопасности, а не потому, что вы думаете, что они помогут вам повысить рейтинг в поисковых системах.

И, конечно, если вам нужна помощь при запуске сертификата SSL или если вы хотите воспользоваться пожизненной безопасностью SSL, свяжитесь с нами. Мы будем рады помочь!

Автор

Анна долгое время работала в сфере социальных сетей и меседжеров, но сейчас активно увлеклась созданием и сопровождением сайтов. Она любит узнавать что-то новое и постоянно находится в поиске новинок и обновлений, чтобы делиться ими с миром. Ещё Анна увлекается изучением иностранных языков. Сейчас её увлёк язык программирования!

MNorin.com

Блог про Linux, Bash и другие информационные технологии

TLS и SSL: Необходимый минимум знаний

TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.

Что такое SSL и что такое TLS?

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.

Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:

SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года

Принцип работы SSL и TLS

Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:

Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.

Установка соединения обеспечивается в несколько этапов:

1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.

2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.

5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.

Читать еще:  Как загрузить безопасный режим

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

Корневой сертификат

Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.

Запрос на подпись (CSR, Certificate Sign Request)

Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.

Клиентский сертификат

Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата

Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

Если необходим клиентский сертификат в формате PKCS12, создаем его:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:

После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

На стороне клиента обращаемся к серверу, например, culr’ом:

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

Со стороны сервера ошибка выглядит так:

Со стороны клиента так:

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.

Является ли STARTTLS менее безопасным, чем TLS /SSL?

В Thunderbird (и я предполагаю, что у многих других клиентов тоже) у меня есть выбор между «SSL /TLS» и «STARTTLS».

Насколько я понимаю, «STARTTLS» означает простые слова »шифровать, если оба конца поддерживают TLS, в противном случае не шифруют передачу« . И «SSL /TLS» означает простые слова «всегда шифровать или вообще не подключаться» . Правильно ли это?

Или другими словами:

Является ли STARTTLS менее безопасным, чем SSL /TLS, потому что он может вернуться к открытому тексту без уведомления?

7 ответов

Ответ на основе STARTTLS RFC для SMTP ( RFC 3207 ):

STARTTLS менее безопасен, чем TLS.

Вместо того, чтобы говорить сам, я позволю RFC говорить сам за себя, с четырьмя соответствующими битами, выделенными в BOLD :

Атаку «человек в середине» можно запустить, удалив «250 STARTTLS «от сервера. Это приведет к тому, что клиент не будет чтобы попытаться запустить сеанс TLS. Другая атака «человек в середине» чтобы сервер мог объявить о своей возможности STARTTLS, но изменить запрос клиента на запуск TLS и ответ сервера. В чтобы защитить от таких атак, как клиенты, так и серверы ДОЛЖНЫ быть , чтобы требовать успешного согласования TLS соответствующий набор шифров для выбранных хостов до сообщений может быть успешно перенесен. Дополнительная опция использования TLS, когда возможно ДОЛЖНО также предоставляться. Реализация MAY обеспечивает способность записывать, что TLS использовался при общении с данным сверять и генерировать предупреждение, если оно не используется в более позднем сеансе.

Если согласование TLS завершается с ошибкой или если клиент получает 454 ответ, клиент должен решить, что делать дальше. Есть три основные варианты: выполните оставшуюся часть сеанса SMTP , [. ]

Как вы можете видеть, сам RFC заявляет (не очень четко, но достаточно ясно), что нет НИЧЕГО, требуя от клиентов устанавливать безопасное соединение и информировать пользователей о неудачном соединении. Он явно предоставляет клиентам возможность тихо устанавливать соединения с открытым текстом .

Нет никакой разницы в безопасности между двумя параметрами.

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 за пределами этого типа ошибки конфигурации.

Для электронной почты, в частности, в январе 2018 года был выпущен RFC 8314 , в котором явно рекомендуется, чтобы «Неявный TLS» используется в предпочтении механизма STARTTLS для сообщений IMAP, POP3 и SMTP.

Вкратце, в этой заметке теперь рекомендуется:

  • Версия TLS версии 1.2 или выше будет использоваться для всего трафика между MUA и почтовые серверы отправки, а также между MUA и Mail Access Серверы.
  • Поставщики MUA и почтовых услуг (MSP) (a) препятствуют использованию протоколы открытого текста для почтового доступа и отправки почты и (b) отказаться от использования протоколов cleartext для этих целей в качестве как только это практически осуществимо.
  • Подключения к серверам отправки почты и серверам почтового доступа сделанный с использованием «Неявный TLS» (как определено ниже), в предпочтении подключение к порту «cleartext» и согласование TLS с использованием STARTTLS или аналогичной команды.
Читать еще:  Скачать баннер вирус

В какой-то степени ответ зависит от того, что вы подразумеваете под «безопасным».

Во-первых, ваше резюме не совсем отражает разницу между SSL /TLS и STARTTLS.

  • С SSL /TLS клиент открывает TCP-соединение с «SSL-портом», назначенным прикладному протоколу, который он хочет использовать, и сразу же начинает говорить TLS.
  • С помощью STARTTLS клиент открывает TCP-соединение с «портом cleartext», связанным с протоколом приложения, который он хочет использовать, затем спрашивает сервер «какие расширения протоколов вы поддерживаете?». Затем сервер отвечает на список расширений. Если одно из этих расширений — «STARTTLS», клиент может сказать «хорошо, давайте использовать TLS», а два начинающих говорящих TLS.

Если клиент настроен на требование TLS, два подхода более или менее одинаково безопасны. Но есть некоторые тонкости о том, как STARTTLS необходимо использовать, чтобы сделать его безопасным, и для реализации STARTTLS немного сложнее получить эти данные.

С другой стороны, если клиент настроен на использование TLS только в том случае, если TLS доступен, и использовать cleartext, когда TLS недоступен, то, что может сделать клиент, сначала попробуйте подключиться к порту SSL, используемому протоколом, и если это не удается, подключитесь к порту cleartext и попробуйте использовать STARTTLS и, наконец, вернитесь к cleartext, если TLS недоступен в любом случае. Для злоумышленника довольно легко заставить соединение с портом SSL выйти из строя (все, что требуется, это некоторые своевременные пакеты TCP RST или блокировка порта SSL). Это немного сложнее, но только немного — для злоумышленника, чтобы победить переговоры 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)
  • Использовать TLS, если он доступен (Tries starttls , использует незашифрованное соединение при его отсутствии)
  • Всегда используйте TLS (используется starttls ) и сбой, если он не работает)

Преимущество TLS на выделенном порту заключается в том, что вы можете быть уверены, что нет резервной копии при использовании той программы, которую вы еще не знаете или которая не раскрывает подробные настройки обработки ошибок в своем мастерском первого запуска.

Но в целом безопасность зависит от обработки ошибок безопасности. Программа может решить переключиться на открытый столбец, когда TLS на TLS-порту также терпит неудачу. Вам нужно знать, что он будет делать, и выбрать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.

Разница между SSL и TLS

Secure Socket Layer (SSL) и Transport Layer Security (TLS) — это протоколы, разработанные для обеспечения безопасности между веб-сервером и веб-браузером.

Однако между SSL и TLS есть небольшие различия, SSL является основным подходом для достижения этой цели, а также поддерживается всеми браузерами, тогда как TLS — это следующий интернет-стандарт с некоторыми расширенными функциями безопасности и конфиденциальности.

Сравнительная таблица

Определение SSL

Протокол Secure Socket Layer (SSL) — это интернет-протокол, который обеспечивает безопасный обмен информацией между веб-браузером и веб-сервером. Он предлагает две основные службы безопасности: аутентификация и конфиденциальность . Логически это обеспечивает безопасное соединение между веб-браузером и веб-сервером. Netscape Corporation разработала SSL в 1994 году. С тех пор SSL стал самым популярным в мире механизмом веб-безопасности. Все важные веб-браузеры поддерживают SSL. В настоящее время SSL доступен в трех версиях: 2, 3 и 3.1.

Уровень SSL можно условно считать дополнительным в наборе протоколов TCP / IP . Уровень SSL расположен между прикладным уровнем и транспортным уровнем . Здесь сначала данные прикладного уровня передаются на уровень SSL. Затем уровень SSL выполняет шифрование данных, полученных от уровня приложений, а также добавляет свой собственный заголовок информации о шифровании, называемый заголовком SSL (SH), к зашифрованным данным. После этого данные уровня SSL становятся входными данными для транспортного уровня. Он добавляет свой собственный заголовок и передает его на уровень Интернета и так далее. Этот процесс происходит точно так же, как и в случае обычной передачи данных по TCP / IP. Наконец, когда данные поступают на физический уровень, они передаются в форме импульсов напряжения вдоль среды передачи.

На стороне получателя процедура очень похожа на то, как это происходит в случае обычного соединения TCP / IP, пока оно не достигнет нового уровня SSL. Уровень SSL на стороне получателя исключает заголовок SSL (SH), расшифровывает зашифрованные данные и возвращает простой текст обратно на прикладной уровень принимающего компьютера.

Как работает SSL?

Три подпротокола, которые формируют общее функционирование протокола SSL:

  1. Протоколы рукопожатия : на самом деле он состоит из четырех этапов.
    • Установить возможности безопасности
    • Проверка подлинности сервера и обмен ключами
    • Аутентификация клиента и обмен ключами
    • Конец
  2. Протокол записи : Протокол записи в SSL появляется только после успешного завершения рукопожатия между клиентом и сервером. Протокол предлагает две определенные службы для соединений SSL, которые являются следующими:
    • Конфиденциальность — это достигается с помощью секретного ключа, который определяется протоколом рукопожатия.
    • Целостность . Общий секретный ключ (MAC) определяется протоколом квитирования, который используется для обеспечения целостности сообщения.
  3. Протокол оповещения : если клиент или сервер идентифицирует ошибку, идентифицирующая сторона отправляет оповещение другой стороне. В случае фатальной ошибки обе стороны быстро закрывают соединение SSL.

Определение TLS

Безопасность транспортного уровня (TLS) — это начало стандартизации IETF (Internet Engineering Task Force), целью которой было предложить стандартную версию SSL для Интернета. Netscape передал протокол через IETF, потому что он хотел стандартизировать SSL. Существуют серьезные различия между SSL и TLS. Однако основная идея и реализация довольно похожи.

Ключевые различия между SSL и TLS

  1. Протокол TLS не поддерживает наборы шифров Fortezza / DMS, в то время как SSL поддерживает Fortezza. Кроме того, процесс стандартизации TLS значительно упрощает определение новых наборов шифров.
  2. В SSL для создания главного секрета используется дайджест сообщения предварительного секрета. Напротив, TLS использует псевдослучайную функцию для генерации главного секрета.
  3. Протокол записи SSL добавляет MAC (код аутентификации сообщения) после сжатия каждого блока и шифрует его. В отличие от этого, протокол записи TLS использует HMAC (код аутентификации сообщений на основе хэша).
  4. Предупреждающее сообщение «Нет сертификата» включено в SSL. С другой стороны, TLS удаляет описание оповещения (без сертификата) и добавляет дюжину других значений.
  5. Аутентификация сообщений SSL объединяет ключевую информацию и данные приложения специальным образом, созданным только для протокола SSL. Принимая во внимание, что протокол TLS опирается только на стандартный код аутентификации сообщений, известный как HMAC.
  6. В сертификате TLS проверьте сообщение, хэши MD5 и SHA-1 вычисляются только по сообщениям рукопожатия. Напротив, в SSL при расчете хеша также учитываются главный секрет и блокнот.
  7. Как и в случае готового сообщения в TLS, создается путем применения PRF к главному ключу и сообщениям рукопожатия. Принимая во внимание, что в SSL, это построено, применяя дайджест сообщения к главному ключу и сообщениям рукопожатия.

Заключение

И SSL, и TLS являются протоколами, которые служат одной и той же цели, обеспечивая безопасность и шифрование вашего соединения между TCP и приложениями. Сначала была разработана версия 3.0 SSL, затем была разработана версия 1.0 TLS, которая является предшественницей или последней версией SSL, которая состоит из всех функций SSL, но также имеет некоторые расширенные функции безопасности.

Ссылка на основную публикацию
Adblock
detector