Изменения

'''SSL''' изначально разработан компанией [https://en.wikipedia.org/wiki/Netscape Netscape] для добавления протокола [https://en.wikipedia.org/wiki/HTTPS - HTTPS] в свой веб-браузер [https://en.wikipedia.org/wiki/Netscape_Navigator Netscape Navigator], потому что компания считала, что безопасное соединение между клиентом и сервером в первую очередь послужит успехом развитию Интернета как инструмента бизнеса.  Из-за невозможности гарантировать безопасность сети, через которую передается информация наилучшим способом защитить ее было выбрано шифрование и дешифрование на концах устанавливаемого соединения соответственно. ''Netscape'' могли бы встроить этот подход напрямую в свой браузер, но это бы не предоставило единого решения, которое другие приложения могли бы использовать. Требовалось получить более общный, независимый от приложения подход.  В итоге, ''Netscape'' разработал протокол ''SSL'' работающий поверх ''TCP'', а также предоставляющий ''TCP''-подобный интерфейс для приложений более высокого уровня. В теории, одним из преимуществ SSL для разработчиков являлась возможность заменить все традиционные ''TCP'' вызовы на новые ''SSL'' вызовы. Специфические детали того, как ''SSL'' шифрует и дешифрует данные были относительно прозрачны. == Устройство протокола SSL == [[Файл:SSL on top of TCP.png|right|Фаза рукопожатия]]Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент ([https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP], [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP], [https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAP], [https://en.wikipedia.org/wiki/Telnet TELNET] и т.д.) и транспортным протоколом [https://en.wikipedia.org/wiki/Internet_protocol_suite TCP/IP]. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.  Работу протокола можно разделить на два уровня:* Слой протокола подтверждения подключения (Handshake Protocol Layer)* Слой протокола записи

* Протокол подтверждения подключения (Handshake Protocol)* Протокол изменения параметров шифра (Cipher Spec Protocol)* Предупредительный протокол (Alert Protocol) 

 Протокол изменения параметров шифра используется для изменения данных ключа (keyingmaterialkeying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей. 

===Протокол записи=== 

* Протокол рукопожатия (handshake protocol);* Протокол тревоги (alert protocol);* Протокол изменения шифра (the change cipher spec protocol);* Протокол приложения (application data protocol); 

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

Клиент инициирует рукопожатие посылая ''“hello”''-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим ''“hello”''-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его '''публичный ключ'''.

'''Сертификат ''' - это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как '''центр сертификации ''' (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.

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

''Фаза рукопожатия '' завершается отправкой ''“finished”''-сообщений, как только обе стороны готовы начать использование секретного ключа.Начинается ''фаза передачи данных'', в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений '''MAC''' (MAC - message authentication code). '''Код авторизации сообщения ''' это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.

==Цифровые сертификаты==

* Использовать сертификат, выданный [https://en.wikipedia.org/wiki/Certificate_authority центром сертификации ] (Certification authority)* Использовать самоподписанный сертификат* Использовать «пустой» сертификат 

==Хэширование==Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются [https://en.wikipedia.org/wiki/MD5 MD5 ] (Message Digest 5), который создает 128-битное хеш-значение, [https://en.wikipedia.org/wiki/SHA-1 SHA-1 ] (Standard Hash Algorithm), создающий 160-битное хеш-значение, [https://en.wikipedia.org/wiki/SHA-2 SHA-2 ] и [https://en.wikipedia.org/wiki/SHA-3 SHA-3]. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.

=Шифрование== Открытый ключ === Существует два основных способа шифрования данных[[Файл: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ)ssl_public-key_encryption.png|center|Шифрование открытым ключом]]

Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA) Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA) '''RSA''' — самый распространенный алгоритм шифрования с использованием асимметричных ключей. === Секретный ключ === [[Файл:ssl_secret-key_encryption.png|center|Шифрование симметричным ключом==]]При шифровании симметричным секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используются алгоритмы [https://en.wikipedia.org/wiki/Data_Encryption_Standard DES], 3-DES, RC2, [https://en.wikipedia.org/wiki/RC4 RC4 ] и [https://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES]. === Комбинированный подход ===

Однако, шифрование открытым ключом использует ключ как экспоненту, поэтому значительное увеличения ключа сильно увеличивает количество вычислений, требуемых для шифрования / дешифрования данных.  Таким образом хотя алгоритмы шифрования открытым ключом не сталкиваются с проблемой распределения, с которой сталкиваются алгоритмы шифрования секретным ключом, они требует значительно больше вычислительной мощности. Для использования сильных сторон обоих типов алгоритмов протоколы безопасности обычно используют шифрование открытым ключом для передачи секретных ключей. Как только секретный ключ доставлен начинается передача данных с использованием симметричного шифрования. Существует еще один подход, использующий открытый ключ как соглашение, а не как способ доставки секретного ключа другим. Обе стороны обмениваются публичными ключами и независимо генерируют секретный ключ. Самой распространенной формой такого соглашения является [https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%94%D0%B8%D1%84%D1%84%D0%B8_%E2%80%94_%D0%A5%D0%B5%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD%D0%B0 протокол Диффи-Хеллмана]. Хотя SSL поддерживает протокол Диффи-Хеллмана, большинство SSL транзакций не используют его. Вместо него используется алгоритм [https://en.wikipedia.org/wiki/RSA_(cryptosystem) RSA], который решает проблему распределения секретных ключей. == Аутентификация и обмен ключами ==

* аутентификация обеих сторон (клиент — сервер),* аутентификация сервера с неаутентифицированным клиентом,* полная анонимность. Обычно для аутентификации используются алгоритмы: ''RSA'', [https://en.wikipedia.org/wiki/Digital_Signature_Algorithm DSA], [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA]. Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента.  Главная цель процесса обмена ключами — это создание секрета клиента (''pre_master_secret''), известного только клиенту и серверу. Секрет (''pre_master_secret'') используется для создания общего секрета (''master_secret''). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (''message authentication code'') и сообщения ''«finished»''. Отсылая сообщение ''«finished»'', стороны указывают, что они знают верный секрет (''pre_master_secret).==Анонимный обмен ключами==Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret'').

==Аутентификация и = Анонимный обмен ключами при использовании RSA==В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS (???). Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия (???).=

==Аутентификация и обмен ключами Полностью анонимная сессия может быть установлена при использовании Diffieалгоритма ''RSA'' или ''Диффи-Hellman==Хеллмана'' для создания ключей обмена. В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать использования ''RSA'' клиент шифрует секрет (''pre_master_secret'') с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением helloРезультат посылается в сообщении обмена ключами от клиента.random перед подписанием для того, чтобы злоумышленник Поскольку перехватчик не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу.Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellmanзнает закрытого ключа сервера, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты ему будет невозможно расшифровать секрет (pre_master_secret) каждый раз, когда они устанавливают соединение. Для тогоПри использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, чтобы предотвратить хранение секрета (pre_master_secret) и клиенту посылают в памяти компьютера на время дольшесообщении обмена ключами. Перехватчик, чем необходимокоторый не знает приватных значений, секрет должен быть переведен в общий не сможет найти секрет (master_secret''pre_master_secret'') настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

=== Аутентификация и обмен ключами при использовании RSA === В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ ''RSA'', который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат ''DSS''. Сигнатура содержит текущее значение сообщения ''Client_Hello.random'', таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (''pre_master_secret'') при помощи открытого ключа сервера. После успешного декодирования секрета (''pre_master_secret'') создается сообщение ''«finished»'', тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера. Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение ''Server_Hello.random'', которому ставит в соответствие сигнатуру текущему сообщению рукопожатия. === Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана === В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением ''hello.random'' перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу. Если клиент имеет сертификат, содержащий параметры ''алгоритма Diffie-Hellman'', то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (''pre_master_secret'') каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (''pre_master_secret'') в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (''master_secret'') настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами. ==Восстановление сессии==[[Файл:ssl_session_resumption.png|right|Фаза рукопожатия]]

===Администрирование=======Обслуживание сертификатов и ключей====

====Хранилище идентификаторов сессий====

==SSL 1.0, 2.0, 3.0 и TLS=Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL версии 3.0. Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” до SSL 3.0 для работы с клиентами, использующими SSL 3.0.=

=Протоколы SSL Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и TLS=определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола '''SSL (Secure Sockets Layer)3.0''' был разработан и принят стандарт ''RFC'', получивший имя '''TLS (Transport Level Security)1.0''' {{---}} криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а Его также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефониичасто называют '''SSL 3.1'''.

СоединениеХотя TLS и SSL имеют существенные различия в реализации, защищенное протоколом TLSразработчики обычно замечают лишь немногие из них, обладает одним или несколькими следующими свойствами:* а конечные пользователи вовсе их не различают. Тем не менее ''Безопасность'': симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицамиTLS 1.0 и SSL 3.* 0 несовместимы''Аутентификация'': "личность" участника соединения можно проверить с помощью асимметричного шифрования.* ''Целостность'': каждое сообщение содержит код ('''Message Authentication CodeЗначительное различие состоит в том, MAC''')что TLS требует определенные алгоритмы шифрования, с помощью которого можно проверить, что данные которые SSL не были изменены или потеряны в процессе передачиподдерживает. Так как большинство протоколов связи могут быть использованы как с Таким образом TLS/сервер должен “откатиться” (downgrade) до SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS3. Один способ добиться этого {{---}} использовать порт, по которому соединение всегда устанавливается 0 для работы с использованием TLS (напримерклиентами, 443 для HTTPS)использующими SSL 3. Другой способ {{---}} использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты)0.

==Механизм Принцип работы протоколаTLS ==

==Меры безопасности в TLS==