2009-12-18 9 views
7

Возможно ли отправить сообщение через https, которое не зашифровано? Например, требуется проверка и авторизация сертификата, но не шифрование фактических данных, отправляемых через сокет?Нешифрованный протокол SSL?

+0

Мне любопытно, как это будет использоваться? Почему бы просто не использовать альтернативный метод аутентификации? Мне кажется, что все, что вам нужно, аутентификация действительного хозяина? * shrug * – Jakub

+0

Вопрос не имеет смысла, так как https является защищенной версией HTTP, запущенной стандартным портом 443. Стандарт диктует, что все шифрование и авторизация/авторизация сертификата применяются к этому протоколу https. И вообще, любое сообщение, отправленное через https, зашифровано. Можете ли вы уточнить, что вы пытаетесь сделать? – t0mm13b

+2

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

ответ

20

Да, TLS и SSL поддерживают режимы «без шифрования». Независимо от того, настроен ли конкретный клиент и сервер для включения, это отдельная проблема.

Возможно, маловероятно, чтобы сервер мог включить один из этих наборов шифров по умолчанию. Скорее всего, сервер по умолчанию разрешает использование слабых наборов шифров (например, «экспортных» классов на основе DES). Вот почему вы должны тщательно просмотреть белый список серверов шифрованных наборов, и leave only a few trusted, widely-supported algorithms.

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

«RSA» в данном случае относится к алгоритму обмена ключами, а «SHA» относится к алгоритму аутентификации сообщений, используемому для защиты трафика от изменения. «NULL» - это алгоритм шифрования или, в данном случае, отсутствие шифрования.

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

Если вы ищете понижающее решение, в котором некоторые данные обмениваются через SSL, тогда SSL отключается, но трафик приложений продолжается, но это также возможно, но имейте в виду, что он не обеспечивает абсолютно никакой безопасности для открытого текста трафик; он может быть взломан злоумышленником. Так, например, аутентификация с помощью SSL, а затем переход к протоколу «in-the-clear» для приема команд, использующих аутентификацию, согласованную через SSL, будет небезопасным.

+0

Здравствуйте, у меня есть вопрос о openssl, вы бы хотели взглянуть со следующим адресом?. http://stackoverflow.com/questions/2542156/openssl-ssl-encryption – deddihp

-3

Нет, протокол не позволяет этого.

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

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

-1

Думаю, вы можете.

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

+4

Конфиденциальность и целостность - это две разные вещи. Вы можете использовать TLS без конфиденциальности; злоумышленники могут читать ваши пакеты, но вы знаете, изменили ли они пакет. – erickson

+0

@erickson Я не знаю SSL и его детей достаточно хорошо, но почему вы хотите использовать криптографический хеш на своих транзитных данных, а не просто шифровать его? –

+0

У меня не было приложения для этого. Я просто указывал, что SSL может защитить от изменения пакета без обеспечения конфиденциальности, а простого шифрования недостаточно для предотвращения изменения пакета. – erickson

5

Спецификации SSL/TLS определяют «NULL-шифр», который вы могли бы использовать для этого. Большинство клиентских и серверных программ отключает его по очевидным причинам.

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

Смежные вопросы