¿Necesita un tipo especial de certificado para usar Diffie Hellman como protocolo de intercambio de claves en SSL?

Hay dos formas naturales de hacerlo.

1. La especificación puede identificar un conjunto de grupos predefinidos. Los parámetros de grupo para cada uno están codificados en el software utilizado por ambos puntos finales. La clave pública luego especifica con cuál de esos grupos está diseñado para usarse. En el caso de Diffie-Hellman, los parámetros del grupo son g y p , por lo que el identificador de grupo en la clave pública determina el valor de g . Dado que el identificador de grupo está en la clave pública, está incluido en el certificado.

2. Alternativamente, los parámetros del grupo ( g y p ) pueden incluirse en el certificado, como parte de la clave pública.

De cualquier manera funciona. De cualquier manera, la información en el certificado le permite determinar el valor correcto de g y p para usar. Más allá de eso, no se requiere nada especial.

No necesita un certificado especial para el intercambio de claves efímero Diffie-Hellman, pero necesita el mensaje de intercambio de claves del servidor. Necesita un certificado especial para DH fijo. Como dice la especificación TLS:

• En Sección 7.4.3 :

  The server key exchange message is sent by the server only when
  the server certificate message (if sent) does not contain enough
  data to allow the client to exchange a premaster secret.  This is
  true for the following key exchange methods:

       DHE_DSS
       DHE_RSA
       DH_anon

  It is not legal to send the server key exchange message for the
  following key exchange methods:

       RSA
       DH_DSS
       DH_RSA

     

Significado de este mensaje:

  This message conveys cryptographic information to allow the client
  to communicate the premaster secret: either an RSA public key with
  which to encrypt the premaster secret, or a Diffie-Hellman public
  key with which the client can complete a key exchange (with the
  result being the premaster secret).

• En Apéndice A.5 (sobre conjuntos de cifrado DH no efímeros):

  

Las siguientes definiciones de CipherSuite se utilizan para server-   Autentificado (y opcionalmente autenticado por el cliente) Diffie-Hellman. DH   denota suites de cifrado en las que el certificado del servidor contiene el   Parámetros de Diffie-Hellman firmados por la autoridad de certificación (CA).   [...]

• En Apéndice F.1.1.3 :

  

Cuando se usa el intercambio de claves Diffie-Hellman, el servidor puede suministrar   un certificado que contenga parámetros fijos de Diffie-Hellman o use el   Mensaje de intercambio de claves del servidor para enviar un conjunto de Diffie-Hellman temporal   Parámetros firmados con un certificado DSS o RSA. Parámetros temporales   se procesan con los valores de hello.random antes de firmar para garantizar que   Los atacantes no reproducen los parámetros antiguos. En cualquier caso, el cliente   Puede verificar el certificado o la firma para asegurar que los parámetros   Pertenecen al servidor.

Tenga en cuenta que los certificados con parámetros DH son bastante raros de todos modos.

Stephen Henson (de OpenSSL) dijo lo siguiente (admitido hace mucho tiempo) :

  

He preguntado por todo el lugar y todavía no he visto un solo ejemplo de   un certificado de DH. De esto puedo concluir que no son muy comunes.

Nelson Bolyard (de Mozilla NSS) dijo lo siguiente más recientemente :

  

[...] pregunto porque no conozco NINGUNA CA pública que emita tales problemas   Hoy certs. La última CA que supe de eso fue la CA del Departamento de Defensa de los Estados Unidos que   Certificados emitidos para tarjetas strongzza.

Sospecho que hay poca demanda para estos certificados. Requeriría más trabajo por parte de las AC, es tan fácil de usar EDH hoy en día, y las suites de cifrado que pueden usarlas no son ampliamente compatibles. La la última lista de conjuntos de cifrado compatibles de Java 7 no incluye ninguna DH_RSA o DH_DSS conjuntos de cifrado (solo DH_anon y EDH).