Discussion :

[Gordon Fowler]

La majorité des sites n'utilise pas correctement SSL
Selon un chercheur au Black Hat 2010, la crédibilité du protocole de chiffrement est en jeu



Décidément, chaque année le protocole SSL est une cible de choix pour les conférenciers du Black Hat, la conférence sur la sécurité informatique qui se tient une fois par an à Las Vegas.

L'année dernière, un chercheur en sécurité répondant au pseudo de Moxie Marlinspike avait mis à mal le Secure Socket Layer.

SSL est un protocole de sécurité qui protège les sites Web en chiffrant les informations sensibles pendant les transactions en ligne. Même s’il s’agit d’un protocole efficace, certains déploiements posent problèmes, notamment pour la configuration et la validation du certificat, ce qui rend alors SSL quasiment inutile et peut même compromettre la sécurité d'un site.

Cette année, c'est au tour de Ivan Ristic, chercheur chez Qualys de déclarer que « SSL est un protocole fiable [...] mais qui n’est tout simplement pas configuré correctement sur la plupart des sites ».

Pire, la grande majorité des sites qu'il a étudiés auraient un certificat SSL qui ne correspondrait pas au nom du site auquel ce certificat est censé être rattaché.

Son rapport révèle également plusieurs points préoccupants :

• Seuls 70% des certificats sont valides

