2010-02-01 7 views
3

J'ai été chargé de trouver un remplacement pour un ancien code. Je suppose qu'il a été testé pour voir si le navigateur prend en charge le cryptage 128 bits. Voici l'ancien code: (je volontairement diviser le lien en 4 lignes)

http://www.verisign.com/update-cgi/outPage.exe
?good=../docs/html/good.html
&nsbad=../docs/html/upgradeNSonly.html
&ie2=../docs/html/upgradeIEonly.html

Avez-vous vu tous ce code avant?
Comment puis-je dupliquer cette fonctionnalité dans une page php?

Comment puis-je tester un navigateur pour voir s'il prend en charge le cryptage 128 bits?

Précision
Le vieux webmaster trouvé un lien vers verisign que cela a fait la vérification du navigateur. Verisign a depuis cessé de supporter ce lien. Personnellement, je pense que nous devrions simplement dire à nos clients de cliquer sur le Aide> A propos de à l'intérieur du navigateur et de chercher la force de chiffrement. Si ce n'est pas au moins 128 alors nous leur disons simplement de mettre à jour leur navigateur.

Répondre

1

Tous les navigateurs modernes prennent en charge le cryptage 128 bits prêt à l'emploi. Avez-vous besoin de prendre en charge les navigateurs plus anciens que IE 5.5?

Vous pouvez vérifier la chaîne User-Agent du navigateur et faire des hypothèses, ou vous pouvez les diriger vers une page qui utilise un certificat SSL 128 bits et s'ils continuent à le faire .. bien, ils doivent le supporter.

+0

@CalebD - Merci de m'avoir indiqué "Keep it Simple Stupid". J'ai décidé de rester simple et montrer aux clients comment vérifier la force de chiffrement de leur navigateur par leurs propres moyens. –

0

Tous les navigateurs modernes prennent en charge 128 bits. Toutefois, vous devez appliquer ce côté serveur de manière administrative car quelqu'un pourrait utiliser un navigateur plus ancien ou forger une requête pour utiliser un niveau de cryptage de niveau inférieur (par exemple 40 ou 56).

Je vous suggère de demander comment configurer le serveur Web à l'appliquer en fonction de votre plate-forme à:

http://serverfault.com

1

Les trucs que vous avez collé ici est pas de code - son URL.

Si vous ne comprenez pas la différence alors je m'attends à ce que vous ne compreniez pas vraiment la réponse à la question implicite «comment mesurez-vous la qualité de cryptage en php? Tout d'abord, il est impossible de tester si un navigateur prend en charge un algorithme de chiffrement particulier ou une taille de clé autre que de tester la connexion à l'aide de cette méthode de chiffrement. Cela signifie donc configurer plusieurs niveaux de chiffrement différents sur votre serveur et la création de pages Web dans chacun d'eux puis de tester à quoi le navigateur peut se connecter. Ce n'est pas une tâche insignifiante, et ce n'est pas quelque chose que la plupart des gens rencontreraient dans leur vie normale. Si vous utilisez mod_ssl sur apache, combiné avec mod_php (vous n'avez pas dit quel OS/webserver fonctionne dans PHP), alors vous pourrez voir toutes sortes de variables $ _SERVER supplémentaires, y compris "SSL_CIPHER" , « SSL_CIPHER_USEKEYSIZE », « SSL_CIPHER_ALGKEYSIZE » et « SSL_SERVER_A_KEY »

Voir aussi

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#envvars

Alors, vraiment, je pense que vous posez la mauvaise question, mais je ne peux pas dire ce que la bonne question est jusqu'à vous pouvez répondre à cette question:

Qu'attendez-vous pour savoir si un navigateur prend en charge l'encodage 128 bits?

C.

+0

Notre site Web ne prend en charge que les navigateurs dotés d'un cryptage 128 bits ou supérieur. Si le navigateur de notre client ne prend pas en charge ce niveau de cryptage, je dois poster un message lui indiquant d'aller mettre à jour son navigateur. Je pense que la chose la plus facile à faire est de faire en sorte que le client clique sur l'aide et cherche la force de chiffrement. –

+0

Vous pouvez essayer de mettre un iframe https dans une page http et essayer de détecter s'il charge (éventuellement en présentant du javascript dans l'iframe) - mais je suspecte que la plupart des navigateurs traitent ces origines différentes donc isolent les 2 frames. Certes, un appel Ajax à une page https à partir d'une page http ne fonctionnera pas.Les cookies seraient transférés entre http et https afin que vous puissiez essayer de déposer un cookie de http, en essayant de le détecter dans l'iframe https puis en traitant les résultats sur une page suivante en utilisant une session. – symcbean

