Il n’est pas prévu de faire traiter les problèmes de congestion, de réémission, etc, par HTTP. C’est QUIC qui le fera. « HTTP/3 » n’est qu’une étiquette marketing, sans significtaion technique. (Le passage de HTTP/1 à HTTP/2 avait entrainé bien plus de changements.)
Le
30/09/2019 à
11h
42
Non, en QUIC. UDP n’est là que pour calmer les middleboxes stupides.
Le
30/09/2019 à
11h
39
La description « HTTP/3 est basé sur UDP, et non TCP » est à la fois exacte et très trompeuse. Et cela explique beaucoup des questions posées ici. QUIC est un concurrent de TCP. Il en assure toutes les fonctions (dont la réémission en cas de perte de paquet).
QUIC devrait, dans un monde idéal, fonctionner directement sur IP. Mais comme les « middleboxes » à la c… l’empêchent, il tournera sur UDP, comme tout autre protocole de transport nouveau (SCTP avait déjà montré le chemin). UDP n’est donc qu’une très mince couche entre IP et QUIC, le « vrai » protocole de transport.
Avec un tel raisonnement, on ne ferait jamais de politique (ou alors seulement sur de toutes petites choses sans importance comme de changer la durée du mandat présidentiel, ou le nombre de députés). La politique, c’est d’agir pour les choses qui ne se font pas spontanément. (Theodore Roosevelt, à propos du démantelement de la Standard Oil.)
Le
11/03/2019 à
10h
24
Je résume : arguments de droite, idiots, sexistes (contre Ocasio-Cortez), attaques personnelles, bref du troll à ignorer.
J’ai bien dit que je déconseillais l’utilisation de résolveurs DNS publics états-uniens.
Personnellement, j’utilise toujours les résolveurs du réseau local, contrôlés par moi ou par mon employeur.
Le
25/02/2019 à
14h
14
Les deux méthodes (reproduction du vrai site, ou bien homme du milieu, bien que ce nom ne soit pas parfaitement adapté ici) sont possibles.
Et les attaquants avaient des certificats, qu’on peut voir avec crt.sh.
Le
25/02/2019 à
14h
08
Oui, DNSSEC est de bout en bout (si on valide sur une machine de confiance, bien sûr ; au bureau, c’est une machine de mon employeur, à la maison, une machine du réseau local que je contrôle).
DNScrypt n’a rien à voir : il protège le canal et pas les données et n’est donc pas de bout en bout.
Le
25/02/2019 à
14h
06
Par contre, je ne comprends pas bien la « seule contrainte » dont vous parlez. Let’s Encrypt utilise évidement les mêmes serveurs faisant autorité que tout le monde. Leur résolveur demande au domaine du dessus et obtient la même liste que tout le monde. Donc, si je contrôle nextinpact.com et que je change les enregistrements, tout le monde les verra (c’est le principe du DNS).
Le
25/02/2019 à
14h
04
Et c’est justement ce qu’ont fait les attaquants (l’article de Krebs, cité par Next Inpact, contient tous les détails techniques). Les journaux « certificate transparency » montrent bien les certificats Let’s Encrypt obtenus par les attaquants.
Le
25/02/2019 à
14h
03
J’avoue ne pas bien comprendre votre message. Oui, contrôler le DNS permet en effet de mettre une adresse IP de son choix à la place de la vraie. C’est justement le principe de cette attaque. Une fois que c’est fait, les clients vont vers vous et plus vers le bon serveur. Vous avez gagné. Si vous pouvez contrôler facebook.com, vous avez tout le trafic de Facebook.
Le
25/02/2019 à
14h
01
Quad9 est en effet un résolveur DNSSEC validant (vérifiant les signatures DNSSEC). Comme des tas d’autres. Après, ça n’est qu’un résolveur, il faut encore que les serveurs faisant autorité servent des signatures (que les zones soient signées).
Et utiliser un résolveur public états-unien pose d’autres problèmes….
Il n’y a pas interruption de service si le site pirate sert de relais (terminant la session TLS, et en faisant une nouvelle vers le vrai site Web).
Le
14/01/2019 à
12h
59
Pas complètement d’accord. En théorie, vous avez raison. Mais en pratique, dans pas mal de boîtes, il y a des services qui sont à peu près correctement gérés, et il y a le DNS, qui est sous le radar, pas pris en compte, et dont le mot de passe du compte chez l’hébergeur ou le BE est sur un post-it connu de tout le monde et du stagiaire.
C’est le mérite du rapport de FeuŒil. Rien de nouveau, en effet, mais une utile piqure de rappel : n’oubliez pas les noms de domaine !
Le
14/01/2019 à
12h
54
« Alors que l’entrée « A » désigne le serveur principal, la « NS » permet
de ne toucher qu’à un sous-domaine précis, comme celui d’un webmail. » Cela ne veut absolument rien dire. Il faut virer cette phrase. Proposition de remplacement : Alors que l’entrée « A » désigne l’adresse IP d’un serveur donné, les « NS » permettent au pirate de rediriger ses victimes vers ses propres serveurs de noms, lui donnant un meilleur contrôle sur le domaine détourné.
On ne pourra pas taper « nos optimisations fiscales » dans un document sans que Word n’insère à la place la liste des comptes de la boîte dans les paradis fiscaux, avant d’envoyer à Mediapart un lien vers le document.
Notez que l’utilisation du DNS n’est qu’une des façons d’exploiter la faille. LTE permet de modifier les données, et on peut changer bien d’autre chose que l’adresse IP du résolveur DNS.
D’autre part, DNSSEC est certes une excellente techniquej, très utile (d’ailleurs, Next Inpact le teste, c’est direhttps://dns.bortzmeyer.org/nextinpact.com/DNSKEYhttps://dns.bortzmeyer.org/nextinpact.com/DS) mais, DANS CE CAS PRÉCIS, elle ne servirait pas à grand’chose puisque rare sont les smartphones qui valident (la validation est typiquement faite sur le résolveur, justement ce qui est détourné).
« Bordélique » au sens de « ce n’est pas Disneyland, aucune entreprise centralisée n’a mis de l’ordre là-dedans et chacun fait ce qu’il veut » ? Oui, c’est nul, la liberté.
Et, de toute façon, c’est absurde de le faire sur la machine terminale, où ça peut être difficile (Network Manager, systemd-resolve) ou impossible (Android non rooté). Ça doit plutôt être fait dans un engin spécialisé, tout fait (Turris Omnia…) annoncé en DHCP.
Le
03/04/2018 à
08h
49
En quoi Quad9 est-il meilleur que Cloudflare ?
Le
03/04/2018 à
08h
04
Le meilleur résolveur ? (“DNS” tout court ne veut pas dire grand’chose.) Le résolveur local, sur une machine que je contrôle.
Le
03/04/2018 à
08h
02
Et puis c’est une racine alternative (donc ils ajoutent des TLD bidons) et question vie privée, c’est zéro, le trafic étant en clair (à moins que vous ne fassiez partie de la minorité des utilisateurs d’OpenNIC ,qui ont réussi à déployer dnscrypt).
Le
03/04/2018 à
08h
01
« C’est vrai que le protocole aurait besoin d’un bon coup de dépoussiérage » Ça fait juste quatre ans que le projet “DNS privacy” à l’IETF a commencé et Cloudflare met en œuvre au moins deux de ses RFC. Mais on accepte des volontaires :-) Ce n’est pas parce que les médias ne s’en étaient pas aperçus que rien n’était fait.
Pour la box déjà toute prête, avec résolveur DNS, il en existe plusieurs, comme la Turris Omnia.
Le
03/04/2018 à
07h
58
Cloudflare permet d’authentifier le serveur en DNS-sur-TLS par “The certificate presented is for cloudflare-dns.com”
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = CA, L = San Francisco, O = “Cloudflare, Inc.”, CN = *.cloudflare-dns.com
verify return:1
—
RFC 8310, section 8.1
Le
03/04/2018 à
07h
56
Rien de bizarre, on sait depuis des années que le préfixe 1.1.1.0/24 est pourri, utilisé dans plein de documentations écrites par des incompétents, et mis dans plein de configurations par défaut faites par des zozos.https://labs.ripe.net/Members/gih/content-traffic-network-10008
Merci pour l’excellent résumé de qui est McAffee. Ce projet n’aurait normalement suscité aucun intérêt, même pas une brève, s’il n’y avait le nom de ce clown.
Je voudrais ajouter un petit mot à propos de RDAP. Ce n’est qu’un protocole, comme whois, et l’éventuel remplacement de whois par RDAP (ce qui n’est pas gagné, loin de là) ne changera pas forcément grand’chose au débat autour des données personnelles et du RGPD.
Les principales différences que je vois entre les deux protocoles, pour ce qui concerne la vie privée :
les données RDAP sont structurées, contrairement à celles de whois, donc peuvent faciliter la tâche de ceux qui veulent les récupérer en masse (on dit souvent que whois est un “semantic firewall” en raison de l’absense de format de sortie standard, encore que ce n’est plus vrai pour les TLD ICANN)
RDAP permet l’authentification et la confidentialité, donc peut permettre, potentiellement, d’avoir des accès différenciés (par exemple d’envoyer toutes les données à la police et seulement une partie au public anonyme).
Aujurd’hui, les seuls TLD qui ont déployé RDAP en production sont des TLD non-ICANNhttp://data.iana.org/rdap/dns.json mais il y a un RDAP de test pour .com (sans les données personnelles, puisque .com est un registre mince)
Si c’est un .fr, et qu’il est enregistré par une personne physique, les données ne sont PAS distribuées, par défaut. Cf. le commentaire de Gats hier soir. .fr n’est pas un TLD ICANN et n’est donc pas concerné par leurs règles.
Le
18/01/2018 à
18h
15
Les informations actuelles sont souvent incorrectes parce que c’est la seule façon dont l·e·a titulaire d’un domaine dans les TLD ICANN peut protéger sa vie privée. Si elle ne sont plus distribuées aussi largement, les titulaires seront peut-être plus motivé·e·s pour donner des renseignements exacts.
Le
18/01/2018 à
17h
49
Euh, non, rien à voir avec l’« indépendance » de l’ICANN. Les mouvements actuels sont plutôt dûs au RGPD comme bien expliqué dans l’article. (Notons qu’une partie des obligations du RGPD étaient déjà dans les lois nationales et directives européennes précedentes. Le RGPD ne tombe pas du ciel !)
La décision d’Akamai n’était pas purement technique. Si l’attaque leur coûte trop cher, ils laissent tomber. Aux États-Unis, on fait du business, pas du sentiment.
« à part certains sites illégaux, rien n’est censuré à ma connaissance, en tout cas pas en France pour le moment » Ah ben c’est pareil en Chine, à part ce qui est censuré, rien n’est censuré.
Le
20/11/2017 à
09h
04
On n’a le “AD” que si le domaine est signé (ce qui n’est pas le cas de nextinpact.com hélas). Essayez avec afnic.fr, paypal.fr ou ietf.org.
Le
20/11/2017 à
09h
03
Quad9 fait mieux, il utilise DNS-sur-TLS (RFC 7858) qui a l’avantage d’être une solution normalisée.
Le
19/11/2017 à
11h
56
Le pays n’a guère d’importance, pour un service anycast, c’est l’AS qui compte, car c’est de lui que dépend la présence ou pas de peerings, et leur qualité.
Le
19/11/2017 à
11h
55
Certes mais sans indiquer si le cache était chaud ou pas, c’est difficile d’en tirer des conclusions.
Le
19/11/2017 à
11h
54
Oui, sur un cache chaud, le résolveur local gagnera toujours, et de loin. Sur un cache froid, c’est moins évident. (Cf. ma remarque initiale sur l’extrême difficulté de faire des benchmarks sérieux.)
360 commentaires
Cloudflare active HTTP/3, Chrome et Firefox partenaires de l’opération
30/09/2019
Le 30/09/2019 à 11h 44
Il n’est pas prévu de faire traiter les problèmes de congestion, de réémission, etc, par HTTP. C’est QUIC qui le fera. « HTTP/3 » n’est qu’une étiquette marketing, sans significtaion technique. (Le passage de HTTP/1 à HTTP/2 avait entrainé bien plus de changements.)
Le 30/09/2019 à 11h 42
Non, en QUIC. UDP n’est là que pour calmer les middleboxes stupides.
Le 30/09/2019 à 11h 39
La description « HTTP/3 est basé sur UDP, et non TCP » est à la fois exacte et très trompeuse. Et cela explique beaucoup des questions posées ici. QUIC est un concurrent de TCP. Il en assure toutes les fonctions (dont la réémission en cas de perte de paquet).
QUIC devrait, dans un monde idéal, fonctionner directement sur IP. Mais comme les « middleboxes » à la c… l’empêchent, il tournera sur UDP, comme tout autre protocole de transport nouveau (SCTP avait déjà montré le chemin). UDP n’est donc qu’une très mince couche entre IP et QUIC, le « vrai » protocole de transport.
[Màj] Qwant : en finir avec l’omerta
23/09/2019
Le 21/09/2019 à 10h 49
Sur la question du référencement, je viens de taper “manach” dans Qwant et en premier, dans la colonne News, on voit justement cet article.
Une sénatrice américaine veut démanteler les GAFAM pour restaurer la concurrence
11/03/2019
Le 11/03/2019 à 10h 41
Avec un tel raisonnement, on ne ferait jamais de politique (ou alors seulement sur de toutes petites choses sans importance comme de changer la durée du mandat présidentiel, ou le nombre de députés). La politique, c’est d’agir pour les choses qui ne se font pas spontanément. (Theodore Roosevelt, à propos du démantelement de la Standard Oil.)
Le 11/03/2019 à 10h 24
Je résume : arguments de droite, idiots, sexistes (contre Ocasio-Cortez), attaques personnelles, bref du troll à ignorer.
Non, Internet n’est pas mort ce week-end (mais déployez DNSSEC)
25/02/2019
Le 25/02/2019 à 16h 09
Certainement pas les navigateurs, Internet, ce n’est pas que le Web !
- les gérants des zones DNS (pas nextinpact.com, qui est partiellement OK, mais les autres)
Le 25/02/2019 à 14h 46
Que ceux de FDN soient bien ou pas d’y change rien :https://www.bortzmeyer.org/dns-resolveurs-publics.html
Le 25/02/2019 à 14h 36
J’ai bien dit que je déconseillais l’utilisation de résolveurs DNS publics états-uniens.
Personnellement, j’utilise toujours les résolveurs du réseau local, contrôlés par moi ou par mon employeur.
Le 25/02/2019 à 14h 14
Les deux méthodes (reproduction du vrai site, ou bien homme du milieu, bien que ce nom ne soit pas parfaitement adapté ici) sont possibles.
Et les attaquants avaient des certificats, qu’on peut voir avec crt.sh.
Le 25/02/2019 à 14h 08
Oui, DNSSEC est de bout en bout (si on valide sur une machine de confiance, bien sûr ; au bureau, c’est une machine de mon employeur, à la maison, une machine du réseau local que je contrôle).
DNScrypt n’a rien à voir : il protège le canal et pas les données et n’est donc pas de bout en bout.
Le 25/02/2019 à 14h 06
Par contre, je ne comprends pas bien la « seule contrainte » dont vous parlez. Let’s Encrypt utilise évidement les mêmes serveurs faisant autorité que tout le monde. Leur résolveur demande au domaine du dessus et obtient la même liste que tout le monde. Donc, si je contrôle nextinpact.com et que je change les enregistrements, tout le monde les verra (c’est le principe du DNS).
Le 25/02/2019 à 14h 04
Et c’est justement ce qu’ont fait les attaquants (l’article de Krebs, cité par Next Inpact, contient tous les détails techniques). Les journaux « certificate transparency » montrent bien les certificats Let’s Encrypt obtenus par les attaquants.
Le 25/02/2019 à 14h 03
J’avoue ne pas bien comprendre votre message. Oui, contrôler le DNS permet en effet de mettre une adresse IP de son choix à la place de la vraie. C’est justement le principe de cette attaque. Une fois que c’est fait, les clients vont vers vous et plus vers le bon serveur. Vous avez gagné. Si vous pouvez contrôler facebook.com, vous avez tout le trafic de Facebook.
Le 25/02/2019 à 14h 01
Quad9 est en effet un résolveur DNSSEC validant (vérifiant les signatures DNSSEC). Comme des tas d’autres. Après, ça n’est qu’un résolveur, il faut encore que les serveurs faisant autorité servent des signatures (que les zones soient signées).
Et utiliser un résolveur public états-unien pose d’autres problèmes….
Une attaque DNS compromettrait les sites de nombreuses entreprises et organisations
11/01/2019
Le 14/01/2019 à 13h 01
Il n’y a pas interruption de service si le site pirate sert de relais (terminant la session TLS, et en faisant une nouvelle vers le vrai site Web).
Le 14/01/2019 à 12h 59
Pas complètement d’accord. En théorie, vous avez raison. Mais en pratique, dans pas mal de boîtes, il y a des services qui sont à peu près correctement gérés, et il y a le DNS, qui est sous le radar, pas pris en compte, et dont le mot de passe du compte chez l’hébergeur ou le BE est sur un post-it connu de tout le monde et du stagiaire.
C’est le mérite du rapport de FeuŒil. Rien de nouveau, en effet, mais une utile piqure de rappel : n’oubliez pas les noms de domaine !
Le 14/01/2019 à 12h 54
« Alors que l’entrée « A » désigne le serveur principal, la « NS » permet
de ne toucher qu’à un sous-domaine précis, comme celui d’un webmail. » Cela ne veut absolument rien dire. Il faut virer cette phrase. Proposition de remplacement : Alors que l’entrée « A » désigne l’adresse IP d’un serveur donné, les « NS » permettent au pirate de rediriger ses victimes vers ses propres serveurs de noms, lui donnant un meilleur contrôle sur le domaine détourné.
Word va se doter de fonctions organisationnelles propulsées par l’IA
09/11/2018
Le 09/11/2018 à 14h 06
On ne pourra pas taper « nos optimisations fiscales » dans un document sans que Word n’insère à la place la liste des comptes de la boîte dans les paradis fiscaux, avant d’envoyer à Mediapart un lien vers le document.
aLTEr : de nouvelles failles sur la 4G peuvent rediriger un utilisateur vers un site malveillant
02/07/2018
Le 03/07/2018 à 09h 02
Notez que l’utilisation du DNS n’est qu’une des façons d’exploiter la faille. LTE permet de modifier les données, et on peut changer bien d’autre chose que l’adresse IP du résolveur DNS.
D’autre part, DNSSEC est certes une excellente techniquej, très utile (d’ailleurs, Next Inpact le teste, c’est direhttps://dns.bortzmeyer.org/nextinpact.com/DNSKEYhttps://dns.bortzmeyer.org/nextinpact.com/DS) mais, DANS CE CAS PRÉCIS, elle ne servirait pas à grand’chose puisque rare sont les smartphones qui valident (la validation est typiquement faite sur le résolveur, justement ce qui est détourné).
#Replay : pyramide de Kheops, ptérosaures et fantômes asiatiques
29/06/2018
Le 30/06/2018 à 08h 48
Les ptérosaures ne sont PAS des dinosaures.
PeerTube : la campagne de financement passe le premier palier
27/06/2018
Le 27/06/2018 à 09h 27
« Bordélique » au sens de « ce n’est pas Disneyland, aucune entreprise centralisée n’a mis de l’ordre là-dedans et chacun fait ce qu’il veut » ? Oui, c’est nul, la liberté.
Amazon pourrait bloquer Signal en raison du domain fronting
02/05/2018
Le 02/05/2018 à 13h 17
Voir aussi la réaction de Reporters sans Frontièreshttps://rsf.org/fr/actualites/rsf-demande-google-de-retablir-le-domain-fronting-…
1.1.1.1 : Cloudflare annonce son résolveur DNS rapide, sécurisé et respectueux de la vie privée
03/04/2018
Le 03/04/2018 à 08h 50
Et, de toute façon, c’est absurde de le faire sur la machine terminale, où ça peut être difficile (Network Manager, systemd-resolve) ou impossible (Android non rooté). Ça doit plutôt être fait dans un engin spécialisé, tout fait (Turris Omnia…) annoncé en DHCP.
Le 03/04/2018 à 08h 49
En quoi Quad9 est-il meilleur que Cloudflare ?
Le 03/04/2018 à 08h 04
Le meilleur résolveur ? (“DNS” tout court ne veut pas dire grand’chose.) Le résolveur local, sur une machine que je contrôle.
Le 03/04/2018 à 08h 02
Et puis c’est une racine alternative (donc ils ajoutent des TLD bidons) et question vie privée, c’est zéro, le trafic étant en clair (à moins que vous ne fassiez partie de la minorité des utilisateurs d’OpenNIC ,qui ont réussi à déployer dnscrypt).
Le 03/04/2018 à 08h 01
« C’est vrai que le protocole aurait besoin d’un bon coup de dépoussiérage » Ça fait juste quatre ans que le projet “DNS privacy” à l’IETF a commencé et Cloudflare met en œuvre au moins deux de ses RFC. Mais on accepte des volontaires :-) Ce n’est pas parce que les médias ne s’en étaient pas aperçus que rien n’était fait.
Pour la box déjà toute prête, avec résolveur DNS, il en existe plusieurs, comme la Turris Omnia.
Le 03/04/2018 à 07h 58
Cloudflare permet d’authentifier le serveur en DNS-sur-TLS par “The certificate presented is for cloudflare-dns.com”
" />53 -showcerts
% openssl s_client -connect 1.1.1.1
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = CA, L = San Francisco, O = “Cloudflare, Inc.”, CN = *.cloudflare-dns.com
verify return:1
—
RFC 8310, section 8.1
Le 03/04/2018 à 07h 56
Rien de bizarre, on sait depuis des années que le préfixe 1.1.1.0/24 est pourri, utilisé dans plein de documentations écrites par des incompétents, et mis dans plein de configurations par défaut faites par des zozos.https://labs.ripe.net/Members/gih/content-traffic-network-10008
Nouvelle fuite pour la base de données biométrique indienne Aadhaar, les responsables font l’autruche
26/03/2018
Le 26/03/2018 à 09h 42
Notez que le gouvernement ment, très clairement. Ils ont affirmé qu’il n’y a pas eu de fuite alors que les données sont publiées :
Twitter
Le 26/03/2018 à 09h 35
@archangeBlandin Si :http://www.business-standard.com/article/economy-policy/aadhaar-data-kept-behind…
Hiveway, un énième réseau social décentralisé au code « inspiré » de Mastodon
05/03/2018
Le 05/03/2018 à 09h 29
Merci pour l’excellent résumé de qui est McAffee. Ce projet n’aurait normalement suscité aucun intérêt, même pas une brève, s’il n’y avait le nom de ce clown.
Avec le RGPD, la fin annoncée d’une partie de l’annuaire public des noms de domaine
18/01/2018
Le 19/01/2018 à 09h 27
Je voudrais ajouter un petit mot à propos de RDAP. Ce n’est qu’un protocole, comme whois, et l’éventuel remplacement de whois par RDAP (ce qui n’est pas gagné, loin de là) ne changera pas forcément grand’chose au débat autour des données personnelles et du RGPD.
Les principales différences que je vois entre les deux protocoles, pour ce qui concerne la vie privée :
Aujurd’hui, les seuls TLD qui ont déployé RDAP en production sont des TLD non-ICANNhttp://data.iana.org/rdap/dns.json mais il y a un RDAP de test pour .com (sans les données personnelles, puisque .com est un registre mince)
Plus de détails sur RDAP, et les RFC qui le normalisent enhttp://www.bortzmeyer.org/weirds-rdap.html
Le 19/01/2018 à 09h 10
Si c’est un .fr, et qu’il est enregistré par une personne physique, les données ne sont PAS distribuées, par défaut. Cf. le commentaire de Gats hier soir. .fr n’est pas un TLD ICANN et n’est donc pas concerné par leurs règles.
Le 18/01/2018 à 18h 15
Les informations actuelles sont souvent incorrectes parce que c’est la seule façon dont l·e·a titulaire d’un domaine dans les TLD ICANN peut protéger sa vie privée. Si elle ne sont plus distribuées aussi largement, les titulaires seront peut-être plus motivé·e·s pour donner des renseignements exacts.
Le 18/01/2018 à 17h 49
Euh, non, rien à voir avec l’« indépendance » de l’ICANN. Les mouvements actuels sont plutôt dûs au RGPD comme bien expliqué dans l’article. (Notons qu’une partie des obligations du RGPD étaient déjà dans les lois nationales et directives européennes précedentes. Le RGPD ne tombe pas du ciel !)
Google détaille trois failles, qui ont leur site dédié : après Intel, ARM confirme être touché
04/01/2018
Le 03/01/2018 à 09h 28
Tiens, il y a une bogue dans le CMS : seule une partie de l’URL a été transformée en lien.
Le 03/01/2018 à 09h 27
Bientôt les premiers spams PTI https://mastodon.gougere.fr/@ashgan/99284942928651301
Le 03/01/2018 à 09h 25
C’est cool, de spéculer :-)
Le 03/01/2018 à 09h 19
Annonce Xen demain midi (UTC)https://xenbits.xen.org/xsa/ ce qui est cohérent avec celle d’Amazon. Du boulot en perspective demain.
Le cinéma obtient le blocage de Zone Téléchargement, Papystreaming et Sokrostream
22/12/2017
Le 22/12/2017 à 11h 17
@Inny Parce que personne n’utilise le moteur de recherche français souverain ?
Botnet Mirai : trois jeunes universitaires américains ont plaidé coupables
14/12/2017
Le 17/12/2017 à 19h 58
La décision d’Akamai n’était pas purement technique. Si l’attaque leur coûte trop cher, ils laissent tomber. Aux États-Unis, on fait du business, pas du sentiment.
Le 17/12/2017 à 18h 45
Mouais, enfin, pour le Libéria, cela n’a jamais été confirmé https://krebsonsecurity.com/2016/11/did-the-mirai-botnet-really-take-liberia-off… Prudence dès qu’on parle d’attaques en ligne. Il y a peu d’informations fiables (et beaucoup de gens qui copient/collent les articles des autres).
Quad9 : un résolveur DNS ouvert qui veut vous protéger en respectant votre vie privée
17/11/2017
Le 22/11/2017 à 07h 48
« à part certains sites illégaux, rien n’est censuré à ma connaissance, en tout cas pas en France pour le moment » Ah ben c’est pareil en Chine, à part ce qui est censuré, rien n’est censuré.
Le 20/11/2017 à 09h 04
On n’a le “AD” que si le domaine est signé (ce qui n’est pas le cas de nextinpact.com hélas). Essayez avec afnic.fr, paypal.fr ou ietf.org.
Le 20/11/2017 à 09h 03
Quad9 fait mieux, il utilise DNS-sur-TLS (RFC 7858) qui a l’avantage d’être une solution normalisée.
Le 19/11/2017 à 11h 56
Le pays n’a guère d’importance, pour un service anycast, c’est l’AS qui compte, car c’est de lui que dépend la présence ou pas de peerings, et leur qualité.
Le 19/11/2017 à 11h 55
Certes mais sans indiquer si le cache était chaud ou pas, c’est difficile d’en tirer des conclusions.
Le 19/11/2017 à 11h 54
Oui, sur un cache chaud, le résolveur local gagnera toujours, et de loin. Sur un cache froid, c’est moins évident. (Cf. ma remarque initiale sur l’extrême difficulté de faire des benchmarks sérieux.)