Génération de la clé des exigences pour l'utilisation de TLS ecdhe n'-ECDSA-AES128-GCM-SHA256

Je me demandais si il existe un minimum de clés génération des exigences pour ecdhe n'-ECDSA-AES128-GCM-SHA256 et ecdhe n'-ECDSA-AES128-GCM-SHA256? Je suis en train d'essayer d'obtenir un TLS client et le serveur en utilisant un des algorithmes ci-dessus pour connecter les uns aux autres et continuez à recevoir des "non partagée de chiffrement erreurs". J'ai créé une autorité de certification pour signer le client et le serveur de certificats, et la tentative de connexion avec juste openssl et aussi dans node.js. Je suis en cours d'exécution de la cliengt et server localhost (127.0.0.1) pour éliminer tout autres problèmes possibles.

Voici ce que j'ai fait jusqu'à présent:

CA paire de clés création:

  $ openssl genrsa -out ca-key.pem 4096
  $ openssl req -new -x509 -days 365 -key ca-key.pem -out ca-cert.pem

Serveur /client la paire de clés création:

  $ openssl genrsa -out server-key.pem 4096
  $ openssl req -new -key server-key.pem -out server-csr.pem
  $ openssl x509 -req -days 365 -in server-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem 

  $ openssl genrsa -out client-key.pem 4096
  $ openssl req -new -key client-key.pem -out client-csr.pem
  $ openssl x509 -req -days 365 -in client-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial 02 -out client-cert.pem

J'ai été à l'origine de la tentative de connexion à un node.js serveur à partir de la ligne de commande (tls.createServer() avec les options: algorithmes: 'ecdhe n'-ECDSA-AES256-GCM-SHA384:ecdhe n'-ECDSA-AES128-GCM-SHA256'), mais d'éliminer nœud soupçons je suis tombé en arrière pour openssl pour le client et le serveur de création.

Les commandes suivantes se connecter CORRECTEMENT pour le client et le serveur et déclare que c'est à l'aide d'un algorithme de chiffrement de "Nouvelles, TLSv1/SSLv3, Cipher est ecdhe n'-RSA-AES256-GCM-SHA384":

$ openssl s_server -accept 8888 -cert server-cert.pem -key server-key.pem -pass stdin -CAfile ca-cert.pem  -state
<password entered here>

$ openssl s_client -connect 127.0.0.1:8888 -cert client-cert.pem -key client-key.pem -pass stdin -CAfile ca-cert.pem -state
<password entered here>

Avec le partage de l'algorithme de chiffrement de l'information comme suit:

Shared ciphers:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-R
SA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES2
56-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384
:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-A
ES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECD
H-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH
-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384
:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES
-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA
:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA
:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA2
56:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS
-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256

Les commandes suivantes ne fonctionnent PAS lorsque je spécifie un algorithme de chiffrement sur le serveur ou le client et le serveur. Notez que le ecdhe n'-ECDSA-AES128-GCM-SHA256 de chiffrement est répertorié comme partagé dans la liste ci-dessus.

$ openssl s_server -accept 8888 -cert server-cert.pem -key server-key.pem -pass stdin -CAfile ca-cert.pem -cipher ECDHE-ECDSA-AES128-GCM-SHA256
<password entered here>
<< Server output after client connection attempt >>
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
ERROR
2674688:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353:
shutting down SSL
CONNECTION CLOSED
ACCEPT
$ openssl s_client -connect 127.0.0.1:8888 -cert client-cert.pem -key client-key.pem -pass stdin -CAfile ca-cert.pem -cipher ECDHE-ECDSA-AES128-GCM-SHA256
<password entered here>
<<client output after connection attempt>>
CONNECTED(00000003)
2674688:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:708:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 166 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Quelqu'un a une idée? Merci à l'avance!

Quelle est la version de openssl utilisez-vous? une version d'openssl
Je suis à l'aide d'OpenSSL 1.0.1 14 Mar 2012
Veillez également à utiliser un "le nom de la courbe". Pour plus de détails, voir la Cryptographie à Courbe Elliptique | Named Courbes sur la OpenSSL wiki.

OriginalL'auteur aspergillusOryzae | 2012-04-17

