Journal La pire monoculture Microsoft de la planète

Posté par  (site web personnel) .
Étiquettes :
45
9
juil.
2010
Un article très intéressant sur le site h-online => http://www.h-online.com/open/features/South-Korea-Super-fast(...)

Selon cet article la Corée du Sud a fait un choix dramatiquement stupide en 1998. Le gouvernement a imposé l'utilisation du chiffrement SEED (inconnu au bataillon sauf chez eux) et cet algorithme n'était disponible que via Microsoft Internet Explorer à travers ActiveX.
Le résultat c'est que tout le commerce online de Corée dépendait d'IE. Tous les sites gouvernementaux, toutes les banques dépendaient d'IE et le gouvernement avait rendu tout ça obligatoire.
En dépit d'une infrastructure de réseau très moderne et rapide la pénétration des autres OS que Microsoft Windows est restée complètement marginale puisque tous les sites exigeaient ActiveX pour fonctionner correctement.

Cette situation absurde va changer. Les autorités coréennes se sont aperçues (il a fallu le temps) que cette monoculture Microsoft posait des graves problèmes. L'arrivée de Vista avait déjà provoqué la grogne chez les utilisateurs (l'article parle d'une "massive disruption") mais ce qui a fait pencher la balance c'est l'arrivée des smartphones.
Pour surfer sur le net avec un smartphone en utilisant les sites marchands coréens il faut absolument sortir de la dépendance ActiveX.

"iPhone/BlackBerry/Android users in Korea (not to mention Firefox/Opera/Safari/Chrome users) cannot bank online or purchase items online or do any secure transaction with the smartphone browser because Korean services only support the PKI mechanism that only works with Active-X in IE and Windows".

