скажите пожалуйста, как делается индивидуальное шифрование для https протокола? пример: ведь если взять 2 сайта разных с https то у них по разному будет шифроватся соединение. это самостоятельно настраивается на сервере или автоматически уникально для каждого сайта шифрует?
Хостеры предоставляют такую услугу, выдавая специальный сертификат, после чего соединение шифруется, если я не ошибаюсь ключами. Вот пример: http://www.reg.ru/help/serv_ssl_cert
по-разному не может и не будет шифроваться. стандарт https crypto сейчас - TLS (AES-256). откройте сайт банка и в данных о сайте увидите инфо о SSL сертификате. можно сделать сертификат и самому, бывает. но если он не issued and verified(выпущен и подписан цифровой подписью) by VeriSign или другой authority - липа. UPD. две разные стороны, само криптование - это доступно со знанием OpenSSL, и доверие к этому криптованию в браузере - это решают authorities.
Не очень понятен вопрос. Что значит уникально? Уникалный набор настроек или уникальные ключи шифрования? Набор настроек может быть одинаковый. Ключи шифрования сессии будут разные даже для разных сессий одного и того же клиента на одном и том же сервере. Если упрощенно, то https работает так. Клиент приходит к серверу, устанавливает tcp соединение. Дальше они договариваются о том, какие алгоритмы шифрования и обмена ключами будут использовать. У сервера есть список алгоритмов, которые он поддерживает, клиент из них выбирает те, что поддерживает он. Сервер посылает клиенту свой сертификат ключа. Сертификат содержит: - common name - даты, с какой до какой он действителен - открытый ключ сервера - алгоритм ключа, хеша и подписи (еще куча всего) - цифровую подпись под всем этим. Клиент выполняет следующие проверки: - эцп должна быть верна. - common name должно совпадать с тем, что написано в url по которому клиент обратился к серверу. Там может быть как DNS имя так и ip адрес. Если обратился по имени, то должно быть имя. Если по IP адресу, то должен быть IP адрес. - текущая дата должна быть в промежутке, когда сертификат валиден. - Клиент должен обладать открытым ключем того, кто проставил ЭЦП ( выдал, или подписал сертификат) и должен доверять этому ключу. Если первое условие не выполняется, процесс дальше не идет. Если не выполняется одно или больше остальных условий, то процесс идет, но пользователю выдается предупреждение. Далее клиент выполняет проверку того, что у сервера есть секретный ключ, соответствующий тому откытому, который есть в сертификате сервера. Для этого клиент лезет к себе в /dev/random и берет там немного случайных чисел. Инициализирует ими генератор ключей и генерирует случайный сеансовый ключ для симметричного криптоалгоритма (ну AES обычно), которым будет пошифрована сессия. Далее он берет этот сеансовый ключ и шифрует его на открытом ключе сервера ассиметричным криптоалгоритмом, ну например RSA. Если у сервера таки есть секретный ключ от его открытого ключа, он расшифровывает сеансовый ключ, и начинает шифровать соединение с его помощью. Этот процесс повторяется при каждой новой установке соединения SSL. У SSL/TLS есть несколько режимов, я описал режим с аутентификацией сервера. Есть еще с аутентификацией клиента, когда клиенту тоже нужен сертификат. Там вообще довольно много подробностей, которые уже в RFC нуно читать.
