Du coup, par mesure de sécurité, il ne faut plus utiliser https ?!?

Ca me rappelle un débat avec un collègue sur le déploiement de ssh sur des Cisco distants sur Internet. Pour lui c'était indispensable. Pour moi non vu que j'avais mis une politique Tacacs très restrictive empechant toute re-utilisation d'un login/mdp compromis. Quelques jours passent et Cisco sort une faille affectant le service ssh de ses équipements. Le genre de grosse faille où la désactivation du service était la seule solution possible. En fait, si on avait déployé, on aurait été compromis rapidement...

Aaah les joies de la sécurité informatique...

à ok. Vivien à corriger la faille sur son serveur ?

ok merci

Je réalise que ce souci concerne aussi Tor.

(C'est moi qui met en exergue certaines parties.)

OpenSSL bug CVE-2014-0160

Posted April 7th, 2014 by arma in openssl security advisory

A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server.

If you're using an older OpenSSL version, you're safe.

Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.

Here are our first thoughts on what Tor components are affected:

Clients: The browser part of Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But the Tor client part is: Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor.

Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. (You will need to update your MyFamily torrc lines if you run multiple relays.)

Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, this shouldn't allow an attacker to identify the location of the hidden service, but an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.

Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.
Tails is still tracking Debian oldstable, so it should not be affected by this bug.

Orbot looks vulnerable; they have some new packages available for testing.

The webservers in the https://www.torproject.org/ rotation needed (and got) upgrades. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.

https://blog.torproject.org/blog/openssl-bug-cve-2014-0160

Conclusion : Tor est vraiment très sérieusement concerné.

Qu'en pensez-vous? Est-ce que la NSA pouvait l'ignorer? Est-ce que la NSA pouvait cacher cela? Est-ce qu'elle l'a caché à ses alliés et ses agents?

Est-ce qu'en fin de compte la NSA ne serait pas aussi nulle que les dév d'OpenSSL?

Aie!

Donc potentiellement les données du serveur peuvent avoir été récupérées...

Y compris :
- les cookies d'identification
- les login/mdp
- la clé TLS du serveur
...

Le test indiquait que le site n'étais pas vulnérable, je ne sais pas si c'était une erreur du test, car j'étais bien sur une version impactée.

J'ai vu deux tests différents dire que le site n'était pas vulnérable.

Il me semble que la faille dépend d'une extension d'OpenSSL, Hearbeat, qui n'est pas activée chez tout le monde ?

Quelle était la version avant la mise à jour ? Elle venait de quel dépôt ?