Изменения

Существует два основных способа шифрования данных: ''симметричный ключ '' (общий секретный ключ) и ''асимметричный ключ '' (открытый ключ).

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

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

== Протоколы 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==