Discussion :

[tolstoy]

Bonjour
Je suis entrain de développer une application java web avec des web services Restful. Maintenant je veux que les échanges des web services soient cryptés. Je voudrais pour cela solliciter votre aide pour savoir comment m'y prendre. Quelles technologies existent et laquelle utilisée?
Merci pour votre aide

[fr1man]

Rest étant basé sur HTTP, tu peux passer par sa version sécurisée à savoir HTTPS.
Acheter un certificat ou le générer toi même pour tes tests, paramétrer ton serveur web ou d'application avec ce certificat et le tour est joué.

[tolstoy]

Merci pour la réponse. Mais cela ne nécessite pas des codes à ajouter à mes web services? Les clients qui appellent mes services n'auront pas d'autres traitements à faire de leur coté?

[Carhiboux]

Salut,

A priori, tu as plusieurs options :

Chiffrer ou non le données.

Passer par un canal en clair (http) ou chiffré (https).

Si tes données sont si sensibles que cela, https seul ne suffit peut être pas. A toi alors de rajouter un cryptage de tes données qui t'es propre. Par exemple, tu peux utiliser AES ou toute autre méthode de ton choix.

Au passage, et sans tomber dans la parano, les données n'en valent peut être pas la peine, mais rien ne garantit qu'à l'heure actuelle l'inviolabilité de HTTPS. Si les données en valent la peine donc les chiffrer AVANT de les balancer sur le réseau peut donc être une bonne idée. Mais cela suppose bien sur que la clé de chiffrage/déchiffrage soit elle même en sécurité.

[tolstoy]

Merci. Mais j'ai besoin d'informations sur les deux questions suivantes:

1-Comment m'y prendre si je décide d'utiliser l'AES? comment je l'implémente dans mes web services?(je rappelle que je développe des services restful)

2-Comment implémenter le système avec HTTPS? (je voudrais comprendre tout le mécanisme)

Merci

[Carhiboux]

Pour AES, tu peux trouver un tuto là : http://jmdoudoux.developpez.com/cours/developpons/java/

J'ai pas regardé dans le détail, mais il me semble que c'est les mêmes classes/packages que ce que j'ai eu l'occasion d'utiliser.


Pour HTTPS, la plupart des conteneurs d'application proposent un mode HTTPS, c'est juste une question de configuration, et de certificat. Sachant que tu peux auto-signer ton certificat, mais dans ce cas, les appelants devront accepter ton certificat (tu sais, la fameuse pop-up "attention, certificat non signé" suivi de "je comprends les risques", etc...).

Maintenant, la question à laquelle tu n'as pas répondu, c'est si tes données valent le coup d'être cryptées.

[tolstoy]

Merci pour l'aide. Je pense que mes données nécessitent le cryptage car c'est une application de vente sur le net. Si je comprend bien, pour la cryptographie il me faut lire la partie sécurité du cours de dej.

[Carhiboux]

En tout cas, cela t'expliquera les bases, maintenant, le cours date un peu je viens de voir que c'est du java 1.4, donc les librairies ont peut être évolué depuis, mais dans tous les cas, les grands principes restent les mêmes.

[tolstoy]

ok merci

[fr1man]

@Carhiboux
Si on part du principe que HTTPS n'est pas fiable, tout peut être considéré comme non fiable...

@tolstoy
Si c'est seulement les échanges que tu veux sécuriser, HTTPS semble déjà un bon début. Si les clients de tes webservices sont des navigateurs, à priori pas de modifications à faire, si ce n'est vérifier que le type de certificat
sera géré par les navigateurs cibles.
Après tu peux effectivement chiffrer tes données les plus sensibles sur ton serveur, mais là, on dépasse le cadre de la sécurisation de l'échange.

[OButterlin]

https devrait suffire, avec quasiment rien à faire d'autre que de modifier le paramétrage du serveur.

Pour ce qui est du chiffrement/déchiffrement des données par le poste client, je n'en vois pas l'intérêt, d'autant qu'il va falloir chiffrer/déchiffrer avec du javascript... ça risque de vite devenir galère

Les choses simples étant souvent les meilleurs, tu peux regarder ce qu'on en dit ici...

[Carhiboux]

@Carhiboux
Si on part du principe que HTTPS n'est pas fiable, tout peut être considéré comme non fiable....

Rien ne garantit que personne ne sait déchiffrer le HTTPS... Donc si les données sont extrêmement sensibles, d'où ma question sur le sujet, il peut être intéressant d'aller au delà du HTTPS.

Dans le monde bancaire, beaucoup de données qui sont échangées entre les établissements bancaires sont chiffrées. Et transitent via des canaux de communication eux aussi chiffrés.

Maintenant, clairement, si le but est de faire un site de commerce en ligne "lambda", chiffrer les données n'est sans doute pas nécessaires et HTTPS est sans doute suffisant.

Mais ce n'est pas pour autant que l'on peut assurer avec certitude que personne n'est en mesure de lire les flux HTTPS. On peut juste raisonnablement penser que ceux qui en auraient éventuellement les moyens ne se donneraient pas la peine de le faire sur un petit site.

[OButterlin]

Rien ne peut garantir que des données chiffrées échangées par des banques ne puissent être déchiffrées...

[Carhiboux]

Non, bien sur, mais cela rajoute au moins un obstacle

[OButterlin]

C'est sûr, mais dans le cadre d'une application web, dans la mesure où c'est le client (et donc du javascript la plupart du temps), je ne pense pas que ce soit un gage de sécurité.