Вопрос

Мы находимся в процессе удостоверения нашего продукта здравоохранения (сертификация Hitech). Одним из критериев процесса сертификации является то, что наш продукт должен быть способен использовать «хеширование» при отправке информации о пациентах по сети. Наш продукт - это толстый клиент, который подключается непосредственно к базе данных SQL Server 2005. Таким образом, когда мы отправляем информацию о пациентах от клиента в процедуру магазина DB, она должна использовать «хеширование», чтобы убедиться, что информация не была изменена в транзите.

Теперь мы планируем подключить наш клиент к SQL Server с помощью SSL Secure Connection. Когда я читаю о протоколе SSL, кажется, что SSL использует хеширование внутренне. Поэтому, если это правда, я мог бы автоматически удовлетворить требование к хэшингу с помощью SSL-соединения между клиентом и SQL SVR.

Так вот мои вопросы

  • Когда данные передаются по подключению SSL, каждое сообщение прикреплено к HASH внутренне, так что протокол SSL проверяет, что данные не были изменены?
  • Использует ли SSL механизм хеширования только во время начальных этапов его рукопожатия? Поэтому после завершения рукопожатия он только шифрует / расшифрует данные без какого-либо механизма хеширования?
  • Если SSL прикрепит хэш для каждого сообщения, это «открытый ключ», используемый для создания хеша?
Это было полезно?

Решение

Когда данные передаются по подключению SSL, каждое сообщение прикреплено к HASH внутренне, так что протокол SSL проверяет, что данные не были изменены?

да. Это добавляет MAC-ключ к каждой записи TLS.

Использует ли SSL механизм хеширования только во время начальных этапов его рукопожатия?

Нет, это происходит во всем.

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

Нет. Общий секрет используется для создания хеша.

Видеть RFC2246. для деталей.

Другие советы

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

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

Это зависит. Две партии переговоров могут договориться о уровне защиты и использованные алгоритмы. Наиболее распространенным делом является то, что переговоры используют TLS., не SSL, запрошена конфиденциальность сообщения (т. Е. Шифрование) и защита подделок (т. Е. Подписание). TLS использует за хеширование сообщения на основе Hmac., см. Главу 5 RFC2246.. Отказ SSL использует а Mac, который немного слабее, чем HMac (Mac не содержит секрет в его дайджесте).

На 10000 футов Представительский уровень представления Ответ «Да, хэши SSL каждое сообщение». Подтверждение шифрования SSL в Client Client Server Server обычно требуется в совместимых развертываниях. Для более подробной информации и рекомендации проверьте веб-трансляцию и белые документы в SQL Server Соответствие.

SSL сильнее, чем хеширование. Это должно удовлетворять ваше требование.

Я буду яснее:

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

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

ВАЖНОЕ ПРИМЕЧАНИЕ. Убедитесь, что это связь SSL правильно реализована - это единственная точка отказа.

SSL или TLS (вы, вероятно, сможете использовать TLSV1.0, по крайней мере, в наши дни, даже если говорить о «SSL»), стремится защищать цели »...] Чтобы обеспечить конфиденциальность и целостность данных между двумя коммуникационными приложениями" (видеть Rfc.).

RFC 4346 продолжает говорить:

Протокол записи TLS обеспечивает безопасность подключения, которая имеет два основных свойства:

  • Соединение является частным. [...
  • Соединение надежно. Перевозка сообщений включает в себя проверку целостности сообщений с помощью Mac-Mac. Безопасные хеш-функции (например, SHA, MD5 и т. Д.) Используются для вычислений MAC. Протокол записи может работать без Mac, но обычно используется только в этом режиме, когда другой протокол использует протокол записи в качестве транспортировки для согласования параметров безопасности.

Итак, да, он обнаружит попытки повредить передачу данных (преднамеренные или случайные).

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top