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
Erwann Abalea
Le dimanche 23 décembre 2012 05:47:50 UTC+1, ptilou a écrit :
Y a t'il du nouveau pour eviter ce type d'attaque ? (sur du SSL )
Rien de bien nouveau: - vérifier le certificat obtenu, son état de révocation, son chaîn age avec une banque de confiance, sa cohérence avec le host souhaité - faire de l'authentification client (avec certificat) - éventuellement faire du cert/CA/key pinning. - si DANE est utilisé, procéder aux vérifications.
À part DANE, et dans une moindre mesure le pinning, le reste est très c lassique.
Le dimanche 23 décembre 2012 05:47:50 UTC+1, ptilou a écrit :
Y a t'il du nouveau pour eviter ce type d'attaque ?
(sur du SSL )
Rien de bien nouveau:
- vérifier le certificat obtenu, son état de révocation, son chaîn age avec une banque de confiance, sa cohérence avec le host souhaité
- faire de l'authentification client (avec certificat)
- éventuellement faire du cert/CA/key pinning.
- si DANE est utilisé, procéder aux vérifications.
À part DANE, et dans une moindre mesure le pinning, le reste est très c lassique.
Le dimanche 23 décembre 2012 05:47:50 UTC+1, ptilou a écrit :
Y a t'il du nouveau pour eviter ce type d'attaque ? (sur du SSL )
Rien de bien nouveau: - vérifier le certificat obtenu, son état de révocation, son chaîn age avec une banque de confiance, sa cohérence avec le host souhaité - faire de l'authentification client (avec certificat) - éventuellement faire du cert/CA/key pinning. - si DANE est utilisé, procéder aux vérifications.
À part DANE, et dans une moindre mesure le pinning, le reste est très c lassique.
Erwan David
Erwann Abalea écrivait :
Le dimanche 23 décembre 2012 05:47:50 UTC+1, ptilou a écrit :
Y a t'il du nouveau pour eviter ce type d'attaque ? (sur du SSL )
Rien de bien nouveau: - vérifier le certificat obtenu, son état de révocation, son chaînage avec une banque de confiance, sa cohérence avec le host souhaité - faire de l'authentification client (avec certificat) - éventuellement faire du cert/CA/key pinning. - si DANE est utilisé, procéder aux vérifications.
À part DANE, et dans une moindre mesure le pinning, le reste est très classique.
Utiliser la RFC 5746 pour gérer les renégociations.
-- Les simplifications c'est trop compliqué
Erwann Abalea <eabalea@gmail.com> écrivait :
Le dimanche 23 décembre 2012 05:47:50 UTC+1, ptilou a écrit :
Y a t'il du nouveau pour eviter ce type d'attaque ?
(sur du SSL )
Rien de bien nouveau:
- vérifier le certificat obtenu, son état de révocation, son chaînage avec une banque de confiance, sa cohérence avec le host souhaité
- faire de l'authentification client (avec certificat)
- éventuellement faire du cert/CA/key pinning.
- si DANE est utilisé, procéder aux vérifications.
À part DANE, et dans une moindre mesure le pinning, le reste est très classique.
Utiliser la RFC 5746 pour gérer les renégociations.
Le dimanche 23 décembre 2012 05:47:50 UTC+1, ptilou a écrit :
Y a t'il du nouveau pour eviter ce type d'attaque ? (sur du SSL )
Rien de bien nouveau: - vérifier le certificat obtenu, son état de révocation, son chaînage avec une banque de confiance, sa cohérence avec le host souhaité - faire de l'authentification client (avec certificat) - éventuellement faire du cert/CA/key pinning. - si DANE est utilisé, procéder aux vérifications.
À part DANE, et dans une moindre mesure le pinning, le reste est très classique.
Utiliser la RFC 5746 pour gérer les renégociations.
