Wiki Memo Sllabs
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
DROWN is a serious vulnerability that affects HTTPS and other services that rely on SSL and TLS, some of the essential cryptographic protocols for Internet security. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication. DROWN allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data. Our measurements indicate 33% of all HTTPS servers are vulnerable to the attack. https://www.drownattack.com/drown-attack-paper.pdf
And many more in fact.
The keys and certificates that will underlie Let’s Encrypt have been generated. This was done during a key ceremony at a secure facility today
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.
J'ai publié il y a quelques mois un tuto pour mettre en place "facilement" un serveur XMPP/Jabber avec Prosody et du SSL/TLS plutôt bien configuré sous Debian, j'ai eu pas mal de retours positifs depuis et je pense qu'il pourrait intéresser d'autres personnes.
A French government agency has been caught signing SSL certificates and impersonating Google.
Une nouvelle autorité de certification par Mozilla, Cisco, Akamai, EFF et IdenTrust : "It’s free, automated, and open."
Prévu pour l'été 2015.
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.
SSL : yes we Scan !
SSL : yes we Scan !
Publié le 20 Octobre 2014 par Philippe Macia dans bonnes pratiques
4 bonnes raisons d’inspecter les flux SSL
SSL : yes we Scan ! 4 bonnes raisons d’inspecter les flux SSL
Malgré la faille Heartbleed le cadenas du SSL reste une marque de confiance forte pour les utilisateurs. Le déchiffrement des flux SSL s’impose donc de plus en plus dans les entreprises. Voici quatre bonnes raisons d’inspecter les flux SSL et deux points de vigilance à ne pas sous-estimer.
L’usage du SSL s’est largement répandu ces dernières années dans l’Internet grand public. Utilisé pour garantir la confidentialité des échanges entre l’utilisateur et le site internet, le SSL est aujourd’hui utilisé par la plupart des messageries en ligne, sites de partage de photos et réseaux sociaux. Aujourd’hui, le volume du trafic Internet chiffré est en augmentation constante et représente entre 15% et 25% du trafic global sur Internet selon Gartner.
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 getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD.
The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely.
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.
I've been spending the past 3 months doing a full review of the TLS landscape. I plan on publishing it very soon (just need to polish the doc), and in the meantime, here are a few pointers for configuring state-of-the-art TLS on Nginx.
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.