Ne TLS assurer l'intégrité du message et de la confidentialité de la transmission de données dans un cadre Reposant Java enterprise
Je veux faire une demande de sécurité des services web selon OWASP de Sécurité des Services Web. Ainsi que je suis tombé sur deux points:
Jusqu'à présent, il est juste un service RESTful qui peut être directement accessibles par un client. Pour chaque requête, le client doit s'authentifier par le serveur. Toute la communication est sécurisée via TLS. Je suis maintenant des doutes sur Message Integrity depuis je ne comprends pas la phrase:
Lors de l'utilisation de la cryptographie à clé publique de chiffrement ne pouvons garantir la confidentialité, mais il ne garantit pas l'intégrité depuis l'
récepteur de la clé publique est publique. Pour la même raison, le cryptage n'
ne pas s'assurer de l'identité de l'expéditeur.
Est-il également nécessaire que les données a été signé par le client, afin que l'intégrité du message est assurée? TLS est seulement point-à-point, qu'est-ce que sur les procurations?
Concernant Message Confidentiality, je l'ai compris comme suit.
- Utiliser TLS pour assurer la confidentialité des messages sur le fil.
- Utiliser un chiffrement symétrique pour chiffrer les données transmises.
- Les données chiffrées sont stockés dans la base de données.
Ai-je comprendre que le droit?
Vous devez vous connecter pour publier un commentaire.
De la TLS spécification:
Donc, oui, TLS sera de vous fournir de l'intégrité et de la confidentialité du message au cours de son transport, à condition qu'il soit utilisé correctement.
En particulier, le client doit vérifier le certificat pour s'assurer qu'il est en communication avec le bon serveur (en vérifiant que le certificat est authentique et émises par une partie de confiance, et délivré au nom de l'hôte il a l'intention de contact).
TLS sera d'en assurer la confidentialité via le chiffrement. (Vous devez utiliser une suite de chiffrement, et en particulier pas un anonyme de la suite de chiffrement ou une suite de chiffrement sera chiffrement null, mais c'est toujours le cas par défaut).
Si vous souhaitez crypter les données dans votre base de données, c'est un autre problème. TLS vous donne seulement l'intégrité et la confidentialité pendant le transport. Une fois qu'il est manipulé par votre application web, c'est déchiffré.
Les proxies HTTP seule relais de la TLS trafic-est, sans regarder ou de les modifier. (Certains serveurs proxy peuvent intercepter le trafic, mais la vérification de certificat serait un échec, sauf si vous oubliez de vérifier le certificat.)
Oui.
Hors de propos. La réponse est encore oui.
Hors de propos. TLS n'est pas de chiffrement à clé publique. Je n'arrive vraiment pas à voir l'intérêt de ces remarques dans ce contexte, mais elles ne sont pas correctes. Aucune forme de chiffrement seul garantissent ni l'intégrité ou l'identité: vous avez besoin de mesures supplémentaires pour que; et la clé publique n'est pas pertinente pour ainsi.
Pas. Une sécurité HMAC sera de faire aussi bien, et TLS utilise l'un de ceux-ci. TLS ne utiliser des signatures numériques au cours de la phase d'authentification.
Procurations sont soit de confiance TLS points de terminaison de leur propre ou autre transparent octet de passage de procurations que, par conséquent, de préserver les propriétés de TLS entre leurs pairs comme des points de terminaison.
Correcte.
TLS le fait que.
Pas. Les données chiffrées obtient descrypted par les pairs-off sur le fil. Les pairs peuvent chiffrer de nouveau à la base de données, ou de la base de données peut le faire, mais c'est une question distincte.