Si vous utilisez HTTPS, vos paramètres d'URL seront-ils à l'abri du reniflement?
Supposons que je configure un simple serveur Web PHP avec une page accessible par HTTPS. L'URL a des paramètres simples, comme https://www.example.com/test?abc=123.
Est-il vrai que le paramètre ici dans ce cas sera à l'abri des personnes reniflant les paquets? Et serait-ce vrai si le serveur n'emploie aucun certificat SSL?
Oui, votre URL ne risque pas d'être reniflée; Cependant, un trou qui est facilement négligé est que si votre page fait référence à des ressources tierces telles que Google Analytics, Ajouter du contenu, votre URL entière sera envoyée au tiers dans le référent. S'il est vraiment sensible, il n'appartient pas à la chaîne de requête.
Quant à votre deuxième partie de la question, vous ne pouvez pas utiliser SSL si vous n'avez pas de certificat sur le serveur.
http://answers.google.com/answers/threadview/id/758002.html
HTTPS Établit une connexion SSL sous-jacente avant le transfert des données HTTP. Cela garantit que toutes les données URL (à l'exception du nom d'hôte, qui est utilisé pour établir la connexion) sont transportées uniquement dans cette connexion cryptée et sont protégées contre les attaques de l'homme du milieu de la même manière que toutes les données HTTPS. .
Toutes les transactions de niveau HTTP au sein d'une connexion HTTPS sont effectuées au sein de la session SSL établie et aucune donnée de requête n'est transférée avant l'établissement de la connexion sécurisée.
De l'extérieur, les seules données visibles par le monde sont le nom d'hôte et le port auquel vous vous connectez. Tout le reste est simplement un flux de données binaires qui est crypté à l'aide d'une clé privée partagée uniquement entre vous et le serveur.
Dans l'exemple que vous fournissez, votre navigateur ferait ceci:
- Dérivez le nom d'hôte (et le port si présent) de l'URL.
- Connectez-vous à l'hôte.
- Vérifiez le certificat (il doit être "signé" par une autorité connue, appliqué spécifiquement pour corriger l'adresse IP et le port, et être à jour).
- Le navigateur et le serveur échangent des données cryptographiques et le navigateur reçoit une clé privée.
- La demande HTTP est effectuée et chiffrée avec une cryptographie établie.
- Une réponse HTTP est reçue. Également crypté.
HTTP est un protocole "Application Layer". Il est porté au-dessus de la couche sécurisée. Selon la spécification SSL, établie par Netscape, elle stipule qu'aucune donnée de couche application ne peut être transmise tant qu'une connexion sécurisée n'est pas établie - comme indiqué dans le paragraphe suivant:
"À ce stade, un message de modification de spécification de chiffrement est envoyé par le client et le client copie la spécification de chiffrement en attente dans la spécification de chiffrement actuelle. Le client envoie ensuite immédiatement le message terminé sous les nouveaux algorithmes, clés et secrets. En réponse , le serveur enverra son propre message de modification de spécification de chiffrement, transférera l'attente vers la spécification de chiffrement actuelle et enverra son message terminé sous la nouvelle spécification de chiffrement. À ce stade, la prise de contact est terminée et le client et le serveur peuvent commencer à échanger l'application. données de couche. " http://wp.netscape.com/eng/ssl3/draft302.txt
Donc oui. Les données contenues dans la requête URL sur une connexion HTTPS sont cryptées . Cependant, il est très pauvre d'inclure des données sensibles comme mot de passe dans une demande 'GET'. Bien qu'elles ne puissent pas être interceptées, les données seraient enregistrées dans les journaux du serveur en texte brut sur le serveur HTTPS récepteur, et très probablement également dans historique du navigateur . Il est probablement également disponible pour les plugins de navigateur et peut-être même d'autres applications sur l'ordinateur client. Tout au plus, une URL HTTPS pourrait raisonnablement être autorisée à inclure un ID de session ou une variable similaire non réutilisable. Il ne doit JAMAIS contenir de jetons d'authentification statiques.
Le concept de connexion HTTP est expliqué plus clairement ici: http://www.ourshop.com/resources/ssl_step1.html
L'URI demandé (/ test? Abc = 123) est envoyé au serveur Web dans le cadre de l'en-tête de requête HTTP et donc chiffré.
Cependant, les URL peuvent fuir d'autres manières, généralement des barres d'outils de navigateur Web, des signets et l'envoi de liens à des amis. La publication de données peut être plus appropriée selon le contexte/la sensibilité des données que vous envoyez.
Je pense qu'une connexion HTTPS nécessite un certificat SSL, même auto-généré si vous ne voulez pas en acheter un.
J'espère que ça aidera un peu!
dépend de ce que vous entendez par coffre-fort
SSL crypte l'intégralité de la demande/réponse HTTP, de sorte que l'URL dans la partie GET sera cryptée. Cela n'empêche pas les attaques MITM et la corruption de l'intégrité de la session SSL elle-même. Si un certificat sans autorité est utilisé, cela simplifie les vecteurs d'attaque potentiels.
Les en-têtes de demande REST sont-ils cryptés par SSL?
Est une question similaire.
L'url: s sera stocké à la fois dans les journaux du serveur et dans l'historique du navigateur, donc même s'ils ne sont pas reniflables, ils sont loin d'être sûrs.
Sur le fil, oui. Aux extrémités (navigateur et serveur) pas nécessairement. SSL/TLS est sécurité de la couche de transport . Il cryptera votre trafic entre le navigateur et le serveur. Il est possible côté navigateur de jeter un œil aux données (a BHO par exemple). Une fois qu'il a atteint le côté serveur, il est bien sûr à la disposition du destinataire et n'est aussi sécurisé qu'il le traite. Si les données doivent se déplacer en toute sécurité au-delà de l'échange initial et protégées des regards indiscrets sur le client, vous devriez également regarder sécurité de la couche de message .
Le SSL/TSL est un Transport Layer Security, oui les données peuvent être récupérées avec BHO (comme @JP l'a écrit) ou n'importe quel add-on mais aussi avec des sniffers HTTP "out of browser". Ils lisent la messagerie entre winsock32 et l'application. Le cryptage a lieu dans le winsock32 et non dans le navigateur.
Jetez un œil (cette partie a été tirée de la page d'IEinspector): IEInspector HTTP Analyzer est un outil très pratique qui vous permet de surveiller, tracer, déboguer et analyser HTTP/ [~ # ~] https [~ # ~] trafic en temps réel.