Похожие вопросы

Шифрование с открытым ключом

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

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

5
задан nhinkle
источник

7 ответов

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

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

SSL-подтверждения

на очень высоком уровне протокол выглядит примерно так:

  1. клиент отправляет начальное сообщение "HELLO", которое содержит версию ssl, которую он хотел бы использовать, псевдослучайную строку битов (назовем ее B1) и список различных шифров, которые она поддерживает.

  2. сервер отвечает своим собственным сообщением "HELLO", другой псевдослучайной строкой битов (давайте назовем это B2), шифр, который он выбрал (обычно самый сильный шифр из списка, который клиент отправил, который поддерживает сервер), и его сертификат, который содержит его открытый ключ (давайте назовем это k).

  3. клиент затем использует сертификат для аутентификации сервера (см. ниже) и создает "premaster secret" - другую строку pseduo-случайных битов, которые мы будем называть S.

  4. Если клиент доволен результатами аутентификации сервера, он шифрует премастер секрет S с открытым ключом сервера k, и отправляет его на сервер (сам по себе шифруется, но соединения все равно нет).

  5. на данный момент сервер и клиент совместно используют три строки битов-B1, B2 и S. B1 и B2 были отправлены в открытом виде-S был зашифрован, и поэтому, предполагая, что закрытый ключ сервера действительно является частным, известен только клиенту и сервер.

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

  7. клиент и сервер обмениваются сообщениями, которые указывают на изменение протокола, и все последующие сообщения шифруются (симметрично, с ключом, вычисленным выше).

сервер проверка подлинности

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

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

Итак, когда клиент получит приветствие сервера, он выполнит следующие проверки:

  • попадает ли сегодняшняя дата в период действия сертификата?
  • совпадает ли имя субъекта сертификата с именем сервера, к которому я пытаюсь подключиться?
  • имя эмитента сертификата совпадение с любым из ЦС, чьи открытые ключи мне известны?
    • если да, то открытый ключ, который я имею для этого CA, проверяет этот сертификат?

Если все эти проверки проходят, клиент предполагает, что он может верить, что сервер, кого он ожидал. Затем он принимает открытый ключ (все еще k) из сертификата и использует его для безопасной передачи S на сервер. На данный момент идея заключается в том, что у вас есть утверждение третьей стороны (Verisign) что открытый ключ принадлежит серверу; поэтому только сервер сможет расшифровать результат E (S,k), и, следовательно, только сервер может создать соответствующий ключ, который вы будете использовать для симметричного шифрования.

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

(есть и другие приятные повороты-например, причина, по которой используются три битовые строки чтобы предотвратить атаки воспроизведения. Если используется только S, злоумышленник может записать весь сеанс и воспроизвести его в свободное время-например, повторяя инструкцию по переводу денег снова и снова. Имея как клиент, так и сервер генерировать дополнительные строки pseduo случайных, вы значительно уменьшить вероятность двух независимых SSL рукопожатий, производящих тот же S.)

6
отвечен Andy 2009-12-17 15:25:22
источник

все проще, на самом деле.

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

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

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

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

1
отвечен Satanicpuppy 2009-12-17 15:00:47
источник

Ваш вопрос немного общий. Что именно вы ищете?

  • реализации протокола (как открыть зашифрованный пакет)
  • математические детали (как сайт шифрует пакет, который предназначен для меня)
  • secrurity проблемы (мужик в атаки ближнего')

вы читали обзоры Википедия запись?

0
отвечен lorenzog 2009-12-17 14:16:55
источник

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

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

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

0
отвечен Thilo 2009-12-17 14:21:57
источник

здесь используются два типа шифров. Там открытым ключом (асимметричные) типа, а более общий-ключ (симметричный) тип. Симметричные шифры намного эффективнее, так как существует не так много способов настроить шифр с открытым ключом.

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

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

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

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

0
отвечен David Thornley 2009-12-17 15:04:59
источник

простой ответ: точно так же.

предположим, можете отправить данные надежно до Б, но Б может только отправлять данные небезопасным А. Все, что вам нужно сделать, это составить случайный ключ и отправить его безопасно для Б. Теперь Б может шифровать данные со случайным ключом, отправить его, и это безопасно.

таким образом, если у вас есть двунаправленная ссылка, которая безопасна только в одном направлении, тривиально сделать ее безопасной в обоих направлениях.

0
отвечен David Schwartz 2011-10-02 21:39:59
источник

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

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

0
отвечен Dan Rosenstark 2011-10-02 22:35:30
источник

Другие вопросы encryption https ssl