Ssl tls что такое
Что Такое SSL/TLS И HTTPS? Установка Сертификата Безопасности
Что такое SSL? SSL является аббревиатурой для Secure Sockets Layer. Это тип цифровой безопасности, которая позволяет зашифровать связь между веб-сайтом и веб-браузером. Технология в настоящее время устарела и полностью заменена TLS.
Что такое TLS? Это означает Transport Layer Security и обеспечивает конфиденциальность данных так же, как и SSL. Поскольку SSL фактически больше не используется, это правильный термин, который люди должны начать использовать.
Что таоке HTTPS? Это безопасное расширение HTTP. Веб-сайты, устанавливающие и настраивающие SSL/TLS-сертификат, могут использовать протокол HTTPS для установления безопасного соединения с сервером.
В этом руководстве вы узнаете:
Как работают сертификаты SSL/TLS?
Сертификаты SSL/TLS работают путём цифровой привязки криптографического ключа к идентифицирующей информации компании. Это позволяет им шифровать передачу данных таким образом, что они не могут быть расшифрованы третьими лицами.
SSL/TLS работает, имея как частный, так и открытый ключ, а также ключи сеанса для каждого уникального безопасного сеанса. Когда посетитель вводит защищённый SSL-адрес в свой веб-браузер или переходит на безопасную страницу, браузер и веб-сервер устанавливают соединение.
Во время первоначального подключения общедоступные и закрытые ключи будут использоваться для создания ключа сеанса, который затем будет использоваться для шифрования и дешифрования передаваемых данных. Этот ключ сеанса останется действительным в течение ограниченного времени и будет использоваться только для данного сеанса.
Вы можете определить, использует ли сайт SSL, по значку замочка или зелёной полосе в верхней части браузера. Вы можете щёлкнуть по этому значку, чтобы просмотреть информацию о том, кому принадлежит сертификат, и управлять настройками SSL.
Когда и почему SSL/TLS необходимы?
SSL/TLS является обязательным, когда передаётся конфиденциальная информация, такая как имена пользователей и пароли или информация о платёжной обработке.
Цель SSL/TLS состоит в том, чтобы убедиться, что только один человек — лицо или организация, утверждённое пользователем, может получить доступ к передаваемым данным. Это особенно важно, когда вы думаете о том, между сколькими устройствами и серверами передаются данные до того, как они достигнут своего пункта назначения.
Существует три основных варианта использования SSL/TLS для вашего веб-сайта:
Помните, что 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, — это проверить 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 для одного сайта.
После того, как ваш сертификат готов, вы можете активировать 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, свяжитесь с нами. Мы будем рады помочь!
Анна долгое время работала в сфере социальных сетей и меседжеров, но сейчас активно увлеклась созданием и сопровождением сайтов. Она любит узнавать что-то новое и постоянно находится в поиске новинок и обновлений, чтобы делиться ими с миром. Ещё Анна увлекается изучением иностранных языков. Сейчас её увлёк язык программирования!
Различия между SSL и TLS
Хроническая эпидемия расстройства восприятия лиц у жителей Метрополиса, из-за которой никто не замечает, что Кларк Кент и чудаковатый летающий пришелец, похожий на него как две капли воды, — это в действительности одно и то же лицо, распространяется и на технический сектор, где мы постоянно спорим о том, насколько строго нужно различать протоколы SSL и TLS.
Справедливости ради стоит сказать, что это не ситуация из разряда «SSL с Земли, TLS с Криптона», а достойный подражания пример постоянного усовершенствования стандартов шифрования и отказа от устаревших и ненадежных методов обмена данными между клиентами и серверами для повышения общей безопасности Интернета.
Более 20 лет назад компания Netscape разработала версию 1.0 протокола SSL (Secure Sockets Layer), чтобы в браузерах можно было просматривать страницы Geocities и обмениваться ASCII-графикой по мотивам «Звездного пути», не беспокоясь о безопасности.
Версии SSL 1.0–3.0, как и все первые попытки создать эффективный алгоритм шифрования, подверглись критике из-за наличия серьезных проблем с безопасностью, в связи с чем потребовался выпуск нескольких доработанных версий с улучшенной архитектурой системы безопасности.
В 1999 году была выпущена версия 1.0 протокола TLS (Transport Layer Security): tools.ietf.org/html/rfc2246. Название было изменено для того, чтобы подчеркнуть открытый характер стандарта, благодаря чему кто угодно мог использовать его в своих проектах, и тем самым отделить его от фирменного продукта компании Netscape (которая на тот момент еще продавала программное обеспечение для веб-серверов Netscape Enterprise Server, использующее SSL для шифрования данных из внешних каналов). Кроме того, протокол TLS разрабатывался как протокол, независимый от приложений, тогда как SSL изначально планировалось использовать только для подключений HTTP.
В лингвистическом противостоянии («Как называется протокол, при использовании которого появляется зеленый замочек?») победил термин SSL. Если вам нужно доказательство, посмотрите сравнение «SSL и TLS» на сайте Google Trends.
Именно поэтому в материалах об общей концепции или при рассказе об этой концепции людям без профильных знаний используется общепринятый термин SSL, так как он у всех на слуху, а правильное понимание терминологии в таких вопросах имеет огромное значение.
При обсуждении _протокола_ как такового и версий SSL/TLS, которые должны быть включены, более правильным будет термин TLS.
Однако на практике специалисту по обеспечению безопасности и администрированию необходимо знать следующее.
• Существуют различные версии SSL/TLS.
• При несовпадении протоколов более старые системы не могут обмениваться данными с более новыми. Если вы когда-либо задумывались над тем, почему браузер Internet Explorer при установке Windows 95 на новом компьютере не открывает сайты HTTPS, то теперь вы знаете ответ.
• Необходимо создать корпоративную политику, позволяющую включать только более поздние версии TLS (номер текущей версии — 1.2).
• Многие устройства и приложения по-прежнему поддерживают устаревшие и небезопасные версии TLS/SSL, которые необходимо отключать специально.
В общем и целом вопрос «В чем заключается разница между SSL и TLS?» очень интересен, если обсуждать только практические моменты и доказывать, почему мелкие различия между протоколами безопасности так важны.
Что такое TLS
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.
Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, которые предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.