Blog Stéphane Bortzmeyer : Accueil

Ethereum, la prochaine étape des systèmes transparents
►https://www.bortzmeyer.org/ethereum.html

Ethereum est souvent présenté par rapport à Bitcoin : « Bitcoin 2.0 », « the next Bitcoin », « Bitcoin on steroids », etc. Il est vrai qu’il s’inspire très fortement de Bitcoin mais, en le présentant ainsi, on peut le confondre avec tous les autres machins qui ont été faits à partir de Bitcoin comme Dogecoin, Litecoin ou encore Namecoin. À part ce dernier, ces comparaisons peuvent amener à conclure qu’Ethereum n’est qu’« une nouvelle monnaie virtuelle et cryptographique (alt coin) ». Alors qu’il est bien plus que cela.

[...]

Ethereum reprend plusieurs concepts importants de Bitcoin, notamment la blockchain et la preuve de travail (il n’est donc pas plus écologiste que Bitcoin). Mais le code est radicalement différent, réécrit de zéro (contrairement à la plupart des alt coins). Il existe en outre plusieurs implémentations, avec une spécification commune (contrairement à Bitcoin où le code est la spécification, le papier original de Sakamoto ne descendant pas dans les détails). Mais le gros changement par rapport à Bitcoin est que les transactions stockées dans la blockchain ne sont pas limitées à envoyer et recevoir de l’argent. Ethereum dispose d’un quasi-langage de Turing et est donc un système de calcul réparti : les pairs dans le réseau Ethereum ne se contentent pas de vérifier l’intégrité de la blockchain et d’ajouter de la monnaie, ils exécutent du code arbitraire, celui des applications que vous ou moi développons et envoyons sur le réseau.

Cela permet d’écrire des contrats (appelés, dans le style marketing fréquent dans le monde Ethereum, des smart contracts) qui sont la description, dans un langage de programmation, des règles qui s’imposent aux parties contractantes. Un prêt d’argent, par exemple, peut se programmer dans un contrat et s’exécuter automatiquement, sans intervention humaine, et donc sans possibilité de triche. (Question philosophique : quel est le pourcentage des contrats entre humains qui peuvent s’automatiser, c’est-à-dire ne plus accepter d’arrangement, de cas particuliers, etc ?) Les applications d’Ethereum ne sont donc limitées que par votre imagination.

#Blockchain #Ethereum #Innovation_disruptive #Numérique

RFC 7686 : The .onion Special-Use Domain Name
►https://www.bortzmeyer.org/7686.html

Le TLD .onion est utilisé par Tor pour nommer des serveurs Internet dont la localisation exacte est cachée. Tor est surtout connu pour permettre aux clients de demeurer relativement intraçables pendant leurs activités sur l’Internet, et .onion étend cette possibilité aux serveurs. Ce TLD n’avait aucune forme d’existence officielle avant, il avait juste été choisi comme cela et était reconnu par les logiciels Tor. Désormais, il est stocké dans le registre des noms de domaine spéciaux créé par le RFC 6761.

C’est politiquement une certaine forme de reconnaissance de la part de l’IETF pour ces services cachés de Tor (que TF1 et les ministres nomment le Dark Web). Mais cela ne changera pas grand’chose en pratique, .onion était utilisé depuis des années, illustrant d’ailleurs la déconnexion entre la réalité et certains professionnels de la gouvernance Internet, qui croient que l’ICANN est le « régulateur de l’Internet ».

#.onion #Domain_Name_System #Internet #Internet_Engineering_Task_Force #RFC #Request_for_comments #The_Onion_Router #Tor

RFC 7686 : The .onion Special-Use Domain Name

Le TLD .onion est utilisé par #Tor pour nommer des serveurs Internet dont la localisation exacte est cachée. Tor est surtout connu pour permettre aux clients de demeurer relativement intraçables pendant leurs activités sur l’Internet, et .onion étend cette possibilité aux serveurs. Ce TLD n’avait aucune forme d’existence officielle avant, il avait juste été choisi comme cela et était reconnu par les logiciels Tor. Désormais, il est stocké dans le registre des noms de domaine spéciaux créé par le #RFC 6761.

►http://www.bortzmeyer.org/7686.html

#oignon #Ser_Davos #anonymat #DarkWeb

RFC 7663 : IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report

Une caractéristique importante de l’Internet d’aujourdhui, et qui le distingue considérablement de l’architecture initialement prévue, est la prévalence de #middleboxes un peu partout sur le trajet. Alice et Bob ne peuvent plus, dans la plupart des cas, se parler directement, ils doivent passer par des middleboxes, dont les intérêts ne sont pas ceux des utilisateurs, et qui sont en outre fréquemment boguées et/ou limitées dans leurs fonctions. Un des effets est l’#ossification_Internet : innover devient de plus en plus difficile, car il y aura toujours une middlebox sur le trajet qui ne sera pas d’accord. Quelles sont les conséquences de cette middleboxation de l’Internet ? Comment peut-on résoudre les problèmes qu’elle posent ? C’est le but du programme IP Stack Evolution de l’#IAB que de trouver des réponses à ces questions. C’est dans ce cadre qu’un atelier a été organisé en janvier 2015 à Zurich pour explorer la question. Ce #RFC est le compte-rendu de l’atelier SEMI (Stack Evolution in a Middlebox Internet).