La Financial Services Commission coréenne a donc édicté une nouvelle régulation applicable au premier juillet et qui ouvre l'accès aux autres logiciels que ceux de Microsoft.
Bien entendu la transition va sans doute être longue et coûteuse mais c'est le prix à payer quand on s'enferme dans une technologie propriétaire non standardisée. Le réveil est toujours douloureux !
  • # Pour une fois, le problème ne vient pas du logiciel proprio…

    Posté par  . Évalué à 7.

    > Le gouvernement a imposé
    Je crois que le problème est ici. C’est quoi cette idée stupide d’imposer législativement une technologie spécifique ?

    (au passage : c’est une nouvelle loi qui introduit une dérégulation, pas une nouvelle régulation)
    • [^] # Re: Pour une fois, le problème ne vient pas du logiciel proprio…

      Posté par  (site web personnel) . Évalué à 9.


      Pour une fois, le problème ne vient pas du logiciel proprio…


      Ben si, parce que si le gouvernement avait imposé un standard à la place d'une technologie proprio, le problème ne se poserait pas. Donc le problème vient bien du proprio.

      Après on peut discuter de l'opportunité pour un gouvernement de faire des choix technologiques, mais c'est un autre débat.
    • [^] # Re: Pour une fois, le problème ne vient pas du logiciel proprio…

      Posté par  (site web personnel) . Évalué à 2.

      Si les transactions commerciales, les ordres bancaires, la consultation et/ou l'utilisation des sites gouvernementaux peuvent entrainer des conséquences légales, commerciales ou économiques

      Alors il est normal qu'un gouvernement propose et choisisse une solution afin de garantir à tous un accès et une sécurité identique pour tous

      Toutefois, comme on peut le voir, un tel choix n'est pas évident et peut défoncer l'économie d'un pays pendant des années...

      Un truc étonnant : je sais pas vous, mais moi je n'ai jamais entendu parler de cette histoire concernant la Corée du Sud...C'est quand même étonnant, c'est un pays très connecté et ouvert sur le monde...Bizarre que cette histoire n'ait pas "filtré" avant....
    • [^] # Re: Pour une fois, le problème ne vient pas du logiciel proprio…

      Posté par  (site web personnel) . Évalué à 7.

      C’est quoi cette idée stupide d’imposer législativement une technologie spécifique ?

      Je sais bien que les rôles fondamentaux de l'État sont en voie d'extinction de nos jours dans nos sociétés, mais tout de même, l'un de ceux-ci est de protéger ces citoyens de l'agression et de la prédation.

      C'est le rôle de l'État de s'assurer qu'il n'y a pas (trop) d'énergumènes a rouler sans permis, parce que c'est dangereux pour moi.

      Des l'or, il ne me semble pas délirant que l'État s'assure que les organismes qui opèrent des transactions bancaires le fasse avec une sécurité minimale garantie, dans l'intérêt de tous les citoyens qui vont utiliser ce système.

      Ensuite, on sait très bien qu'en crypto, on ne peut pas se contenter de caractéristiques générales pour garantir un niveau de sécurité (comme la taille des clefs). Si tu dis "clefs de 128 bits minimum", tu vas avoir des boulets pour chiffrer en 256bits, mais en RSA (ce qui doit tomber en quelques secondes avec la puissance d'un téléphone portable). Et même si tu donnes des tailles de clefs précises pour le chiffrement symétrique et asymétrique, tu auras toujours des malins pour t'inventer le chiffrement du siècle: le double XOR en 4096 bits!!!! incassable ma p'tite dame!

      Et et et et même si tu impose un algo particulier et sérieux, genre Blowfish, t'es pas sorti d'affaire, parce que le Blowfish implémenté par le petit Kevin en turbo pascal, je suis certain que même ma petite sœur elle peut le casser ( ouai elle déchire en timing attack ma petite sœur... ).

      Tout ca pour dire que ca a du sens pour un etat de valider quels sont les moyens legaux pour procéder a des échanges bancaire, après c'est certain que de choisir CET algo, c'etait un gros epic fail...
  • # Pas peindre le diable sur la muraille

    Posté par  (site web personnel) . Évalué à 5.

    Même s'ils ont fait une erreur, c'est quand même moins dramatique :

    http://en.wikipedia.org/wiki/SEED
    http://tools.ietf.org/html/rfc4269
    http://tools.ietf.org/html/rfc4196
    http://tools.ietf.org/html/rfc4010
    https://bugzilla.mozilla.org/show_bug.cgi?id=478839

    Et c'est compréhensible à l'époque où SSL était limité à 40 bits ...

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # smartphone standard != iPhone/BlackBerry/Android

    Posté par  (site web personnel) . Évalué à 4.

    iPhone/BlackBerry/Android users in Korea (not to mention Firefox/Opera/Safari/Chrome users) cannot bank online or purchase items online or do any secure transaction with the smartphone browser

    Si la Corée du Sud assimilait les ordinateurs à des PC sous Windows qui exécutent le navigateur IE, il ne faudrait pas qu'ils recommencent et ne considèrent comme smartphones que ceux qui tournent sous iPhoneOS/blackberryOS/Android. Déjà j'en ai un qui tourne sous Symbian, mais il y a aussi Maemo/Meego, plus des millions d'autres qui n'existent pas encore.

    L'important, c'est le respect des standards. Après, on se fiche de savoir sur quelle machine ça tourne, si la machine ne respecte pas les standards, c'est son problème.
  • # Algo du SEED

    Posté par  . Évalué à 6.

    Je vous confirme pour l'avoir utilisé, le SEED est présent depuis un moment dans NSS (la librairie crypto de Mozilla : Firefox, Thunderbird,...) mais aussi dans OpenSSL. Cet algo est national et de type optionnel. Ce qui veut dire qu'il vaut l'activer lors de la compilation de la librairie crypto.

    En ce qui concerne NSS, il a été inclus dans la libraire en avril 2009 quant à OpenSSL, j'ai la flemme de chercher.
    • [^] # Re: Algo du SEED

      Posté par  . Évalué à 1.

      D'après l'article Wikipedia ça date de fin 2009. Ce qui me paraît bizarre, si le format est documenté, c'est que personne n'ai eu l'idée plus tôt de l'implémenter. Même en dehors de Mozilla, pour Opera par exemple, le marché Sud Coréen n'est pas négligeable vu le taux d'équipement et les débits disponibles. Quand on voit que .Net à été réimplémenté en libre peu de temps après sa sortie alors que pour le coup c'est 100% microsofto-microsoftien et que les débouchés ne sont pas phénoménaux pour d'autres fournisseurs, comment a-t-il pu s'écouler 10 ans sans que qui que ce soit se préoccupe de la question. Il n'y a pas de FSF en Corée du Sud ?
      • [^] # Re: Algo du SEED

        Posté par  . Évalué à 2.

        Je peux t'assurer que ça date de bien avant 2009.

        Du reste, si on se réfère aux notes de sortie suivantes : http://www.mozilla.org/projects/security/pki/nss/nss-3.12.3/nss-3.12.3-release-notes.html

        => 1er avril 2009
        => New Korean SEED cipher
      • [^] # Re: Algo du SEED

        Posté par  . Évalué à 2.

        Quand on voit que .Net à été réimplémenté en libre peu de temps après sa sortie

        Sauf que Mono n'est pas compatible avec la denière version de .Net, ni même l'avant dernière, http://www.mono-project.com/Compatibility . Oui, il couvre une grande partie des besoins des applications mais pas tout, de là à certifier qu'une application bancaire prévue pour .Net tournera sans faille de sécurité sur Mono, il y a un pas reccord du monde de saut en longueur que je ne franchirais pas et que peu d'entreprises s'y risqueraient à mon avis.

        et que les débouchés ne sont pas phénoménaux pour d'autres fournisseurs

        .Net c'est quand même le concurrent de Java, donc certains concurrents de Sun ont tout intérêt à voir Mono se développer rapidemment. Ce n'est pas pour la beauté du geste que Novell participe activement au projet.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Algo du SEED

          Posté par  . Évalué à 2.

          certains concurrents de Sun ont tout intérêt à voir Mono se développer rapidemment

          C'est un comme dire que les concurrent d'EDF devraient lancer un nouveau format de prise électrique. Le meilleur moyen de ne jamais gagner de clients.

          Sun n'est pas seul aux commandes de Java. IBM est clairement un concurrent de Sun et pourtant ils misent aussi sur Java. Pourquoi ? Parce que c'est une norme qui évolue et sur laquelle ils ont leur mot à dire aussi. Pourquoi dupliquer les efforts et mettre une barrière (migration techno) à l'entrée de nouveaux clients ? C'est comme pour le libre. IBM mise dessus car c'est plus intéressant pour eux de mutualiser les efforts tout en proposant leur valeur ajoutée sur certains produits.

          Dans le cas de .Net, Microsoft décide de tout. Donc viser la compatibilité est une chimère. Les bases sont standardisées et documentées mais tout ce qui est au dessus peu changer quand ils veulent.
          • [^] # Re: Algo du SEED

            Posté par  . Évalué à 2.

            Pourquoi dupliquer les efforts et mettre une barrière (migration techno)

            Il y a une base actuellement assez importante d'utilisateur de .Net, c'est beaucoup plus facile de leurs vendre une migration légère (Mono) plutôt que de devoir tout changer (Java). De plus, Novell peut se dire qu'ils n'ont pas les moyens de lutter contre IBM et Sun et qu'il vaut mieux proposer une autre technologie. Ce n'est pas forcément mieux, mais c'est peut-être plus rentable pour la société.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # D'autres problèmes

    Posté par  (site web personnel) . Évalué à 8.

    J'avais lu l'article suivant:

    http://www.osnews.com/story/23481/Sad_State_of_South_Korean_(...)

    Ils ont aussi un système d'ID associé à chaque personne physique à utiliser pour le login (plutôt qu'un compte anonyme), obligatoire pour les plus gros sites. Ce qui:
    - va à l'encontre de l'anonymat sur le net
    - permet des usurpations d'identité
    - met souvent à l'écart les étrangers
  • # Juste un petit aperçu

    Posté par  . Évalué à 2.

    Au cas où ce journal serait promu en dépêche, je signale cette petite faute d'accord :
    « Les autorités coréennes se sont aperçus »
    aperçues

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.