Как именно работает HTTPS (ssl)

Question

Я читал по HTTPS, пытаясь выяснить, как именно это работает. Мне кажется, это не имеет смысла, например, я читал это

https://ssl.trustwave.com/support/support-how-ssl-works.php

И обратите внимание, на странице написано

Шаг 4: xyz.com затем создаст уникальный хэш и зашифруйте его, используя оба открытый ключ клиента и закрытый ключ от xyz.com и отправьте назад к клиенту.

Шаг 5: браузер клиента расшифрует хеш. Этот процесс показывает что xyz.com отправил хеш и только клиент может прочитать его.

Что я не понимаю, так это то, что хакер не мог просто перехватить открытый ключ, который он отправляет обратно в «браузер клиента», и иметь возможность расшифровать все, что может клиент?

Спасибо за любой ответ

Answer 1

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

Answer 2

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

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

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

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

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

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

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

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

Вышеуказанные действия по обмену ключами гарантируют, что только Клиент и Сервер могут знать, что общим ключом является « DummySharedKey », никто не знает его.

Поэтому важно понимать, что ответственность за генерацию общего ключа лежит на клиенте, а не на СЕРВЕРЕ! (я думаю, это то, что вас смутило)

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

Answer 3

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

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

Такое асимметричное шифрование было обнаружено только в середине 1970-х годов.Он зачисляется на Диффи и Хеллмана и Ривеста, Шамира и Адлемана .(Тем не менее, обе фактически заново открыли вещи , уже известные британскими спецслужбами.)

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

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

Answer 4

Я изучаю смежные темы и читаю несколько блогов, таких как how-https-works и How-do-https-work-rsa-encryption-объяснено / .

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

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

Answer 5

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

SSL Handshake

Небольшой фрагмент того же кода:

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

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

Answer 6

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

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

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

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

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

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

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

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

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