le problème, c’est que les certificats sont gérés n’importe comment.
Today, we're releasing a new version of SSL Rating Guide as well as a new version of SSL Test to go with it. Because the SSL/TLS and PKI ecosystem continues to move at a fast pace, we have to periodically evaluate our rating criteria to keep up.
https://www.ssllabs.com/projects/rating-guide/
https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009e.pdf
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.
A few weeks ago I wrote a long post about the NSA's 'BULLRUN' project to subvert modern encryption standards. I had intended to come back to this at some point, since I didn't have time to discuss the issues in detail. But then things got in the way. A lot of things, actually. Some of which I hope to write about in the near future.
But before I get there, and at the risk of boring you all to tears, I wanted to come back to this subject at least one more time, if only to pontificate a bit about a question that's been bugging me.
The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov
Une excellente étude sur les vulnérabilités des applications utilisant #TLS (autrefois nommé #SSL), à l’exclusion des navigateurs Web. Des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait de détourner le trafic vers un autre serveur que celui visé. Mais, contrairement aux navigateurs Web, ces applications, souvent critiques (paiement entre cyber-marchands, par exemple) n’ont guère été étudiées et ont des vulnérabilités souvent énormes, permettant à un attaquant de se faire passer pour le serveur légitime, malgré TLS.
Pour ne donner qu’un exemple (mais un des plus beaux), la bibliothèque #cURL, très utilisée par d’innombrables applications, a un paramètre CURLOPT_SSL_VERIFYHOST. La documentation dit bien qu’il doit être mis à 2 (sa valeur par défaut) pour que le nom soit vérifié et à 1 pour couper la vérification. Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation...
Les auteurs de l’article, après avoir cassé la sécurité de TLS dans des dizaines d’applications, suggèrent des API mieux documentées, plus claires et de plus haut niveau, pour diminuer le risque que les programmeurs se trompent.
http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
Hi,
a very dirty fact happened yesterday that still didn't have the
appropriate attention.
The French Government ANSSI made a MITM against Google SSL/TLS:
http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html
Google does not mention who's ANSSI.
ANSSI is the French CyberSecurity agency, closely working with defense
and intelligence agencies:
http://www.ssi.gouv.fr/
ANSSI declare that they are generating fake-certificate for the purpose
to inspect SSL traffic:
"ANSSI has found that the intermediate CA certificate was used in a
commercial device, on a private network, to inspect encrypted traffic
with the knowledge of the users on that network. "
Google Detected the MITM and Blocked it:
https://code.google.com/p/chromium/issues/detail?id=326787
ANSSI issued a statement that it was a "Human Error" from someone from
the Finance Ministry:
http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html
So, the summary of the story can be read as follow:
"A French Governmental Agency working on cybersecure with defense and
intelligence agencies admitted that they are doing SSL MITM and that,
due to a human error, they have been caught"
On parle beaucoup d'auto-hébergement par ici et un sujet n'a pas été abordé suffisament à mon sens : la sécurisation des accès à ses services auto-hébergés via HTTPS.
A quoi bon reprendre ses billes (carnet d'adresse, agenda, emails, fichiers, etc.) aux géants du cloud NSA-compatibles, si c'est pour tout faire transiter en clair (mots de passe, contenus) ?
Avoir un serveur SMTP qui envoie des mails est bien, le sécuriser c’est mieux.
La législation française impose d’enregistrer les méta-données de connexion aux serveurs, que ce soit vers l’Internet ou en interne. L’authentification est alors une étape primordiale dans la configuration de notre serveur d’envoi SMTP.
Afin de sécuriser nos échanges, nous ajouterons une couche de chiffrement SSL à Postfix, évitant à des attaquants d’intercepter des mails en clair sur le réseau.
Monitoring SSL/TLS-encrypted traffic is a classic problem for intrusion detection systems. Currently, hypervisor- or network- based IDSes that wish to analyze encrypted traffic must perform a man-in-the-middle attack on the connection, presenting a false server certificate to the client. Not only does this require the client to cooperate by trusting certificates signed by the intrusion detection system, it also takes control of the certificate verification process out of the hands of the client---a dangerous step, given that many existing SSL/TLS interception proxies have a history of certificate trust vulnerabilities.
Instead of a man-in-the-middle attack, we can instead attempt to locate the code that generates SSL/TLS master secret; this secret is sufficient to decrypt any encrypted traffic in a given session, giving us a "man-on-the-inside". Once we have identified the location of the code that generates this secret, we can hook it using any number of standard techniques in order to dump out the master secret. This secret can then be provided to an IDS to decrypt the content of the SSL stream; it may also be provided to a tool like Wireshark to decrypt packet captures after the fact (even if perfect forward secrecy is used).
In this tutorial, we will show how to use a PANDA plugin called keyfind, which examines memory accesses made during a recorded session and looks for code that processes SSL/TLS master secrets.
Trois semaines durant, la presse qui raffole d’histoires d’espionnage n’a eu d’attention que pour les écoutes de la NSA et les efforts de piratage de la No Such Agency visant les liaisons SSL (ou plus exactement les « regrettables erreurs commises dans certaines implémentations de SSL ») et les conversations réalisées à l’aide de téléphones portables (voix, SMS, emails, photos etc.). Pourtant, en ce lendemain du 11 septembre, cette même presse est frappée d’amnésie… en raison de la sortie d’un nouveau téléphone un peu plus intelligent, un peu plus collecteur d’informations, un peu plus lié aux réseaux sociaux et à leurs atteintes à la vie privée, un peu plus avide de synchronisations hasardeuses avec un ordinateur de bureau : les iphone 5C et 5S sont sur le marché. Oubliés, les risques d’écoute, de pillage de données et le spectre des collectes de métadonnées : la techno-mode l’emporte, et strictement aucun journaliste ne se hasarde à revenir sur la sympathie d’Apple vis-à-vis des fonctionnaires de l’Administration Fédérale US en général et ceux de la NSA en particulier. Qui aurait cru, il n’y a pas 24 heures, que le marketing résoudrait d’un coup les complexes problèmes de compromission des algorithmes de chiffrement. Il s’est rédigé en une nuit plus de papiers sur les icones et le look du dernier iphone que d’articles sur les implications politiques des révélations Snowden tout au long des 5 derniers jours. A tel point que la page de garde de nos confrères de Network World fait cohabiter deux articles étonnamment opposés, l’un intitulé « les récentes activités de la NSA soulèvent de sérieuses questions à propos des rapprochements réalisés avec les industries technologiques » et un autre qui titre « IOS 7 : beaucoup de choses que les professionnels de la sécurité vont apprécier ». Cynisme ou Alzheimer galopant ? Et nos confrères d’IDG ne sont certainement pas les seuls à se pâmer devant un simple GSM.
SSL/TLS Deployment Best Practices
SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works . . . except that it does not, really. The first part is true—SSL is easy to deploy—but it turns out that it is not easy to deploy correctly. To ensure that SSL provides the necessary security, users must put more effort into properly configuring their servers.
In 2009, we began our work on SSL Labs because we wanted to understand how SSL was used and to remedy the lack of easy-to-use SSL tools and documentation. We have achieved some of our goals through our global surveys of SSL usage, as well as the online assessment tool, but the lack of documentation is still evident. This document is a first step toward addressing that problem.
Our aim here is to provide clear and concise instructions to help overworked administrators and programmers spend the minimum time possible to obtain a secure site or web application. In pursue of clarity, we sacrifice completeness, foregoing certain advanced topics. The focus is on advice that is practical and easy to understand. For those interested in advanced topics, we provide references at the end of the guide.
Download the guide:
SSL/TLS Deployment Best Practices (PDF)
Version 1.3 / 17 September 2013
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf
pdf by ssllabs.com
Même si vous n'êtes pas programmeur, vous êtes tous au courant des attaques XSS, CSRF, des injections SQL, etc. Mais, une fois le site Web en place et bien programmé pour éviter ces attaques, il en reste d'autres que vous n'avez peut-être pas évaluées.
Selon les documents confiés par Edward Snowden, la NSA serait capable de déchiffrer le HTTPS et le SSL, grâce à un programme baptisé BullRun, mis au point avec son allié britannique. Des révélations à prendre avec des pincettes.
La propriété de forward secrecy1 permet à une information chiffrée aujourd’hui de rester confidentielle en cas de compromission future de la clef privée d’un correspondant. C’est un mécanisme assez coûteux en calculs et de nombreux serveurs font donc l’impasse sur celui-ci. Google a récemment annoncé le support du forward secrecy pour tous ses sites accessibles en HTTPS. Adam Langley a rédigé un article plus détaillé sur ce qui a été réalisé pour améliorer l’efficacité d’un tel mécanisme : avec quelques collègues, il a écrit une implémentation plus efficace pour OpenSSL, basée sur la cryptographie sur les courbes elliptiques.
En septembre 2013, un cycle de conférences débute à La Cantine avec comme idée principale d'expliquer et d'aider à comprendre comment fonctionne Internet. Chaque conférence développe un thème précis, regroupant aussi bien le fonctionnement général, des détails techniques, des notions théoriques ou des exemples de configurations. Les conférences sont diffusées en direct via le site ubicast.eu (quand elles ont lieu à la cantine), l'ensemble (vidéos, slides, bonus…) est sous licence Creative Commons BY:SA-fr. En espérant qu'elles puissent servir à beaucoup, que ce soit pour comprendre ou construire un morceau d'Internet.
Defending yourself against the NSA, or any other government intelligence agency, is not simple, and it's not something that can be solved just by downloading an app. But thanks to the dedicated work of civilian cryptographers and the free and open source software community, it's still possible to have privacy on the Internet, and the software to do it is freely available to everyone. This is especially important for journalists communicating with sources online.
Recently the IETF working group on HTTP met in Berlin, Germany and discussed the concept of mandatory to offer TLS for HTTP/2, offered by Mark Nottingham. The current approach to transport security means only 1/5 of web transactions are given the protections of TLS. Currently all of the choices are made by the content owner via the scheme of the url in the markup.
duraconf - A collection of hardened configuration files for SSL/TLS services
Hopefully this will help you make a more informed choice about what cipher list
should be used for different applications. What you find here are recommended
configurations, you should seriously consider using these, but you have to make
some choices. When you pick a cipher list, you have a couple different options
of how you go about it:
-
make a very specific declaration of what is acceptable. This has the
advantage of being able to define very closely of what you want, but the
disadvantage of having to stay on top of the latest crypto advancements, with
every crypto library upgrade. -
make a general declaration of which cipher list to use. this has the
advantage of allowing you to rely on your crypto libraries to make
(hopefully) informed choices for you (and to deactivate known
bad/weak/recently broken) ciphers while you don't have the burden of ensuring
that they are always resulting in a good cipher suite. The disadvantage is
that you cannot fine tune what exactly you get in return. -
A mixture of being specific and letting your crypto library decide from
general statements. This can be useful if, for example, you find out that
some particular crypto has become too weak, for example you might use a
generic list but then exclude MD5, because your crypto libraries haven't
removed that yet. -
Decide on a threat model for possible attacks that may expose an important
private key. Ciphers are often offered in a mode that provides Perfect
Forward Secrecy. While there are performance considerations, if you run a
high security operation where traffic disclosure would be a serious problem,
it is an important property to consider.
Generally it seems safer to have the crypto library take the bulk of the
decision since it should be for the most part fire-and-forget, while the other
options require that you always stay up to date on things and tweak as needed.
For practical use, and for people who can afford to follow crypto news, a
mixture of both is surely a good idea. So start with the general cipher list and
when you become aware that something is bad then just add this specific part to
your otherwise general cipher list until the crypto library defaults get updated
to fix that.
Unfortunately, its not possible to come up with one cipher configuration that is
going to work for all configurations. There are many different programs that
implement different versions of libraries that have different ciphers
available. In fact, a different versions of the same program may be linked
against different libraries which have different ciphers available.
An important configuration issue for service operators and users is
understanding Perfect Forward Secrecy. Generally, PFS sessions are
computationally more expensive than connections without PFS properties.
It is extremely important to remember that using SSL and/or TLS does not ensure
that your traffic is encrypted for all time. Generally, SSL/TLS services offer
two general modes of operation - one mode is ephemerally keyed and the other is not.
A TLS server that only offers AES256-SHA is strong against an attacker who will
never recovery the secret key used by the server and who cannot break AES256.
However, if an attacker is able to recover the server's key, the attacker will be able
to retroactively decrypt all traffic that has been recorded when the AES256-SHA
cipher is in use. If that same server uses an ephemeral cipher such as
DHE-RSA-AES256-SHA, the attacker cannot recover previous encrypted sesssions
without breaking RSA and/or AES256 for each session.
In both cases, when the attacker has the private key, all future communications
with the server are unsafe. Clients generally deal with this by looking up a
revokation list or by using something like the OCSP. Realistically, they're in
a lot of trouble and that kind of trouble is out of scope. If you're in doubt
it's probably a reasonable thing to use DHE or EDH modes unless you have load
issues.
The cipher lists you will find here actually vary depending on which version of
the crypto library that you have. For example, if you were to find this list
recommended:
HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH
In one version of openssl this will mean the following list of ciphers:
$ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH'
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
In a newer openssl, this list of ciphers will be different:
$ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH'
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
It is also worth noting that this is setting a policy, and your site may have
different policies, depending on your intended audience. There are many
questions to consider in determining a policy. For example, in the worst case,
when a client doesn't support the higher strength ciphers my server supports, do
I want to keep up the image that medium strength ciphers are secure enough in my
specific use case, environment and opponents? Or should I not allow anything but
the highest strength ciphers, and those clients that do not support them are
just denied? Its likely that in many cases there is no possibility of making it
clear to the user that their setup does not allow for secure use of your
services, and what their options are. I think, at least with apache, it
should be possible to redirect users whose setup doesn't provide a compatible
cipher suite, to an informational web page which explains further steps they can
and should take (i have no idea how)..
Unfortunately, in most cases, users will not get any message at all and they
will have no clue why they are shut out. This could result in unhappy users with
no idea of where to turn, and potentially a higher support burden.
Notes on format of cipher designations
Format of cipher designations differ, but in general they follow the format
described in ciphers(5). A few notes:
The order specified is the preference order, and the list is separated by
colons. The list can be specific ciphers (eg. RC4-SHA), a list of suites
containing a certain algorith (SHA1), or a cipher suite of a certain type
(TLSv1). There are also cipher strings which are a grouping of different ciphers
into a specific category (eg. HIGH).
When removing ciphers that you do not want, you have a choice between indicating
! or -, the difference is subtle but important. It's good practice to use ! if
you really do not want this class to ever get used, and to use - when you want
to allow them to be still used if you later added something to your existing
cipher list.
Finally, there is also the @STRENGTH parameter, which sorts the cipher list in
order of encryption algorithm key length.