1

Dans SSL, le client se connecte et envoie la liste des chiffrements qu'il prend en charge; alors le serveur sélectionne l'un des chiffrements qu'il supporte également, et ce chiffrement est utilisé pour la connexion. Ce n'est que lorsque la connexion est établie (le "handshake" est terminé) HTTP entrent en jeu. Dans votre configuration, cela signifie que vous devez configurer votre serveur SSL pour accepter une variété de chiffrements, mais privilégier ceux avec une clé privée de 128 bits ou plus par rapport aux autres. Ainsi, un chiffrement inférieur à 128 bits sera sélectionné uniquement si aucun chiffrement à 128 bits ou plus n'est supporté par le client et le serveur. Ensuite, la page envoyée dans cette connexion serait modifiée, en fonction du chiffrement effectivement négocié.

Pour une telle configuration, vous devez être en mesure de faire ce qui suit:

  • pour configurer la liste des chiffrements pris en charge par le serveur SSL;
  • pour appliquer la préférence du serveur à la préférence du client, dans la liste des chiffrements pris en charge par le client et le serveur;
  • pour accéder au chiffrement réellement utilisé à partir de votre moteur de génération de page, par ex. PHP.

Dans Apache mod_ssl, il semble que le point 1 est facile (directive « SSLCipherSuite ») et la section intitulée « Variables d'environnement » semble indiquer que le serveur SSL est prêt à donner des informations sur ce chiffre a été sélectionné pour la page générant le moteur; en particulier, la variable SSL_CIPHER_USEKEYSIZE semble assez bonne. Donc le point 3 semble facile aussi. Je ne suis pas sûr de savoir comment cela se traduit dans le monde PHP, cependant.

Pour le point 2, c'est un peu plus difficile. La documentation de "SSLCipherSuite" semble indiquer que le serveur, par défaut, utilise son propre ordre de préférence, donc le point 2 serait facile aussi, mais cela nécessiterait un peu de test.

Maintenant, il ne reste qu'un point mineur, qui est l'état de 3DES. Nominalement, il utilise une clé de 192 bits. Tout cryptographe ou programmeur décent rappellerait que sur ces 192 bits, seulement 168 bits sont utilisés (les bits supplémentaires étaient censés servir de bits de contrôle de parité, mais personne ne les vérifie, ils sont simplement ignorés). Maintenant, certains universitaires ont également montré que la force réelle de l'algorithme est plus faible, quelque peu équivalente à une clé de 112 bits, du moins lorsqu'elle est vue dans la lumière académique appropriée. Le NIST (l'institution fédérale américaine qui traite de telles normes) a donc émis une recommandation selon laquelle 3DES devrait être considéré comme offrant «seulement 112 bits de sécurité», et 112 est inférieur à 128.

Bien sûr, 112 bits est encore loin dans le domaine de la technologie infaisable (et devrait le rester pendant au moins 30 ans, même si le progrès technologique continue son rythme effréné), donc ce n'est pas un vrai problème pour toute situation pratique, mais si vous êtes dans un cadre d'esprit standard-maniaque et souhaitent imposer "128" bits "réels" alors c'est une question à considérer.

Questions connexes