est-il possible d'envoyer un message sur https qui n'est pas crypté? Par exemple, exigez que la validation et l'autorisation de certificat se produisent, mais ne cryptez pas les données réelles envoyées sur la prise?
4 Réponses :
Non, le protocole ne le permet pas.
Une solution que vous pouvez effectuer est de vous connecter via HTTPS, de vérifier la connexion, puis de supprimer les connexions suivantes à HTTP avec un cookie de session. Sans ce cookie, redirige vers HTTPS afin que le client se connecte toujours dessus.
Cela pourrait ne pas être pertinent pour vous, cependant, si vous fournissez plus d'informations sur le problème que vous essayez de résoudre, nous pourrions avoir plus d'aide.
Oui, TLS et SSL Support des modes "No-cryptage". Si le client et le serveur en question sont configurés pour activer est un problème distinct.
Il est possible, bien que peu probable, qu'un serveur pourrait activer l'une de ces suites ciphères par défaut. Ce qui est plus probable, c'est qu'un serveur permettrait à des suites ciphères faibles (comme les «exportation»-grade des suites basées sur la grade) par défaut. C'est pourquoi vous devriez examiner attentivement la liste blanche du serveur de suites Cipher et Ne laissez que quelques algorithmes de confiance et largement pris en charge. < / p>
Vous pouvez utiliser la suite TLS_SA_WITH_NULL_SHA CIPHER, entre autres, pour protéger l'authenticité et l'intégrité du trafic, sans cryptage.
Le "RSA" dans ce cas fait référence à l'algorithme d'échange de clé, tandis que "SHA" fait référence à l'algorithme d'authentification de message utilisé pour protéger le trafic d'être modifié. "NULL" est l'algorithme de cryptage ou, dans ce cas, le manque de cryptage.
Il est important de réaliser que le trafic, bien que ce ne soit pas crypté, est regroupé dans les enregistrements SSL. Le client et le serveur doivent être activés SSL.
Si vous recherchez une solution progressive lorsque certaines données sont échangées sur SSL sur SSL, SSL est désactivé, mais le trafic d'applications se poursuit également, mais gardez à l'esprit qu'il offre absolument aucune sécurité pour le trafic ClearText ; Il peut être altéré par un attaquant. Donc, par exemple, authentifier avec SSL, puis descendre à un protocole "en clair" pour recevoir des commandes utilisant l'authentification négociée via SSL serait dangereuse.
Bonjour, j'ai une question sur OpenSSL, voudriez-vous jeter un coup d'oeil avec l'adresse suivante?. Stackoverflow.com/Questions/2542156/OPENSSL-SSL-CENGRICTION
Je pense que vous pouvez.
Mais ce serait stupide, vous perdrez le point de l'authentification et laissez-vous être exposé à des attaquants pouvant intercepter et modifier vos paquets.
La vie privée et l'intégrité sont deux choses différentes. Vous pouvez utiliser TLS sans intimité; Les attaquants pourraient lire vos paquets, mais vous sauriez si elles ont modifié un paquet.
@erickson Je ne connais pas SSL et ce sont les enfants assez bien, mais pourquoi voudriez-vous utiliser Hash cryptographique sur vos données de transit et ne pas simplement le crypter?
Je n'ai pas eu de demande pour cela moi-même. Je voudrais simplement souligner que SSL peut protéger contre la modification de paquets sans fournir de la confidentialité et que le cryptage simple n'est pas suffisant pour empêcher la modification des paquets.
@erickson, il est trop large d'un sujet pour discuter ici. En bref, mon avis est que pour l'intégrité, il n'est pas nécessaire d'utiliser les pouvoirs magiques de la cryptographie, ni la magie sombre qui est SSL. L'authenticité est autre chose d'ailleurs, et vous pouvez obtenir une meilleure authenticité et une meilleure sécurité, si vous utilisez les puissances complètes de SSL. Une autre chose, un cryptage simple (tant que fait correctement) est plus suffisant pour se défendre contre l'altération.
Une utilisation pour TLS avec authentification mais pas le cryptage serait de permettre aux caches transparents de cacher vos données non privées. Cela serait particulièrement utile avec les vidéos ou le système d'exploitation de l'ISO. En outre, le cryptage sans authentification ne protège pas contre l'alternance du tout (bien que sans doute, le cryptage sans authentification n'est pas "fait correctement").
Les spécifications SSL / TLS définissent un "chiffre null" que vous pouvez utiliser pour cela. La plupart des logiciels client et serveur désactivent-le pour des raisons évidentes.
Cependant, si vous écrivez votre propre logiciel, vous pourrez peut-être convaincre votre bibliothèque de la négocier.
Je suis un peu curieux comment cela serait utilisé? Pourquoi ne pas simplement utiliser une autre méthode d'authentification? Pour moi, il semble que c'est tout ce que vous voulez, l'authentification d'un hôte valide .. haussement d'épaules
La question n'a pas de sens, car HTTTPS est une version sécurisée de HTTP Off Off Off Off Off Standard Port 443. Le standard dicte que toutes les autorisations / authentification / authentification de certificat s'appliquent à ce protocole HTTPS. Et de toute façon, tout message envoyé via HTTPS est crypté. Pouvez-vous clarifier ce que vous essayez de faire?
Ah, je ne veux en fait pas utiliser cela. Je veux juste m'assurer que si j'utilise le protocole HTTPS, je n'ai pas à dire au serveur de le crypter. De cette façon, je peux faire confiance à ce que les données sont cryptées si j'utilise HTTPS.
@ Tommieb75 Je n'utilise pas non plus le port standard 443 - Je suis à 7002. Est-ce que cela applique toujours la norme de cryptage dans ce cas?
@bkritzer: Dans votre cas, si le HTTPS est exécuté du port 7002, alors oui, le cryptage est toujours appliqué. Voyez ici sur Wikipedia à propos de HTTPS Protocol en.wikipedia.org/wiki/http_secure