2011-01-03 7 views
0

Je n'arrive pas à comprendre ce qui suit: WS-Security et https sont présentés comme des alternatives. Le problème avec https (comme décrit) est quand les intermédiaires, c'est-à-dire les proxies, se trouvent entre le client et le serveur.
Ensuite, nous pouvons travailler ensemble et garantir une sécurité point à point, par ex. entre proxy et serveur mais pas de bout en bout.
donc nous pouvons avoir:ws-security and transport security

client < - (sécurisé) -> Proxy < - (Secure) -> Serveur

Mais ce n'est pas égal à

Client <--(secure)--> Server 

Alors, pourquoi la garantie de bout en bout n'est-elle pas garantie? Quelqu'un pourrait-il donner un exemple précis?
Aussi, si dans mon réseau je n'ai pas de proxy, cela signifie-t-il que https est ok?
Et vice versa si j'ai des proxies, je DOIS utiliser WS-Security à la place?
Merci

Répondre

3

Votre compréhension n'est pas exactement correcte. Avec HTTPS, votre communication est sécurisée entre le client et le serveur. Le proxy ne sait rien de la communication sauf une chose - l'hôte auquel vous communiquez. Ceci est réalisé en utilisant le proxy HTTPS (commande HTTP Connect, voir RFC 2616 pour plus de détails). Donc, il n'y a pas de problème avec HTTPS (je ne sais pas où vous avez trouvé le contraire).

+0

@Eugene: Merci de répondre.Vous pouvez même regarder dans le wiki http://en.wikipedia.org/wiki/WS-Security#Alternative. Il mentionne ceci: – Cratylus

+0

@ user384706 Le texte Wikipedia parle de "si les messages devaient passer par un serveur proxy au niveau de l'application". Le proxy HTTPS n'est pas un proxy au niveau application (contrairement au proxy HTTP) mais un proxy au niveau du transport: le proxy HTTPS construit un tunnel entre un client et un serveur (ou un autre proxy) et envoie les données sans regarder dedans. –

+0

@Eugene: Je vois, mais dans ce cas, pourquoi WS-Security avait-il besoin d'être introduit? – Cratylus