TLS, état des lieux côté serveur

Magazine
Marque
MISC
Numéro
72
|
Mois de parution
mars 2014
|
Domaines


Résumé
Configurer TLS côté serveur est difficile. 19% des sites en HTTPS proposent toujours SSLv2. 28% vont négocier une session avec DES_CBC_SHA et ses clés de 56 bits si le client le demande. Il y a un peu plus d'un an, la majorité des experts en SSL/TLS recommandaient RC4 à AES. Quelques mois plus tard, c'était l'inverse. Une partie de la communauté cryptographique supporte Perfect Forward Secrecy, alors qu'une autre le refuse pour cause de lenteur. Il existe même des doutes sur le niveau réel de sécurité fourni par AES-256, par rapport à la version 128 bits. Ajoutons à cela une bonne dose de perte de confiance dans les standards existants, en particulier depuis que l'on sait Dual_EC_DRBG backdoored, et nous voici avec une parfaite recette de confusion et d'incohérence. Les désaccords sur la meilleure façon de configurer HTTPS sont nombreux. Et si le débat est utile aux experts, il est presque impossible pour un non-initié de naviguer dans la nébuleuse TLS, et d'en extraire une configuration de référence.

La suite est réservée aux abonnés. Déjà abonné ? Se connecter

Sur le même sujet

Introduction au dossier : Sécurité des navigateurs web : où en sommes-nous ?

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Il y a maintenant 5 ans, MISC dédiait un dossier complet à la sécurité des navigateurs web [1]. Il y était traité de sandboxing sous Firefox, de JIT, de cloisonnement JavaScript, d’exploitation du navigateur Chrome sous Android. Une grande partie de ce qui a été écrit à l’époque est encore en partie valide et je vous invite à y jeter un œil si vous ne connaissez pas déjà ce dossier.

Un œil technique sur les sanctions de la CNIL

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Près de trois quarts des sanctions prononcées par la Commission Nationale de l’Informatique et des Libertés (CNIL) ont parmi leurs causes des vulnérabilités techniques de sécurité. À partir de ce constat, et au prisme de notre expérience à la fois en cybersécurité technique et en protection des données à caractère personnel, nous avons analysé les sanctions de la CNIL publiées sur le site https://www.legifrance.gouv.fr/. Nous avons notamment établi une correspondance avec les catégories de vulnérabilités techniques identifiées dans la nomenclature du top 10 de l'OWASP 2017 (Open Web Application Security Project). Nous avons également étudié les fuites de données majeures survenues en Europe et dans le monde. Il en ressort que les vulnérabilités les plus communes sont liées à l’authentification, au contrôle d’accès et à la protection des données au repos et en transit.

De l’audit de code pendant un Red Team ?

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Pendant un Red Team, l’exhaustivité des découvertes est mise de côté pour privilégier l’efficacité en se concentrant sur l’identification des vulnérabilités à fort impact permettant de mettre rapidement un pied dans le système d’information ciblé.

Tomoyo, le contrôle d’accès facile

Magazine
Marque
GNU/Linux Magazine
Numéro
235
|
Mois de parution
mars 2020
|
Domaines
Résumé

Par un contrôle fin des accès aux fichiers, les logiciels de type Mandatory Access Control (MAC) permettent de lutter efficacement contre le piratage et le vol de données. Tomoyo-linux propose une alternative simple d’utilisation à SELinux.

Par le même auteur

Mozilla InvestiGator : quand vos serveurs se prennent pour Sherlock Holmes

Magazine
Marque
MISC
HS n°
Numéro
11
|
Mois de parution
juin 2015
|
Domaines
Résumé

Avec suffisamment de serveurs à surveiller, l'investigateur expérimenté se retrouve souvent à chercher l'aiguille dans la botte de foin. Pour peu que l'infrastructure soit hétérogène, la recherche peut prendre plusieurs heures et souvent ne pas couvrir l’intégralité du domaine. Si vous êtes familier de ce problème et que PSSH ne fait plus l'affaire, la suite devrait vous intéresser. Une note toutefois : les personnages et situations qui suivent sont purement fictifs et ne représentent pas forcément la routine des investigations réalisées par l'auteur dans le cadre de son activité.

TLS, état des lieux côté serveur

