Https peut-il être utilisé à la place de sftp pour des transferts de fichiers sécurisés?
Mon entreprise travaille avec des services financiers et nous sommes tenus de transférer en toute sécurité des fichiers contenant des informations non publiques sur les consommateurs entre notre entreprise et nos clients.
La solution habituelle consiste à utiliser sftp pour les transferts de fichiers, mais beaucoup de nos clients ne sont pas technophiles, et les configurer avec le logiciel sftp et leur apprendre à l'utiliser prend beaucoup de temps et est souvent frustrant pour les deux parties.
Comme solution facile, j'ai créé un site Web très basique hébergé sur https qui permet aux utilisateurs de se connecter en utilisant leurs informations d'identification ftp et de télécharger/télécharger des fichiers via une interface Web.
Mais https peut-il être considéré comme l'équivalent de sftp comme moyen de transférer un fichier en toute sécurité?
HTTPS et SFTP lorsqu'ils sont utilisés correctement sont également sûrs. Les algorithmes de chiffrement sous-jacents dans la pratique sont tous deux fonctionnellement équivalents - aucun ne peut être rompu en pratique en attaquant directement les protocoles cryptographiques.
Cependant, dans la pratique avec les utilisateurs non avertis en technologie, HTTPS est légèrement plus faible à mon avis.
Il y a des attaques sur les deux qui peuvent être lancées sur des utilisateurs peu avertis et non avertis. L'attaque contre SFTP, comme l'a dit Rell3oT, est que vous ne connaissez généralement pas la clé publique du SFTP lors de votre première connexion et que vous vous en souvenez pour toutes les connexions suivantes (bien que l'enregistrement DNS SSHFP défini dans DNSSEC pourrait résoudre ce problème) , mais ne sont pas actuellement largement utilisés ). Cela signifie qu'un attaquant qui a initialement redirigé le trafic Internet vers son faux serveur sftp pourrait capturer vos données s'il ciblait l'attaque sur une personne se connectant au site sftp pour la première fois à partir d'un ordinateur (qui n'a pas la clé publique enregistrée). Cette attaque ne peut pas se produire sur les connexions suivantes.
Cependant, avec https, il existe plusieurs autres attaques potentielles introduites dans lesquelles les utilisateurs non avertis pourraient être trompés.
- L'utilisateur ne peut pas accéder à https://your-secure-file-transfer.com mais au lieu de cela, il suffit de taper
your-secure-file-transfer.comdans le navigateur Web (qui par défaut passe à la versionhttp). Un attaquant pourrait attendre ce cas, puis capturer ce trafic et le rediriger vers leur copie falsifiée de ce site; voler les informations d'authentification/données financières. (Oui, une chose similaire pourrait se produire avec le remplacement de sftp par ftp; mais comme cela se fait généralement dans une application distincte qui enregistre les informations de connexion, cela semble moins probable - pour accéder à la version ftp, l'utilisateur doit généralement saisir manuellement une autre numéro de port). Vous pouvez résoudre ce problème en demandant au site d'avoir HSTS activé . À moins qu'il ne fasse attention à la barre d'URL affichanthttps, l'utilisateur peut ne pas remarquer qu'il se trouve sur un sitehttpou une URL différente. HSTS n'est activé que sur une petite liste des principaux sites Web par la plupart des navigateurs. La plupart du temps, il est activé dans un navigateur Web après avoir visité avec succès le site HTTPS la première fois (où il y a un en-tête pour se rappeler que ce site doit toujours se connecter via https); donnant une sécurité fonctionnellement équivalente à SFTP. - Le navigateur Web d'un utilisateur non averti en technologie est moins sûr que votre client SFTP standard. Les utilisateurs installent souvent diverses extensions de navigateur qui ont la possibilité d'accéder à toutes vos activités Internet pour obtenir une sorte de fonctionnalité. Cette fonctionnalité ajoutée peut s'accompagner d'une attaque secrète; par exemple, voler des cookies de session, des informations saisies sur des formulaires (comme leur mot de passe), etc. qui sont finalement renvoyées à l'auteur du client.
- L'autorité de certification (ou l'autorité de certification intermédiaire) pourrait être compromise à n'importe quelle date et les attaquants pourraient obtenir des certificats de navigateur qui leur permettent d'usurper votre https sans détection. Cela diffère à nouveau de SFTP, où le client sftp se souvient de la clé publique du site qu'il a déjà vu et vous avertit si elle a changé. (Les navigateurs Web ne le feront pas; les certificats sont autorisés à changer tant qu'ils sont correctement signés. Encore une fois, cela ne devrait pas changer de sitôt, car les serveurs Web à charge équilibrée ont généralement tous des certificats signés différents.
Dans l'ensemble, je dirais que HTTPS est légèrement plus faible dans la pratique que SFTP; tandis que les deux sont également sécurisés en fonction de leurs mérites cryptographiques. Si vous entraînez vos utilisateurs à vérifier que https est présent et au bon domaine, et que vous avez en outre instillé une certaine paranoïa à propos de l'utilisation des extensions de navigateur sur leurs ordinateurs de travail (ou suggérez d'utiliser le mode privé des navigateurs généralement avec peu d'extensions installées), il sera à peu près équivalent (en supposant que vous avez correctement configuré le site avec HSTS/cookies sécurisés http uniquement, etc.).
Oui. Je dirais que HTTPS est équivalent ou meilleur que SFTP.
HTTPS utilise une autorité de certification centrale, contrairement à SFTP. Il y a un risque la première fois que vous vous authentifiez avec SFTP. L'utilisation par HTTPS du tiers de confiance évite ce risque.
Il est important de noter que (en supposant qu'un canal sécurisé est établi) SFTP et HTTPS sont également sécurisés.
HTTPS et SFTP diffèrent d'une manière très importante qui, à mon avis, incline considérablement l'avantage vers HTTPS: le streaming de données contre le transfert de fichiers. Une connexion HTTPS appropriée entre les services logiciels génère et transmet des données de manière incrémentielle et ne nécessite pas de fichiers au repos. D'un autre côté, SFTP par convention, pratique et protocole exige que les fichiers soient créés et stockés pendant leur transfert (envoi et réception) - donc deux copies au repos existent simultanément.
Zéro fichier au repos contre deux fichiers au repos est énorme, en particulier lorsqu'il est mis en contexte avec le problème de l'autorité de certification. HTTPS gagne.
Une réponse donnant quelques bonnes raisons pour SFTP a été acceptée mais il semble que personne n'ait mis en avant de nombreux avantages d'utiliser https.
Premièrement, la disponibilité des outils pour 'https est beaucoup plus large que pour SFTP. Il a une utilisation beaucoup plus large, devrait donc être une technologie plus mature.
Il est beaucoup plus facile d'intégrer des outils de différents fournisseurs sans compromettre la force du chiffrement.
Le déplacement de fichiers seul a peu d'avantages. C'est lorsque les données sont traitées que la valeur est réalisée. Il est beaucoup plus facile d'intégrer le traitement avec les transferts 'https qu'avec SFTP.
Http (et 'https) a un vocabulaire pour décrire comment les données doivent être interprétées (encodage, langue, type mime) et traitées (get, post, put, delete) qui ne sont pas disponibles dans SFTP.
Http (s) fournit un mécanisme pour fournir des informations contextuelles à côté de la capacité de transfert - la documentation, les informations sur l'utilisation des comptes, la gestion des comptes, la journalisation des problèmes et plus qui ne sont pas disponibles sont SFTP.
Les utilisateurs sont souvent le maillon le plus faible d'un réseau sécurisé. Les utilisateurs ont une bien meilleure compréhension de HTTPS que de SFTP. Les certificats/clés client ajoutent de la complexité à cela, mais il est beaucoup plus facile de dire aux gens de vérifier un fond vert dans l'URL que de les parler en permettant une vérification stricte de l'hôte et en traitant le roulement s'ils changent jamais.
Et les certificats https ont une date d'expiration et un mécanisme de vérification oob (pré-enregistrement HSTS).
Que vous posiez la question me fait penser que vous êtes un analyste de sécurité/administrateur système. De ce point de vue, les différences ne sont peut-être pas aussi claires. Allez parler à vos développeurs et utilisateurs et vous obtiendrez une image très différente.
Je commenterais sans réponse, mais je dois d'abord établir ma réputation. SFTP peut être conçu pour avoir une surface d'attaque plus petite. HTTPS implique un processus de serveur Web et qui est lui-même exposé aux attaques. SFTP semble une configuration plus simple.
Liste de tâches: -dédiez un hôte pour SFTP -exécutez rcconf et tuez tous vos services inutiles -créez un groupe d'utilisateurs sftp et chrootez -activez la journalisation des activités des utilisateurs SFTP séparées en mode verbeux -créez des sous-répertoires couronnés pour chacun de vos clients/partenaires-sauvegarder vos données sur un autre hôte