Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 3 sur 3 PremièrePremière 123
Affichage des résultats 61 à 75 sur 75
  1. #61
    Citation Envoyé par Croaker Voir le message
    C'est comment le Huawei niveau facilité de config, en fait, j'ai jamais touché à cette saleté de pourriture communiste.
    Plutôt mieux que Cisco (façon Juniper) ou même pas ?
    Je n'écris pas pire que Cisco parce que ça me semble impossible (surtout maintenant qu'il n'y a plus de constructeurs français).
    Globalement c'est pareil, même si t'as quelques subtilités sur le LACP ou le NAT/PAT par exemple.
    Sinon les commandes changent un peu.
    Perso, alors que j'oublie des trucs au fur et à mesure, j'étais pas largué. La période d'adaptation ne me semble donc pas folle si tu connais ton sujet par ailleurs.
    La loutre ça poutre !

  2. #62
    C'est ici le topic des experts réseaux?

    J'ai une question stupide

    Contexte: Il y a une spécification européenne pour le transfert d'informations sécurisées entre entreprises ferroviaires. Il s'agit d'informations pour sécuriser la circulation des trains donc c'est assez sensible. Cette spécification indique qu'il faut utiliser le protocole TCP avec le protocole TLS pour sécuriser le tout grâce à des certificats PKI transmis par CMP.

    Jusque là je crois que j'ai plus ou moins compris le principe dans les grandes lignes (je suis électroniciens à la base, tout ça c'est presque du chinois pour moi ).

    Maintenant on a des fournisseurs qui se pointent en disant que leur solution utilise le HTTP. Ce qui a déclenché une shitstorm au niveau européen en mode "la spec dit qu'il faut utiliser le TCP/IP, pas le HTTP !".

    Or pour moi ce sont deux choses différentes. Le HTTP utilise le TCP/IP non? Ce sont deux couches différentes. Techniquement le HTTP utilise le TCP/IP ou j'ai raté un truc? En fait j'ai sûrement raté un truc car je ne comprend pas la shitstorm...

    C'est quoi le soucis d'utiliser le HTTP pour répondre à une spéc qui demande du TCP/IP ? On perd des fonctions en se restreignant au seul HTTP? Est-ce que cela pose un risque pour la sécurité des données?

  3. #63
    Ben techniquement tu vas encapsuler HTTP et donc avoir un paquet de trucs inutiles. Alors tu peux faire avec, sauf que s'il faut aller chercher les infos différemment suivant les équipements, ben ça va gueuler si le standard n'est même pas respecté dès le début.

  4. #64
    Je suis pas sur de comprendre le contexte mais oui, le http, le TCP et l'IP c'est des couches différentes (cf modèle OSI : https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI)

    Si c'est du http et non pas du https, en termes de sécurité c'est en effet pas ça. Mais je me dis que j'ai pas assez de billes pour comprendre, d'autres feront sans doute ça mieux que moi.

    grilled by Robix66 qui m'a fait me taper sur le front en me disant "mais c'est bien sur".
    La loutre ça poutre !

  5. #65
    OK, si je comprend bien, on pourrait transférer les infos directement en TCP/IP, rajouter une surcouche HTTP rajoute une étape qui n'est pas nécessaire.

    Edit: Effectivement, j'ose espérer qu'ils entendent HTTPS quand ils disent HTTP. Quand des cheminots se lancent dans les réseaux informatiques c'est pas forcément très clair

  6. #66
    Citation Envoyé par Praetor Voir le message
    OK, si je comprend bien, on pourrait transférer les infos directement en TCP/IP, rajouter une surcouche HTTP rajoute une étape qui n'est pas nécessaire.
    Voilà.
    Prend un pdf dont la numérotation ne correspond pas à celle du document, tu regardes le sommaire, tu vas page 184, et tu t'aperçois que t'es en fait page 177.
    C'est pas un problème énorme, mais si t'as la possibilité de taper sur celui qui a fourni le document et de lui demander de faire comme font les autres, ben c'est plus simple que de gérer un cas particulier.

  7. #67
    C est pas très clair effectivement, le soucis pourrait être qu ils utilisent Http/tcp plutot que https/tls/tcp avec une verrue de sécurité quelconque par dessus http qui gère les clés.
    J interprete "ils utilisent http" comme "ils n utilisent pas https et tls" (en pratique https = http sur tls)

    Sinon oui http est 90% du temps sur tcp/Ip a part pour des applis comme le streaming ou le transfert unidirectionnel.
    Allez au diable Square-Enix Co. Ltd., Character Development, Marketing Division, et autres Online Business chaipasquoi.

  8. #68
    D'accord, du coup je comprend pourquoi ça râle. Merci.

  9. #69
    Heuuuu de mémoire sauf erreur HTTP utilise maintenant QUIC et plus TCP/IP, donc s'ils savent de quoi ils parlent ils ont raison, puisque HTTP n'utilise presque plus TCP/IP depuis la version 3.

    Après il faudrait plus de détails pour bien répondre à ta question Praetor...

    Parce qu'on ne parle pas de la même chose quand on parle de TCP ou de HTTP, puisque ce ne sont pas des protocoles concurrents.

    Ton dialogue je le comprends comme ça moi :

    - Pour aller de Paris à Marseille on passera par Lyon
    - OK Je prends le train du coup
    - OULA NON ON A DIT QU'ON PASSAIT PAR LYON !!

  10. #70
    Citation Envoyé par Croaker Voir le message
    C est pas très clair effectivement
    Oui, désolé. Pour ceux que ça intéresse, voici la spec en question (c'est un doc publique): https://www.era.europa.eu/sites/defa...t-137_v100.pdf

    Par contre je n'ai pas d'info sur les solutions en HTTP donc je ne sais pas ce qu'il y a concrètement derrière.

    - - - Mise à jour - - -

    Citation Envoyé par Wobak Voir le message
    Parce qu'on ne parle pas de la même chose quand on parle de TCP ou de HTTP, puisque ce ne sont pas des protocoles concurrents.
    C'est pour ça que je ne comprend pas la shitstorm.

    - - - Mise à jour - - -

    Citation Envoyé par Wobak Voir le message
    Heuuuu de mémoire sauf erreur HTTP utilise maintenant QUIC et plus TCP/IP, donc s'ils savent de quoi ils parlent ils ont raison, puisque HTTP n'utilise presque plus TCP/IP depuis la version 3.
    Ca c'est intéressant, je l'ignorais.

  11. #71
    Ouais a priori c'est bien ce que je me disais, le protocole que vous devez implémenter, c'est lui la couche application, donc tu ne vas pas aller l'encapsuler dans une autre couche application.

  12. #72
    Quic c est 100% udp effectivement.
    Et c etait aussi100% Google jusqu'à deux mois je crois (tls et Quic ca me semble assez nouveau).
    Allez au diable Square-Enix Co. Ltd., Character Development, Marketing Division, et autres Online Business chaipasquoi.

  13. #73
    Ah attendez, je crois que j'ai compris. J'ai confusionné deux choses.

    L'utilisation du HTTP ne concerne que le CMP. Or la spec fait appel au document "RFC-4210 - Internet X.509 Public Key Infrastructure Certificate Management Protocol" qui au §3.1.2 point 8 liste le HTTP.

    Du coup c'est pas clair si on peut utiliser le HTTP ou pas. OK pour ça.

    Et si je vous ai bien compris il s'agit bien de deux protocoles différents donc si les uns utilisent le HTTP et d'autres le TCP ça ne va pas aller et il faut se mettre d'accord.

    Je crois que je vois. Je ne sais pas quels sont les avantages et inconvénients de chaque solution mais j'ai compris qu'il y avait un problème à clarifier. Merci.

    - - - Mise à jour - - -

    Citation Envoyé par Robix66 Voir le message
    Ouais a priori c'est bien ce que je me disais, le protocole que vous devez implémenter, c'est lui la couche application, donc tu ne vas pas aller l'encapsuler dans une autre couche application.
    Ah, le KMS (notre système) est au même niveau que le HTTP en fait, je n'avais pas percuté!

  14. #74
    Je pense que la description des échanges dans le doc (§6) interdit en pratique l'utilisation d'autre chose que TLS. Même si la RFC l'autorise dans le cas général.
    (J'ai pas tout lu hein, seulement les titres de chapitre.)
    Allez au diable Square-Enix Co. Ltd., Character Development, Marketing Division, et autres Online Business chaipasquoi.

  15. #75
    Citation Envoyé par Wobak Voir le message
    Heuuuu de mémoire sauf erreur HTTP utilise maintenant QUIC et plus TCP/IP, donc s'ils savent de quoi ils parlent ils ont raison, puisque HTTP n'utilise presque plus TCP/IP depuis la version 3.
    Pour preciser, http/3 utilise QUIC, et http/2 est sur TCP.

    Et c'est loin d'etre majoritaire, c'est toujours a l'etat de draft IEFT, et il me semble qu'on est plutot dans les 20% du traffic http (la grande majorite etant du http/2, donc sur TCP).
    J'ai quand meme des doutes sur ce 20%, j'ai pas de source et pas de temps pour regarder plus

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •