Il est important de comprendre ce que fait et ne fait pas SSL, d'autant plus qu'il s'agit d'une source très courante de malentendus.

• Il crypte le canal
• Il applique un contrôle d'intégrité
• Il fournit une authentification

Donc, le rapide La réponse 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 meilleures que les versions précédentes. Par exemple. SSL 2 était relativement facile à MITM (l'homme au milieu). Donc, d'abord, cela dépend de la version du protocole.
• Le cryptage du canal 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 lotis ... Cependant, SSL prend même en charge un mode de cryptage NULL - c'est-à-dire pas de cryptage du tout, il suffit d'envelopper les requêtes jusqu'au tunnel via le protocole SSL. C'est-à-dire pas de protection. (Ceci est configurable à la fois sur le client et sur le serveur, la suite de chiffrement sélectionnée est le premier ensemble correspondant selon l'ordre configuré).
• L'authentification 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 suffisamment forte, cependant la validité de l'authentification réelle n'est aussi bonne que vos contrôles de validité: vous embêtez-vous même à vérifier le certificat? Assurez-vous sa validité? Chaîne de confiance? Qui l'a délivré? Etc.
• Ce dernier point concernant l'authentification est beaucoup plus simple dans les applications Web, où le client peut facilement visualiser le certificat des serveurs, l'icône de verrouillage est facilement visible, etc. Avec les services Web , 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é tant d'applications mobiles - même si le développeur de l'application s'est souvenu de n'utiliser que TLS entre le téléphone et le serveur, si l'application ne vérifie pas explicitement les certificats, le TLS est cassé.
• Bien qu'il y ait des attaques principalement théoriques sur la cryptographie de SSL, à partir de mon PoV, il est encore assez puissant pour presque toutes les fins, et le sera pendant longtemps.
• Que fait-on réellement des données à l'autre bout? Par exemple. si ses données ultra-sensibles, ou même de carte de crédit, vous ne voulez pas qu'elles soient dans le cache du navigateur, 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'il est explicitement marqué avec l'attribut "secure".

Alors, réponse plus courte? Oui, SSL peut être suffisamment sécurisé, mais (comme pour la plupart des choses) cela dépend de la manière dont vous l’utilisez. :)

Il y a quelques problèmes ici, le principal étant l'authentification. Les deux extrémités doivent être sûres de parler à la bonne personne ou institution pour contrecarrer les attaques de l'homme du milieu. De votre côté, il est essentiel que vous utilisiez 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 clandestines.

L'authentification dans l'autre sens (c'est-à-dire s'assurer que vous parlez à l'utilisateur réel) est généralement gérée en dehors du protocole SSL au niveau de l'application, par exemple, par nom d'utilisateur / mot de passe, openID ou une autre forme de identifiants.

Comme dernière note, il convient de mentionner que lors de la négociation de connexion SSL, le client et le serveur s'accordent sur une suite de chiffrement et le client peut prétendre ne faire que du "cryptage nul", c'est-à-dire , ne cryptez 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 en pratique car les implémentations de serveur n'offrent généralement pas le chiffrement nul comme 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 tous les proxys 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 easvdrop sur votre conversation SSL.

Pour atténuer cela, regardez "l'émetteur" du certificat SSL. Si la connexion SSL passe par un proxy, alors l'émetteur sera celui du proxy. Si vous utilisez une connexion directe, vous verrez alors l'autorité de certification de confiance publique pertinente.

[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é au niveau du proxy d'entreprise et présenté à votre serveur.

Selon qui gère le proxy et comment 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 , voir ce 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 ProxySG. Cette fenêtre contextuelle ne se produit pas si le certificat d'émetteur utilisé par SSL Proxy est importé en tant que racine de confiance dans le magasin de certificats du navigateur client.

Le ProxySG rend tous les certificats configurés disponibles pour 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 de l'installer en tant qu'autorité de certification de confiance dans le navigateur de leur choix. Cela élimine la fenêtre contextuelle de certificat pour certificats émulés ...

Certaines entreprises contournent le problème de la fenêtre contextuelle 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. Les 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 quasiment toute organisation peut devenir une autorité de certification, les attaques man-in-the-middle avec de faux certificats signés par une CA sont toujours possibles. Ainsi, bien que SSL soit toujours une énorme amélioration par rapport au non cryptage du tout, sa sécurité est surfaite en raison du système CA cassé. À cet égard, les certificats auto-signés seraient tout aussi sécurisés que n'importe quel 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 pouviez, je rendrais le site entièrement SSL. Ou peut-être que le cookie ne soit envoyé que pour les connexions cryptées et que des pages publiques non sécurisées ne soient pas spécifiques à cet utilisateur.

Il y a toujours la possibilité d'une attaque de type "man-in-the-middle", qui dans votre cas serait que l'utilisateur se connecte à un tiers prétendant être votre site et transmette 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 activés et se font tromper par un cadenas favicon.

Ce n'est pas vraiment un problème avec SSL lui-même, juste quelque chose dont il faut être conscient. 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.

Puisque SSL crypte la transmission, aucune donnée ne peut être écoutée (puisque le certificat est approuvé).

Bien que le problème réside dans l'endroit (et dans quelle mesure) vous utilisez SSL dans votre application Web: par exemple, par exemple, vous avez besoin d'une connexion SSL uniquement pour authentifier votre utilisateur (pour les laisser envoyer des paires utilisateur / pass cryptées à votre serveur), puis lorsque vous renvoyez un cookie, vous devez être conscient qu'il pourrait être facilement intercepté (comme si votre utilisateur est sur une connexion sans fil non protégée).

Le récent drame FireSheep est tout à ce sujet.

Non. L'analyse du trafic peut encore en dire beaucoup à quelqu'un.

L'analyse du trafic est le processus d'interception et d'examen des messages afin de déduire des informations à partir de modèles de communication. Elle peut être effectuée même lorsque les messages sont chiffrés et ne peuvent pas être déchiffrés. En général, plus le nombre de messages observés, voire interceptés et stockés est élevé, plus le trafic peut en être déduit.

TLS est généralement déployé pour préserver la confidentialité - un l'attaquant ne doit pas atteindre un niveau de confiance élevé sur le contenu de la communication.

En supposant,

1. un attaquant connaît votre protocole,
2. un attaquant le sait qui communique avec qui
3. l'attaquant ne peut pas déchiffrer les messages.
4. 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:

1. Vous envoyez un message "tirez les armes nucléaires sur ..." lorsque vous voulez tirer des armes nucléaires
2. Vous n'envoyez pas message lorsque vous ne voulez pas tirer d’armes nucléaires.

Un espion qui ne peut pas déchiffrer vos données c et déterminez par la simple présence d'un message que vous voulez tirer des armes nucléaires, mais peut-être pas contre qui.

Si votre protocole est plus complexe:

1. Vous demander un livre.
2. Je vous envoie le contenu.

Un attaquant peut ne pas être en mesure de dire qui lit "Guerre et Paix" vs " Atlas Shrugged " mais peut distinguer, en se basant uniquement sur la taille du message, s'ils lisent l'un des romans de 55 pages de l'ancien ou de Kafka" The Metamorphosis ".

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 le prouverais à Verisign et ils signeraient mon certificat pendant un certain temps. Des problèmes surviennent avec un CA signe un certificat qu'il ne devrait pas signer. Cela peut se produire lorsque quelqu'un prétend posséder un autre domaine, acquiert un certificat générique qui est trop large ou simplement XKCD la CA 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 n'existe dans votre chaîne de confiance, 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 faire efficacement, c'est m'empêcher de surveiller votre trafic au Starbucks local lorsque vous vérifiez votre courrier électronique sur GMail. Ce qu'il ne peut pas faire, c'est m'empêcher d'utiliser une attaque MITM où je vous relaie tout sans SSL et votre client n'est pas configuré pour vous déranger sur le fait qu'il n'a jamais démarré une session cryptée.

Sans compter les différentes réponses des autres sur d'autres problèmes potentiels, en supposant que vous utilisez SSL 3.0 et un cryptage fort, cela devrait être sécurisé.

En utilisant des protocoles SSL plus anciens (2.0) ou en utilisant une clé de cryptage faible pourrait vous ouvrir à des vulnérabilités.

SSL augmente généralement la sécurité en fournissant:

1. Authentification du serveur (l'utilisateur sait qu'il parle au site 'correct')
2. L'intégrité des données (l'utilisateur et le serveur savoir que le trafic n'est pas modifié en cours de route)
3. (facultatif, mais généralement) Confidentialité des données (l'utilisateur et le serveur savent que le trafic n'est pas intercepté en route)
4. (facultatif , mais rare) Authentification du client, si le client a aussi un certificat

Il existe essentiellement deux types de certificat SSL, le certificat serveur (qui est toujours impliqué) et un certificat client (qui est facultatif).

Ceci est juste un croquis, et il y a beaucoup de si, et 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.

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 encore y avoir une écoute clandestine?

Le maillon faible de cette chaîne n'est presque certainement pas SSL mais l'utilisateur, qui peut généralement être amené à se connecter à un faux site intermédiaire soit par usurpation de sites Web / hyperliens, soit en se voyant présenter un certificat invalide et en rejetant l'avertissement du navigateur et en procédant quand même à la connexion.

Cependant, le système que vous décrivez est une bonne pratique de toute façon, vous ne pouvez pas faire grand-chose d'autre (à part éduquer vos utilisateurs à prendre les avertissements SSL au sérieux si vous le pouvez).

Lorsque vous n'utilisez pas SSL, toutes les communications peuvent être facilement interceptées - la seule chose à faire est de lancer un renifleur de paquets (par exemple, Wireshark).
SSL empêche cela, tous les paquets sont cryptés donc il y a 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, n'est-ce pas?
En ce qui concerne la recherche Google, ils l'ont simplement fait pour cacher ce que les gens demandent. C'est parce que certains gouvernements sont trop curieux à ce sujet.

Comment SSL augmente la sécurité? Cela ne fonctionne pas tout seul. Ce qui fait 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), de l'autre, il garantit que vous parlez à une entreprise légitime - authentifie le serveur. Le canal est donc sécurisé et fiable.

Il existe un certain nombre de certificats SSL, comme il existe de nombreux services PKI. 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.

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 man-in-the-middle, qu'avec la connexion SSL traditionnelle, quelqu'un qui écoute le trafic pourrait encore le déchiffrer plus tard si ils ont obtenu une clé secrète du serveur (pensez à la NSA et aux lettres de sécurité nationale). Il existe une option dans le protocole TLS pour utiliser le protocole Diffie-Helman pour assurer la liaison de manière confidentielle. Consultez l'image suivante lorsque j'accède à gmail.com à l'aide de Chrome.

Regardez le texte RC4_128 avec SHA1 pour l'authentification de message ECDHE_ECDSA. Ceci se lit comme suit:

1. Le serveur a offert le canal SSL RC4_128b avec le résumé SHA
2. À 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é avec le chiffrement Ecliptic Curves à l'aide de l'algorithme de signature numérique

En d'autres termes, même si quelqu'un a la 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 après utilisation. Bonne chance NSA!

@Vladimir a raison de dire que http://en.wikipedia.org/wiki/Forward_secrecy est souhaitable, mais les détails sont erronés. 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 des suites de chiffrement dans SSL / TLS indiquent 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, il fait partie (la plupart) du poignée de main qui se produit une fois au début de la session: ECDHE utilise la variante Elliptic Curve de Diffie-Hellman en mode éphémère (plus quelques étapes supplémentaires non importantes ici) pour créer les clés de session utilisées pour le chiffrement et HMAC ; et l'échange de clé ECDHE (uniquement) est signé par la variante de courbe elliptique de l'algorithme de signature numérique. (Vous ne pouvez jamais crypter quoi que ce soit directement avec DH ou ECDH, ils ne font que la clé ou un autre petit accord secret.)

Est-ce sans danger pour l'utilisateur ou est-ce sans danger pour vous? Supposons une attaque de type "homme du 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 donné à l'utilisateur ne serait pas correct. Par exemple, l'attaquant donne à 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 le détecter.

Donc, si l'espionnage et la modification du trafic blessent l'utilisateur, c'est vraiment de leur faute et de leur propre 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 qui se fait passer pour vous. Mais si l'espionnage et la modification du trafic vous font mal, alors 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).

Je pense que les gens ici ne comprennent pas la question:

Si vous avez une ligne non sécurisée et que vous établissez une connexion SSH / SSL réussie sur cette ligne, il demande maintenant s'il est sûr de faire l'hypothèse que la ligne est "sécurisée" et que les données non cryptées peuvent être transmises LE LONGS AVEC la connexion cryptée (par exemple, à la vue, pas à l'intérieur de la connexion SSL / SSH cryptée).

Je dirais non. Dans ce cas, il pourrait y avoir une écoute passive qui ignore simplement les données cryptées et enregistre les données non cryptées.

MAIS vous pouvez être sûr qu'il n'y a pas d'espionnage actif (MITM), ce qui signifie que vous pouvez établir en toute sécurité un SSL / non authentifié. Connexion SSH avec la même source / destination que la ligne authentifiée.Cela à condition qu'il n'y ait aucune écoute sélective de certains connecteurs MITM, MAIS cependant, l'espionnage ne peut pas savoir si vous allez authentifier la connexion ou non, il ne peut donc pas savoir à quelle connexion MITM échapper à la détection. Le MITMer, s'il MITM, MITM toutes les connexions et espère que les gens cliquent simplement à travers 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 peut également connecter en toute sécurité un client SSH de 123.123.123.123 à 24.24.24.24 sans authentifier mutuellement l'empreinte digitale SSH, à condition que vous puissiez faire confiance à tout ce qui se trouve derrière le routeur NAT ou le pare-feu de l'autre côté.

Mais même si cela signifie généralement sûr , il y a un petit risque qu'une espionne simplement des connexions MITM aléatoires et espère ne pas être détectée, 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 digitale SSH? C'est simple comme publier l'empreinte digitale SSH correcte sur un site Web sécurisé SSL!

Même les versions les plus modernes de HTTPS utilisant TLS peuvent facilement être interceptées par un MitM (par exemple, un périphérique Juniper configuré à cet effet) si le client fait confiance à l'autorité de certification. Dans ce cas particulier, ce n'est pas sécurisé.