MinimaLT, un remplaçant réaliste pour TCP, TLS et IPsec ?
Il y a des chercheurs ambitieux. En voici qui proposent un protocole qui veut remplacer à la fois #TCP et #TLS et #IPsec. Ils exagèrent ? Pas complètement. Le projet est prometteur (mais encore à ses touts débuts) mais il y a quelques points noirs qu’ils « oublient » de mentionner.
Un lien direct vers le projet, pas enterré au 3/4 de ton excellente analyse, serait souhaitable :) J’ai triché et utilisé Google.
Tu trolles : les liens (deux, au cas où l’un casse) sont dans le deuxième paragraphe de mon article. http://www.ethos-os.org/~solworth/minimalt-20130522.pdf
Has HTTPS finally been cracked? Five researchers deal SSL/TLS a biggish blow...
http://nakedsecurity.sophos.com/2013/03/16/has-https-finally-been-cracked
Cryptographers have once again put SSL/TLS (that’s the padlock in HTTPS) in their gunsights and opened fire.
This time, they’ve done some severe damage.
Paul Ducklin takes a detailed look…
http://i2.wp.com/sophosnews.files.wordpress.com/2013/03/ts-cracked-250.png
Source: Naked Security - Paul Ducklin
#cryptography #featured #analysis #beast #cracked #lucky_13 #lucky_thirteen #ssl #tls
Une amusante attaque contre le protocole de #cryptographie #TLS, l’attaque Lucky Thirteen (en cryptographie, la moitié du travail est de trouver un nom rigolo). L’attaque n’aura sans doute pas de conséquence pratique mais elle permet de regarder un aspect peu connu des protocoles cryptographiques : l’erreur est plus lente que le succès.
Ce texte est la version grand public :
http://nakedsecurity.sophos.com/2013/02/07/boffins-crack-https-encryptionin-lucky-thirteen-attack
Et l’article original est :
Un certain nombre de services sur l’Internet, notamment de serveurs Web, sont protégés par le protocole #TLS, qui utilise presque toujours un #certificat #X.509 pour vérifier l’authenticité du serveur. Ces certificats ont une durée de vie limitée et doivent donc être renouvelés de temps en temps. Comme un certain nombre d’administrateurs ont oublié, au moins une fois, un tel renouvellement, il me semble utile de donner ce conseil : intégrez la surveillance des dates d’expiration dans votre système de #supervision !
http://www.bortzmeyer.org/tester-expiration-certifs.html
PS : le certificat de SeenThis a expiré mais, de toute façon, il est tellement à l’Ouest ►http://seenthis.net/messages/98342 que ce n’est pas le problème le plus grave.
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.
Excellente étude pratique sur l’efficacité (ou plutôt l’absence de) des avertissements de sécurité lors de connexions #SSL, avec des tests de design alternatifs « Crying Wolf : An Empirical Study of SSL Warning Effectiveness » de Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., et L. Cranor
http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf
#ergonomie #Web #TLS #X.509 #certificats
RFC 6797 : HTTP Strict Transport Security (HSTS)
La technique #HSTS (HTTP Strict Transport Security), normalisée dans ce #RFC (mais déjà largement déployée) vise à résoudre une attaque contre #TLS. Si un site Web est accessible en #HTTPS, et qu’un méchant arrive à convaincre un utilisateur de se connecter en HTTP ordinaire à la place, le méchant peut alors monter une attaque de l’homme du milieu. Le fait que le site soit protégé par TLS n’aidera pas dans ce cas. Pour éviter cette attaque, HSTS permet à un site de déclarer qu’il n’est accessible qu’en HTTPS. Si l’utilisateur a visité le site ne serait-ce qu’une fois, son navigateur se souviendra de cette déclaration et ne fera plus ensuite de connexions non sécurisées.
http://www.bortzmeyer.org/6797.html
Ça serait cool pour améliorer la sécurité de SeenThis mais, de toute façon, il faudrait d’abord résoudre <►http://seenthis.net/messages/98342>
Permettre un accès en #HTTPS à Seenthis, c’est très cool (pour les lecteurs situés dans des pays dictatoriaux, ou qui travaillent dans une entreprise qui flique ses salariés, c’est même recommandé par l’EFF). Mais il faudrait un certificat plus sérieux. Mon Firefox me dit :
« The certificate is not trusted because it is self-signed. »
Il faudrait utiliser une AC comme CAcert ou StartSSL ou autre.
« The certificate is not valid for any server names. »
Et, en effet, aucun nom de serveur n’est indiqué dans le certificat.
« The certificate expired on 01/12/12 16:37. The current time is 11/20/12 10:41. »
Il faudrait renouveler le certificat (truc : CAcert envoie un rappel automatiquement)
#SeenThis_bug #TLS #X.509
Je trouve que c’est de toutes manières inutilisable, parce que les liens « Accueil » et « Seenthis » renvoient vers la version http.
je vote aussi pour une utilisation plus fluide avec #HTTPS. Et pourquoi pas une case à cocher dans les préférences pour être systématiquement redirigé vers la version https?
RFC 6698 : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA
À chaque seconde, d’innombrables transactions sur l’Internet sont protégées contre l’écoute et la modification malveillante par le protocole #TLS. Ce dernier est capable de chiffrer la session (pour la protéger contre l’écoute par un tiers) et d’authentifier le pair avec qui on parle (pour s’assurer qu’on n’est pas en train de communiquer avec un usurpateur). Comment TLS authentifie t-il ? La méthode la plus courante aujourd’hui est de se servir de certificats #X.509 vérifiés (en théorie) par une Autorité de Certification. Ce mécanisme repose sur une confiance aveugle dans de très nombreuses organisations, et a de nombreuses faiblesses, comme on l’a vu en 2011 où le piratage de plusieurs AC a permis à des attaquants d’obtenir de « vrais-faux » certificats, y compris pour des organisations qui n’étaient pas clientes des AC piratées. La démonstration étant ainsi faite que X.509 n’était pas digne de la confiance que certains lui accordent, il restait à concevoir une meilleure solution. Rendue possible par le déploiement de #DNSSEC, voici #DANE (DNS-based Authentication of Named Entities) et ses enregistrements #DNS #TLSA. DANE permet à chacun de publier de manière sécurisés ses certificats, bouchant ainsi les vulnérabilités de X.509, ou permettant même de s’en passer complètement.
DANE permettrait par exemple, d’accéder à SeenThis sans se faire engueuler par son navigateur. Aujourd’hui, SeenThis est accessible en #HTTPS mais avec un certificat auto-signé, et pour un nom invalide ("SeenThis" et pas "seenthis.net"). Ajouter un enregistrement TLSA à _443._tcp.seenthis.net permettrait de ne plus avoir d’avertissement de sécurité (pour les futurs navigateurs Web avec gestion de DANE/TLSA).
http://www.bortzmeyer.org/6698.html
#RFC
RFC 6520 : #TLS and #DTLS Heartbeat Extension
Le protocole de cryptographie TLS ne disposait pas en standard de mécanisme de « battement de coeur », permettant de tester qu’une connexion est toujours vivante. C’est désormais chose faite. Grâce à la nouvelle extension de TLS, normalisée dans ce #RFC, deux pairs TLS peuvent s’assurer, par un mécanisme standard, que l’autre pair est bien là, et répond.
Technical Architecture shapes Social Structure : an example from the real world
Cet article date de 2007 mais est toujours très bon, comme critique du modèle de sécurité de #X.509 et comme analyse des solutions alternatives. Bonne explication au début pour les débutants.
►http://lair.fifthhorseman.net/~dkg/tls-centralization
#TLS
Je voudrais ici poser une question : je n’ai pas coché « Suivre Stéphane Bortzmeyer » et je reçois cependant des notifications de ses publications dans ma boite mail. Pourquoi ?
Sans exclure la possibilité d’un bug : je vois que tu suis notamment @fil, qui « partage » assez régulièrement les messages de Bortz. Il suffit en effet que quelqu’un que tu suis partage un message pour que ce message passe dans son propre flux. Donc, sauf erreur, également dans les mails qui lui sont associés.
C’est quand même un peu le binzz (je ne suis pas du tout, mais alors là pas du tout) technicien je reçois des trucs comme ça, sans mention d’expéditeur :
world Cet article date = ?UTF-8 ?B ?ZGXigKY= ?=
X-PHP-Originating-Script : 33:seenthis_options.php
From : = ?UTF-8 ?B ?U3TDqXBoYW5lIEJvcnR6bWV5ZXIgKEBzdGVwaGFuZSk= ?= - Seenthis <no-reply@seenthis.net>
Content-Type : text/plain ; charset="utf-8"
Content-Transfer-Encoding : 8bit
Message-Id :<44237@seenthis.net>
Date : Thu, 1 Dec 2011 21:40:04 +0100 (CET)
Stéphane Bortzmeyer (@stephane) a posté un nouveau billet
http://seenthis.net/messages/44237
Technical Architecture shapes Social Structure : an example from the real world (etc…)
Cet article date de 2007 mais est toujours très bon, comme critique du modèle de sécurité de #X.509 et comme analyse des solutions alternatives. Bonne explication au début pour les débutants.
►http://lair.fifthhorseman.net/~dkg/tls-centralization
#TLS
–--------
Pour ne plus recevoir d’alertes de Seenthis,
vous pouvez régler vos préférences dans votre profil
►http://seenthis.net
Cet article date de 2007 mais est toujours très bon, comme critique du modèle de sécurité de #X.509 et comme analyse des solutions alternatives. Bonne explication au début pour les débutants.
►http://lair.fifthhorseman.net/~dkg/tls-centralization
#TLS
–--------
Pour ne plus recevoir d’alertes de Seenthis,
vous pouvez régler vos préférences dans votre profil
►http://seenthis.net
Cet article date de 2007 mais est toujours très bon, comme critique du modèle de sécurité de #X.509 et comme analyse des solutions alternatives. Bonne explication au début pour les débutants.
►http://lair.fifthhorseman.net/~dkg/tls-centralization
#TLS
–--------
Pour ne plus recevoir d’alertes de Seenthis,
vous pouvez régler vos préférences dans votre profil
►http://seenthis.net
je n’ai pas réussi à copier l’ensemble du bazar infernal que je reçois. Je ne suis pas fâché, juste intrigué.
sinon dans les paramêtres de ton compte tu peut virer les notifications par mail aussi nan ?
Je ne vois pas bien comment faire car il n’y a pas de nom d’expéditeur dans le champs où il y a normalement l’identité du correspondant.
RFC 6394 : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
Le projet #DANE (DNS-based Authentication of Named Entities), vise à améliorer et/ou remplacer les certificats #X.509 utilisés dans des protocoles comme #TLS. Ces certificats souffrent de plusieurs problèmes, le principal étant qu’une Autorité de Certification (AC) malhonnête ou piratée peut créer des certificats pour n’importe quelle entité, même si celle-ci n’est pas cliente de l’AC tricheuse. C’est ce qui s’est produit dans les affaires #Comodo et #DigiNotar et ces deux affaires ont sérieusement poussé aux progrès de DANE. Ce premier #RFC du groupe de travail DANE établit les scénarios d’usage : quels problèmes veut résoudre DANE et selon quels principes ?
La presse a comme d’habitude annoncé n’importe quoi à propos de la faille de sécurité #TLS qui sera officiellement publiée le samedi 24, vers 00h00 UTC. Les titres les plus sensationnalistes se sont succédés, « Le protocole SSL aurait été craqué », « Une faille dans le chiffrement SSL et des millions de sites HTTPS vulnérables », « Des pirates [sic] brisent le cryptage [re-sic] SSL utilisé par des millions de sites » et autres fariboles du même genre. C’est la loi habituelle des médias officiels : parler sérieusement et étudier son sujet ne rapportent rien. Faire de la mousse est bien plus efficace... et sera de toute façon oublié dans deux jours. Mais, derrière cette ridicule campagne de presse, qu’y a-t-il comme information fiable ?
Ah, le son du troll le soir au fond des bois... Lauren Weinstein est un vigoureux défenseur des droits et libertés sur l’Internet mais il fait parfois aussi des conneries, comme pour son projet IDONS, pur vaporware annoncé à grands renforts de trompettes mais qui, comme un autre vaporware (DNS-P2P) n’a rien produit.
http://lauren.vortex.com/archive/000873.html
Ici, Weinstein s’attaque à #DANE (utiliser #DNSSEC pour distribuer des certificats, utilisables par exemple pour #TLS). Il a deux arguments : c’est un déplacement de pouvoir depuis les CA #X.509 vers la mafia du #DNS (pas faux). Et c’est vulnérable aux interventions du gouvernement états-unien (pas faux non plus).
Alors, quel est le problème ? C’est que Weinstein ne regarde pas les alternatives. Pourquoi parle-t-il de la mafia du DNS pour ICANN / registres / BE et pas pour les CA ? Les CA sont meilleurs ? Plus honnêtes ? Plus compétents ? Moins susceptibles d’obéir à un ordre légal de leur État ?
Bref, du pur FUD.
OVH et Gandi vendent des « certificats SSL ». Techniquement le nom est peut-être pas le bon, mais on se comprend :-)
Pouvoir envoyer le couple login/passwd de manière chiffrée sur le réseau est le minimum. Et quand on a un site tout web2.0 qui peut participer à faire chuter des régimes politiques, le chiffrement est indispensable.
Mais je sais, la sécurité est la grande oubliée du développement Internet de ces dernières années (X.509 semble le confirmer d’ailleurs)
#seenthis a déjà du SSL qui fonctionne, pas besoin que ça soit validé par une entreprise pas fiable pour que ça soit « vraiment » un « bon » certificat.
Le certificat actuel génère une erreur, les geeks s’en contentent, mais il y a bien qu’eux. En plus, c’est à moi de forcer le HTTPS. En 2011, le minimum est d’avoir HTTPS pour login/passwd.
Le pire est que je suis sûr que vous devez adhérer à l’initiative HTTPS Everywhere.
Oui l’action du formulaire de login devrait être en HTTPS.
Le certificat ne génère pas d’erreur, il génère un dialogue d’information qui demande à accepter ou refuser le certificat selon si tu lui fait confiance ou non.
Je te conseille l’extension MonkeySphere (et CertPatrol) pour Firefox pour aider ce travail de confiance (ça se base sur ton cercle de confiance GPG/PGP, bien plus fiable qu’une signature d’une entreprise qui ne vérifie rien à part que la transaction a bien été payée...).
Sinon tu peux aussi faire comme les gens un peu sérieux : effacer les certificats des entreprises « officielles » de ton navigateur/OS afin de vérifier chaque certificat, ainsi tu verra que SeenThis n’est pas différent des millions d’autres sites utilisant TLS ;)
Juste pour dire que je suis tout à fait d’accord avec @bohwaz. C’est pour cela que je pinaillais sur la différence entre TLS et X.509. TLS est très bien et SeenThis devrait l’utiliser davantage. C’est X.509 le problème.
Etant en https, en cliquant sur « Seenthis » ou « Accueil », on passe en http. #seenthis_bug @seenthis
pareil, quand on veut récupérer son mot de passe (ou vouloir en changer), on repasse en http. #seenthis_bug
RFC 6125 : Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using #X.509 (PKIX) Certificates in the Context of Transport Layer Security (#TLS)
Un RFC long et complexe pour un problème difficile. En résumant violemment, il s’agit de savoir quelle identité utiliser lorsqu’un client TLS s’assure de l’authenticité du serveur auquel il se connecte. Par exemple, si un MTA veut transmettre du courrier à bill@example.com, que doit contenir le certificat X.509 du MX d’example.com pour que l’authentification réussisse ? example.com ? D’autres noms, plus spécifiques à ce service, sont-ils possibles ? Comme de nombreux autres protocoles ont des problèmes de ce genre, l’idée avait germé de faire un RFC générique, définissant un cadre et des principes, RFC que les protocoles n’auraient plus qu’à citer. C’est notre RFC 6125.