▻https://www.bortzmeyer.org/7663.html

RFC 7583 : DNSSEC Key Rollover Timing Considerations

Contrairement au #DNS classique, le système de sécurité #DNSSEC est très dynamique : il faut changer les signatures régulièrement et il est souvent recommandé de remplacer (changer) les clés. Compte-tenu du fait que le DNS n’est pas synchrone (les changements n’apparaissent pas instantanément partout dans l’Internet), ce changement, ce remplacement (rollover, dans la langue d’Alan Turing) est une opération délicate et qui nécessite le strict respect d’un certain nombre de durées. Ce #RFC donne des conseils sur la temporalité des opérations DNSSEC.

▻https://www.bortzmeyer.org/7583.html

#temps

On a beaucoup parlé des attaques #DoS par réflexion + amplification en les présentant souvent comme spécifiques à #UDP. Mais un article récent (mais passé curieusement inaperçu) montre qu’on peut en faire également avec #TCP.

▻https://www.bortzmeyer.org/amplification-tcp.html

#attaque_par_déni_de_service #sécurité_Internet

SeenThis ne l’utilise pas pour la connexion au site Web mais l’API, elle, s’en sert :

RFC 7617 : The ’Basic’ HTTP Authentication Scheme

Ce court #RFC (re-)définit le mécanisme d’authentification « de base » (basic authentication scheme) de #HTTP : un mécanisme trivial, où un nom d’utilisateur et un mot de passe sont transmis en Base64 au serveur HTTP. Ce RFC (et ses copains) annule et remplace l’ancien RFC 2617.

▻http://www.bortzmeyer.org/7617.html

#authentification #sécurité_informatique

Je viens de me lancer dans #Ethereum et j’ai envie de partager avec vous (partager mon expérience, pas mon argent virtuel, faut pas rêver).

►http://www.bortzmeyer.org/ethereum.html

RFC 7626 : DNS privacy considerations
►https://www.bortzmeyer.org/7626.html

Les révélations d’Edward Snowden en juin 2013 ont fait comprendre à tous, même aux plus obtus qui s’obstinaient à nier l’ampleur et la gravité de la surveillance généralisée, que les problèmes de vie privée ne sont pas un simple détail. Au contraire, il est maintenant établi que l’Internet, et les technologies numériques en général, sont utilisés comme arme de surveillance massive par le gouvernement des États-Unis et, quasi-certainement, par plusieurs autres, dans la mesure de leurs moyens. Cela a mené l’IETF, qui avait parfois tendance à relativiser l’intensité du problème, à se pencher sérieusement sur la question. Plusieurs travaux ont été lancés. L’un d’eux concerne la protection de la vie privée lors de l’utilisation du DNS et ce nouveau RFC, écrit par votre serviteur, est son premier résultat.

#Domain_Name_System #Internet #Internet_Engineering_Task_Force #Request_for_comments #Révélations_d'Edward_Snowden #Stéphane_Bortzmeyer #Surveillance_de_masse #Sécurité_informatique #Vie_privée

RFC 7606 : Revised Error Handling for BGP UPDATE Messages

Que doit faire un routeur #BGP lorsqu’il reçoit un message de type UPDATE avec un attribut incorrect ? La norme était claire : le routeur doit fermer la session BGP en cours (et donc perdre toutes les routes associées). Cela partait du bon sens (si l’attribut est corrompu, on ne peut pas se fier au routeur qui l’a envoyé) mais cela avait des conséquences sérieuses : on supprimait toutes les routes, pas seulement celle dans l’annonce UPDATE. Ce court #RFC modifie donc BGP sur un point : on ne coupe plus forcément toute la session, on retire uniquement la route qui figurait dans l’annonce incorrecte.

▻https://www.bortzmeyer.org/7606.html

#résilience_Internet

RFC 7626 : DNS privacy considerations

Les révélations d’Edward Snowden en juin 2013 ont fait comprendre à tous, même aux plus obtus qui s’obstinaient à nier l’ampleur et la gravité de la surveillance généralisée, que les problèmes de vie privée ne sont pas un simple détail. Au contraire, il est maintenant établi que l’Internet, et les technologies numériques en général, sont utilisés comme arme de surveillance massive par le gouvernement des États-Unis et, quasi-certainement, par plusieurs autres, dans la mesure de leurs moyens. Cela a mené l’#IETF, qui avait parfois tendance à relativiser l’intensité du problème, à se pencher sérieusement sur la question. Plusieurs travaux ont été lancés. L’un d’eux concerne la protection de la vie privée lors de l’utilisation du #DNS et ce nouveau #RFC est son premier résultat.

►http://www.bortzmeyer.org/7626.html

#NSA #surveillance_Internet #vie_privée

