• [^] # Re: Transport via SSH

    Posté par . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 4.

    Oups, je me rends compte que j'avais oublié autre chose : les performances de HTTP <= 1.1 n'égalent pas SSH, qui a des paquets binaires, le multiplexage de flux, et les connexions ouvertes longtemps (websocket est un peu un hack, quand même).

    Avec HTTP 2, on pourra comparer.

    Tu peux déjà avoir une infra qui toute la chaine d'authentification en place pour HTTP (LDAP, Kerberos, TLS client...) .

    Bonne remarque. Mais sauf si j'ai loupé un truc, la question n'est donc pas "je voudrais bien pousser en HTTP", mais plutôt "je voudrais bien que Pijul gère les cent-cinquante standards différents d'authentification en HTTP".

    Ou alors il doit y avoir un moyen générique de faire faire ça à un proxy ? Je serais bien content d'avoir une référence à lire sur le sujet.

    On arrive bien à faire du TLS client, du Kerberos, du 2factor, du Yubikey en SSH en ligne de commande.

    On pourrait certes y arriver, mais ce n'est quand même pas (à mon avis) le même degré de complexité. SSH est un seul protocole, qui comporte trois façons de s'authentifier (password, public key, none), plus une extension très utilisée (keyboard-interactive, utilisée par OpenSSH pour les mots de passe à la place de password).

    Tout est spécifié de manière extrêmement précise dans une seule RFC (plus l'extension dans une autre RFC), et on a déjà une bonne sécurité une fois qu'on a ça. C'est tellement facile à implémenter que les implémentations les plus utilisées ont des failles de sécurité qui se comptent sur le doigts de la main, alors qu'OpenSSL a un très gros problème par an, et plusieurs petits chaque mois.