Magazine
Marque
MISC
Numéro
72
|
Mois de parution
mars 2014
|
Domaines
Résumé
Configurer TLS côté serveur est difficile. 19% des sites en HTTPS proposent toujours SSLv2. 28% vont négocier une session avec DES_CBC_SHA et ses clés de 56 bits si le client le demande. Il y a un peu plus d'un an, la majorité des experts en SSL/TLS recommandaient RC4 à AES. Quelques mois plus tard, c'était l'inverse. Une partie de la communauté cryptographique supporte Perfect Forward Secrecy, alors qu'une autre le refuse pour cause de lenteur. Il existe même des doutes sur le niveau réel de sécurité fourni par AES-256, par rapport à la version 128 bits. Ajoutons à cela une bonne dose de perte de confiance dans les standards existants, en particulier depuis que l'on sait Dual_EC_DRBG backdoored, et nous voici avec une parfaite recette de confusion et d'incohérence. Les désaccords sur la meilleure façon de configurer HTTPS sont nombreux. Et si le débat est utile aux experts, il est presque impossible pour un non-initié de naviguer dans la nébuleuse TLS, et d'en extraire une configuration de référence.

Postscreen, l'exterminateur de zombies

Magazine
Marque
GNU/Linux Magazine
Numéro
147
|
Mois de parution
mars 2012
|
Domaines
Résumé
Il y a plus d'un an de cela, je vous présentais dans ces pages un formidable répulsif à Sus scrofa domesticus, j'ai nommé DSPAM. Au même moment, notre rédacteur en chef préféré m'avouait sa passion déraisonnable et certainement bien personnelle pour ce formidable résidu de cuisine qu'est le pâté de jambon, communément appelé Spam de mon côté de l'Atlantique. Fort de ma machine à tokens dopée aux amphétamines (toujours DSPAM), je m'empressais de pondérer les propos du malheureux finnois d'une statistique bien négative, et éventuellement repoussais lesdits échanges aux confins de mon dossier spam (sans pour autant bannir complètement l'intéressé, dont la conversation est toujours des plus constructive et bienvenue). Heureux de ma vie tranquille, lisant plaisamment mes courriels sans l'once d'une distraction viagriarienne « enlarge your peniche » pendant presque un an, je relâchais donc ma garde. Mais le spammer est malin, et sous prétexte de bricoler des bidules électroniques, le voilà qui libérait toute une armée de zombies spammers prêts à délivrer leurs contenus dégoûtants dans les entrailles de l'Internet.

Développement web en Perl avec Mojolicious

Magazine
Marque
GNU/Linux Magazine
Numéro
138
|
Mois de parution
mai 2011
|
Résumé
Cela fait maintenant quelques années que Perl, en tant que langage de développement web, se fait discret. Beaucoup de développeurs l'utilisent toujours, mais la (relativement récente) vague Python/Ruby s'est ajoutée à PHP pour occuper l'essentiel du Web. En tant que sysadmin, j'ai une tendance naturelle au conservatisme : si ça marche, ne touche à rien. Bon, évidemment, ça ne s'applique pas partout, mais quand il s'agit de programmation, j'aime bien me dire que Perl fera le boulot au moins aussi bien, et peut-être mieux, que d'autres langages.J'étais donc curieux du petit dernier de la communauté Perl : le framework MVC Mojolicious. Petit frère du très reconnu Catalyst, Mojolicious est un projet récent qui essaie de corriger certains mécontentements que les moines de Perl ont pu ressentir en utilisant Catalyst. Dans la mesure où les robes en bure, hormis le fait que ça gratte, ce n'est pas ma spécialité (et n'étant pas développeur de nature), cet article n'est pas un rapport d'expertise sur Perl et les frameworks MVC, mais plutôt une introduction au développement web avec Perl et Mojolicious 1.1.

Combattre efficacement le spam avec DSPAM

Magazine
Marque
GNU/Linux Magazine
Numéro
132
|
Mois de parution
novembre 2010
|
Résumé
Vous avez déjà goûté du spam ? Je veux dire, du vrai spam. Celui qui est servi en boîtes rectangulaires et a vaguement la couleur du jambon. On m’en a servi, une fois, lors d’un réveillon, et je peux vous assurer que ce n’est vraiment pas bon ! Mais le spam dont on va parler ici est différent, plus électronique, mais tout aussi dégoûtant.Combattre le spam est probablement la tâche la plus complexe du postmaster. Les techniques sont nombreuses et il est indispensable de les cumuler pour obtenir un résultat pertinent.