SSL utilise-t-il le hachage en interne?

Nous sums en train de certifier notre produit de santé (certificateion Hitech). L'un des critères du process de certificateion est que notre produit devrait être capable d'utiliser le "hachage" lors de l'envoi d'informations patient sur le réseau. Notre produit est un client lourd qui se connecte directement à la database Sql Server 2005. Ainsi, lorsque nous envoyons des informations patient du client à la procédure de magasin DB, il convient d'utiliser le "hachage" pour s'assurer que l'information n'a pas été modifiée pendant le transport.

Maintenant, nous prévoyons de connecter notre client au server Sql en utilisant une connection sécurisée SSL. Quand je lis sur le protocole SSL, il semble que SSL utilise le hachage en interne. Donc si c'est vrai, je pourrais satisfaire automatiquement l'exigence de hachage en utilisant la connection SSL entre client et sql svr.

Donc, voici mes questions

  • Lorsque datatables sont transmises via une connection SSL, chaque message est-il associé à un hachage interne, de sorte que le protocole SSL vérifie que datatables n'ont pas été modifiées?
  • SSL utilise-t-il le mécanisme de hachage uniquement pendant les étapes initiales de sa négociation? Donc, après la poignée de main est terminée, il crypte / décrypte seulement datatables sans mécanisme de hachage impliqué?
  • Si SSL joint un hachage à chaque message, la "key publique" est-elle utilisée pour créer le hachage?

Lorsque datatables sont transmises via une connection SSL, chaque message est-il associé à un hachage interne, de sorte que le protocole SSL vérifie que datatables n'ont pas été modifiées?

Oui. Il ajoute une key MAC à chaque logging TLS échangé.

SSL utilise-t-il le mécanisme de hachage uniquement pendant les étapes initiales de sa négociation?

Non, cela se produit partout.

Si SSL joint un hachage à chaque message, la "key publique" est-elle utilisée pour créer le hachage?

Non. Un secret partagé est utilisé pour créer le hachage.

Voir RFC2246 pour plus de détails.

Même si SSL utilise le hachage, cela ne garantit que la partie de la transmission que SSL gère. Il existe toujours un écart à chaque extrémité entre l'application cliente et la connection réseau, et entre la connection réseau et l'application server.

Vous devez créer un hachage des données qui voyagent avec datatables depuis l'intérieur de l'application client jusqu'à l'intérieur de l'application server.

Ça dépend. Les deux parties négociasortingces peuvent négocier le niveau de protection et les algorithms utilisés. Le cas le plus courant est que la négociation utilise TLS , pas SSL, la confidentialité des messages est demandée (c'est-à-dire le encryption) et une protection contre la falsification est demandée (signature). TLS utilise par hachage de message basé sur HMAC , voir le chapitre 5 de la RFC2246 . SSL utilise un MAC , qui est légèrement plus faible qu'un HMAC (un MAC ne contient pas de secret dans son résumé).

À une vue de niveau exécutif de 10000 pieds, la réponse est «Oui, SSL hache chaque message». L'application du chiffrement SSL sur le protocole client SQL Server est généralement requirejse dans les deployments conforms. Pour plus de détails et de conseils, consultez la webdiffusion et les livres blancs sur SQL Server Compliance .

SSL est plus fort que le hachage. Cela devrait satisfaire votre exigence.

Je serai plus clair:

SSL crypte toutes datatables transmises. Cela signifie que datatables ne peuvent pas être lues et si elles sont modifiées, elles ne peuvent pas être déchiffrées. SSL vous évite ainsi de tomber des gouttières et des changements.

L'exigence a été écrite avec l'espoir que la plupart des communications ont été faites en clair. Avec l'utilisation de SSL, vous répondez facilement à cette exigence.

Remarque importante: Assurez-vous que la communication SSL est correctement implémentée – c'est le sharepoint défaillance unique.

SSL, ou TLS (vous pourrez probablement utiliser TLSv1.0 au less de nos jours, même en parlant de "SSL"), vise à protéger les objectives " […] d'assurer la confidentialité et l'intégrité des données entre deux applications communicantes "(voir RFC ).

RFC 4346 continue en disant:

Le protocole d'logging TLS fournit une security de connection qui a deux propriétés de base:

  • La connection est privée. […]
  • La connection est fiable. Le transport de messages comprend un contrôle d'intégrité de message à l'aide d'un MAC avec key. Des fonctions de hachage sécurisées (par exemple, SHA, MD5, etc.) sont utilisées pour les calculs MAC. Le protocole d'logging peut fonctionner sans MAC, mais n'est généralement utilisé que dans ce mode, tandis qu'un autre protocole utilise le protocole d'logging comme moyen de transport pour négocier les parameters de security.

Donc, oui, il détectera les tentatives de corruption de la transmission de données (intentionnelle ou accidentelle).