Une connexion HTTPS établie signifie-t-elle qu'une ligne est vraiment sécurisée?
Du point de vue de quelqu'un qui propose une application Web, lorsque quelqu'un se connecte avec TLS (https) à notre service et soumet les données d'authentification correctes, est-il sûr de transmettre toutes les données sensibles sur cette ligne, ou peut-il y avoir encore des écoutes?
Cette question était Question de sécurité de la semaine de la TI.
Lisez le 29 juillet 2011 entrée de blog pour plus de détails ou soumettez le vôtre Question de la semaine.
Il est important de comprendre ce que SSL fait et ne fait pas, d'autant plus qu'il s'agit d'une source très courante de malentendus.
- Il crypte la chaîne
- Il applique la vérification d'intégrité
- Il fournit une authentification
Donc, la réponse rapide devrait être: "oui, il est suffisamment sécurisé pour transmettre des données sensibles". Cependant, les choses ne sont pas si simples.
- Les dernières versions de SSL - version 3, ou mieux encore: TLS, même TLS 1.2, sont nettement meilleurs que les versions précédentes. Par exemple. SSL 2 était relativement facile pour MITM (Man in the middle). Donc, cela dépend d'abord de la version du protocole.
- Le cryptage des canaux et la vérification d'intégrité sont configurables dans le protocole, c'est-à-dire que vous pouvez choisir les algorithmes à utiliser (suite de chiffrement). De toute évidence, si vous utilisez RSA1024/SHA512, vous êtes beaucoup mieux ... Cependant, SSL prend même en charge un mode de cryptage NULL - c'est-à-dire aucun cryptage du tout, juste en emballant les demandes pour tunneler via le protocole SSL. C'est-à-dire, aucune protection. (Ceci est configurable à la fois au niveau du client et du serveur, la suite de chiffrement sélectionnée est le premier ensemble correspondant selon l'ordre configuré).
- L'authentification en SSL a deux modes: authentification serveur uniquement et authentification mutuelle (certificats clients). Dans les deux cas, la sécurité assurée par les certificats cryptographiques est certainement assez forte, mais la validité de l'authentification réelle est seulement aussi bonne que vos contrôles de validité: vous dérangez-vous même de vérifier le certificat? Assurez-vous sa validité? Chaîne de confiance? Qui l'a délivré? Etc.
- Ce dernier point sur l'authentification est beaucoup plus facile sur le Web applications, où le client peut facilement visualiser le certificat des serveurs, l'icône de verrouillage est facilement visible, etc. Avec Web Services, vous devez généralement être plus explicite dans la vérification de sa validité (en fonction de votre choix de plateforme). Notez que ce même point a déclenché de nombreuses applications mobiles - même si le développeur de l'application s'est souvenu d'utiliser uniquement TLS entre le téléphone et le serveur, si l'application ne vérifie pas explicitement les certificats, alors le TLS est cassé.
- Bien qu'il existe des attaques principalement théoriques contre la cryptographie de SSL, mon PoV est encore suffisamment puissant pour presque tous les usages, et le sera pendant longtemps.
- Que fait-on réellement avec les données à l'autre bout? Par exemple. si ce sont des données super sensibles, ou même des cartes de crédit, vous ne voulez pas cela dans le cache des navigateurs, ou dans l'historique, etc.
- Les cookies (et donc l'authentification) peuvent être partagés entre un canal SSL sécurisé et un canal HTTP non sécurisé - sauf s'ils sont explicitement marqués avec l'attribut "sécurisé".
Alors, réponse plus courte? Oui, SSL peut être suffisamment sécurisé, mais (comme avec la plupart des choses) cela dépend de la façon dont vous l'utilisez. :)
Il y a quelques problèmes ici, le principal étant l'authentification. Les deux extrémités doivent s'assurer qu'elles parlent à la bonne personne ou à la bonne institution pour contrecarrer les attaques de l'homme du milieu. De votre côté, il est essentiel d'utiliser un certificat SSL approuvé par le navigateur de l'utilisateur. Ce faisant, le navigateur de l'utilisateur peut être sûr qu'il parle vraiment au bon site. Une fois la connexion établie, vous pouvez être sûr de parler à cet utilisateur tout le temps et la connexion est cryptée, c'est-à-dire sécurisée contre les écoutes.
L'authentification dans l'autre sens (c'est-à-dire s'assurer que vous parlez au vrai utilisateur) est généralement gérée en dehors du protocole SSL au niveau de l'application par, par exemple, nom d'utilisateur/mot de passe, openID ou toute autre forme d'informations d'identification.
Comme dernière note, il convient de mentionner que lors de la connexion SSL, le client et le serveur de prise de contact conviennent d'un Cipher suite et le client peut prétendre ne faire que "un cryptage nul", c'est-à-dire ne crypter aucune des données . Si votre serveur accepte cette option, la connexion utilise SSL, mais les données ne sont toujours pas cryptées. Ce n'est pas un problème dans la pratique car les implémentations de serveur n'offrent généralement pas le chiffre nul en option.
En plus de ce qu'AviD répertorie, SSL n'est aussi sécurisé que l'infrastructure DNS qui vous a dirigé vers ce serveur et tout proxy d'entreprise dans le chemin de communication.
Si l'infrastructure DNS est piratée (empoisonnement du cache, etc.), l'attaquant pourrait soumettre votre utilisateur à de nombreuses attaques.
De plus, si le client utilise un logiciel comme Fiddler , ou un proxy d'entreprise, ce logiciel peut faciliter votre conversation SSL.
Pour atténuer cela, regardez l '"émetteur" du certificat SSL. Si la connexion SSL passe par un proxy, l'émetteur sera celui du proxy. Si vous passez par une connexion directe, vous verrez l'autorité de certification publique de confiance appropriée.
[Plus d'informations]
Un proxy HTTPS d'entreprise est quelque chose qui gère la connexion entre le navigateur Web et le proxy (dont l'adresse IP apparaît dans les journaux de votre serveur Web). Dans ce cas, le contenu Web (mot de passe HTTPS également) est décrypté, puis rechiffré sur le proxy d'entreprise et présenté à votre serveur.
Selon qui gère le proxy et la façon dont ses journaux sont utilisés, cela peut être acceptable ou une mauvaise chose de votre point de vue.
Pour plus d'informations sur la façon dont l'interception SSL est effectuée, consultez ceci lien :
Lorsque le proxy SSL intercepte une connexion SSL, il présente un certificat de serveur émulé au navigateur client. Le navigateur client envoie une fenêtre contextuelle de sécurité à l'utilisateur final car le navigateur ne fait pas confiance à l'émetteur utilisé par le ProxySG. Cette fenêtre contextuelle ne se produit pas si le certificat d'émetteur utilisé par le proxy SSL est importé en tant que racine approuvée dans le magasin de certificats du navigateur client.
Le ProxySG rend tous les certificats configurés disponibles au téléchargement via sa console de gestion. Vous pouvez demander aux utilisateurs finaux de télécharger le certificat d'émetteur via Internet Explorer ou Firefox et l'installer en tant qu'autorité de certification de confiance dans le navigateur de leur choix. Cela élimine le popup de certificat pour les certificats émulés ...
Certaines entreprises contournent le problème de pop-up de certificat mentionné ci-dessus en déployant les certificats racine (du proxy) sur chaque poste de travail via GPO. Bien que cela n'affecte que les logiciels qui utilisent le magasin de certificats Microsoft. Des logiciels tels que Firefox et Chrome doivent être mis à jour différemment.
Étant donné que SSL repose sur des autorités de certification (CA) et que pratiquement toute organisation peut devenir une autorité de certification, des attaques de type intermédiaire avec des certificats faux mais signés par une autorité de certification sont toujours possibles. Ainsi, bien que SSL soit encore une énorme amélioration par rapport au non-cryptage, sa sécurité est surévaluée en raison du système de CA défaillant. À cet égard, les certificats auto-signés seraient tout aussi sécurisés que tout certificat signé par une autorité de certification, mais les navigateurs les marquent comme suspects.
SSL est très sécurisé, bien que quelqu'un puisse voler le cookie de session de quelqu'un si vous exécutez N'IMPORTE QUELLE page sur une ligne non chiffrée. Si vous le pouviez, je ferais du site tout SSL. Ou peut-être que le cookie n'envoie que pour les connexions cryptées et que les pages publiques non sécurisées ne sont pas spécifiques à cet utilisateur.
Il y a toujours la possibilité d'une attaque de l'homme du milieu, qui dans votre cas serait l'utilisateur se connectant à un tiers prétendant être votre site et transmettant ensuite la demande. Bien sûr, un utilisateur averti devrait remarquer l'absence de connexion SSL ou le mauvais certificat, mais la plupart des utilisateurs ne sont pas allumés et sont dupés par un favicon de cadenas.
Ce n'est pas vraiment un problème avec SSL lui-même, juste quelque chose à savoir. Vous pouvez supposer en toute sécurité que personne n'est en mesure d'écouter la connexion SSL entre votre site et la source de la connexion. Cependant, vous ne pouvez pas être sûr que la source de la connexion est bien l'utilisateur.
Étant donné que SSL crypte la transmission, aucune donnée ne peut être écoutée (car le certificat est approuvé).
Même si le problème réside sur l'endroit (et combien) vous utilisez SSL dans votre webapp: par exemple, vous avez besoin d'une connexion SSL uniquement pour authentifier votre utilisateur (pour les laisser envoyer des paires utilisateur/passe cryptées à votre serveur) , alors lorsque vous renvoyez un cookie, vous devez savoir qu'il peut être facilement intercepté (comme si votre utilisateur est sur une connexion sans fil non protégée).
Le récent drame FireSheep est tout cela.
Non. Analyse du trafic peut encore en dire long à quelqu'un.
L'analyse du trafic est le processus d'interception et d'examen des messages afin de déduire des informations des modèles de communication. Elle peut être effectuée même lorsque les messages sont cryptés et ne peuvent pas être décryptés. En général, plus le nombre de messages observés, voire interceptés et stockés est important, plus le trafic peut être déduit.
TLS est généralement déployé pour préserver la confidentialité - un attaquant ne devrait pas atteindre un niveau de confiance élevé concernant le contenu de la communication.
En supposant,
- un attaquant connaît votre protocole,
- un attaquant sait qui communique avec qui
- l'attaquant ne peut pas décrypter les messages.
- vous n'obscurcissez pas votre trafic réel dans beaucoup de trafic absurde (paillettes)
Un attaquant peut probablement dire quand vous êtes éveillé et quand vous dormez quel que soit le protocole, et peut en dire beaucoup plus selon la nature du protocole que vous utilisez.
Si votre protocole est très simple:
- Vous envoyez un message "tirez sur les armes nucléaires à ..." lorsque vous voulez tirer des armes nucléaires
- Vous n'envoyez pas de message lorsque vous ne voulez pas tirer d'armes nucléaires.
Un espion qui ne peut pas décrypter vos données peut déterminer par la simple présence d'un message que vous souhaitez tirer des armes nucléaires, mais peut-être pas à qui.
Si votre protocole est plus complexe:
- Vous demandez un livre.
- Je vous envoie le contenu.
Un attaquant peut ne pas être en mesure de dire qui lit "War and Peace" vs "Atlas Shrugged" mais peut distinguer, sur la base uniquement de la taille du message, s'il lit l'un des anciens vs 55 de Kafka roman de la page "La Métamorphose".
SSL effectue deux tâches de base: l'authentification et le cryptage.
L'authentification se fait au moyen d'autorités de certification (CA). Les navigateurs sont livrés avec une liste de certificats SSL pour les clés de signature des autorités de certification. Les autorités de certification signent des certificats qui décrivent la clé publique d'une entité. Par exemple, si je possédais Google.com, je prouverais cela à Verisign et ils signeraient mon certificat pendant un certain temps. Des problèmes surgissent avec une CA qui signe un certificat qu'ils ne devraient pas signer. Cela peut se produire lorsque quelqu'un prétend posséder un autre domaine, acquiert un certificat générique trop large ou simplement XKCDs l'autorité de certification en émettant quelque chose de néfaste (les gouvernements, peut-être?). Nous avons vu des exemples de tout ce qui précède se produire, mais c'est assez rare.
Si un certificat pour un site est correctement signé et qu'aucun faux certificat dans votre chaîne de confiance n'existe, alors lorsque vous vous connectez à un site, vous pouvez (à des fins de discussion) être sûr que le certificat correspond. Dans des circonstances normales, cette connexion est cryptée. Cela empêche quiconque de lire vos données.
Les certificats SSL sont très complexes et un certain nombre d'attaques existent contre les implémentations SSL. Ce que SSL peut effectivement faire, c'est m'empêcher de surveiller votre trafic sur le Starbucks local lorsque vous consultez vos e-mails sur GMail. Ce qu'il ne peut pas faire, c'est m'empêcher d'utiliser une attaque MITM où je vous transmets tout sans SSL et votre client n'est pas configuré pour vous déranger du fait que vous n'avez jamais démarré de session cryptée.
Sans compter les différentes réponses des autres concernant d'autres problèmes potentiels, en supposant que vous utilisez SSL 3.0 et un cryptage fort, il devrait être sécurisé.
L'utilisation d'anciens protocoles SSL (2.0) ou l'utilisation d'une clé de chiffrement faible peut vous ouvrir à des vulnérabilités.
SSL augmente généralement la sécurité en fournissant:
- Authentification du serveur (l'utilisateur sait qu'il parle au site "correct")
- Intégrité des données (l'utilisateur et le serveur savent que le trafic n'est pas modifié en cours de route)
- (facultatif, mais généralement) Confidentialité des données (l'utilisateur et le serveur savent que le trafic n'est pas intercepté en cours de route)
- (facultatif, mais rare) Authentification client, si le client possède également un certificat
Il existe essentiellement deux types de certificats SSL, le certificat serveur (qui est toujours impliqué) et un certificat client (qui est facultatif).
Ce n'est qu'un croquis, et il y a beaucoup de si, et de mais. Dans le scénario le plus typique, SSL basé sur un navigateur, le schéma peut être rompu dans de nombreux cas sans casser la cryptographie ou le protocole, mais simplement en comptant sur l'utilisateur pour faire la mauvaise chose (c'est-à-dire ignorer les avertissements du navigateur et se connecter de toute façon). Les attaques de phishing peuvent également fonctionner en envoyant l'utilisateur vers un faux site protégé par SSL, conçu pour ressembler au vrai à tous égards sauf à l'URL.
Cela dit, SSL et son cousin TLS sont toujours très utiles car ils permettent au moins une communication sécurisée, bien que loin d'être infaillible.
@Vladimir a raison: http://en.wikipedia.org/wiki/Forward_secrecy est souhaitable, mais les détails sont faux. Le serveur a choisi cette suite de chiffrement parmi celles proposées par le navigateur. "chiffré avec RC4_128 avec SHA1 pour l'authentification des messages" utilise le chiffrement RC4 128 bits et le contrôle d'intégrité HMAC-SHA-1. (Les noms Ciphersuite en SSL/TLS disent jusqu'à récemment SHA mais ils signifient SHA-1 et en fait HMAC-SHA-1.) "ECDHE_ECDSA comme mécanisme d'échange de clés" ne s'applique pas aux messages individuels , cela fait partie (la plupart) de la poignée de main qui se produit une fois au début de la session: ECDHE utilise la variante de courbe elliptique de Diffie-Hellman en mode éphémère (plus quelques étapes supplémentaires non importantes ici) pour créer la session clés utilisées pour le chiffrement et HMAC; et l'échange de clés ECDHE (uniquement) est signé par la variante de courbe elliptique de l'algorithme de signature numérique. (Vous ne pouvez jamais chiffrer quoi que ce soit directement avec DH ou ECDH, ils ne font que la clé ou tout autre petit accord secret.)
Lorsque vous n'utilisez pas SSL, toutes les communications peuvent être facilement interceptées - la seule chose à faire est de lancer le renifleur de paquets (c'est-à-dire Wireshark).
SSL empêche cela, tous les paquets sont cryptés, il n'y a donc aucun moyen de savoir ce que vous envoyez. Fondamentalement, il est utilisé pour protéger les mots de passe et le contenu privé contre l'interception. Vous ne voulez évidemment pas que quelqu'un d'autre lise vos e-mails privés, non?
Quant à la recherche Google, ils l'ont simplement fait pour cacher ce que les gens demandent. En effet, certains gouvernements sont trop curieux à ce sujet.
Comment SSL augmente la sécurité? Ce n'est pas en soi. Qu'est-ce que c'est une combinaison de cryptage (clé SSL) et PKI (infrastructure à clé publique) - principalement des certificats. OK, la question était de savoir comment. D'un côté, il sécurise votre canal de communication (voir ci-dessus), d'autre part, il garantit que vous parlez à une entreprise légitime - authentifie le serveur. Le canal est donc sécurisé et fiable.
Il y a pas mal de certificats SSL, comme il y en a pas mal PKI Services . Un service fondamentalement différent nécessite un type de certificat SSL différent. Il existe donc des certificats pour la signature de code, le cryptage et la signature des e-mails, ceux concernant l'authentification du serveur, etc.
Lorsque quelqu'un se connecte avec SSL (https) à notre service et soumet les données d'authentification correctes, est-il sûr de transmettre toutes les données sensibles sur cette ligne, ou peut-il y avoir encore des écoutes?
Le maillon faible de cette chaîne n'est certainement pas SSL mais l'utilisateur, qui peut généralement être amené à se connecter à un faux site intermédiaire soit via l'usurpation Web/l'usurpation d'hyperlien, soit en se voyant présenter un certificat invalide et en rejetant l'avertissement du navigateur et en procédant à connectez quand même.
Cependant, le système que vous décrivez est de toute façon la meilleure pratique, il n'y a pas grand-chose d'autre à faire (à part éduquer vos utilisateurs à prendre les avertissements SSL au sérieux si vous le pouvez).
La réponse courte est non. Réponse plus longue: une collection des réponses ci-dessus plus: si nous résolvons l'authentification, donc l'homme du milieu, qu'avec une connexion SSL traditionnelle, quelqu'un écoutant le trafic pourrait encore le déchiffrer plus tard s'ils obtenaient une clé secrète de serveur (pensez de NSA et lettres de sécurité nationale). Il existe une option dans le protocole TLS pour utiliser le protocole Diffie-Helman pour assurer la liaison en toute confidentialité. Voir l'image suivante lorsque j'accède à gmail.com en utilisant Chrome. 
Regardez le texte RC4_128 avec SHA1 pour l'authentification de message ECDHE_ECDSA. Cela se lit comme suit:
- Le serveur a offert le canal SSL RC4_128b avec SHA digest
- À l'intérieur de ce tunnel, chaque message est chiffré avec des courbes écliptiques où la clé est dérivée à l'aide de la fonction Diffie-Helman et est signée avec le chiffrement des courbes écliptiques à l'aide de l'algorithme de signature numérique
En d'autres termes, même si quelqu'un possède une clé privée du serveur SSL, les messages ont été chiffrés avec des clés temporaires qui sont supprimées de la mémoire peu de temps après leur utilisation. Bonne chance NSA!
Est-ce sûr pour l'utilisateur ou est-il sûr pour vous? Supposons une attaque d'homme au milieu. L'attaquant parvient à capturer le trafic de l'utilisateur, prétend être vous pour l'utilisateur et prétend être l'utilisateur pour vous. Ce type d'attaque échouait généralement, car le certificat remis à l'utilisateur n'était pas correct. Par exemple, l'attaquant remet à l'utilisateur un certificat auto-signé pour votre site Web. Cependant, si l'utilisateur agit stupidement, il peut accepter ce certificat auto-signé. Alors maintenant, l'attaquant peut lire et modifier tout le trafic entre l'utilisateur et vous, et pour autant que je sache, il n'y a aucun moyen pour vous de détecter cela.
Donc, si l'espionnage et la modification du trafic blessent l'utilisateur, c'est vraiment sa faute et son problème. Et vous ne pouvez pas l'empêcher complètement de toute façon, car le MITM peut vous couper complètement et simplement parler à l'utilisateur se faisant passer pour vous. Mais si l'espionnage et la modification du trafic vous blessent, vous devez faire confiance à l'utilisateur pour ne pas être stupide, ou mieux authentifier l'utilisateur également (l'utilisateur aurait besoin d'un certificat, et vous pouvez le vérifier d'une manière que le MITM ne peut pas faux).
Même les versions les plus modernes de HTTPS utilisant TLS peuvent facilement être interceptées par un MitM (par exemple un appareil Juniper configuré à cet effet) si le client fait confiance à l'autorité de certification. Dans ce cas particulier, ce n'est pas sécurisé.
Je pense que les gens ici ne comprennent pas la question:
Si vous avez une ligne non sécurisée et que vous effectuez une connexion SSH/SSL réussie sur cette ligne, il vous demande maintenant si vous pouvez supposer que la ligne est "sécurisée" et que les données non cryptées peuvent être transmises LE LONG DE CÔTÉ avec la connexion cryptée ( par exemple, à la vue de tous, pas à l'intérieur de la connexion SSL/SSH cryptée).
Je dirais non. Dans ce cas, il pourrait y avoir un écouteur passif qui ignore simplement les données chiffrées et enregistre les données non chiffrées.
MAIS vous pouvez être sûr qu'il n'y a pas d'écoute active (MITM), ce qui signifie que vous pouvez établir en toute sécurité une connexion SSL/SSH non authentifiée avec la même source/destination que la ligne authentifiée. Cela n'a fourni aucune écoute sélective que MITM certains connecteurs, MAIS cependant, l'écoute ne peut pas savoir si vous allez authentifier la connexion ou non, donc il ne peut pas savoir quelle connexion au MITM pour échapper à la détection. Le MITMer, s'il MITM, MITM toutes les connexions et espère que les gens cliqueront simplement sur toutes les boîtes de dialogue d'authentification.
Ainsi: si vous vous connectez authentifié à un service SSL de, disons 123.123.123.123 à 24.24.24.24, vous pouvez également connecter en toute sécurité un client SSH de 123.123.123.123 à 24.24.24.24 sans authentifier mutuellement l'empreinte SSH, à condition que vous puissiez faire confiance à tout derrière NAT routeur ou pare-feu de l'autre côté).
Mais même si cela signifie généralement sûr, il y a IS un petit risque qu'un espionne simplement des connexions MITM aléatoires et espère ne pas être détecté, donc puisque vous avez déjà une connexion authentifiée à l'IP cible, pourquoi ne pas utiliser cette connexion authentifiée pour vérifier mutuellement l'empreinte SSH? C'est aussi simple que de poster l'empreinte SSH correcte sur un site Web sécurisé SSL!