Quand la justice française pousse les internautes dans les bras de #Google !
▻http://www.dsfc.net/infrastructure/dns-infrastructure/quand-la-justice-francaise-pousse-les-internautes-dans-les-bras-de-google

http://media-cache-ec0.pinimg.com/736x/8c/6f/81/8c6f8154edcfcad73d9fa6b2f41b4f8b.jpg

Sur le plan technique, la décision de bloquer l’accès au site T411 est très facilement contournable. Cette mesure ne sert à rien !Autres lectures sur le thèmeBlocage du site islamic-news.info : le grand bidonnage !Copwatch Idf : la justice française impuissante !Les services de collecte de données personnelles made in…

#Dns #DNS_menteur #DNS_menteurs #DNScrypt #FAI #OpenDNS #OpenNIC

GNUnet: IETF getting cold feet about P2P Names?
▻http://lwn.net/Articles/652406

The #GNUnet blog has this story ( ▻https://gnunet.org/ietf93dnsop ) about recent resistance from the #IETF toward the standardization of “special use” domain names (such as .onion or .gnu) “to reduce the likelihood of #ICANN accidentally creating a conflicting #gTLD assignment.”

Despite the provisions made in RFC 6761 (▻https://tools.ietf.org/html/rfc6761) , the article notes that “there are also a number of DNS-centric people with a totally lack of alacrity in the dnsop WG to continue to stall the process by repeating arguments that were exchanged dozens of times in hundreds of e-mails.” Among those offering resistance, it reports, is Internet Architecture Board Chair Andrew Sullivan, who “says the IETF should not support special use domain names threatening the #DNS business model.”

RFC 7505 : A "Null MX" No Service Resource Record for Domains that Accept No Mail

Comment indiquer qu’un domaine ne reçoit jamais de courrier ? Jusqu’à présent, il n’existait pas de mécanisme standard, permettant d’indiquer aux clients de ne pas perdre de temps à essayer d’écrire. Ce nouveau #RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l’enregistrement MX.

▻https://www.bortzmeyer.org/7505.html

#courrier_électronique #DNS

#Cisco rachète #OpenDNS (et aura donc accès à toutes les requêtes DNS des utilisateurs). Rappel : utiliser un résolveur #DNS public d’une grosse boîte US (OpenDNS, Google Public DNS) est une très mauvaise idée, question #vie_privée.

▻http://www.enterprisenetworkingplanet.com/netsecur/cisco-acquires-opendns-for-635-million.html

RFC 7568 : Deprecating Secure Sockets Layer Version 3.0

Ce nouveau #RFC formalise un point déjà bien connu des experts en sécurité : le dernier survivant de la famille #SSL, SSL version 3, a de graves failles et ne doit pas être utilisé. [...] Il y a bien longtemps que SSL est dépassé, remplacé par #TLS [...]

▻https://www.bortzmeyer.org/7568.html

#cryptographie #sécurité_réseaux

RFC 7572 : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) : Instant Messaging

Ce court #RFC décrit une correspondance entre deux protocoles standards de #messagerie_instantanée, #SIP et #XMPP. Cela permet de développer proprement des passerelles connectant ces deux mondes, autorisant ainsi Juliette, utilisatrice de XMPP, à parler avec son Roméo, qui utilise SIP. C’est aussi un exercice intellectuel rigolo, mais parfois difficile, comment faire se parler deux protocoles différents, qui n’ont pas exactement les mêmes sémantiques.

▻https://www.bortzmeyer.org/7572.html

RFC 7526 : Deprecating Anycast Prefix for 6to4 Relay Routers

#6to4 en #anycast, c’est fini ! Cette technique de transition entre IPv4 et #IPv6, reposant sur des #tunnels établis automatiquement, a pu être utile à un moment pour faciliter l’accès à IPv6 depuis les opérateurs qui étaient en retard pour le déploiement. Mais elle a plein de défauts techniques, qui ont contribué à donner une mauvaise image d’IPv6. Elle est donc marquée par ce #RFC comme officiellement abandonnée.

▻https://www.bortzmeyer.org/7526.html

RFC 7503 : OSPFv3 Auto-Configuration

Le protocole de #routage #OSPF est traditionnellement configuré statiquement, et à la main par l’administrateur réseaux. Certains réseaux, comme par exemple des réseaux un peu complexes à la maison (#Homenet), ont besoin d’un protocole de routage, mais sans avoir d’administrateur réseaux disponible. Il faudrait un OSPF qui se configure tout seul, « plug and play ». Ce court #RFC montre que c’est possible, avec très peu de modifications des mises en œuvre d’OSPF.

▻https://www.bortzmeyer.org/7503.html

RFC 7530 : Network File System (NFS) Version 4 Protocol

Le protocole d’accès aux fichiers #NFS est très ancien. Sa version 2 est décrite dans le RFC 1094, sa version 3 dans le RFC 1813 et la version 4 faisait l’objet du RFC 3530, qui vient d’être remplacé par ce nouveau #RFC. Rien de spectaculaire, juste des clarifications. Notez que, malgré son ancienneté, NFSv3 reste encore très utilisé.

▻https://www.bortzmeyer.org/7530.html