2017-03-21 3 views
0

Je viens de tester ce serveur HTTPS j'ai trouvé sur le site de l'agent:connexion détection est cryptée (ou non)

const https = require("https"); 
const fs = require("fs"); 

const options = { 
    "key": fs.readFileSync("key.pem"), 
    "cert": fs.readFileSync("cert.pem") 
}; 

server = https.createServer(options, (req, res) => { 
    res.writeHead(200); 
    res.write("Hello!"); 
    res.end(); 
}); 

server.listen(8000); 

J'ai créé les deux fichiers de certificats auto-signés avec OpenSSL:

openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out cert.pem 

il fonctionne très bien, je peux me connecter avec un navigateur et un avertissement de certificat (car il est auto-signé) et cliquez-trhough pour accepter la page quand même. Ce dont j'ai besoin n'est pas l'authentification client ou serveur, juste le chiffrement! Je ne vais pas me connecter au serveur avec un navigateur, ce n'est que le début d'un projet plus long et il y aura un client personnalisé qui sait que le serveur n'est pas authentifié et ignorer cette lacune.

Mes problèmes concernent le cryptage. Est-il un moyen de dire côté serveur, si la connexion a été effectivement cryptée avec succès? Ou, détecter si la connexion a pas crypté comme promis?

Répondre

1

Le default cipher suites configuration prend en charge uniquement les suites de chiffrement qui fournissent un chiffrement puissant. Cela signifie que si une connexion a été établie, le cryptage de la suite de chiffrement choisie sera appliqué.

Cependant, vous devez forcer l'utilisation de TLS 1.2 afin de prévenir les attaques de déclassement du protocole par le options:

const options = { 
    "key": fs.readFileSync("key.pem"), 
    "cert": fs.readFileSync("cert.pem"), 
    "secureProtocol": "TLSv1_2_method" 
}; 
+0

Malheureusement, je travaille aussi avec mono sur linux. Avec '" secureProtocol ":" TLSv1_2_method "' les downgrades vers 'TLSv1/SSLv3' ne sont pas autorisés. Je comprends que cela aide contre les vulnérabilités. Mais ils sont surtout liés à l'authentification du serveur, que je n'utilise pas de toute façon. Le client mono ne se connecte pas hors de la boîte car il ne prend pas en charge 'TLSv1.2'. Est-ce qu'une rétrogradation vers 'AES256-SHA version TLSv1/SSLv3' est nécessaire pour le cryptage? Je suis seulement intéressé à éviter l'usurpation de paquets d'intercepter des informations d'identification. Est-ce si mauvais si j'omets la ligne et permet une rétrogradation? – pid

+0

Une attaque de «downgrade de protocole» n'affecterait pas le serveur. La seule charge utile critique est le pré-hachage du mot de passe SHA256 envoyé au serveur. Un attaquant serait juste capable de lire la réponse ('CRED', ce qui signifie erreur d'identifiants) dans ** ses propres paquets (!) **, mais rien de plus du serveur. A peut être totalement faux, mais j'ai l'impression que les vulnérabilités sont pertinentes pour le web, où les utilisateurs peuvent suivre des liens vers des sites Web imposteurs montrant des faux certificats. Mais s'il n'y a pas de liens? Pas de certificat à exposer? Juste des paquets pour protéger de l'écoute? ... s'il vous plaît éclairer moi :) – pid

+0

Vous êtes sûr si vous supposez qu'un attaquant est passif (peut seulement observer des paquets). Si un attaquant est actif (peut déposer et manipuler des paquets), il peut rétrograder la connexion TLS 1.0 à la connexion SSLv3 et utiliser d'autres attaques pour déchiffrer les textes chiffrés observés via des attaques de type padding (pour les modes CBC) ou RC4). –