• La moitié de tous les sites supportent encore le protocole SSLv2 (l'ancien protocole beaucoup moins fiable)

• 62% des sites SSL ne sont pas bien configurés

• Environ 32% des sites continuent de pâtir de la vulnérabilité liée à la renégociation

Ces remises en cause ne sont pas sans poser la question de la crédibilité du SSL.

Ce protocole, supposé rassurer l'internaute - et surtout lui assurer une sécurité supplémentaire, serait au final presque inefficace parce que très mal utilisé.

Ivan Ristic le regrette mais plaide tout de même pour sa généralisation (lire par ailleurs « Pourquoi si peu de trafic chiffré aujourd'hui ? »). Aujourd'hui, seule une fraction de l’ensemble des sites Web utilise en effet SSL.

Il milite également pour une meilleure connaissance du protocole qui, d'après lui, devrait permettre de diminuer les mauvaises pratiques.

Il joint d'ailleurs le geste à la parole puisqu'il vient de mettre au point un outil de test en ligne gratuit, baptisé Qualys SSL Labs, pour auditer la qualité des certificats SSL des sites Web.

Un test grandeur nature pour savoir si votre site (et vous même) fait partie des « bons » ou des « mauvais élèves ».


Source


Lire aussi :

Des millions de routeurs vulnérables à une technique d'exploit vieille de 15 ans, une variation de l'attaque par DNS rebinding menace

Les rubriques (actu, forums, tutos) de Développez :

Sécurité
Réseaux
Systèmes
Développement Web

Et vous ?

Faites-vous partie des « bons élèves » ou avez-vous des surprises avec le test de Qualys ?

Pensez-vous que le protocole SSL soit encore crédible ?

[grunk]

A propos de https://cfspart.impots.gouv.fr

This server is vulnerable to MITM attacks because it supports renegotiation (more info here).

Et un score de 52/100 ... c'est rassurant

Quoi qu'il en soit pour moi le protocole ssl reste une valeur sure et les navigateurs on fait de gros progrès pour détecter les certificats louche ou non valide qui pourrait nous exposer.

[Inazo]

Bonjour,

Intéressant en effet et il ne met pas a disposition un guide des bonnes pratiques de mise en place de SSL ?

Et les certificats auto-signé ? Beaucoup moins bon ?

EDIT : Je viens de faire le test sur un hébergeur connu plein de 1, 85/100...

Cordialement,

[Michaël]

Je ne vois pas en quoi ils ont fait des progrès... un certificat c'est soit il est valide, soit il ne l'est pas.
Si le nom du certificat ne correspond pas au nom du site : il n'est pas valide.
S'il est auto-signé : il n'est pas valide. Je viens de créer un certificat pour www.mabanque.fr : est-ce que pour autant je suis www.mabanque.fr ? Non.
Si le certificat n'a pas été signé par une autorité de certification de confiance, il n'est pas valide. Il n'y a aucun progrès à faire sur la validité d'un certificat mais plutôt sur son utilisation.

Après pour les bonnes pratiques, ne pas permettre sslv2, ne pas utiliser de certificat auto-signé, utiliser des crl/oscp, surveiller les dates d'expiration/renouvellement des certificats en ligne, etc. Il faut aussi faire attention aux chiffrements autorisés (ne pas utiliser des chiffrements faibles aujourd'hui).

Pour le test de qualys : ils y vont un peu fort ! J'ai pas envie d'avoir un certificat qui accepte tous les préfixes de domaine.

Prefix handling : Not valid for "****.fr" CONFUSING

[Tinmar88]

Bon ben il n'y a pas que des mauvais élèves.
Ma banque a une moyenne de 85/100 c'est rassurant!

[jfsenechal]

Je viens de faire le test pour mon site pas terrible

c'est quoi la weak key ?

"Weak key (Debian) Yes INSECURE"

[marcusien]

Paypal n'a un résultat que de 85/100 avec une vulnérabilité pour les attaques par Man In The Middle...On pourrait au moins s'attendre de leur part à un beau 100%

[Michaël]

@jf_homer : Il y a eu un problème avec openssl sur debian : il faut que tu mettes à jour ton serveur et que tu recréés une paire de clés. Enfin je pense qu'il parle de ça

[atb]

Ce test est-il fiable ? Par ce que ma banque a eu un score de 56

Par contre mail.gmail.com est à 85.

Avons-nous un site à 100% ?

[marcusien]

@atb : Non il n'y a pas de 100% qui ait été testé sur le site apparemment. Regarde dans les Recent Best-Rated le mieux c'est 93%

[djouk]

c'est la 1 ère que j'ai entendu parler de ce protocole "SSL"

[grunk]

Je ne vois pas en quoi ils ont fait des progrès... un certificat c'est soit il est valide, soit il ne l'est pas.
Si le nom du certificat ne correspond pas au nom du site : il n'est pas valide.
S'il est auto-signé : il n'est pas valide. Je viens de créer un certificat pour www.mabanque.fr : est-ce que pour autant je suis www.mabanque.fr ? Non.
Si le certificat n'a pas été signé par une autorité de certification de confiance, il n'est pas valide. Il n'y a aucun progrès à faire sur la validité d'un certificat mais plutôt sur son utilisation.

Après pour les bonnes pratiques, ne pas permettre sslv2, ne pas utiliser de certificat auto-signé, utiliser des crl/oscp, surveiller les dates d'expiration/renouvellement des certificats en ligne, etc. Il faut aussi faire attention aux chiffrements autorisés (ne pas utiliser des chiffrements faibles aujourd'hui).

Pour le test de qualys : ils y vont un peu fort ! J'ai pas envie d'avoir un certificat qui accepte tous les préfixes de domaine.

Quand je parlais de progrès c'était au niveau des navigateurs qui affichent bien plus clairement qu'avant lorsque qu'un certificat n'est pas valide.

[WhoIsTiti]

Je m'intéresse depuis quelques jours précisément à ce sujet (sujet évoqué dans le forum MySql). Etrange coïncidence.
Je ne suis pas administrateur de serveur, tout juste un débutant.
J'ai donc fait en partie le nécessaire sur mon VPS IIS7 et je viens de soumettre ma protection sur le site donné ci dessus [cf : résultat du test]
Évidement, j'ai un zéro pointé vu que j'ai un certificat auto-signé. Ce qui n'empêche d'avoir un cryptage correct malgré tout (corrigé moi si je me goure).
J'ai encore quelques soucis avec le support des protocoles TLS 1.1 et TLS 1.2 (que j'ai pourtant ajouté à la base de registre) et avec Cipher Strength ...(ajoutés également à la base de registre).
Je pense que je dois régler ça dans l'éditeur de stratégie de groupe locale [modèle d'administration/réseau/Paramètres de configuration SSL] au sein d'ISS.
Si certains d'entre vous connaissent les manip exactes, je suis preneur, sinon je vais continuer à fureter sur le net.