16

Vous de faire le mauvais type de clé avec
```
 openssl genrsa -out ca-key.pem 4096 
```
Vous devez utiliser ecparam
```
openssl ecparam -name secp521r1 -out ca-key.pem -genkey
```
et
```
openssl ecparam -name secp521r1 -out client-key.pem -genkey
```
genrsa génère une clé RSA qui, lorsqu'il est utilisé avec ecdhe n', authentifie les Elliptic Curve Diffie Hellman (ecdhe n').

La ECDSA dans ecdhe n'-ECDSA-AES128-GCM-SHA256 signifie que vous avez besoin de la Elliptic Curve Digital Signature Algorithm pour authentifier que les principaux. Parce que vous n'avez pas ces types de touches, la commande échoue. Cependant, ecdhe n'-RSA-AES256-GCM-SHA384 fonctionne parce qu'il utilise des clés RSA que vous avez.

Vous obtenez sha384, car openssl choisit le plus fort de la suite de chiffrement et toutes choses étant égales sha384 est mieux que sha256. Vous pouvez la remplacer, et il semble que vous l'avez fait avec --cipher.

Remarque vous pouvez utiliser un autre type de courbe. Vous pouvez obtenir la liste complète avec
```
openssl ecparam -list_curves
```
Par curiosité, pourquoi spécifiques de la suite de chiffrement? Ecdhe n', et ECDSA sont l'état de l'art, mais sha256 est juste norme, et bien AES 128 est certainement assez bon, les gens ont tendance à utiliser 256 si ils sont en train d'être aussi prudents que les ecdhe n', et ECDSA trucs implique.

Merci! Qui m'a mis sur la bonne voie. 😀 j'ai choisi ces suites de chiffrement pour correspondre RFC 6460, et doit être ramassé sur le " Acceptable Courbes, une section qui indique à l'aide de secp256r1 ou secp384r1 respectivement. Pour de plus amples informations, je vais poster les commandes que j'ai utilisé dans openssl. J'ai également eu à configurer le demoCA répertoire et son contenu comme indiqué dans le exemples.
J'ai utilisé ce Courbe Elliptique CA guide pour openssl exemples de signer les clés. J'ai dû créer les répertoires mentionnés dans CA exemples avant que je puisse signer quoi que ce soit. J'ai utilisé les commandes suivantes pour tester: openssl s_server -accept 8888 -cert server.cert -key server.key -pass stdin -CAfile ca.cert -cipher ECDHE-ECDSA-AES128-GCM-SHA256 et openssl s_client -connect 127.0.0.1:8888 -cert client.cert -key client.key -pass stdin -CAfile ca.cert -cipher ECDHE-ECDSA-AES128-GCM-SHA256
Pinailler: pour ecdhe n'-ECDSA le serveur de clé, et la clé du client si le client d'authentification est utilisée comme ici, doit être ECC. La clé de l'AC n'est pas nécessaire d'être ECC, RSA fonctionne toujours. Mais les bonnes pratiques dit tout CA la clé doit être au moins aussi fort, les clés de l'signé sous elle, de sorte que (minime) ECC de 256 nécessite RSA>=3072 à l'aide du NIST équivalences.
Pinailler^2: Pour ecdhe n'-ECDSA de chiffrement, la clé de client/cert peut être RSA. Pour l'algorithme de chiffrement RSA, la clé de client/cert peut être ECDSA. La phase de vérification sur le serveur s'attend seulement à arriver à un certificat de confiance, pas nécessairement utiliser le même algorithme de chiffrement. La phase de vérification client est de plus en plus strictes, comme vous l'avez décrit.
vous avez raison; je dois avoir des hallucinations de la journée. Client EE cert&type de clé n'est limitée que par CertificateRequest. Et pour ajouter une ride: dans TLS1.2, qui est plus utilisé aujourd'hui qu'elle ne l'était en 2012, la chaîne d'/CA certificats à partir du serveur sont limitées par le signature_algorithms dans ClientHello, et à partir d'un client par un champ similaire CertificateRequest, mais dans les deux cas pas par ciphersuite.

OriginalL'auteur imichaelmiers

Vous devez vous connecter pour publier un commentaire.