Использует ли SSL внутреннее хеширование?

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

Теперь мы планируем подключить нашего клиента к серверу Sql, используя безопасное соединение SSL. Когда я читаю о протоколе SSL, мне кажется, что SSL использует внутреннее хеширование. Так что, если это правда, я мог бы автоматически удовлетворить требование хеширования, используя SSL-соединение между клиентом и sql svr.

Итак, вот мои вопросы

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

ssl sql-server pii hash
person FatherFigure    schedule 02.11.2010    source источник

Ответы (5)


arrow_upward
1
arrow_downward

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

Да. Он добавляет MAC-адрес с ключом к каждой обмениваемой записи TLS.

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

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

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

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

Подробности см. в RFC2246.

person user207421    schedule 04.11.2010
comment
Спасибо всем за столько комментариев и точек зрения. Это очень помогает. - person FatherFigure; 04.11.2010

arrow_upward
2
arrow_downward

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

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

person Guffa    schedule 02.11.2010
comment
Разве ОП не говорит, что он устанавливает SSL-соединение из клиентского приложения в SQL? Похоже, что эти точки не являются проблемой. - person Hogan; 02.11.2010
comment
@Hogan: Если бы я заказал приложение, я бы, конечно, увидел в этом проблему, если бы оно не могло проверить, что данные не изменены. Есть и другие вещи, помимо простой передачи данных, которые могут пойти не так. - person Guffa; 02.11.2010
comment
@Guffa: Конечно, но сертификация состоит не только из одного элемента. Я уверен, что есть и другие требования, касающиеся риска на конечных точках. - person Hogan; 02.11.2010
comment
@Гуффа. Предположим, что это приложение C# для Windows. И соединение SQL открывается с помощью Use Encryption for Data=True. И выдается заявление SQL, я не понимаю, где может быть пробел? - person Conrad Frix; 02.11.2010
comment
@Conrad Frix: вам все еще нужно иметь возможность убедиться, что значения, которые вы отправляете в запрос, не изменены и не усечены запросом. Шифрование никак от этого не защищает. - person Guffa; 02.11.2010
comment
@Гуффа. Таким образом, предложение состоит в том, что каждый запрос должен использовать какую-то функцию сужения, потому что параметры могут быть изменены до выполнения запроса, например, с помощью отладчика. Этот вектор атаки, вероятно, недостаточно часто рассматривается на толстых клиентах. - person Conrad Frix; 02.11.2010
comment
@Guffa Подождите, что. Я вызываю sp_set_foo bar, есть опасения, что записано только b, и это не результат чего-то вредоносного? - person Conrad Frix; 02.11.2010
comment
@Конрад Фрикс: Да, в основном. Длина поля не должна прерываться автоматически, но такие вещи, как кодировка символов и точность чисел, будут. - person Guffa; 02.11.2010

arrow_upward
2
arrow_downward

Это зависит. Две договаривающиеся стороны могут договориться об уровне защиты и используемых алгоритмах. В наиболее распространенном случае при согласовании используется TLS, а не SSL, запрашивается конфиденциальность сообщения (т. шифрование) и требуется защита от несанкционированного доступа (т.е. подпись). TLS использует хеширование сообщений на основе HMAC, см. главу 5 RFC2246. SSL использует MAC, который немного слабее, чем HMAC (MAC не содержит секрета в его дайджест).

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

person Remus Rusanu    schedule 02.11.2010
comment
Все это кажется неважным. Суть требования в том, что PII не отправляется в открытом виде. Кажется, SSL всегда удовлетворит это, верно? - person Hogan; 02.11.2010

arrow_upward
1
arrow_downward

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

Я буду яснее:

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

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

Важное примечание. Убедитесь, что связь SSL реализована правильно — это единственная точка отказа.

person Hogan    schedule 02.11.2010
comment
Примечание: сертификаты больше касаются буквы требований, чем духа требований, поэтому OP, вероятно, нуждается в проверке того, что определенные шаги хеширования и проверки выполняются на указанных шагах в протоколе. - person jball; 02.11.2010
comment
@jball: прочитайте мои дополнительные комментарии. Я не могу представить, что OP будет отказываться от использования SSL. Каждая сертификация, которую я когда-либо проходил, была посвящена удовлетворению или превышению требований — вы сделаете это с помощью SSL. - person Hogan; 02.11.2010
comment
@ Хоган, если требования в сертификации указывают или превышают или что-то подобное, ваш ответ правильный. Я только что столкнулся со слишком большим количеством бюрократических проволочек, должен иметь x требования, чтобы чувствовать себя в безопасности, предполагая это. - person jball; 02.11.2010
comment
@jball: хорошо, посмотри здесь en.wikipedia.org/wiki/Secure_Sockets_Layer#How_it_works как Я читал, что MD5 используется во всех коммуникациях. - person Hogan; 02.11.2010
comment
@jball: Кроме того, я никогда не работал над сертификацией, где превышение требований не удовлетворяло бы их. - person Hogan; 02.11.2010
comment
Вы не совсем ответили на вопрос здесь. Шифрование не гарантирует ipso facto невозможность расшифровки данных в случае их изменения. Для этого требуются специальные методы шифрования, и там, где это необходимо, обычно используется MAC или, что еще лучше, цифровая подпись. - person user207421; 04.11.2010
comment
@EJP: ваше утверждение может быть верным в общем случае, но неверно в конкретном случае, SSL гарантирует это, иначе SLL не был бы безопасным. - person Hogan; 04.11.2010
comment
SSL защищен от изменений данных, потому что он вычисляет HMAC, а не только потому, что он шифрует, как вы сказали. - person user207421; 05.11.2010

arrow_upward
1
arrow_downward

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

RFC 4346 продолжает:

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

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

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

person Bruno    schedule 02.11.2010