CVE-2014-3566 — Vulnérabilité POODLE

Posté par  . Édité par Nÿco, bubar🦥, Davy Defaud, Xavier Teyssier, palm123 et Benoît Sibaud. Modéré par patrick_g. Licence CC By‑SA.
32
17
oct.
2014
Sécurité

Qu’est‐ce POODLE ?

POODLE signifie Padding Oracle On Downgraded Legacy. Il s’agit d’une vulnérabilité permettant via une attaque de l’« homme du milieu » (MIM, Man In the Middle), en se plaçant entre le navigateur Web et le serveur Web, de déchiffrer les informations chiffrées.

POODLE affecte les anciennes normes de chiffrement, notamment Secure Socket Layer (SSL) version 3.0. Il n’affecte pas le mécanisme de chiffrement plus récent, et standardisé, appelé Transport Layer Security (TLS).

Recommandations

Pour atténuer cette vulnérabilité, désactivez SSL 3.0 en forçant l’utilisation de TLS, tout en vérifiant la compatibilité des navigateurs clients devant y avoir accès.

Plusieurs bulletins de sécurité ont annoncé la vulnérabilité :

Histoire et aides diverses

Google a identifié une faille dans le protocole SSL v3. Il existe des contournements côté serveurs comme côté clients : garder en tête la compatibilité avec les navigateurs clients. Red Hat n’a pour l’instant pas publié d’errata. Cela affecte RHEL5, RHEL6 et RHEL7, également les CentOS. À voir pour les autres distributions…

Remarque : poodle signifie caniche en anglais.

Page pour tester votre navigateur client

https://www.poodletest.com/

Tester par vous même

openssl s_client -connect mon_site:443 -ssl3

Configurer Apache

SSLProtocol All -SSLv2 -SSLv3

Configurer Postfix

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

Tester la vulnérabilité de vos sites

Voici le script proposé par Red Hat :

#!/bin/bash
#
# Copyright (C) 2014 by Dan Varga <dvarga@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.


host=$1
port=$2

if [ "$2" == "" ]
then
    port=443
fi

out="`echo x | timeout 5 openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
ret=$?

if [ $ret -eq 0 ]
then
    echo "VULNERABLE! SSLv3 detected."
    exit
