Serveurs en round-robin et certificats SSL multiples
2 réponses
Colin Leroy
Bonjour,
Certains serveurs, email par exemple, sont load-balancés et configurés
avec les pieds; c'est à dire que tous n'ont pas forcément le même
certificat SSL.
Par exemple, mail.hp.com:993 montre ce problème.
Certains utilisateurs du client mail que je développe, agacés de
devoir cliquer sur "Accept changed certificate" à peu près à toutes
les connexions, m'ont demandé si ce serait possible de gérer plusieurs
certificats SSL pour un hôte/port donné...
Le résultat serait qu'ils n'auraient plus qu'une demande de
confirmation (certificat inconnu) par certificat...
D'après vous, au niveau sécurité, serait-ce une hérésie? Doit-on ne
considérer qu'un seul et unique certificat comme valide pour un
hôte/port donné ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Philippe Gaulier
On 05 Dec 2006 19:45:34 GMT Colin Leroy wrote:
Salut Colin,
Certains utilisateurs du client mail que je développe, agacés de devoir cliquer sur "Accept changed certificate" à peu près à toutes les connexions, m'ont demandé si ce serait possible de gérer plusieurs certificats SSL pour un hôte/port donné...
Le résultat serait qu'ils n'auraient plus qu'une demande de confirmation (certificat inconnu) par certificat...
D'après vous, au niveau sécurité, serait-ce une hérésie?
Les utilisateurs de claws ont toujours été bien éduqué jusqu'à présent, continuer me semble être la bonne chose. Développer le client en ce sens reviendrait à accepter n'importe quelle connexion de type "man in the middle" de plein pied.
Exemple sur un réseau local : le réseau local (domaine de broadcast) est redirigé par l'intermédiaire d'une saturation arp au niveau du commutateur. Tout flux passe par notre attaquant. Celui-ci est alors libre de casser la chaîne de certificat et de proposer le sien, avec bien sûr, le même nom, les mêmes identifiants, etc. Le moyen le plus évident pour détecter cette tentative d'usurpation est l'alerte de l'utilisateur de la modification du certificat par rapport à celui habituel. Le certificat est donc automatiquement accepté, notre pirate peut donc proposer n'importe quoi au client friand de flux mail/nntp/rss.
Évidemment, on peut imaginer plein de scénarios, mais en gros, c'est une mauvaise solution.
Doit-on ne considérer qu'un seul et unique certificat comme valide pour un hôte/port donné ?
Oui, c'est l'usage de ssl.
jp
On 05 Dec 2006 19:45:34 GMT
Colin Leroy <colin@colino.net> wrote:
Salut Colin,
Certains utilisateurs du client mail que je développe, agacés de
devoir cliquer sur "Accept changed certificate" à peu près à toutes
les connexions, m'ont demandé si ce serait possible de gérer plusieurs
certificats SSL pour un hôte/port donné...
Le résultat serait qu'ils n'auraient plus qu'une demande de
confirmation (certificat inconnu) par certificat...
D'après vous, au niveau sécurité, serait-ce une hérésie?
Les utilisateurs de claws ont toujours été bien éduqué jusqu'à présent,
continuer me semble être la bonne chose. Développer le client en ce
sens reviendrait à accepter n'importe quelle connexion de type "man in
the middle" de plein pied.
Exemple sur un réseau local :
le réseau local (domaine de broadcast) est redirigé par l'intermédiaire
d'une saturation arp au niveau du commutateur. Tout flux passe par
notre attaquant. Celui-ci est alors libre de casser la chaîne de
certificat et de proposer le sien, avec bien sûr, le même nom, les
mêmes identifiants, etc. Le moyen le plus évident pour détecter cette
tentative d'usurpation est l'alerte de l'utilisateur de la modification
du certificat par rapport à celui habituel. Le certificat est donc
automatiquement accepté, notre pirate peut donc proposer n'importe quoi
au client friand de flux mail/nntp/rss.
Évidemment, on peut imaginer plein de scénarios, mais en gros, c'est
une mauvaise solution.
Doit-on ne
considérer qu'un seul et unique certificat comme valide pour un
hôte/port donné ?
Certains utilisateurs du client mail que je développe, agacés de devoir cliquer sur "Accept changed certificate" à peu près à toutes les connexions, m'ont demandé si ce serait possible de gérer plusieurs certificats SSL pour un hôte/port donné...
Le résultat serait qu'ils n'auraient plus qu'une demande de confirmation (certificat inconnu) par certificat...
D'après vous, au niveau sécurité, serait-ce une hérésie?
Les utilisateurs de claws ont toujours été bien éduqué jusqu'à présent, continuer me semble être la bonne chose. Développer le client en ce sens reviendrait à accepter n'importe quelle connexion de type "man in the middle" de plein pied.
Exemple sur un réseau local : le réseau local (domaine de broadcast) est redirigé par l'intermédiaire d'une saturation arp au niveau du commutateur. Tout flux passe par notre attaquant. Celui-ci est alors libre de casser la chaîne de certificat et de proposer le sien, avec bien sûr, le même nom, les mêmes identifiants, etc. Le moyen le plus évident pour détecter cette tentative d'usurpation est l'alerte de l'utilisateur de la modification du certificat par rapport à celui habituel. Le certificat est donc automatiquement accepté, notre pirate peut donc proposer n'importe quoi au client friand de flux mail/nntp/rss.
Évidemment, on peut imaginer plein de scénarios, mais en gros, c'est une mauvaise solution.
Doit-on ne considérer qu'un seul et unique certificat comme valide pour un hôte/port donné ?
Oui, c'est l'usage de ssl.
jp
Colin Leroy
On 07 December 2006 at 10h12, Jean-Philippe Gaulier wrote:
Hi,
Évidemment, on peut imaginer plein de scénarios, mais en gros, c'est une mauvaise solution.
Merci de ton avis. Comme j'ai quelques utilisateurs que j'aime bien qui me l'avaient demandé, j'ai suivi le processus usuel, la préférence cachée avec le comportement par défaut étant le comportement correct...
-- Colin
On 07 December 2006 at 10h12, Jean-Philippe Gaulier wrote:
Hi,
Évidemment, on peut imaginer plein de scénarios, mais en gros, c'est
une mauvaise solution.
Merci de ton avis. Comme j'ai quelques utilisateurs que j'aime bien qui
me l'avaient demandé, j'ai suivi le processus usuel, la préférence
cachée avec le comportement par défaut étant le comportement correct...
On 07 December 2006 at 10h12, Jean-Philippe Gaulier wrote:
Hi,
Évidemment, on peut imaginer plein de scénarios, mais en gros, c'est une mauvaise solution.
Merci de ton avis. Comme j'ai quelques utilisateurs que j'aime bien qui me l'avaient demandé, j'ai suivi le processus usuel, la préférence cachée avec le comportement par défaut étant le comportement correct...
