CacheBleed is a side-channel attack that exploits information leaks through cache-bank conflicts in Intel processors. By detecting cache-bank conflicts via minute timing variations, we are able to recover information about victim processes running on the same machine. Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys from OpenSSL 1.0.2f running on Intel Sandy Bridge processors after observing only 16,000 secret-key operations (decryption, signatures). This is despite the fact that OpenSSL's RSA implementation was carefully designed to be constant time in order to protect against cache-based (and other) side-channel attacks. While the possibility of an attack based on cache-bank conflicts has long been speculated, this is the first practical demonstration of such an attack. Intel's technical documentation describes cache-bank conflicts as early as 2004. However, these were not widely thought to be exploitable, and as a consequence common cryptographic software developers have not implemented countermeasures to this attack. https://ssrg.nicta.com.au/projects/TS/cachebleed/cachebleed.pdf

And many more in fact.

Test TLS de vos navigateurs (en fonction du user-agent)

Firefox about:config
security.ssl3.dhe_rsa_aes_128_sha = false
security.ssl3.dhe_rsa_aes_256_sha = false

Suite aux révélations du héros Edward Snowden, bien des gens ont pris conscience de ce que tous les experts en sécurité annonçaient depuis longtemps : les services d'espionnage espionnent et ne respectent aucune limite. Notamment, tout le trafic envoyé sur l'Internet peut être écouté, si on ne prend pas de précautions particulières. La solution technique la plus souvent citée est l'usage systématique de la cryptographie. Ce choix est tout à fait justifié. Mais il ne faut pas s'imaginer qu'il va être gratuit : tout chiffrer va faire perdre certaines possibilités, notamment en matière de déboguage.

A French government agency has been caught signing SSL certificates and impersonating Google.

How strong is your HTTPS connection? SSleuth ranks an established SSL/TLS connection and gives a brief summary of the cipher suite, certificate and other SSL/TLS parameters.

Today we are publishing details of a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. I discovered this issue in collaboration with Thai Duong and Krzysztof Kotowicz (also Googlers).

http://seenthis.net/messages/302666

Côté serveurs, les actions concrètes :

Apache avec GnuTLS : GnuTLSPriorities SECURE:-VERS-SSL3.0

Apache avec OpenSSL : SSLProtocol -SSLv3 -SSLv2

Nginx avec OpenSSL : ssl_protocols TLSv1.2 TLSv1.1 TLSv1

Postfix avec OpenSSL : smtpd_tls_protocols = !SSLv2,!SSLv3

Serveurs IMAP Dovecot : ssl_protocols = !SSLv2 !SSLv3

Serveurs IMAP Courier : TLS_PROTOCOL="TLS1_2:TLS1_1:TLS1"

Côté Clients:

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0

http://blog.erratasec.com/2014/10/some-poodle-notes.html
https://www.imperialviolet.org/2014/10/14/poodle.html
https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html

The first release of LibreSSL portable has been released. LibreSSL can be found in the LibreSSL directory of your favorite OpenBSD mirror.

http://ftp.openbsd.org/pub/OpenBSD/LibreSSL has it, and other mirrors will soon.

libressl-2.0.0.tar.gz has been tested to build on various versions of Linux, Solaris, Mac OSX, and FreeBSD.

This is intended as an initial release to allow the community to start using and providing feedback. We will be adding support for other platforms as time and resources permit.

As always, donations (http://www.openbsdfoundation.org/donations.html) are appreciated to assist in our efforts.

As a web developer, I knew that using HTTPS to protect users’ sensitive data was A Very Good Idea, but I didn’t have much understanding about how it actually worked.

It seems that evaluating different SSL/TLS configurations has become a hobby of mine. After publishing Server Side TLS back in October, my participation in discussions around ciphers preferences, key sizes, elliptic curves security etc...has significantly increased (ironically so, since the initial, naive, goal of "Server Side TLS" was to reduce the amount of discussion on this very topic).

More guides are being written on configuring SSL/TLS server side. One that is quickly gaining traction is Better Crypto, which we discussed quite a bit on the dev-tech-crypto mailing list.

People are often passionate about these discussions (and I am no exception). But one item that keeps coming back, is the will to kill deprecated ciphers as fast as possible, even if that means breaking connectivity for some users. I am absolutely against that, and still believe that it is best to keep backward compatibility to all users, even at the cost of maintaining RC4 or 3DES or 1024 DHE keys in our TLS servers.

One question that came up recently, on dev-tech-crypto, is "can we remove RC4 from Firefox entirely ?". One would think that, since Firefox supports all of these other ciphers (AES, AES-GCM, 3DES, Camellia, ...), surely we can remove RC4 without impacting users. But without numbers, it is not an easy decision to make.

Challenge accepted: I took my cipherscan arsenal for a spin, and decided to scan the Internet.