elif [ $ret -eq 1 ]
then
    out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`
    if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ]
    then
        echo "Not Vulnerable. We detected that this server does not support SSLv3"
        exit
    fi
elif [ $ret -eq 124 ]
then
    echo "error: timeout connecting to host $host:$port"
    exit
fi
echo "error: Unable to connect to host $host:$port"

Aller plus loin

  • # Précision que le `DLE` de `POODLE`

    Posté par  . Évalué à 9.

    Je pense qu'il manque une information sur cette attaque. Le Padding Oracle est sur SSL3.0. le Downgraded Legacy vient du comportement des clients. Le scénario est le suivant:

    • le client se connecte et demande une connexion en TLS1.0 - TLS1.2 par exemple
    • le MIM renvoie un refus de ces versions (cette partie n'est pas encore authentifiée)
    • le client se reconnecte (c'est une choix d'implémentation ici - mais qui est très répandue) et demande alors du SSL3.0

    Pour éviter ce scénario, une cipher suite vide a été rajoutée: TLS Fallback Signaling Cipher Suite Value (SCSV). Cf

    http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

  • # Quelques ressources supplémentaires sur le sujet

    Posté par  (site web personnel) . Évalué à 4.

    Pour savoir si un serveur accepte encore SSLv3, il y a par exemple la commande openssl citée ci-dessus, on peut aussi utiliser nmap :
    nmap --script ssl-enum-ciphers -p https HOST

    Un point sur lequel on n'insiste peut-être pas assez : ce problème n'est pas un bogue logiciel, pas un problème d'implémentation, mais bien un problème dans le protocole lui-même !

    • [^] # Re: Quelques ressources supplémentaires sur le sujet

      Posté par  . Évalué à 4.

      Un point sur lequel on n'insiste peut-être pas assez : ce problème n'est pas un bogue logiciel, pas un problème d'implémentation, mais bien un problème dans le protocole lui-même !

      La partie MIM, quand même, personne n'obligeait les clients à se reconnecter en demandant SSL3.0, même si d'un point de vue client, être utilisable est prioritaire (TLS propose maintenant un mécanisme pour se protéger lorsqu'on désire avoir ce comportement, mais ce n'est pas un comportement impliqué par le protocole à mon avis).

      Pour la partie Padding Oracle, c'est en effet intrinsèque. Mais là, pas de surprise non plus. On sait maintenant que Mac-then-Encrypt est problématique. Je suis même étonné que cette attaque ne sort que maintenant.

      • [^] # Re: Quelques ressources supplémentaires sur le sujet

        Posté par  (site web personnel) . Évalué à 2.

        Je suis même étonné que cette attaque ne sort que maintenant.

        Pareil.
        en fait, je me demande où est la "nouveauté" : par design (partie non authetifiée, dont l'intégrité sur qui cause n'est pas testée, donc il modifie tout ce qu'il veut), un MITM peut choisir le protocole à utiliser en refusant les protocoles "trop sécurisés" et c'est le client qui passe de lui-même en une version plus faible.

        Le problème vient donc "juste" que SSLv3 est plus ou moins (il faut du temps quand même) troué est qu'il peut toujours être utilisé (il est accepté autant côté client que serveur), et donc ce problème apparait automatiquement (par design) dès qu'on a su que SSLv3 avait un problème.

        La nouveauté est-elle que quelqu'un a regardait comment fonctionnait la phase de négociation du protocole et s'en rendu compte que n'importe quel MITM peut choisir le protocole utilisé? C'est gros (car c'est assez basique), sutout qu'on aura alors exactement le même problème quand on aura TLSv2.0 et que TLSv1.x sera troué : qu'est-ce qui est prévu pour ne pas avoir le même problème plus tard? On redécouvrira cette faille de la négociation à ce moment-la (est-ce que TLSv1.3 a un mécanisme pour détecter que c'était pas le protocole qui été préféré par le client)?

        Ou alors, j'ai loupé un passage du problème, je n'arrive pas à comprendre. Quelqu'un pour expliquer en quoi ça ne fait pas partie du design de l'initialisation HTTPS qu'un MITM puisse décider quel protocole utiliser (quel mécanisme est mis en oeuvre pour sécuriser la liste des protocoles supportés qui est envoyée au serveur, et qui est ici cassé)?

        • [^] # Re: Quelques ressources supplémentaires sur le sujet

          Posté par  (Mastodon) . Évalué à 4.

          Concernant la rétrogradation de protocole, il y a ça : https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ qui est utilisé par OpenSSL dans le jeu de mises à jour de sécurité livré mercredi (https://www.openssl.org/news/secadv_20141015.txt). Mais encore à l’état de brouillon.

          • [^] # Re: Quelques ressources supplémentaires sur le sujet

            Posté par  (site web personnel) . Évalué à 3.

            Si j'ai bien compris (mais je suis vraiment pas à l'aise, n'hésitez pas à me corriger), c'est un ajout au protocole, donc tous les clients et serveurs actuels ne pourront pas tester, et il faut que les deux supportent cette extension, si un seul ça ne marche pas, exact?
            On parle quand même d'IE6 dans l'histoire (le seul encore dans la nature qui ne supporte pas TLS), donc des produits qui n'ont plus aucun support et donc aucune mise à jour, pas sûr qu'IE7 (TLS1.0) sera mis à jour…

            • [^] # Re: Quelques ressources supplémentaires sur le sujet

              Posté par  (site web personnel) . Évalué à 1.

              Si j'ai bien compris, pour cette fois c'est effectivement mort. Donc le cas d'IE6 me semble tranché.

              Mais cette faille met en évidence le problème que pose le «fallback» SSL/TLS de manière générale, et donc oui il est important d'y trouver une solution.
              En effet TLS 1.0 est lui aussi sensible à certaines attaques (BEAST par exemple), à priori de moins grande envergure, et il est dommage qu'il «suffise» de forcer les clients compatibles TLS 1.2 à basculer sur ce protocole.

              alf.life

            • [^] # Re: Quelques ressources supplémentaires sur le sujet

              Posté par  (Mastodon) . Évalué à 3.

              Pour la faille actuelle, ça ne sert pas à grand chose sur les vieux systèmes puisqu’il faut en effet que client et serveur prennent en charge cette nouvelle extension (implémentée côté client comme un nouvel algorithme de chiffrement ajouté à la suite des autres). Par contre, elle devrait répondre à ta question concernant le futur passage à TLSv1.3 ou TLSv3, tant que la validation des messages ChangeCipherSpec et Finished n’est pas cassée (ils permettent de confirmer au pair que la poignée de main initiale et notamment la suite d’algorithmes de chiffrements supportés n’a pas été modifiée par un MITM).

              Pour IE6 et SSLv3, je crois qu’il n’y a plus rien à faire, SSLv3 était déjà connu pour ne pas être solide, là, c’est certainement le coup de grâce…

  • # Configurer Dovecot

    Posté par  . Évalué à 8.

    Dans conf.d/10-ssl-conf

    ssl_protocols = !SSLv2 !SSLv3

  • # Mozilla

    Posté par  . Évalué à 9.

    A noter, l'excellent article sur le Wiki de Mozilla pour bien configurer son serveur Web.
    https://wiki.mozilla.org/Security/Server_Side_TLS

    Et en bonus, une petite commande pour avoir la liste des protocoles SSL utilisés en utilisant nmap :

    $ nmap --script ssl-enum-ciphers -p 443 <IP>
    • [^] # et aussi

      Posté par  (site web personnel) . Évalué à 3.

      cet article :

      https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

      qui est régulièrement mis à jour (pour Apache, nginx…)

    • [^] # Re: Mozilla

      Posté par  (site web personnel) . Évalué à 7.

      Je suis l'auteur du wiki de Mozilla. Merci pour la référence :)
      A voir aussi, l'outil cipherscan écrit pour rapidement lister les paramètres d'une connexion TLS. Moins poussé que SSL Labs, mais en console et plus rapide.
      ```
      $ git clone https://github.com/jvehent/cipherscan.git && cd cipherscan && ./cipherscan google.com
      ……………….
      Target: google.com:443

      prio ciphersuite protocols pfs_keysize
      1 ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 ECDH,P-256,256bits
      2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits
      3 ECDHE-RSA-AES128-SHA TLSv1.1,TLSv1.2 ECDH,P-256,256bits
      4 ECDHE-RSA-RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
      5 AES128-GCM-SHA256 TLSv1.2
      6 AES128-SHA256 TLSv1.2
      7 AES128-SHA TLSv1.1,TLSv1.2
      8 RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
      9 RC4-MD5 SSLv3,TLSv1,TLSv1.1,TLSv1.2
      10 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits
      11 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits
      12 ECDHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
      13 AES256-GCM-SHA384 TLSv1.2
      14 AES256-SHA256 TLSv1.2
      15 AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
      16 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits
      17 ECDHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
      18 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2

      Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
      TLS ticket lifetime hint: 100800
      OCSP stapling: not supported
      Server side cipher ordering
      ```

      • [^] # Re: Mozilla

        Posté par  (site web personnel) . Évalué à 5.

        Cipherscan contient également un script d’analyse des configuration pour aider a atteindre les trois niveaux proposes sur le wiki:

        $ ./analyze.py -l intermediate -t google.com
        google.com:443 has bad ssl/tls
        and DOES NOT comply with the 'intermediate' level

        Things that are really FUBAR:
        * remove cipher ECDHE-RSA-RC4-SHA
        * remove cipher RC4-SHA
        * remove cipher RC4-MD5

        Changes needed to match the intermediate level:
        * remove cipher ECDHE-RSA-CHACHA20-POLY1305
        * remove cipher ECDHE-RSA-RC4-SHA
        * remove cipher RC4-SHA
        * remove cipher RC4-MD5
        * remove cipher ECDHE-RSA-DES-CBC3-SHA
        * disable SSLv3
        * consider using a SHA-256 certificate
        * consider enabling OCSP Stapling

        A noter que Google.com maintient la compatibilité avec les vieux clients, comme windows XP pre-SP3 et java6, ce qui explique la présence de SSLv3, RC4 et un certificat a signature SHA-1.

      • [^] # Re: Mozilla

        Posté par  . Évalué à 4.

        Merci à toi pour ce wiki, j'ai récemment mis en place mon premier serveur et j'étais justement en recherche de bonnes pratiques pour sécuriser nginx ! C'est génial de la part de Mozilla de partager ses recommandations (et de manière aussi détaillée), ça permet aux personnes qui n'ont pas l'expérience d'avoir un référentiel sur lequel s'appuyer : en effet quand on ne s'y connaît pas, il est pour le moins ardu de trouver une réponse qui fasse autorité parmi toutes les préconisations présentes sur le web…

        En parlant de bonnes pratiques : j'ai remarqué que dans l'exemple de configuration pour nginx donné sur le wiki, la directive ssl on; est utilisée. Or ayant justement récemment regardé la documentation officielle, il se trouve que celle-ci est considérée obsolète ; à la place il est recommandé d'utiliser le paramètre ssl de la directive listen. Je ne pense pas que cela change grand chose en termes de sécurité, mais ça fait toujours gagner une ligne…
        ;-)

  • # ProFTPd, NGinx

    Posté par  (site web personnel) . Évalué à 2.

    Configurer ProFTPd

    TLSProtocol TLSv1

    Configurer NGinX

    ssl_protocols -SSLv2 -SSLv3 TLSv1;

    • [^] # Re: ProFTPd, NGinx

      Posté par  (site web personnel) . Évalué à 2.

      Configurer OpenLDAP

      TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:!SSLv3

      • [^] # Re: Minepeon

        Posté par  . Évalué à 2. Dernière modification le 17 octobre 2014 à 14:05.

        Pour sécuriser le serveur de minepeon (arch):
        sudo nano /etc/httpd/conf/extra/httpd-ssl.conf

        Ajouter "SSLProtocol all -SSLv3" juste après "SSLEngine on" puis redémarrer.

      • [^] # Re: ProFTPd, NGinx

        Posté par  (site web personnel) . Évalué à 4.

        J'ai du mal à piger en quoi une attaque qui requiert que l'attaquant fasse des requetes actives ( ie, la partie ou le js intervient dans le papier ) va marcher pour openldap ?

        Quel client va poser souci, dans quels conditions ?

    • [^] # Re: ProFTPd, NGinx

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 17 octobre 2014 à 18:18.

      Configurer Nginx

      Attention, les versions récentes de Nginx semblent ne plus supporter la soustraction de protocole mais uniquement l'explicitation (voir http://nginx.org/en/docs/http/configuring_https_servers.html). La bonne ligne serait donc :

      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

      • [^] # Re: ProFTPd, NGinx

        Posté par  . Évalué à 3.

        C'est un peu bête, parce que le jour où TLS 1.3 est supporté par ta bibliothèque de crypto, tu n'en tires partie qu'à la condition de penser à modifier ton fichier de conf…

    • [^] # Re: ProFTPd, NGinx

      Posté par  . Évalué à 0.

      Configurer NGinX

      ssl_protocols -SSLv2 -SSLv3 TLSv1;

      Es-tu sûr que l'adjonction d'un - devant les protocoles à exclure soit la bonne manière de faire ?

      À la limite ajouter un ! devant comme pour ssl_ciphers, pourquoi pas, mais le plus simple ne serait-il pas de tout simplement mentionner uniquement les protocoles acceptés ? Et d'ailleurs, pourquoi exclure TLSv1.1 et TLSv1.2, qui sont les seuls à atténuer le risque d'attaque BEAST ?

      • [^] # Re: ProFTPd, NGinx

        Posté par  . Évalué à 0.

        J'ai pris trop de temps pour éditer mon commentaire, le vilain sorcier de la page d'erreur m'a repoussé…

        L'édit que je voulais faire :

        J'aurais dû lire tous les commentaires, ianux répond déjà à ce sujet (et en plus le point d'exclamation dans les paramètres de ssl_ciphers semble être lié au format compris par openSSL).

        C'est un peu bête, parce que le jour où TLS 1.3 est supporté par ta bibliothèque de crypto, tu n'en tires partie qu'à la condition de penser à modifier ton fichier de conf…

        À tester : ajouter TLSv1.3 à la directive pour anticiper… Mais pas sûr que nginx accepte de se lancer s'il détecte une anomalie dans sa config (ça m'est arrivé pour moins que ça). Pour tester : $ nginx -t.

        • [^] # Re: ProFTPd, NGinx

          Posté par  . Évalué à 2.

          Cela ne résous pas le problème, On ne peut prédire les numéro de version de TLS pour les 10 ans à venir.

          • [^] # Re: ProFTPd, NGinx

            Posté par  (site web personnel) . Évalué à 3.

            Mes fichiers de conf sont gérés par cfengine… Je fais un coup de sed lorsqu'il faut durcir la configuration de temps en temps et hop, c'est validé puis déployé (et versionné). Imaginer une conf qui puisse tenir 10 ans me semble une idée plus que fumeuse ;-)

    • [^] # Re: ProFTPd, NGinx

      Posté par  . Évalué à 1.

      Je ne comprends pas j'ai effectué les modifications dans Nginx.

      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

      root@www-prod:/usr/local/etc/nginx/conf.d # service nginx restart
      Performing sanity check on nginx configuration:
      nginx: [warn] invalid value "TLSv1.3" in /usr/local/etc/nginx/conf.d/ssl:4
      nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

      Dans le cas ou l'on met TLSv1.3 effectivement il rale au check.

      En testant après modification avec le script fournit par Red Hat …

      Depuis l'extérieur :

      ~$ ./test-poodle.sh www.pentakonix.fr 443
      VULNERABLE! SSLv3 detected.

      Hein ?!

  • # Script

    Posté par  . Évalué à 5.

    Le script proposé n'est pas très pratique pour tester STARTTLS, du coup, j'ai fais un petit script en Python qui test SMTP, IMAP, POP, HTTPS sur l'hôte donnés (et on peut même spécifier un réseau pour tester tous les hôtes). C'est loin d'être parfait mais ça permet de faire le tour rapidement. Si vous avez des idées de ports à ajouter, n'hésitez pas. https://github.com/claudex/test-ssl

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Routeur

    Posté par  . Évalué à 1. Dernière modification le 19 octobre 2014 à 15:44.

    Les routeurs de belgacom (bbox2 je crois) sont faillible (ça ne m'étonne même pas…):

    PORT STATE SERVICE
    443/tcp open https
    | ssl-enum-ciphers:
    | SSLv3:
    | ciphers:
    | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak
    | TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 - weak
    | TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 - weak
    | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak
    | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
    | TLS_RSA_WITH_AES_128_CBC_SHA - strong
    | TLS_RSA_WITH_AES_256_CBC_SHA - strong
    | TLS_RSA_WITH_DES_CBC_SHA - weak
    | TLS_RSA_WITH_IDEA_CBC_SHA - weak
    | TLS_RSA_WITH_RC4_128_MD5 - strong
    | TLS_RSA_WITH_RC4_128_SHA - strong
    | compressors:
    | NULL
    | TLSv1.0:
    | ciphers:
    | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak
    | TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 - weak
    | TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 - weak
    | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak
    | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
    | TLS_RSA_WITH_AES_128_CBC_SHA - strong
    | TLS_RSA_WITH_AES_256_CBC_SHA - strong
    | TLS_RSA_WITH_DES_CBC_SHA - weak
    | TLS_RSA_WITH_IDEA_CBC_SHA - weak
    | TLS_RSA_WITH_RC4_128_MD5 - strong
    | TLS_RSA_WITH_RC4_128_SHA - strong
    | compressors:
    | NULL
    |_ least strength: weak

    • [^] # Re: Routeur

      Posté par  . Évalué à 4.

      ça reste un service accessible uniquement en interne. Ça ne me semble pas si grave que ça.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Routeur

        Posté par  . Évalué à 2.

        Non tu peux tout a fait activer l'accès externe a l'interface d'administration (je pense que c'est pour cela que le NAT de belgacom bloque la redirection des ports 80 et 443).
        Mais si non pour les attaques MITM en interne bah c'est un moyen comme un autre de choper un accès admin au routeur. (bon reste a voir quel proportion d'utilisateur utilise https au lieu de http)

        • [^] # Re: Routeur

          Posté par  . Évalué à 4.

          Non tu peux tout a fait activer l'accès externe a l'interface d'administration (je pense que c'est pour cela que le NAT de belgacom bloque la redirection des ports 80 et 443).

          Je doute que ce soit très utilisé, et si tu en as absolument besoin, tu peux désactivé SSLv3 sur ton navigateur.

          Mais si non pour les attaques MITM en interne bah c'est un moyen comme un autre de choper un accès admin au routeur. (bon reste a voir quel proportion d'utilisateur utilise https au lieu de http)

          Vu que le certificat génère un gros warning sur les navigateurs, je doute que ceux qui y accède en https se rendent compte d'une attaque MitM si le certificat est différent. Du coup, ça me semble une attaque bien plus simple qu'utiliser Poodle.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # script de test

    Posté par  . Évalué à 0. Dernière modification le 20 octobre 2014 à 11:58.

    voici le script de Dan Varga modifié, pour être plus simple à l'utilisation et à la lecture

    Script call = bash poodle.sh {serverIP} {serverPort}

    #Sent variable (host & port)
    host=$1
    port=$2
    # #If empty IP then set 127.0.0.1 as default
    if [ -z $host ];then
    host="127.0.0.1"
    fi
    if [ -z $port ];then
    port=443
    fi
    #create the returned code
    out="`echo x | timeout 5 openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
    ret=$?
    #create a switch statement on $ret, exploit depend on result code
    case "$ret" in
    0)
        echo "VULNERABLE! SSLv3 detected.";
    ;;
    124)
        echo "error: timeout connecting to host $host:$port";
    ;;
    1)
        out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`;
        if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ];then
            echo "Not Vulnerable. We detected that this server does not support SSLv3";exit
        fi  
    ;;
    *)
        echo "warning: $ret isn't a valid code while connecting to host $host:$port";
    ;;
    esac
    
    
    # https://github.com/Fro99666/froggPoodler
  • # Pour désactiver SSL 3.0 dans votre firefox

    Posté par  . Évalué à 1.

    En attendant la version 34 (pour le 25 novembre), une extension permet de désactiver SSLv3 :
    https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.