Recently, SuperFish and PrivDog have received some attention because of the risks that they both introduced to customers because of implementation flaws. Looking closer into these types of applications with my trusty CERT Tapioca VM at hand, I've come to realize a few things.
In this blog post, I will explain
The capabilities of SSL and TLS are not well understood by many.
SSL inspection is much more widespread than I suspected.
Many applications that perform SSL inspection have flaws that put users at increased risk.
Even if SSL inspection were performed at least as well as the browsers do, the risk introduced to users is not zero.
OpenSSL last vulnerabilities
The most anticipated OpenSSL announcement finally reveal no less than 14 vulnerabilities, with 2 of them classified as high severity. But even if this is not an Heartbleed 2, you would be foolish to not patch you servers.
First, FREAK (CVE-2015-0204) has been reclassified to high because EXPORT_RSA seems to be much more common that previously thought, leading the OpenSSL developpers to escalate it from low to high.
The second high vulnerability (CVE-2015-0291, "ClientHello") only concern the last OpenSSL version (1.0.2), and can lead to a DoS against your server. You can read the full report on the OpenSSL website.
https://www.openssl.org/news/secadv_20150319.txt
https://ma.ttias.be/openssl-cve-2015-0291-cve-2015-0286/
Implementations of the Transport Layer Security (TLS) protocol must handle a variety of protocol versions and extensions, authentication modes and key exchange methods, where each combination may prescribe a different message sequence between the client and the server. We address the problem of designing a robust composite state machine that can correctly multiplex between these different protocol modes.
We systematically test popular open-source TLS implementations for state machine bugs and discover several new critical security vulnerabilities that have lain hidden in these libraries for years. We call these collection of vulnerabilities SMACK: State Machine Attacks on TLS.
This page presents exploits and disclosure information related to these attacks. For a technical overview of the TLS state machine and our protocol fuzzing methodology, please refer to our research paper (to appear at IEEE Security & Privacy 2015).
Threat Model
All the attacks on this page assume a network adversary (i.e. a man-in-the-middle) to tamper with TLS handshake messages. The typical scenario to mount such attacks is by tampering with the Domain Name System (DNS), for example via DNS rebinding or domain name seizure.
RC4 is the most popular stream cipher in the world, and in particular is used to protect a significant portion of SSL/TLS sessions. In this session, we will show how an old vulnerability of RC4 can be used to mount a partial plaintext recovery attack on SSL-protected data, when RC4 is the chosen cipher. As opposed to BEAST, POODLE, CRIME, and other attacks on SSL that were published in the recent years, including the attack by Bernstein et-al on the usage of RC4, the new attack is not limited to recovery of temporal session tokens, but can be used to steal parts of permanent secret data such as account credentials when delivered as POST parameters. Furthermore, one of the variants of the new attack requires only passive eavesdropping to SSL connections, and presents the first practical attack on SSL that does not require active Man-in-the-Middle. Another unique characteristic of the new attack allows one of its variants to recover with non-negligible probability, parts of a secret that was transmitted only once over the TLS connection.
Voici la suite des « études » des leaks (fuites) de Snowden menées pour NSA-Observer. Dans cet article, nous allons revenir sur les révélations du Spiegel datant de fin décembre lors du 31c3 (Chaos Computer Congress) et du 17 janvier 2015 portant sur les moyens offensifs de la NSA ainsi que d'autres agences concernant la cryptographie.
http://cdn.media.ccc.de/congress/2014/webm-sd/31c3-6258-en-Reconstructing_narratives_webm-sd.webm
BULLRUN est un « programme » de la NSA exploitant différents moyens pour accéder à du contenu chiffré. Le New York Times avait abordé le sujet fin 2013 dans son article « Secret Documents Reveal N.S.A. Campaign Against Encryption » mais sans aucun détail (comme The Guardian ou encore propublica).
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.
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
Nous ne pouvons pas faire confiance aux gouvernements et encore moins aux entreprises pour assurer notre sécurité et notre vie privée. Nous pouvons, par contre, nous appuyer sur la société civile (comme l'EFF (eff.org) ou La Quadrature du Net, les lanceurs d'alerte (comme Chelsea Manning ou Edward Snowden) et sur des outils qui ne nous trahiront pas, comme les logiciels libres. La cryptographie fonctionne ! Et c'est une des nouvelles importantes de ces révélations. Il existe des tutoriaux partout sur le net pour se mettre à chiffrer ses communications. Je vous laisse aller voir OTR pour Jabber (messagerie instantanée), SSL/TLS pour à peu près tout (mails, chat,...), GPG (qui demande un niveau technique un peu supérieur), Tor, et surtout, surtout, je vous invite à venir à des cryptoparty / café vie privée pour apprendre à s'en servir :)
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.
You might have heard about the critical GnuTLS bug that was recently fixed recently. What's the deal with it? Why is it a big deal? What happened?
Recently, I was working on a security implementation for a system that didn't support TLS 1.1+. Of course, we know that being behind the times is always a Bad Thing in security circles; TLS 1.2 was officially published nearly six years ago, and the TLS working group has already begun formulating 1.3. Yet TLS 1.0 persists and is pretty much the default in most cases. Qualys labs reports that as of January, 2014, only 23% of websites support TLS 1.1. (25% support TLS 1.2; it's unclear how much overlap there is between the two, but since all known TLS 1.2 implementations also support TLS 1.1, I think it's safe to assume that the majority of these are the same sites). So, what's the danger?
How's My SSL? is a cute little website that tells you how secure your TLS client is. TLS clients just like the browser you're reading this with.
How's My SSL? was originally made to help a web server developer learn what real world TLS clients were capable of. It's been expanded to give developers and the very technically-savvy a quick and easy way to learn more about the TLS tools they use.
It's also meant to impell developers to modernize and improve their TLS stacks. Many security problems come from engineers simply not knowing what worries to have. How's My SSL? is a demonstration of what those TLS client worries should be.
This is a collection of information related to the security of Secure Socket Layer (SSL) and Transport Layer Security (TLS).
The aim of this page is to keep track of the current limitations and security problems in SSL/TLS and HTTPS.
The biggest unsolved problem is the trust model of the Certification Authorities.
The Secure Sockets Layer (SSL) is one of the world’s most important forms of commercial encryption. It is the public key system generally employed by e-commerce websites like Amazon, in order to prevent payment details from being intercepted by third parties. At this week’s Black Hat security conference in Washington, details were released on an exploit that takes advantage of the weak way in which SSL is implemented in secure (HTTPS) websites.
The tool – called ‘SSL strip’ – is based around a man-in-the-middle attack, where the system for redirecting people from the insecure to the secure version of a web page is abused. By acting as a man-in-the-middle, the attacker can compromise any information sent between the user and the supposedly secure webpage. The author of the exploit claims to have used it to steal data from PayPal, GMail, Tickermaster, and Facebook – including sixteen credit card numbers and control of more than 100 email accounts.
What is the DANE protocol and how does it make TLS/SSL certificates more secure?
DetecTor is an open source project to implement client side SSL/TLS MITM detection, compromised CA detection and server impersonation detection, by making use of the Tor network.
La vidéo de la conférence de vincib: SSL/TLS
Lien youtube http://www.youtube.com/watch?v=a9IuSBjyzoI
In my earlier blog post, I gave an overview of Forward Secrecy, as well as some configuration tips. If you're new to the concept, I suggest that you go and read that post first. This time, I am following up with detailed configuration examples for Apache, Nginx, and OpenSSL.
With revelations about mass surveillance in the news everywhere, an obscure feature of SSL/TLS called Forward Secrecy has suddenly become very interesting. So what is it, and why is it so interesting now?
==================
https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante