J'ai un écran de connexion que je serais sur SSL. L'utilisateur remplit son identifiant / mot de passe, ceci est affiché sur le serveur. À ce stade, je veux sauter de SSL, alors je les redirige vers la même page sans SSL.
Ceci provoque une boîte de dialogue d'avertissement "Vous êtes sur le point d'être redirigé vers une connexion qui n'est pas sécurisée". Comment puis-je éviter ça? J'ai été beaucoup de sites comme Yahoo Mail et Gmail qui vous donnent une page SSL pour la connexion, puis envoyez-vous une page non SSL après cela.
Question secondaire: Quel est le but de cette boîte de dialogue? Il essaie de m'intervérer un but néfaste - mais ce qui est si grave de rediriger quelqu'un à une page non SSL? Je ne reçois pas un avertissement lorsque je suis sur une page SSL et cliquez sur un lien sans SSL. Ce qui est différent de rediriger quelqu'un?
Je fais cela dans asp.net 2.0 - mais je pense que c'est une question générique de développement Web.
Résumé de la mise à jour : Il semble que la réponse populaire est "n'échante pas ça". Je peux comprendre qu'un utilisateur doit avoir un message lorsque la sécurité est enlevée. Mais je ne reçois pas de boîte de dialogue lorsque je suis un lien et la sécurité est supprimée, alors au moins, je dirais que cela est incohérent.
Les versions de la boîte de dialogue / Navigateur. En fait, je ne vois pas la boîte de dialogue dans IE7 / FF3 (peut-être que j'ai cliqué sur une case à cocher l'empêcher de l'empêcher). Plus important encore, le client le voit dans IE6 - sans cas de coche pour le supprimer (oui, je sais que IE6 est vieille et merde).
Firefox2: FF2 http://img521.imageshack.us/img521/8455/ sslwarning.jpg
IE6: L'alternative: effectuez l'ensemble du site SSL, ne jamais rediriger l'utilisateur de SSL. Je pourrais gérer ça. Mais j'ai un client semi-technique qui a des points assez bons:
Je vais essayer de balancer le client à un site entièrement SSL. Je discuterai de l'approche de Yahoo sur le sens en 1996, ou pour un site beaucoup plus populaire. Quelques liens officiels expliquant pourquoi ce dialogue se produit aiderait (c'est-à-dire le niveau d'authenticité de Jakob Nielsen). 
8 Réponses :
Utilisez SSL pour la page entière en premier!
Il n'y a rien de mal avec SSL. Vous devriez fournir une confidentialité utilisateur partout, non seulement sur la connexion. Cela donne un sens à tout le site. Alors simplement rediriger toutes les pages non-SSL aux pages SSL et garder tout SSL.
Qu'en est-il du cas où le domaine SSL est différent du domaine de l'application? Comme une configuration de type SSO.
Certains pourraient préférer éviter SSL, dans la mesure du possible, car il consomme plus de bande passante (les données cryptées sont généralement plus grandes que son équivalent clairtext), et encourtent et une CPU supplémentaire (pour le processus de cryptage supplémentaire).
@ABIGNALE: Le trafic cryptographique des frais généraux est observé rarement. De plus, la cryptographie est généralement combinée à la compression, donc si vous n'avez pas encore utilisé la compression (par exemple Mod_deflate) avant, la cryptographie pourrait même diminuer le trafic.
@Joel Potter: Si vous n'avez pas de certificat SSL pour votre propre domaine, vous aurez un problème.
Dans la mesure où: il est de vous faire conscience que votre connexion ne sera plus cryptée SSL. Vous avez peut-être vu avant que la connexion soit cryptée et que cela puisse penser qu'elle est toujours, ce qui l'avertisseur dit que "juste pour être clair, quelles que soient les données que vous envoyez d'ici sur le [/ p>. . .
Quant à la façon de le supprimer: Afaik Vous ne pouvez pas, c'est une chose de navigateur, quel serait le point du message autrement? Même s'il y a des contours de contournement comme des redirections côté client, je Ne pensez pas que vous devriez essayer de travailler autour du client "problèmes" comme celui-ci. Si le navigateur choisit d'être verbeux, laissez-le. Case à cocher "Ne pas montrer à cette version" sur la boîte de dialogue après tout si l'utilisateur souhaite supprimer ce message, il peut facilement le faire, et peut-être qu'il aime effectivement le voir.
En outre, IMHO, si le navigateur valait sa peine de sel, il serait toujours apparu cet avertissement, même si vous employiez des tours de redirection côté client.
Case à cocher pour ce dialogue particulier de Firefox, au moins.
"Comment puis-je éviter cela?"
Vous ne devriez pas!
Bien que vous puissiez essayer avec JavaScript. Cela pourrait travailler sur certains navigateurs et échouer sur les autres.
"Quel est le but de cette boîte de dialogue?"
Il avertit car la commutation entre SSL et non SSL sur des sites Web est généralement inattendue par l'utilisateur. Un avertissement sur le "non-SSL à SSL" n'est pas émis car il augmente la sécurité et la confidentialité. Cependant, lorsque la sécurité est soudainement diminuée , l'utilisateur doit le remarquer rapidement, afin d'éviter un faux sentiment de sécurité. En fait, la redirection d'un site non SSL est parfois utilisée dans les attaques XSS / MITM.
"SSL va entraîner une augmentation de la circulation / de la puissance de traitement"
Ceci est un non-sens. Cela pourrait être vrai pour les sites pleins de grand contenu statique. Toutefois, pour les applications Web dynamiques normales, le cryptage est très bon marché par rapport à la logique commerciale, à l'accès à la base de données, etc.
Il y a une légende urbaine disant que la teneur en SSL n'est pas disputée par des navigateurs. Voir " Le contenu du cache de navigateurs Web sur https " pour plus d'informations.
"Yahoo le fait. Yahoo est une grande entreprise technique. Êtes-vous plus intelligent que Yahoo?"
Certaines contre-questions rhétoriques:
Tant que vous pouvez servir votre média statique à partir d'un serveur non-SSL, cela devrait aller bien. Servir des supports statiques sur SSL signifie qu'il ne sera pas mis en cache - rendre l'expérience un peu plus lente sans bonne raison
@Jim Robert: C'est une légende urbaine. Voir: Stackoverflow.com/questions / 174348 / ...
J'ai frappé ce même problème au même moment. J'ai donc eu un look à l'intérieur de Fiddler pour voir comment Yahoo Mail le fait. Voici l'étape que j'ai vue (et utilisée sur mon site):
L'utilisateur remplit le formulaire crypté SSL et les messages sur le serveur. Server authentifie et épine un script pour rediriger le client P>
<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>
Notez simplement que cela dépend de l'actif JavaScript. Je suppose que vous pourriez utiliser une étiquette de redirection méta.
Il y a une bonne raison pour que le navigateur avertit. Vous ne devriez pas le contourner sans comprendre pourquoi il est là en premier lieu. Vous devriez descendre à la racine du problème au lieu de combattre les symptômes.
"Tu ne devrais pas circonstruire sans comprendre" - c'est probablement pourquoi j'ai demandé à ce sujet sur Stackoverflow!
@TesterturnedDeveloper: Je suis tout à fait d'accord. Donc, une réponse devrait expliquer les bonnes raisons de cet avertissement avant suggérant aveuglément des moyens de le contourner.
Cet avertissement ne montre que sur IE6. Il n'y a aucune raison de soutenir cet avertissement. Vous avez toutes les raisons d'essayer de le supprimer si vous le pouvez.
Gmail, Yahoo, etc. Utilisez SSL pour un iframe crypté, qui authentifie, mais rien de la redirection de la page dont vous parlez. La page entière n'est pas cryptée pour ces systèmes de connexion.
Mais alors vous obtenez des messages sur "Cette page contient du contenu sécurisé et insécurisé"
Je pense que la plupart des navigateurs modernes ne montrent que si votre page racine est SSL. Comme il s'agit d'une page non cryptée avec du contenu crypté, cela ne se présente pas.
L'attaque que cela empêche de s'opposer est une bande de session SSL man-in-the-intermédiaire. Le message est là avec une bonne cause.
Pointez simplement votre client sur les dernières attaques contre le contenu en mode mixte (cookeumonster sur FSCKED.ORG) et les attaques de proxy (sur les sites disponibles dans HTTP et HTTPS, LookUp Pretty-Bad-Proxy). Il pourrait reconsidérer.
Il est beaucoup plus facile d'obtenir la sécurité de la sécurité si vous ne faites que traiter un protocole sans mélanger les deux. SSL ajoute un peu de frais généraux, mais ce n'est rien comparé au coût d'une violation.
lire: http://support.microsoft.com/kb/883740 Ce qui dit que cela est corrigé dans un correctif ou avec un paramètre de registre modifié. Cependant, tous les CPU IE6 que nous utilisons ont ce problème, ni que leurs paramètres de registre ne correspondent à ce que cet article dit qu'ils devraient. De plus, certains qui donnent aux MSG sont XPSP3 et IE6 SP3.
Nous avons un écran de connexion HTTPS qui utilise le code pour vous connecter à 15 autres domaines (HTTP) et certains de nos utilisateurs IE6 doivent cliquer sur "Oui" 15 fois. Ceci est inacceptable pour eux. Non, nous ne pouvons pas contrôler quel navigateur tous nos utilisateurs utilisent. Certains ne sont pas compatibles avec la mise à niveau vers IE7.
Nous recherchons un attribut de configuration pour que chaque utilisateur puisse ajuster cela supprimera ce msg. Nous avons présenté de manière identique un navigateur «mauvais» avec des paramètres qui correspondent à celui qui ne donne pas le message. Sécurité Internet et intranet et paramètres avancés et proxies (aucun). Elleso sont des connexions réseau. Pas de joie jusqu'à présent.
Des idées?