Ответ 1

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

Шифрование общего/закрытого ключа основано на модульной арифметике с использованием простых чисел.

Такое асимметричное шифрование было обнаружено только в середине 1970-х годов. Он приписывается Diffie and Hellman и Rivest, Shamir и Adleman. (Хотя, оба действительно заново открыли вещи уже известные британскими спецслужбами.)

Страница wikipedia на Diffie-Hellman содержит подробный пример обмена секретным ключом через общедоступный канал. Хотя он не описывает сам протокол SSL, должно быть полезно понять, почему знание открытого ключа не показывает содержимое сообщения.

Вы также можете найти этот простой пример RSA.

Ответ 2

Почему HTTPS требуется?

Чтобы проверить, является ли сайт аутентифицирован/сертифицирован или нет (несертифицированные сайты могут совершать злые дела). Аутентифицированный веб-сайт имеет уникальный личный сертификат, приобретенный в одном из центров сертификации.

Кто такие CA (центры сертификации)?

Центры сертификации - это компании с мировым именем, такие как GoDaddy, GeoTrust, VeriSign и т.д., Которые предоставляют цифровые сертификаты веб-сайтам.

Что такое открытые ключи и закрытые ключи?

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

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

Как компания получает сертификат?

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

Примечание. Этот зашифрованный текст является цифровой подписью ЦС. Этот текст зашифрован закрытым ключом CA и может быть расшифрован только открытым ключом CA.
Когда вы устанавливаете свою операционную систему или браузер, вместе с ним приходят корневые сертификаты от многих надежных CA, таких как GeoTrust, VeriSign, GoDaddy и т.д. Эти корневые сертификаты содержат открытый ключ этого поставщика CA, который помогает расшифровать подпись.

Безопасность HTTPS можно разделить на 2 части (рукопожатия):

1. Чтобы подтвердить сертификат веб-сайта:

1) Когда вы вводите URL www.Google.com, сервер Googles передает открытый ключ и сертификат (который был подписан GeoTrust) браузеру.

2) Теперь браузер должен проверять подлинность сертификата, то есть фактически ли он подписан на GeoTrust или нет. Поскольку браузеры поставляются с предварительно установленным списком открытых ключей от всех основных ЦС, он выбирает открытый ключ GeoTrust и пытается расшифровать цифровую подпись сертификата, который был зашифрован закрытым ключом GeoTrust.

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

2. Чтобы создать безопасное соединение (шифрует исходящие и входящие данные), чтобы никто другой не мог его прочитать:

1) Как я уже говорил, Google отправляет свой открытый ключ при входе на сайт www.Google.com. Любые данные, зашифрованные с помощью этого открытого ключа, могут быть расшифрованы только с помощью закрытого ключа Googles, который Google не передает никому.

2) После проверки сертификата браузер создает новый ключ, назовем его " Ключ сеанса" и делаю 2 его копии. Эти ключи могут шифровать, а также расшифровывать данные.

3) Затем браузер шифрует (1 копия сеансового ключа + другие данные запроса) открытым ключом Google. Затем он отправляет его обратно на сервер Google.

4) Сервер Googles расшифровывает зашифрованные данные, используя свой закрытый ключ, и получает ключ сеанса и другие данные запроса.

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

5) Когда Google отправляет данные, такие как запрошенный HTML-документ и другие данные HTTP, в браузер, он сначала шифрует данные этим ключом сеанса, а браузер дешифрует данные другой копией ключа сеанса.

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

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

не может насытиться сетью? за кулисами, когда вы набираете www.google.com в браузере

Ответ 3

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

Во-первых, поймите, что, как правило, есть два способа передачи HTTP-сообщений.

1) Создайте общий симметричный ключ, который может быть известен только между клиентом и сервером, никто не знает его

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

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

- Клиент получает открытый ключ с сервера.

- Клиент генерирует ключевую строку " DummySharedKey" , которая позже будет использоваться как общий ключ и зашифрована в " 7 $& ^^% #### LDD!! @" с открытым ключом сервера, Man-in-the-middle может иметь открытый ключ и может перехватывать зашифрованные данные, но данные бесполезны для него, так как данные могут быть дешифрованы только через sever закрытый ключ.

- Сервер получает зашифрованную ключевую строку " 7 $& ^^% #### LDD!! @" и расшифровывает ее на " DummySharedKey" с его закрытым ключом

Над этапами обмена ключами убедитесь, что только клиент и сервер могут знать общий ключ: " DummySharedKey" , никто другой его не знает.

Поэтому важно понять, что ответственность Клиента - генерировать общий ключ, а не SERVER! (я думаю, что это то, что вас смущает)

Я также рекомендую вам взглянуть на это видео, которое очень хорошо объясняет HTTP. https://www.youtube.com/watch?v=JCvPnwpWVUQ&list=FLt15cp4Q09BpKVUryBOg2hQ&index=3

Ответ 4

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

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

Небольшой отрывок из этого можно сделать следующим образом:

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

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

Ответ 5

Я изучаю смежные темы и читаю несколько блогов, таких как, как https-работает и как-https-работа-rsa-шифрование-объяснил/.

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

Для более подробной информации, вы можете проверить упомянутый блог.

Ответ 6

Подробное объяснение SSL см. в https://www.ietf.org/rfc/rfc2246.txt

Вот краткие идеи SSL для ответа на ваш вопрос:

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

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

Общий симметричный ключ устанавливается путем обмена секретным ключом с клиентской стороны (зашифрованный с помощью открытого ключа сервера) и происходит из секретности pre-master вместе с случайным случайным и случайным сервером (спасибо @EJP за указание этого в комментарий):

master_secret = PRF(pre_master_secret, "master secret",
                           ClientHello.random + ServerHello.random)

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

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

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