[jfsenechal]

@jf_homer : Il y a eu un problème avec openssl sur debian : il faut que tu mettes à jour ton serveur et que tu recréés une paire de clés. Enfin je pense qu'il parle de ça

mon serveur à jour il l'est
j'ai vaguement souvenir d'un souci ssl chez debian, c'est vrai que mon certificat a été créé il y a quelques années.

je vais essayer.

[arflam]

c'est la 1 ère que j'ai entendu parler de ce protocole "SSL"

C'est quand tu utilises httpS au début de l'adresse de ton site (pour le protocole http).
Un cetif valide garanti entre autre que le nom du site sur le certificat est bien le même que celui sur le quel tu vas.

Un peu comme une carte d'identité avec la tronche du type que qui te la présente.

[JPLAROCHE]

Bref moi je fais le certificat avec l'AS400

Et je vous en donne pour votre argent de toutes façons, il y a des clients qui ne veulent pas de ssl de certificat .

Vous ne me croyez pas ben si.

Voilà et j'en ai bavé pour arriver à rendre ce site sécurisé.

Alors me direz vous impossible.

Lorsque vous entendez l'administrateur qui dit donnez son mot passe pour faire les traitements a sa place.

Maintenant je mets surtout en place une sécurité qui permet de protéger l'entreprise avec log ect...
traçabilité totale de la pièce en passant par le carton la livraison a qui quand ou et de qui et j'en passe.

Et ça marche preuve les douanes en sont contents ainsi que les clients.
on peut retrouver même les contre façon.


De plus lorsque le marché est signé donc pas d'argent en ligne
la sécurisation est beaucoup plus tourné vers l'authentification et là ont peut verrouiller dur de dur (sauf si .... tu donnes ....)

bon j'ai pas la solution parfaite mais 99%
@bientôt

[Chauve souris]

... en programmation de sites sécurisés c'est une bonne doc (traduite) et un tutorial. J'avais fait l'exemple cité dans le bouquin Campus Press (ASP 2.0) à l'époque, mais je n'y ai plus retouché depuis.

[fabfab75]

Verisign a un score de 76 avec https://www.verisign.com
https://www.ssllabs.com/ssldb/analyz...w.verisign.com

[orden]

Quand les données sont pas sensibles (genre les news, les sites pornos, les jeux, ce qui représente une bonne part du traffic) on en a rien a faire. Le certificat SSL coute du temps et de l'argent.

Il y a deux choses dans le SSL:
- L'identification du serveur
- Le cryptage du canal.

Le cryptage est une bonne chose quand on traite de données sensibles, surtout sur les wifi ouverts. Donc avoir un certificat auto-signé ou un certificat périmé c'est mieux que rien. Je connais pas la solution "HTTPS anywhere" mais il semble que cela corresponde aussi à ce besoin.

Pour une identification du serveur qui évite les IP falsifiées, pourquoi pas, mais cela n’empêchera jamais les arnaqueurs de fabriquer des faux pour monter un dossier. Je suis sur le point de finir une procédure de certification pour le SSL chez OVH et c'est vraiment pénible avec des incapables qui perdent les justificatifs. En fait c'est bureaucratique et inefficace et mes utilisateurs ont des certificats périmés depuis un mois!

Pour les fans de SSL:
Si tu évites ton site de courtage en bourse car le certificat est périmé pour éviter un hypothétique problème mais pendant ce temps tes actions tombent et tu perds ton argent. Si c'est SSL c'est que c'est critique et donc souvent utile, donc tu peux rarement t'en passer le temps que le serveur soit corrigé.

Bref en sécurité informatique, il faut être pragmatique. Si tu mets de coté le service à rendre et que tu te focalise 100% sur la sécurité avoir un site sûr est simple: "shutdown now".