Aujourd'hui a été publiée la faille de sécurité Drown, touchant notamment la bibliothèque cryptographique OpenSSL. C'est l'occasion de se livrer à quelques réflexions sur Drown, TLS et la sécurité. Le même jour, huit (!) failles de sécurité dans OpenSSL ont été publiées (Drown a été éclaté en deux failles, CVE-2016-0800 et CVE-2016-0703). Cela ne facilite pas le travail de ceux qui essaient de démêler tout cela mais Drown est très bien documenté sur son site officiel (très complet, avec logo et tout). Je recommande également le papier officiel, très clair. Il n'y a normalement donc pas besoin de ré-expliquer ce qu'est Drown. Pourtant, je suis étonné de constater que certaines choses n'ont pas été comprises. Par exemple bien des gens croient que, puisque leur serveur HTTPS n'accepte pas SSLv2, ils sont en sécurité. Rien n'est plus faux et c'est bien expliqué dans la FAQ de Drown : pour effectuer cette attaque, il suffit que le certificat du site visé (et donc la clé privée) soit disponible sur un autre site, qui, lui, accepte SSLv2. Et, c'est là un point qui m'a personnellement surpris, ce cas est assez fréquent. Comme le note l'article Drown, le modèle de financement des AC encourage à acheter le moins de certificats possibles, et donc à les utiliser sur plusieurs serveurs, ou bien sur le serveur de production et sur celui de développement. [...] Autre question posée par Drown, pourquoi est-ce qu'il y a autant de machines qui acceptent encore SSLv2 ? Il a été officiellement abandonné en 2011 par le RFC 6176. Et le RFC est sorti bien tard, tous les experts savaient depuis longtemps que SSLv2 était cassé sans espoir de réparation. Mais les mises à jour ne se font, sur l'Internet, qu'à un rythme glacial (voir nul). Le problème n'est pas technique, il vient du fait que les mises à jour ne rapportent rien, n'ont pas de retour sur investissement, et ne sont donc en général jamais faites. Tout le monde s'indigne lorsqu'une faille comme Drown est publiée mais, en temps normal, personne ne s'en préoccupe. La prévention est toujours le parent pauvre de la sécurité. L'opérationnel et la sécurité concrète n'intéressent personne
To every thing there is a season. And in the world of cryptography, today we have the first signs of the season of TLS vulnerabilities.
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
À contre-courant, le gouvernement des Pays Bas refuse l’adoption de mesures restrictives contre le cryptage et investit dans OpenSSL.
À l’heure des débats sur l’encadrement du chiffrement des deux côtés de l’Atlantique, le ministère néerlandais de la Sécurité et de la Justice explique refuser « l’adoption de mesures restrictives contre le développement, la disponibilité et l’utilisation du chiffrement aux Pays-Bas », dans un document officiel publié le 4 janvier. Dans ce texte, le gouvernement néerlandais se prononce pour un renforcement du chiffrement et précise ses arguments contre l’adoption de backoors « légales ». Selon lui, un contournement technique du chiffrement pour faciliter l’accès des autorités aux données « rendrait aussi les fichiers cryptés vulnérables aux [attaques] des criminels, des terroristes et des services étrangers de renseignement ». En outre, l’installation de portes dérobées menace la sécurité des informations communiquées et stockées, ainsi que « l’intégrité des systèmes d’information », indique le document.
Les Pays-Bas financent OpenSSL
Pour les Pays Bas, qui ont récemment approuvé 500 000 euros de financement au projet OpenSSL (la bibliothèque Open Source de chiffrement des connexions), le chiffrement sert « la protection et la vie privée des citoyens, ainsi que les entreprises, le gouvernement et l’économie néerlandaise dans son ensemble ». Cette position des Pays Bas tranche avec celle des États-Unis (où Apple fait de la résistance) et du Royaume Uni, dont les gouvernements prônent une coopération renforcée du secteur privé et des communautés techniques pour déchiffrer les données de leurs clients. Quant à la France, elle veut prendre des mesures complémentaires à celles déjà votées dans le cadre de la loi sur le renseignement pour généraliser les écoutes. Et ce après les attentats du 13 novembre dernier.
repos git : https://github.com/lgarron/badssl.com
openSSL tips
Sommaire
-SSL Labs, l'incontournable
- Création d'un .csr et d'un .key
- c'est pourquoi déjà ce certificat ?
et les deux fichiers, là, ils vont ensemble ?
- configuration SSL/TLS sous Apache2 :
- .chain ? késako
- s_client
- OpenSSL sur mon système :
pour aller plus loin (mais vraiment très, très loin)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/
https://wiki.mozilla.org/Security/Server_Side_TLS // Mozilla has a new tool for generating secure SSL configurations for your web server
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.
But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us. We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.
Hello. My name is Masashi Kikuchi. Here is my story how I find the CCS Injection Vulnerability. (CVE-2014-0224)
Le point sur les raisons qui ont poussé les développeurs OpenBSD à débuter le nettoyage complet du code d'OpenSSL sous le nom de LibreSSL
Throughout the recent months (and particularly: weeks), people have asked me how to properly secure their SSL/TLS communication, particularly on web servers.
At the same time I’ve started to look for good literature on SSL/TLS. I noticed that many of the “guides” on how to do a good SSL/TLS setup are actually cargo cult. Cargo cult is a really dangerous thing for two reasons: First of all, security is never a one-size-fits-all solution. Your setup needs to work in your environment, taking into account possible limitation imposed by hardware or software in your infrastructure. And secondly, some of those guides are outdated, e.g. they do neglect the clear need for Perfect Forward Secrecy, or use now-insecure ciphers. At the worst case, they are simply wrong.
So I won’t be providing yet another soon-outdated tutorial that leaves you non-the-wiser. Instead, I’ll share my collection of free and for-pay documents, books and resources on the topic which I found particularly useful in the hope that they may help you in gaining some insight.
Revocation checking is in the news again because of a large number of revocations resulting from precautionary rotations for servers affected by the OpenSSL heartbeat bug. However, revocation checking is a complex topic and there's a fair amount of misinformation around. In short, it doesn't work and you are no more secure by switching it on. But let's quickly catch up on the background.
Private keys are still not so likely to be exposed, but still much more likely than my original analysis suggested. [...]
In his Q&A http://www.youtube.com/watch?v=UFFTYRWB0Tk to his keynote address at the World Hosting Days Global 2014 conference in April, the world’s largest hosting and cloud event, Julian Assange discussed encryption technology in the context of hosting systems. He discussed the cypherpunk credo of how encryption can level the playing field between powerful governments and people, and about 20 minutes into his address, he discussed how UNIX-like systems like Debian (which he mentioned by name) are engineered by nation-states with backdoors which are easily introduced as ‘bugs’, and how the Linux system depends on thousands of packages and libraries that may be compromised.
I recommend watching his 36 minute Q&A in its entirety, keeping in mind my recent warnings about how Linux is almost entirely engineered by the government/military-affiliated Red Hat corporation.
The Voice of Russia website has an article http://voiceofrussia.com/news/2014_04_07/US-annexed-the-whole-world-through-mass-surveillance-Assange-6580/ on Assange’s address with a few quotes:
“To a degree this is a matter of national sovereignty. The news is all flush with talk about how Russia has annexed the Crimea, but the reality is, the Five Eyes intelligence alliance, principally the United States, have annexed the whole world as a result of annexing the computer systems and communications technology that is used to run the modern world,” stated Julian Assange in his keynote address…Don’t just read the short article, listen to the address yourself, because Assange goes into many areas, and the work being done in these fields.
Assange mentions how Debian famously botched the SSL random number generator for years (which was clearly sabotaged – a known fact). Speaking of botched security affecting Red Hat, Debian, Ubuntu, Gentoo, SuSE, and more, the nightmarish OpenSSL recently botched SSL again https://security-tracker.debian.org/tracker/CVE-2014-0160 . It’s very hard to believe this wasn’t deliberate, as botching the memory space of private keys is about as completely incompetent as you can get, as this area is ultra-critical to the whole system. As a result, many private keys were potentially compromised. Be sure to update your systems as this bug is now public knowledge. (For more on how OpenSSL is a nightmare, and why this bug is one among many that will never be found, listen to FreeBSD developer Poul-Heening Kamp’s excellent talk at the FOSDEM BSD conference. http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm)
From the start, my revelations on this blog about Red Hat’s deep control of Linux, along with their large corporate/government connections, hasn’t been just about spying, but about losing the distributed engineering quality of Linux, with Red Hat centralizing control. Yet as an ex-cypherpunk and crypto software developer, as soon as I started using Linux years ago, I noted that all the major distributions used watered-down encryption (to use stronger encryption in many areas, such as AES-loop, you needed to compile your own kernel and go to great lengths to manually bypass barriers they put in place to the use of genuinely strong encryption). This told me then that those who controlled distributions were deeply in the pockets of intelligence networks. So it comes as no surprise to me that they jumped on board systemd when told to, despite the mock choice publicized to users – there was never any option.
A computer, and especially hosting services (which often run Linux), are powerful communication and broadcasting systems into today’s world. If you control and have unfettered access to such systems, you basically control the world. As Assange notes in the talk, encryption is only as strong as its endpoints. eg if you’re running a very secure protocol on a system with a compromised OS, you’re owned.
As Assange observed:
“The sharing of information, the communication of free peoples, across history and across geography, is something that creates, maintains, and disciplines laws [governments].”L nom a de quoi faire paniquer. Heartbleed (pour «coeur qui saigne») est un bug détecté dans la nuit du lundi 7 au mardi 8 avril, qui permettrait d'accéder à une partie des informations stockées sur un grand nombre de serveurs des services sur Internet: sites, mais aussi messageries ou bien encore «dispositifs de mise à jour des smartphones», précise à Slate l'expert réseau Stéphane Bortzmeyer.
En clair donc, «vos identifiants et mots de passe peuvent être compromis, ainsi que vos échanges chiffrés», prévient PCINpact. D'autres médias avancent aussi que les numéros de cartes bancaires utilisées sur les sites d'e-commerce peuvent avoir été subtilisés.
Alors, est-ce le moment de paniquer et de cesser toute sorte d'activité sur Internet?
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
Tester ses serveurs:
http://s3.jspenguin.org/ssltest.py
http://possible.lv/tools/hb/?sp
Lire aussi:
https://www.pcinpact.com/news/86934-openssl-faille-heartbleed-menace-securite-web-sites-ferment.htm
https://www.peereboom.us/assl/assl/html/openssl.html
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Surveiller ses connexions:
tshark -i eth0 -R "ssl.record.content_type eq 24 and not ssl.heartbeat_message.type"