Differences between revisions 1 and 9 (spanning 8 versions)
Revision 1 as of 2008-06-06 19:03:35
Size: 13575
Editor: ?AlejandroImass
Comment:
Revision 9 as of 2008-06-07 23:18:04
Size: 42973
Editor: FranklinPiat
Comment: link to other translations
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language es
## page was renamed from es/SSLKeys
## page was renamed from SSLKeysES
~-Translation(s): [:SSLkeys:English] - [:es/SSLkeys:Español]-~
----
Line 27: Line 32:
In addition, '''any''' DSA key must be considered compromised if it has been used on a machine with a 'bad' OpenSSL. Simply '''using''' a 'strong' DSA key (i.e., generated with a 'good' OpenSSL) to make a connection from such a machine may have compromised it. This is due to an 'attack' on DSA that allows the secret key to be found if the nonce used in the signature is known or reused.
Line 35: Line 39:
Line 73: Line 76:
To fix this, first {{{aptitude update && aptitude upgrade}}} to install the new version of the openssl and libssl0.9.8 packages (the vulnerability is fixed in version 0.9.8c-4etch3 for etch and version 0.9.8g-9 for lenny/sid). You probably want to also pick up the new openssh packages that include the blacklist of known weak keys, but you will need to {{{aptitude dist-upgrade}}} for that in order to install the new openssh-blacklist package.

--------------------------- LLEGUE HASTA AQUI ---------------------------------

If you choose not to use the above aptitude command, note that all of the following packages must be upgraded (they all come from the same source package):
Parra arreglar esto, primero {{{aptitude update && aptitude upgrade}}} para instalar la nueva versión de los paquetes openssl y libssl0.9.8 (la vulnerabilidad está corregida en la versión 0.9.8c-4etch3 para etch y 0.9.8g-9 para lenny/sid). Probablemente querrás recoger los nuevos paquetes openssh que incluyen una lista negra de llaves débiles conocidas, pero vas a tener que {{{aptitude dist-upgrade}}} para poder acceder al nuevo paquete openssh-blacklist.

Si escoges no usar el método aptitude descrito arriba, debes notas que los siguientes paquetes deben ser actualizados (todos vienen del mismo paquete fuente):
Line 82: Line 83:
Then, regenerate and distribute any potentially vulnerable keys. Instructions for how to regenerate the keys for these applications are below. You can also test to see if keys are vulnerable using the {{{dowkd.pl}}} utility as described below.

== How weak? ==
The broken version of OpenSSL was being seeded only by process ID. Due to differences between endianness and sizeof(long), the output was architecture-specific: little-endian 32bit (e.g. i386), little-endian 64bit (e.g. amd64, ia64), big-endian 32bit (e.g. powerpc, sparc). PID 0 is the kernel and PID_MAX (32768) is not reached when wrapping, so there were 32767 possible random number streams per architecture. This is (2^15-1)*3 or 98301.

Non-broken OpenSSL seeds from PID and {{{/dev/urandom}}}.

= Application Details =
Luego, debes regenrar y distribuir cualquier llave potencialmente vulnerable. Las instrucciones para regenerar las llaves para estas aplicaciones están abajo. También puedes probar para determinar si las llaves son vulnerables usando el utilitario {{{dowkd.pl}}} descrito m;as abajo.


== ¿Qué tan Débil? ==
La versión rota de OpenSSL estaba siendo semillada solamente por el número de proceso (PID). Dadas las diferencias entre las terminaciones (endianness) y el tamaño del entero grande (sizeof(long)), el resultado es dependiente de la arquitectura: little-endian 32bit (i386, o arquitecturas en las cuales los bits menos significativos están al final), little-endian 64bit (amd64, ia64), big-endian 32bit (powerpc, sparc o arquitecturas donde los bits más significativos están al final). El PID 0 es el kernel y PID_MAX (32768) no se usa en el vuelco, así que solo hubo 32767 flujos de números aleatorios por arquitectura. Esto es (2^15-1)*3 o 98301.


El OpenSSL que no está roto se semilla tanto del PID como de {{{/dev/urandom}}}.

= Detalles por Aplicación Afectada =
Line 91: Line 94:
Asterisk uses RSA keys as an optional authentication method for IAX2 and for DUNDI. Keys are SSL public/private key pairs. The Asterisk package does not generate keys automatically and most users don't seem to use them. You should probably know if you use such a key. Asterisk usa llaves RSA como método opcional de autenticación para IAX2 y DUNDI. Estas llaves son pares público/privado. El paquete Asterisk no genera estas llaves automáticamente y la mayoría de los usuarios parecen no usarlas. Usted probablemente sabe si está usando una llave de estas.
Line 93: Line 97:
To regenerate your rndc key, do the following. (This is what the postinst script does as well) Para regenerar su llave rndc, haga lo siguientes. (Esto es lo que hace el script de postinst)
Line 99: Line 103:
> I don't know if this is neccessary or not though...
ronalde: According to [http://packages.debian.org/changelogs/pool/main/b/bind9/bind9_9.4.2-10/changelog the changelog for bind9 in Debian] `rndc-confgen` in Debian uses `/dev/urandom` since March 2002 (before then `/dev/random` was used); I guess rndc-keys aren't affected.

Keys for DNSSEC or DynamicDNS are probably weak too and should also be recreated through the use of dnssec-keygen(1). Exactly what parameters to use depends on how you are using the keys. See [http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html Secure DDNS Howto] for some examples for DDNS.
> (comentario original de la página en inglés) No sé si esto es realmente necesario...
ronalde: Según [http://packages.debian.org/changelogs/pool/main/b/bind9/bind9_9.4.2-10/changelog the changelog for bind9 in Debian]
`rndc-confgen` en Debian usa `/dev/urandom` desde Marzo 2002 (incluso antes `/dev/random` era usado); Me imagino que las llaves rndc-keys no se ven afectadas.

Las llaves para DNSSEC o DynamicDNS son probablemente débiles y también deben ser regeneradas a través del uso de dnssec-keygen(1). Exactamente cuales parámetros deben usar depende de cómo está usando las llaves actualmente. Ver [http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html Secure DDNS Howto] para algunos ejemplos con DDNS.
Line 105: Line 110:
See [http://www.debian.org/security/key-rollover/#boxbackup Official Key-Rollover page]. Ver [http://www.debian.org/security/key-rollover/#boxbackup Official Key-Rollover page].
Line 108: Line 113:
For each cfengine host, remove the old keys and generate new keys: Para cada nodo cfengine, remover las llaves viejas y generar las llaves nuevas:
Line 117: Line 122:
Once the keys are regenerated, exchange keys between hosts as necessary to reestablish 2-way trusts. Una vez que las llaves son generadas, intercambie las llaves entre los nodos para reestablecer la confianza en 2 vías.
Line 121: Line 126:

Or
Siga las instrucciones "Generic PEM Generation" y añada un {{{openssl gendh >> mysite.pem}}}.

o
Line 128: Line 134:
and let dpkg generate back an imapd.pem file. y deje que dpkg regenere un archivo imapd.pem
Line 131: Line 138:
Let dpkg generate back an imapd.pem file. Deje que dpkg genere de vuelta un archivo imapd.pem
Line 141: Line 148:
See [http://www.debian.org/security/key-rollover/#cryptsetup Official Key-Rollover page]. Ver [http://www.debian.org/security/key-rollover/#cryptsetup Official Key-Rollover page].
Line 144: Line 151:
As described in /usr/share/doc/csync2/README.Debian Tal y como es descrito en /usr/share/doc/csync2/README.Debian
Line 153: Line 160:
Then the keys must be distributed out to each host prior to running csync2 again. Luego las llaves deben ser re-distribuidas entre cada nodo antes de correr csync2 nuevamente.
Line 156: Line 163:
To find out which certificates/keys are in use, see the directives whose names contain "key_file" or "cert_file" in /etc/imapd.conf.

Generate new private keys and certificates as shown in "Generic PEM Generation" above, then restart the service:
Para determinar cuales certificados están en uso, ver las directivas que sus nombres contengan "key_file" o "cert_file" en /etc/imapd.conf.

Generar nuevas llaves privadas y certificados como se describe en "Generic PEM Generation" arriba, y luego re-inicie el servicio:
Line 163: Line 170:
if you are using version 2.1 (if you are using another version, please examine /etc/init.d for the correct service name) si usted está usando la versión 2.1 (si está usando otra versión, por favor examinar /etc/init.d para el nombre correcto del servicio)
Line 166: Line 173:
Generate a new PEM as shown in "Generic PEM Generation" above (making sure that it is placed in the correct place according to your dovecot configuration, then restart dovecot: {{{ invoke-rc.d dovecot restart }}}.

Or:
Generar un nuevo PEM como se describe en "Generic PEM Generation" arriba (asegurándose que está colocado en el sitios correcto, según su configuración particular de dovecot, y luego reinicie dovecot: {{{ invoke-rc.d dovecot restart }}}.

o:
Line 177: Line 184:
See [http://www.debian.org/security/key-rollover/#dropbear Official Key-Rollover page]. Ver [http://www.debian.org/security/key-rollover/#dropbear Official Key-Rollover page].
Line 180: Line 187:
If TLS is in use, generate a new PEM using {{{/usr/share/doc/exim4-base/examples/exim-gencert --force}}} to get a self-signed certificate. Per default it has a three years expiration duration. Si TLS es en uso, genere un nuevo PEM usando {{{/usr/share/doc/exim4-base/examples/exim-gencert --force}}} para obtener un certificado auto-firmado. Por omisión, el vencimiento es de tres años.
Line 184: Line 191:
See [http://www.debian.org/security/key-rollover/#ftpd-ssl Official Key-Rollover page]. Ver [http://www.debian.org/security/key-rollover/#ftpd-ssl Official Key-Rollover page].
Line 187: Line 194:
This is just a reminder for those who generate PEM encoded certificates. Your site probably has other policies in place about how to manage keys which you should follow. Additionally, you may need to get the certificates signed again by a 3rd party Certificate Authority rather than by using a self-signed certificate as shown below: Este es solo un recordatorio para aquellos que generan certificados codificados con PEM. Su sitio probablemente tiene otras políticas de cómo gerenciar las llaves, que usted debe seguir. Adicionalmente, es probable que tenga que firmar sus certificados de vuelta por un tercero (autoridad certificadora "3rd party Certificate Authority") en vez de usar certificados auto-firmados como se describe a continuación:
Line 195: Line 202:
(The last command (openssl req.....) is all on one line, ending with .pem) (El último comando (openssl req.....) es todo en una sola línea, terminando con .pem)
Line 201: Line 208:
check all keys under /var/cache/gitosis/repositories/gitosis-admin.git/gitosis-export/keydir/*.pub

(older versions of gitosis using /var/cache/git)

== OpenSSH (Server) ==
See also [http://www.debian.org/security/key-rollover/#openssh Official Key-Rollover page].

Updated packages for openssh that have a blacklist of known weak keys are now available; see [http://www.debian.org/security/2008/dsa-1576 DSA 1576] for more information. Installing these packages on hosts with weak keys will cause the ssh server to regenerate its keys. Weak user keys being used for a connection will also be rejected where possible.

/!\ Note that you will have to use {{{aptitude dist-upgrade}}} (or {{{apt-get dist-upgrade}}}) to install these packages rather than just {{{upgrade}}} because this update will cause the new package openssh-blacklist to be installed.

You can also update your openssh-server keys manually.
revise todas las llaves bajo /var/cache/gitosis/repositories/gitosis-admin.git/gitosis-export/keydir/*.pub

(versiones más viejas en /var/cache/git)

== OpenSSH (Servidor) ==
Ver también [http://www.debian.org/security/key-rollover/#openssh Official Key-Rollover page].

Paquetes actualizados para openssh que contienen lista negra de llaves débiles conocidas están disponibles actualmente. ver [http://www.debian.org/security/2008/dsa-1576 DSA 1576] para mayor información. Al instalar estos paquetes en servidores con llaves débiles, causará que el servidor ssh regenere sus llaves automáticamente. Las llaves débiles de clientes que sean usadas para conectarse serán rechadas en lo posible.

/!\ Note que tendrá que usar {{{aptitude dist-upgrade}}} (o {{{apt-get dist-upgrade}}}) para instalr estos paquetes en vez de solo {{{upgrade}}} porque esta actualización hará que el nuevo paquete openssh-blacklist se instale.

Comentario de Alejandro Imass: ¿No será mejor usar apt-pinning para este paquete en particular?

'''AYUDA DE UN EXPERTO''' Receta para apt-pinning del (los) paquetes necesarios para obtener openssh-blacklist.


También puede actualizar sus llaves de openssh-server manualmente.
Line 218: Line 230:
/!\ Note that in either case, your users will see a "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" warning when they next log on to your ssh server because the key has changed. They will need to edit $HOME/.ssh/known_hosts to remove the offending line before continuing; checking that the key fingerprint is correct, of course (the fingerprint of your new key can be found with {{{ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key}}}). You can remove the key from known_hosts by running "ssh-keygen -R hostname"

Also, note that your existing ssh connections shouldn't be interrupted.

== OpenSSH (Client) ==
See also [http://www.debian.org/security/key-rollover/#openssh Official Key-Rollover page].

You will need to have a list of the openssh keys that you currently have and where they have been copied to. For each key that is vulnerable:
/!\ Nota que en cualquier caso, sus usuarios verán la advertencia "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" la próxima vez que entren en su servidor ya que su llave ha cambiado. Deben editar el archivo $HOME/.ssh/known_hosts para remover la línea del problema antes de continuar; revisando que la huella de la llave sea la correcta, claro (la huella de su nueva llave puede ser determinada con {{{ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key}}}). Usted puede remover la llave problemática de known_hosts corriendo "ssh-keygen -R hostname"


Adicionalmente debe notar que sus conexiones actuales de ssh no deben ser interrumpidas.


== OpenSSH (Cliente) ==
Ver también [http://www.debian.org/security/key-rollover/#openssh Official Key-Rollover page].

Debe tener una lista de las llaves openssh que actualmente tiene y a donde han sido copiadas. Para cada llave que sea vulnerable:
Line 231: Line 245:
Replacing {{{rsa}}} by {{{dsa}}} if you prefer dsa keys and replacing {{{filename}}} and {{{hostname}}} with appropriate values.

Also remember to remove compromised keys from your .ssh/authorized_keys file!
Reemplazando {{{rsa}}} por {{{dsa}}} si prefiere llaves ds y reemplazando {{{filename}}} y {{{hostname}}} con los valores apropiados.

También recuerde remover las llaves comprometidas de su archivo .ssh/authorized_keys!
Line 236: Line 250:
Openswan's raw RSA key generation is not vulnerable, as it does not use the openssl library.
This means all connections using authby=rsasigkey are not vulnerable.

X.509 based keys generated by administrators for use with IPsec could be vulnerable if created
on a Debian system using the openssl command (as per documentation)

See [http://www.debian.org/security/key-rollover/#openswan Official Key-Rollover page].
La generación cruda de RSA no es vulnerable, y no usa la librería openssl.

Esto quiere decir que todas las conexiones que usen authby=rsasigkey no son vulnerables.

Las llaves basadas en X.509 por administradores para ser usadas con IPsec pueden ser vulnerables si fueron creadas en un sistema Debian usando el comando openssl (según la documentación).

Ver [http://www.debian.org/security/key-rollover/#openswan Official Key-Rollover page].
Line 245: Line 259:
See [http://www.debian.org/security/key-rollover/#openswan Official Key-Rollover page]. Ver [http://www.debian.org/security/key-rollover/#openswan Official Key-Rollover page].
Line 248: Line 262:
See [http://www.debian.org/security/key-rollover/#openvpn Official Key-Rollover page].

If you're using x509 certificates, you need to create a whole new CA if you generated the CA key with a broken OpenSSL. Even if you CA key isn't compromised, some of the keys of the OpenVPN clients might be. In that case you need to
Ver [http://www.debian.org/security/key-rollover/#openvpn Official Key-Rollover page].

Si está usando certificados x509, debe crear un CA completo si usted generó la llave CA con un OpenSSL roto. Incluso, si su llave CA no está comprometida, algunas de las llaves de los clientes OpenVPN pueden estarlo. En ese caso deberá revocar todos los certificados para esas llaves y añadir el CRL a la configuración de su OpenVPN. Ver [http://openvpn.net/index.php/documentation/howto.html#revoke OpenVPN HOWTO] para mayor información sobre la revocación.

== postfix ==
Genere un nuevo PEM como está descrito en "Generic PEM Generation" arriba (asegurándose que es colocado en el sitio correcto según la configuración particular, y luego reinicie Postfix: {{{ invoke-rc.d postfix restart }}}.

== puppet ==
Ver [http://www.debian.org/security/key-rollover/#puppet Official Key-Rollover page].

== ssl-cert ==
Ver [http://www.debian.org/security/key-rollover/#ssl-cert Official Key-Rollover page].

== telnetd-ssl ==
Ver [http://www.debian.org/security/key-rollover/#telnetd-ssl Official Key-Rollover page].

== tinc ==
Ver [http://www.debian.org/security/key-rollover/#tinc Official Key-Rollover page].

== Tor Onion Router / Hidden Service Keys ==
Ver [http://www.debian.org/security/key-rollover/#tor Official Key-Rollover page].

== encfs ==

Análisis del impacto aún está siendo determinado. Detalles al momento incluyen: enfs usa RNG de libssl para crear una llave de encriptación interna con un poco de post-procesmiento aplicado. La revisión de esa llave contra una pre-calculada en una lista negra como se hace con dowkd.pl puede ser posible cuando esté listo.

Mientras tanto, los sistemas de archivo encriptados que pudieron haber sido creados usando la versión rota de libssl, deben ser considerados vulnerables contra ataques fuera de línea. Cualquier copia de datos localizados en un ambiente no-confiable podrá ser legible tarde o temprano. Si la fecha de creación es desconocida, se puede revisar la versión originadora en la salida del comando encfsctl contra el changelog del paquete encfs, y esto puede proveer algunas pistas, aunque no es absolutamente confiable porque no habían dependencias fuertes en algunas versiones particulares de openssl.

Para garantizar la seguridad, pruebe lo siguiente:

 * Cree otro sistema de archivo con enfs luego de actualizar a la última versión del openssl corregido.
 * Monte el sistema de archivos original y copie la data a la nueva ubicación.
 * Desmonte el sistema de archivos viejo y destruya toda la data con shred.


== xrdp ==
Ver [http://www.debian.org/security/key-rollover/#xrdp Official Key-Rollover page].

== Kerberos (MIT y Heimdal) ==
Si estaba usando Kerberos de MIT puede estar seguro hasta donde hemos podido ver, ya que Kerberos de MIT tiene su propia capa de encriptacion y sus propias funciones de aliatoriedad.

Heimdal usa OpenSSL y su capa de encriptación. Dado esto, es muy posible que usando fuerza bruta se puede obtener la llave de sesión de cualquier tráfico capturado y encriptado con GSSAPI y desencriptarlo retroactivamente.

Si está usando Heimdal, debe cambiar todas las llaves de largo plazo (tales como aquellas en los archivos keytab) que fueron generadas usando la versión vulnerable de OpenSSL.

Esto puede ser realizado usando ''cpw -r <principal>'' desde kadmin. Tome en cuenta que estos -principals- han sido asignados mediante llave-aleatoria y deben ser regenerados también.

'''AYUDA DE UN EXPERTO''' Por favor definir -principals- en este contexto y re-traducir lo de arriba. Est es el texto original:

This can be done using ''cpw -r <principal>'' within kadmin. Take into account that this principals have been randomed-key assigned and should be regenerated as well.

{{{
kadmin/admin
kadmin/hprop
kadmin/changepw
changepw/kerberos
krbtgt/YOUR.REALM
host/SOMEHOST@YOUR.REALM
host/SOMEOTHERHOST@YOUR.REALM}}}

'''Las llaves basadas en claves de usuario deben estar bien'''.

== pwsafe ==

/!\'''NOTA IMPORTANTE''': Estoy dejando los textos originales aquí ya que hay cosas que verdaderamente no entiendo y pareciera que hay incluso errores en el texto. Invito a un experto en pwsafe para que revise y ajuste la traducción y luego borrar la parte en inglés.

First issue: the random seed of the DBs is now the same. More exactly, the random, the salt and the iv. The random is fixed at creation of the DB. Apparently the seed & iv are renewed at every edition of the DB and depend only on a fresh random. Data encryption depend only on hash and seed/iv so even with different random, if the fresh random for seed is the same, the encrypted data is the same. A practical attack against a pwsafe DB is e.g. to construct a generic rainbow with the possible random seeds and your favorite character class. Once done it could attack any pwsafe DB generated with a broken OpenSSL or even edited with a broken OpenSSL (to be confirmed).

/!\ Estoy dejando la palabra '''random''' (valor aleatorio) en varios sitios para que se entienda mejor la traducción.

Primer problema: la semilla aleatoria de las bases de datos es ahora la misma. Más precisamente, la aleatoriedad, la semilla y el iv (el texto original dice '''salt''' pero creo que debería decir '''seed'''). El random se arregla en la creación de la BD. Aparentemente la semilla y el iv son renovados con cada edición de la BD y dependen solamente de un rendom fresco. La encriptación de datos dependen solo de hash y semilla/iv por lo tanto aunque sea un random diferente, si el random para la semilla es el mismo, la data encriptada es la misma. Una ataque práctico contra una BD de pwsafe consistiría, por ejemplo, en construir un arcoiris genérico las posibles semillas aleatorias y su clase de caracteres favorito. Una vez hecho, puedo atacar cualquier BD de pwsafe que haya sido generada usada una versión rota de OpenSSL o tan siquiera editada con una versión tal (a ser confirmado).


Second issue: all nice passwords proposed by pwsafe when creating a new entry are now broken!
So are all the accounts you created around based on those passwords. No matter the DB/user/group/... you are using. Of course no matter how decently you seeded the RANDFILE ~/.rnd (cf man). To rekey your pwsafe, create a new one, import the old one then delete the old one:

Segundo problema: todas las claves nice propuestas por pwsafe cuando se crea una nueva entrada están rotas!
Así mismo, todas las cuentas creadas a partir de estas claves. No importa el BD/user/group/... que esté usando. Por supuesto no importa que tan decentemente haya semillado el RANDFILE ~/.rnd (cf man). Para regenerar las llaves de su pwsafe, cree uno nuevo, importe el viejo y luego bórrelo:

{{{
$ pwsafe -f newdb --create
Enter passphrase for newdb:
Reenter passphrase for newdb:
$ pwsafe -f newdb --mergedb=/home/myself/.pwsafe.dat
Enter passphrase for newdb:
Enter passphrase for /home/myself/.pwsafe.dat:
Merged 247 entries; skipped 0; 0 duplicates.
$ wipe /home/myself/.pwsafe.dat
$ mv newdb /home/myself/.pwsafe.dat
}}}

And if you generated your account passwords with pwsafe, you should renew all those passwords...

Y si generó sus claves de cuentas con pwsafe, debe renovar todas esas claves...

(información de pwsafe obtenida de http://wiki.yobi.be/wiki/Debian_OpenSSL#pwsafe )

== slurm-llnl ==

Remueva los archivos de llaves vulnerables SLURM:
{{{
rm -f /etc/slurm-llnl/slurm.key /etc/slurm.cert
}}}

Generar nuevo par de llaves con los comandos:
{{{
openssl genrsa -out /etc/slurm-llnl/slurm.key 1024
openssl rsa -in /etc/slurm-llnl/slurm.key -pubout -out \
 /etc/slurm-llnl/slurm.cert
}}}
Copiar los archivos de llaves al controlador y el controlador de respaldo y el archivo de certificado en todos los nodos de su cluster, luego reinicie SLURM con el comando:
{{{
invoke-rc.d slurm-llnl restart
}}}

= Re-Emisión de Certificados SSL =
Si usted ha pagado buen dinero para firmar una llave vulnerable con una Autoridad Certificadora (Certificate Authority - CA), hay altas probabilidades que su CA puede re-emitir un certificado de manera gratuita, siempre y cuando toda la información en el CSR sea idéntica al CSR original. Solo debe crear una nueva llave con una versión no vulnerable de OpenSSL, re-crear el CSR con la misma información que la de llave original del CSR, y re-enviar esto a su CA según so política particular de re-emisión.

/!\ Nota del traductor: A continuación está la lista de los CA más conocidos y sus políticas de re-emisión. No estoy traduciendo esto ya que asumo que quien haya firmado un certificado con una autoridad domina el tema de todas formas:

 * Thawte: http://www.thawte.com/reissue/ (Available throughout the lifetime of the certificate.)
 * VeriSign: https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD91&actp=LIST (Limited waiver of revoke & replace fee until June 30th, 2008 according to advisory e-mail)
 * Comodo: Comodo customers should log into their Comodo accounts to submit their new CSR for a free re-issue. Comodo is offering free replacement SSL certificates to any online businesses affected by the security flaw even if the original certificate was provided by another company. Non Comodo customers should visit http://www.instantssl.com/ssl-certificate-support/debian/ssl-certificate-contact.html to apply for their free replacement SSL certificate.
 * GoDaddy: http://help.godaddy.com/topic/234/article/867 GoDaddy calls the process "re-keying", while they call the act of sending you the same signed certificate as your original order a "reissuance". Via the web interface re-keying is only possible within 30 days of the initial order '''but''' email support (ra@godaddy.com) with the GoDaddy account # and certificate(s) domain name(s) and they will issue re-key credits valid for 7 days.
 * ipsCA: Generate a new CSR as if you are purchasing a new certificate, follow through the procedure up until you get to the point where you are required to pay with your credit card. At that point contact support via their email and let them know that you are requesting a revocation and re-issue and include the ticket number of your new CSR request.
 * [https://www.cacert.org/ CAcert]: This is a cost free certification authority. Simply revoke your old certificates and add new ones. (The key has to be created on a fixed machine and ONLY the certification request has to be uploaded!) At the moment the certificate generation will take some time as it seems that many users are re issue there certificate.
 * [https://www.digicert.com Digicert]: Login to Your account to re-issue (free).
 * GeoTrust: https://certs.tucows.com/geotrust_agreements/refund.htm (Available throughout the lifetime of the certificate. Tucows/OpenSRS in this case, but the instructions are generic to any GeoTrust client. (although see next item for RapidSSL certs.)
 * [http://rapidssl.com RapidSSL]: https://products.geotrust.com/geocenter/reissuance/reissue.do . Click the "buy" link for reissuance insurance, and the price quoted should be $0, allowing you to get a free reissue. Otherwise, [http://www.rapidssl.com/ssl-certificate-support/ssl-support-email.asp?AddrTo=TS2 contact support] and request a waiver for payment.

= Probando llaves con ssh-vulnkey =
En los últimos paquetes de openssh-client para etch, se incluye ssh-vulnkey así como una lista negra de llaves vulnerables conocidas. Esta herramienta parece ser similar a dowkd.pl (abajo) aunque está restringida a revisar solo llaves ssh (no implica que dowkd.pl haga mucho más que esto de todas formas).

Ejecute {{{ssh-vulnkey}}} como usuario para revisar su máquina y sus propias llaves.

Ejecute {{{ssh-vulnkey -a}}} como root para revisar todas las llaves de todos los usuarios (así como la llave de la máquina).

Salida de ejemplo:

{{{
ssh-vulnkey -a
Not blacklisted: 2048 fa:2e:1d:a6:84:64:a1:80:c4:31:68:5a:b0:1a:cb:fe /etc/ssh/ssh_host_rsa_key.pub
Not blacklisted: 1024 f4:34:04:85:58:a0:6b:0a:a1:b9:2d:3b:e6:19:5a:76 /etc/ssh/ssh_host_dsa_key.pub
COMPROMISED: 2048 5c:10:8a:c0:55:8c:1f:d9:4b:05:f0:35:0a:0d:2f:5c /home/someuser/.ssh/authorized_keys
Not blacklisted: 2048 a7:b4:3e:41:18:cb:f7:68:5e:4f:ae:30:14:d2:17:fd /home/someuser/.ssh/authorized_keys
}}}

/!\ Nota: la salida es una linea por llave, no se corta en varias líneas como en el wiki.

/!\ Nota: openssh-blacklist-0.1.1 provisto para Debian Etch no incluye huellas digitales RSA de 4096bit o 1024bit. En vez, obtenga el paquete openssh-blacklist-0.3 de Debian Unstable y haga un backport, u obtenga los deb listos para Etch aquí: http://love.hole.fi/atte/openssh-blacklist/


= Probando las llaves usando dowkd.pl =
El equipo de seguridad ha preparado un utilitario para comprobar sus laves y determinar si tienen una huella que coincida con la lista de huellas que se saben son vulnerables. Descargue: [http://security.debian.org/project/extra/dowkd/dowkd.pl.gz dowkd.pl.gz ] ([http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg signature]) /!\ Atención: Esta versión no es la misam que la herramienta original que publicó Florian Weimer. Así que los parches abajo no aplican!

Cambios a la versión original:

 * Nota de copyright añadida
 * Nota mejorada
 * Se añadió salida más detallada (verbose)
 * Mejor revisión para el matcheo tipodellave/longitud
 * Más robusto
 * Se integró soporte PEM (Disponible con la opción archivo)
 * Soporte integrado para los parches abajo (implementación diferente)
 * Se añadió soporte para otros tamaños de llaves

Tal y como yo (Klaus Ethgen) puedo ver, la herramienta hace lo que debe (Versión sha1:027adef3b86991661394b6ab6159d75dde3c3087 0.9). Pero por favor revise usted mismo. Así mismo si alguien cambia el script, por favor informar en esta misma página para no confundir a otros usuarios.

/!\ '''Nota de traductor: esta es una sección que seguramente va a cambiar. Solicito ayuda para mantenerla al día y suguiero que revise la versión original en inglés contínuamente'''

{{{
cd /tmp
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc
gpg --keyserver subkeys.pgp.net --recv-keys 02D524BE
gpg --verify dowkd.pl.gz.asc
gunzip dowkd.pl.gz
}}}
/!\ Note que {{{dowkd.pl}}} puede producir falsos negativas. Desde 2008-05-19, la versión actual de {{{dowkd.pl}}} imprime warnings si un falso negativo es probable, exceptuando si la llave en cuestión ha sido generada en una arquitectura big-endian (ver arriba definición de big-endian). Si tiene dudas, re-genere sus llaves de todas formas.

Use {{{dowkd.pl}}} de las siguientes formas:

== SSH Server Host Key ==
Key is OK:

{{{
perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
}}}
Key is weak:

{{{
perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
localhost: weak key
localhost: weak key
}}}

A remote check based on the keys generated by HD Moore (http://metasploit.com/users/hdm/tools/debian-openssl/ ) is available at http://itsecurity.net. debian_ssh_scan_v3 now includes fingerprints of all weak DSA 1024, RSA 2048 and RSA 4096 bit keys.

Una revisión remota de llaves generada por HD Moore (http://metasploit.com/users/hdm/tools/debian-openssl/ ) está disponible en
http://itsecurity.net. debian_ssh_scan_v3 ahora incluye huellas para todas las llaves débiles DSA 1024, RSA 2048 y RSA 4096 bit.

{{{
root@box:~/debian_ssh_scan_v2# ./debian_ssh_scan_v2.py 10.128.15.110
65536 fingerprints loaded.
10.128.15.110:22 sshd fingerprint 9cf71acb1b0dff0dceef4f755f721e9d VULNERABLE (RSA 2048 bit key, pid 5252)}}}

== Llave SSH de Usuario ==
Para revisar a un usuario (''someuser''):

{{{
perl dowkd.pl user someuser
/home/someuser/.ssh/authorized_keys:1: warning: unparsable line
/home/someuser/.ssh/authorized_keys:3: warning: unparsable line
/home/someuser/.ssh/authorized_keys:4: weak key
/home/someuser/.ssh/authorized_keys:5: weak key
}}}
Notas:

 * Las quejas sobre las líneas 1 y 3 son porque son comentarios.
 * La línea 2 no tiene una llave dsa no-vulnerable pero debería ser reemplazada de todas formas.
 * Las líneas 4 y 5 contienen llaves rsa débiles (nota que tanto las rsa como las dsa son afectas por la vulnerablidad)

Para revisar a todos los usuario:

{{{
perl dowkd.pl user
}}}

 * Si los nombres de los hosts no están hasheados, puede intentar este [http://nerdbynature.de/bits/CVE-2008-0166/ pequeño script] que mostrará los hosts correspondientes también:

{{{
perl dowkd.pl user > /tmp/weak 2>/tmp/weak.err
./gethk.sh /tmp/weak
==== FILE: /root/.ssh/known_hosts:6:
10.0.0.4 ssh-rsa AAAAB3NzaC1[....]

==== FILE: /home/joe/.ssh/known_hosts:13:
10.0.0.1 ssh-rsa AAAAB3NzaC1[....]
}}}


== Llaves PEM (Certificados SSL) ==
Los certificados SSS, también conocidos como llaves PEM, pueden ser utilizados en varias herramientas (Apache + mod SSL, etc.)

El equipo de Ubuntu ha creado un paquete que verifica si los archivos PEM son vulnerables. Yo lo usé contra llaves PEM creadas en un sistema de control vulnerable y efectivamente las resaltó como vulnerables. El paquete se llama "openssl-blacklist". El paquete está disponible [http://security.ubuntu.com/ubuntu/pool/main/o/openssl-blacklist/openssl-blacklist_0.1-0ubuntu0.8.04.1_all.deb aquí]. Puede ser instalado en etch usando dpkg -i --force-all.

openssl-blacklist empaquetado para Debian: attachment:openssl-blacklist_0.1-0%7Edebian-1_all.deb . Creado para etch/stable aunque debe instalar limpiamente en cualquier versión posterior. No estoy cargando esto presentemente en Debian como tal, porque no he revisado si hay alguna otra persona haciendo esto. Para las fuentes firmadas, ver see http://xillion.org/openssl-blacklist/ . -- PaulCannon

Existe una forma de convertir archivos PEM a llaves públicas de tipo SSH, que la herramienta puede procesar. No he verificado este método completamente, viene con información disponible en: http://webjob.sourceforge.net/Files/Recipes/openssl-convert-ssl-key-to-ssh-keypair.txt

{{{
cp /etc/apache/ssl.key/your.keyfile.key ~/.ssh/id_ssl
ssh-keygen -y -f ~/.ssh/id_ssl > ~/.ssh/id_ssl.pub
./dowkd.pl file ~/.ssh/id_ssl.pub}}}
No he determinado aún que tan preciso es este método, pero parece funcionar de forma consistente. Alguien que esté más familiarizado con el funcionamiento de ssh-keygen puede confirmar la confiabilidad de este método. Hacer un script de esta prueba debería ser suficiente.

 . Si el código para generar la llave en su archivo PEM usó el generador de números aleatorios de OpenSSL aunque sea ligeramente diferente de ssh-keygen de openssh, es probable que obtenga llaves igualmente débiles pero que no estén contenidas en la lista negra. No recomendaría cualquier conclusión de este método. -- MarshRay


-------------------------------------- LEGUE HASTA AQUI ------------------------------------------------------


 . Can you tell us how you tested this? We are unable to reproduce your results as none of the keys we generate with the known-weak version of openssl are flagged as being weak by dowkd.pl or dowkd.pl with RichiH's patch (below). Details of how those certificates were generated are below; are you doing the same? -- Stuart''''''Prescott
''' someone who actually understands this tool and its output, please insert details here!'''

 . I don't know what kind of information is being requested, but it seems fairly easy. On first invocation of the tool, it generates a DB file from the "blacklist" contained in the {{{__DATA__}}} section of the script. If the DB exists, it is opened for reading. Once the DB exists, it uses ssh-keygen to retrieve the fingerprint of the public key presented to it by the executor of the script, and compares the fingerprint that it retrieves to the blacklist. If there is a match, then the script prints 'weak key'.
  . This is perhaps irrelevant now -- an earlier version of this tool didn't say "weak key" but just printed the key name. It also completely failed to parse correctly formed authorized_key files. Perhaps it has now been sufficiently refined as to now be understandable. This page has been a work in progress throughout the day and getting the bones of the content here so that it could then be added to by others was the priority. -- Stuart''''''Prescott
I created a patch to parse PEM files. fw told me to look at the Modulus of the RSA key, so I am doing that. Even though I tested more than 20 certificates generated on an affected machine, I did not find a single weak key. This could mean that

 * the list is incomplete
 * I am looking in the wrong place
 * the certificates are not, in fact, affected by this. Note that I did not generate them myself as I do not have any vulnerable hosts left
As I manually verified the results against, I do not think there is an error in my patch. It is worth noting that none of the certs showed any hits when I converted them into SSH format. Please test this and report back to me!

 * The Patch attachment:dowkd.pl.rh.patch.gz is not needed anymore!
To test this for yourself, do this

{{{
#!/bin/sh -e
for i in $(seq 1 100)
do
    openssl genrsa 1024 > server$i.key 2>/dev/null
    echo -e "\n\n\n\n\n\n\n\n\n\n" | \
            openssl req -new -key server$i.key -days 365 -out server$i.req 2>/dev/null
    openssl x509 -req -days 365 -in server$i.req -signkey server$i.key -out server$i.crt 2>/dev/null
    chmod 600 server$i*
    ssh-keygen -y -f server$i.key > server$i.pub 2>/dev/null
    perl dowkd.pl file server$i.pub
    perl dowkd.pl pem server$i.crt
done
}}}
and please post your results.

 . When we were throwing test cases around on #debian (approx 2008-05-14 02:00 UTC for those who have logs), I threw together this script to run on an unpatched etch box. None of the keys were marked as weak by dowkd.pl when tested by either method even though the keys were generated by a known weak version of openssl. I can only conclude that these methods of testing this class of key for weakness must be incorrect. -- Stuart''''''Prescott
  . I think the existing blacklist works only for keys generated with ssh-keygen and a keylength oh 2048 bits. I tried to produce vulnerable keys on a vulenrable system with ssh-keygen and did not get any weak keys as per dowkd.pl for 1024 bits while 2048 bits worked every time. I also tried to generate 2048 bit keys with openssl genrsa and had no success either. I had a look at the generated keys and found that ssh-keygen uses 35 as public exponent while openssl uses 65535. So probably the blacklists don't fit again. Unfortunately this means we cannot use the script for checking keys generated with openssl until we get updated blacklists or a description how these were generated. -- Joachim Ring
The Patch for authorized_keys2 and known_hosts (attachment:dowkd.pl.ke.patch.gz) is not needed anymore. -- Klaus Ethgen

I have hacked a little shell script using the tables from openssl-blacklist from ubuntu which allows the user to check the ssl key of a webhost from remote by just calling "chksslkey hostname". You can find it here: attachment:chksslkey.tar.bz2 -- Michael Holzt

I threw together a little script that combines everyone elses and lets you test a cert, ssl rsa key, pem file, or remote https against the blacklist's. You can find it at [http://www.gokickrocks.us/wp-content/uploads/2008/05/audit-ssl.tar.gz]. Super easy to use, just take a peek at the README. Basic usage is just "chkssl testtype fileorurl". -- Florian Hines

= Scope of the blacklists =

The current official blacklists (in "openssh-blacklist") cover RSA-2048 and DSA-1024 keys as generated on 32-bit little-endian, 64-bit little-endian and 32-bit big-endian systems. That's sufficient to cover users who used the default key length, but not if some of your users decided they wanted a longer keylength. For non-default keys, see "openssh-blacklist-extra" which contains RSA-1024, RSA-4096, and (an empty) DSA-2048 for all three architectures.

 I have made a blacklist for RSA-4096 keys as generated on 32/64-bit little-endian systems and posted it at http://www.red-bean.com/~maxb/ . The 64-bit keys I generated, the 32-bit ones I took from the metasploit site linked earlier on this page. The format is full fingerprints:
  * suitable for appending to dowkd.pl, if you also edit the body of the script so that it tries to check 4096 bit keys too
  * or, if you remove the first 12 characters from each line, suitable for use with ssh-vulnkey
 (There are also RSA-1024 and RSA-1023 versions there, potentially useful for the paranoid evaluation of older keys.) --MaxBowsher

 I used MaxB's RSA-4096 fingerprint list for my unofficial openssh-blacklist-0.1.2, but it seems there is now openssh-blacklist-0.3 in Debian Unstable which includes these, and RSA-1024 which is also missing from the Etch package. I backported it for Debian Etch, grab it from http://love.hole.fi/atte/openssh-blacklist/ or backport yourself. --Atte Peltomäki

= Technical Summary =
(If you want to add more technical details that an end-user doesn't need to know or isn't likely to understand, please add them here rather than making the above summary impossible for the average user to understand.)

== Causes ==
It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. This was done to try to make it easier to debug C applications that use the openssl libraries which is a good thing to do.

A discussion of why this change was made can be found at [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 #363516] and also on the [http://marc.info/?t=114651088900003&r=1&w=2 openssl-dev list]. Judging from the [http://www.links.org/?p=327#comment-176642 discussion there], the main culprit seems to be a misunderstanding about which is the right list to ask this question on, followed by misleading answers from the list.

== A bit more detail ==
In an effort to clear up confusion about this bug, here's a bit more technical description. This was caused by an overzealous, well-intentioned elimination of code that was believed to have no impact on security. (Please do note from the above links that this ''was'' discussed with the !OpenSSL team and that no objections were raised at the time.)

So here's the problem: the Debian maintainer wanted very much to get rid of valgrind errors while using OpenSSL; certainly a noble cause, right? As you can see here, there are two identical lines, {{{ MD_Update(&m, buf, j); }}} in SSL's md_rand.c file that were commented out way back in 2006: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

The second of these is in {{{ ssleay_rand_bytes }}} where {{{ buf }}} is used as an output buffer. It had already been marked as a bad idea when -DPURIFY was in effect, because Purify (and valgrind, naturally) dislike this use of an output buffer as input. This use of {{{ MD_Update }}} is dubious but shouldn't hurt as long as the mixing function of the PRNG is "sufficiently good". The removal of this call to MD_Update should not meaningfully alter the entropy available in the pool -- that is, OpenSSL does not depend upon uninitialized memory for its correct operation.

The first call, however, is in {{{ ssleay_rand_add }}} where {{{ buf }}} is used as an INPUT buffer, to add entropy to the pool. Failing to call {{{ MD_Update }}} there means that the pool will never actually get the entropy intended for it.

= Acknowledgements =
This document was put together by the folks on [:DebianIRC:#debian] to help with user support. It would have been nice to have had the chance to prepare this (and the key rollover page) in the 5 days between the commit being made to pkg-openssl and the DSA being released. Particular credit to themill, dondelelcaro, stew, Maulklin, iobound for reading, writing and suggesting bits for this page. No thanks to the people who keep using the wiki's GUI editor and keep generating 15 to 20 KB diffs from when it randomly reformats the entire page when you only change one line.

= See Also =
http://www.debian.org/security/key-rollover/
----
CategorySystemSecurity

Translation(s): [:SSLkeys:English] - [:es/SSLkeys:Español]


/!\ Esta página no es más que una traducción rápida y de emergencia de: http://wiki.debian.org/SSLkeys . Por favor ir a esa página para obtener la información más actualizada de este tema. . No creo poder mantener esto así que sería bueno si la gente toma la iniciativa de verificar el sitio original en inglés y actualiza esta acorde. Adicionalmente, donde no he podido encontrar traducción posible o sencillamente no entiendo, estoy colocando AYUDA DE UN EXPERTO para que por favor colaboren con sus aclaratorias.


  • ?TableOfContents

En el enlace [http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory 1571] (New openssl packages fix predictable random number generator), el equipo de seguridad de Debian (Debian Security Team) reveló una vulnerabilidad en el paquete openssl que hace que muchas de las claves criptográficas que son utilizadas para autenticación (ej. a través de SSH) o firmado (ej. certificados digitales de servidores web) sean potencialmente vulnerables.

Sumario para el Usuario Final

The scope of the problem includes: El alcance de este problema incluye:

  • llaves débiles tanto para servidores como para clientes (ver sección "Identificando Llaves Débiles Abajo")
  • todos los tipos de llaves generadas usando openssl (esto incluye llaves RSA y DSA)
  • compromiso de otras llaves o claves que hayan sido transmitidas sobre un enlace encriptado que fuese establecido usando las llaves débiles. Nota que este último punto significa que claves transmitidas sobre ssh a un servidor con una llave DSA débil de servidor pudiese estar comprometida también; ver [http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html la reacción del proyecto Debian a esto].

Las siguientes herramientas criptográficas NO se ven afectadas:

  • cryptsetup (ni LUKS ni el común dm-crypt use openssl, el openssl keyscript - que no es usado en las instalaciones por omisión - si usa openssl, pero solo para encriptar la llave, no para generar la llave que es usada para encriptar la partición; quiere decir que la encriptación de la clave puede ser menos fuerte que lo esperado pero la llave como tal, no)

  • GNUTLS
  • GnuPG

Identificando Llaves Débiles

Características de llaves potencialmente vulnerables:

  • Generadas desde 2006-09-17
  • Generadas con Etch, Lenny o Sid (Sarge no es vulnerable)
  • Generadas usando 'openssl', 'ssh-keygen', o 'openvpn --keygen' (GnuPG y GNUTLS no están afectadas)

Adicionalmente cualquier llave DSA debe ser considerada comprometida si ha sido utilizada en una máquina con un OpenSSL 'malo'. Simplemente usando una llave DSA 'fuerte' (generada con un OpenSSL 'bueno') para hacer una conexión desde una máquina que pudo haberse comprometido. Esto es debido a un 'ataque' sobre DSA que permite encontrar la llave privada si el nonce usado en la firma es conocido o reutilizado.

AYUDA DE UN EXPERTO: Por favor aclarar nonce arriba:

De Wikipedia: http://en.wiktionary.org/wiki/nonce nonce (plural nonces) 1. (cryptography) A datum constructed so as to be unique to a particular message in a stream, in order to prevent replay attacks.

Listas negras de llaves vulnerables en unstable:

  • openssh-blacklist
  • openssh-blacklist-extra
  • openssl-blacklist
  • openvpn-blacklist

Muchas listas de claves 'débiles' fueron generadas por el proyecto metasploit: http://metasploit.com/users/hdm/tools/debian-openssl/

Aplicaciones/protocolos que se saben que usan estas llaves:

  • OpenSSH (llaves tanto de servidores como de usuarios)
  • OpenVPN
  • Openswan
  • StrongSWAN
  • DNSSEC
  • Material de llaves para X.509
  • encfs
  • Tor
  • postfix, exim4, sendmail y otros MTAs usando SSL/TLS
  • cyrus imapd
  • courier imap/pop3
  • uw-imapd
  • dovecot con soporte imaps/pops
  • apache2 (ssl certs, ver "Llaves PEM" abajo)
  • dropbear
  • cfengine
  • puppet
  • xrdp
  • tinc
  • gitosis
  • vsftpd SSL certificados para FTPS
  • proftpd SSL/TLS certificados para FTPS
  • ftpd-ssl SSL certificados para FTPS
  • telnetd-ssl SSL certificados para SSL-Telnet
  • ?DomainKeys (DK) y DKIM

Parra arreglar esto, primero aptitude update && aptitude upgrade para instalar la nueva versión de los paquetes openssl y libssl0.9.8 (la vulnerabilidad está corregida en la versión 0.9.8c-4etch3 para etch y 0.9.8g-9 para lenny/sid). Probablemente querrás recoger los nuevos paquetes openssh que incluyen una lista negra de llaves débiles conocidas, pero vas a tener que aptitude dist-upgrade para poder acceder al nuevo paquete openssh-blacklist.

Si escoges no usar el método aptitude descrito arriba, debes notas que los siguientes paquetes deben ser actualizados (todos vienen del mismo paquete fuente):

  • openssl
  • libssl0.9.8
  • libssl-dev

Luego, debes regenrar y distribuir cualquier llave potencialmente vulnerable. Las instrucciones para regenerar las llaves para estas aplicaciones están abajo. También puedes probar para determinar si las llaves son vulnerables usando el utilitario dowkd.pl descrito m;as abajo.

¿Qué tan Débil?

La versión rota de OpenSSL estaba siendo semillada solamente por el número de proceso (PID). Dadas las diferencias entre las terminaciones (endianness) y el tamaño del entero grande (sizeof(long)), el resultado es dependiente de la arquitectura: little-endian 32bit (i386, o arquitecturas en las cuales los bits menos significativos están al final), little-endian 64bit (amd64, ia64), big-endian 32bit (powerpc, sparc o arquitecturas donde los bits más significativos están al final). El PID 0 es el kernel y PID_MAX (32768) no se usa en el vuelco, así que solo hubo 32767 flujos de números aleatorios por arquitectura. Esto es (2^15-1)*3 o 98301.

El OpenSSL que no está roto se semilla tanto del PID como de /dev/urandom.

Detalles por Aplicación Afectada

Asterisk

Asterisk usa llaves RSA como método opcional de autenticación para IAX2 y DUNDI. Estas llaves son pares público/privado. El paquete Asterisk no genera estas llaves automáticamente y la mayoría de los usuarios parecen no usarlas. Usted probablemente sabe si está usando una llave de estas.

BIND9

Para regenerar su llave rndc, haga lo siguientes. (Esto es lo que hace el script de postinst)

rndc-confgen -r /dev/urandom -a

> (comentario original de la página en inglés) No sé si esto es realmente necesario... ronalde: Según [http://packages.debian.org/changelogs/pool/main/b/bind9/bind9_9.4.2-10/changelog the changelog for bind9 in Debian] rndc-confgen en Debian usa /dev/urandom desde Marzo 2002 (incluso antes /dev/random era usado); Me imagino que las llaves rndc-keys no se ven afectadas.

Las llaves para DNSSEC o DynamicDNS son probablemente débiles y también deben ser regeneradas a través del uso de dnssec-keygen(1). Exactamente cuales parámetros deben usar depende de cómo está usando las llaves actualmente. Ver [http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html Secure DDNS Howto] para algunos ejemplos con DDNS.

boxbackup

Ver [http://www.debian.org/security/key-rollover/#boxbackup Official Key-Rollover page].

Cfengine

Para cada nodo cfengine, remover las llaves viejas y generar las llaves nuevas:

rm /var/lib/cfengine2/ppkeys/localhost.priv
rm /var/lib/cfengine2/ppkeys/localhost.pub
/usr/sbin/cfkey
Then restart cfservd:
/etc/init.d/cfengine2 restart

Una vez que las llaves son generadas, intercambie las llaves entre los nodos para reestablecer la confianza en 2 vías.

courier imap/pop3

Follow the "Generic PEM Generation" instructions and add a openssl gendh >> mysite.pem. Siga las instrucciones "Generic PEM Generation" y añada un openssl gendh >> mysite.pem.

o

rm /etc/courier/imapd.pem
dpkg-reconfigure courier-imap-ssl

y deje que dpkg regenere un archivo imapd.pem

uw-imapd

Deje que dpkg genere de vuelta un archivo imapd.pem

cd /etc/ssl/certs
rm `openssl x509 -noout -hash < imapd.pem`.0
rm imapd.pem
dpkg-reconfigure uw-imapd

cryptsetup

Ver [http://www.debian.org/security/key-rollover/#cryptsetup Official Key-Rollover page].

csync2

Tal y como está descrito en /usr/share/doc/csync2/README.Debian

/etc/csync2_ssl*
openssl genrsa -out /etc/csync2_ssl_key.pem 1024
openssl req -new -key /etc/csync2_ssl_key.pem -out /etc/csync2_ssl_cert.csr
openssl x509 -req -days 600 -in /etc/csync2_ssl_cert.csr \
        -signkey /etc/csync2_ssl_key.pem -out /etc/csync2_ssl_cert.pem

Luego las llaves deben ser re-distribuidas entre cada nodo antes de correr csync2 nuevamente.

cyrus imapd

Para determinar cuales certificados están en uso, ver las directivas que sus nombres contengan "key_file" o "cert_file" en /etc/imapd.conf.

Generar nuevas llaves privadas y certificados como se describe en "Generic PEM Generation" arriba, y luego re-inicie el servicio:

invoke-rc.d cyrus21 restart

si usted está usando la versión 2.1 (si está usando otra versión, por favor examinar /etc/init.d para el nombre correcto del servicio)

dovecot

Generar un nuevo PEM como se describe en "Generic PEM Generation" arriba (asegurándose que está colocado en el sitios correcto, según su configuración particular de dovecot, y luego reinicie dovecot:  invoke-rc.d dovecot restart .

o:

rm /etc/ssl/certs/dovecot.pem
rm /etc/ssl/private/dovecot.pem
dpkg-reconfigure dovecot-common

dropbear

Ver [http://www.debian.org/security/key-rollover/#dropbear Official Key-Rollover page].

exim4

Si TLS está en uso, genere un nuevo PEM usando /usr/share/doc/exim4-base/examples/exim-gencert --force para obtener un certificado auto-firmado. Por omisión, el vencimiento es de tres años.

ftpd-ssl

Ver [http://www.debian.org/security/key-rollover/#ftpd-ssl Official Key-Rollover page].

Generic PEM Generation

Este es solo un recordatorio para aquellos que generan certificados codificados con PEM. Su sitio probablemente tiene otras políticas de cómo gerenciar las llaves, que usted debe seguir. Adicionalmente, es probable que tenga que firmar sus certificados de vuelta por un tercero (autoridad certificadora "3rd party Certificate Authority") en vez de usar certificados auto-firmados como se describe a continuación:

cd /etc/ssl/private
openssl genrsa 1024 > mysite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/mysite.pem -x509 -days 9999 -out mysite.pem

(El último comando (openssl req.....) es todo en una sola línea, terminando con .pem)

gitosis

sudo -H -u gitosis gitosis-init < new_SSH_KEY.pub

revise todas las llaves bajo /var/cache/gitosis/repositories/gitosis-admin.git/gitosis-export/keydir/*.pub

(versiones más viejas en /var/cache/git)

OpenSSH (Servidor)

Ver también [http://www.debian.org/security/key-rollover/#openssh Official Key-Rollover page].

Paquetes actualizados para openssh que contienen lista negra de llaves débiles conocidas están disponibles actualmente. ver [http://www.debian.org/security/2008/dsa-1576 DSA 1576] para mayor información. Al instalar estos paquetes en servidores con llaves débiles, causará que el servidor ssh regenere sus llaves automáticamente. Las llaves débiles de clientes que sean usadas para conectarse serán rechadas en lo posible.

/!\ Note que tendrá que usar aptitude dist-upgrade (o apt-get dist-upgrade) para instalr estos paquetes en vez de solo upgrade porque esta actualización hará que el nuevo paquete openssh-blacklist se instale.

Comentario de Alejandro Imass: ¿No será mejor usar apt-pinning para este paquete en particular?

AYUDA DE UN EXPERTO Receta para apt-pinning del (los) paquetes necesarios para obtener openssh-blacklist.

También puede actualizar sus llaves de openssh-server manualmente.

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

/!\ Nota que en cualquier caso, sus usuarios verán la advertencia "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" la próxima vez que entren en su servidor ya que su llave ha cambiado. Deben editar el archivo $HOME/.ssh/known_hosts para remover la línea del problema antes de continuar; revisando que la huella de la llave sea la correcta, claro (la huella de su nueva llave puede ser determinada con ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key). Usted puede remover la llave problemática de known_hosts corriendo "ssh-keygen -R hostname"

Adicionalmente debe notar que sus conexiones actuales de ssh no deben ser interrumpidas.

OpenSSH (Cliente)

Ver también [http://www.debian.org/security/key-rollover/#openssh Official Key-Rollover page].

Debe tener una lista de las llaves openssh que actualmente tiene y a donde han sido copiadas. Para cada llave que sea vulnerable:

cd ~/.ssh
ssh-keygen -t rsa -f filename
ssh-copy-id -i filename hostname 

Reemplazando rsa por dsa si prefiere llaves ds y reemplazando filename y hostname con los valores apropiados.

También recuerde remover las llaves comprometidas de su archivo .ssh/authorized_keys!

OpenSWAN

La generación cruda de RSA no es vulnerable, y no usa la librería openssl.

Esto quiere decir que todas las conexiones que usen authby=rsasigkey no son vulnerables.

Las llaves basadas en X.509 por administradores para ser usadas con IPsec pueden ser vulnerables si fueron creadas en un sistema Debian usando el comando openssl (según la documentación).

Ver [http://www.debian.org/security/key-rollover/#openswan Official Key-Rollover page].

StrongSWAN

Ver [http://www.debian.org/security/key-rollover/#openswan Official Key-Rollover page].

OpenVPN

Ver [http://www.debian.org/security/key-rollover/#openvpn Official Key-Rollover page].

Si está usando certificados x509, debe crear un CA completo si usted generó la llave CA con un OpenSSL roto. Incluso, si su llave CA no está comprometida, algunas de las llaves de los clientes OpenVPN pueden estarlo. En ese caso deberá revocar todos los certificados para esas llaves y añadir el CRL a la configuración de su OpenVPN. Ver [http://openvpn.net/index.php/documentation/howto.html#revoke OpenVPN HOWTO] para mayor información sobre la revocación.

postfix

Genere un nuevo PEM como está descrito en "Generic PEM Generation" arriba (asegurándose que es colocado en el sitio correcto según la configuración particular, y luego reinicie Postfix:  invoke-rc.d postfix restart .

puppet

Ver [http://www.debian.org/security/key-rollover/#puppet Official Key-Rollover page].

ssl-cert

Ver [http://www.debian.org/security/key-rollover/#ssl-cert Official Key-Rollover page].

telnetd-ssl

Ver [http://www.debian.org/security/key-rollover/#telnetd-ssl Official Key-Rollover page].

tinc

Ver [http://www.debian.org/security/key-rollover/#tinc Official Key-Rollover page].

Tor Onion Router / Hidden Service Keys

Ver [http://www.debian.org/security/key-rollover/#tor Official Key-Rollover page].

encfs

Análisis del impacto aún está siendo determinado. Detalles al momento incluyen: enfs usa RNG de libssl para crear una llave de encriptación interna con un poco de post-procesmiento aplicado. La revisión de esa llave contra una pre-calculada en una lista negra como se hace con dowkd.pl puede ser posible cuando esté listo.

Mientras tanto, los sistemas de archivo encriptados que pudieron haber sido creados usando la versión rota de libssl, deben ser considerados vulnerables contra ataques fuera de línea. Cualquier copia de datos localizados en un ambiente no-confiable podrá ser legible tarde o temprano. Si la fecha de creación es desconocida, se puede revisar la versión originadora en la salida del comando encfsctl contra el changelog del paquete encfs, y esto puede proveer algunas pistas, aunque no es absolutamente confiable porque no habían dependencias fuertes en algunas versiones particulares de openssl.

Para garantizar la seguridad, pruebe lo siguiente:

  • Cree otro sistema de archivo con enfs luego de actualizar a la última versión del openssl corregido.
  • Monte el sistema de archivos original y copie la data a la nueva ubicación.
  • Desmonte el sistema de archivos viejo y destruya toda la data con shred.

xrdp

Ver [http://www.debian.org/security/key-rollover/#xrdp Official Key-Rollover page].

Kerberos (MIT y Heimdal)

Si estaba usando Kerberos de MIT puede estar seguro hasta donde hemos podido ver, ya que Kerberos de MIT tiene su propia capa de encriptacion y sus propias funciones de aliatoriedad.

Heimdal usa OpenSSL y su capa de encriptación. Dado esto, es muy posible que usando fuerza bruta se puede obtener la llave de sesión de cualquier tráfico capturado y encriptado con GSSAPI y desencriptarlo retroactivamente.

Si está usando Heimdal, debe cambiar todas las llaves de largo plazo (tales como aquellas en los archivos keytab) que fueron generadas usando la versión vulnerable de OpenSSL.

Esto puede ser realizado usando cpw -r <principal> desde kadmin. Tome en cuenta que estos -principals- han sido asignados mediante llave-aleatoria y deben ser regenerados también.

AYUDA DE UN EXPERTO Por favor definir -principals- en este contexto y re-traducir lo de arriba. Est es el texto original:

This can be done using cpw -r <principal> within kadmin. Take into account that this principals have been randomed-key assigned and should be regenerated as well.

kadmin/admin
kadmin/hprop
kadmin/changepw
changepw/kerberos
krbtgt/YOUR.REALM
host/SOMEHOST@YOUR.REALM
host/SOMEOTHERHOST@YOUR.REALM

Las llaves basadas en claves de usuario deben estar bien.

pwsafe

/!\NOTA IMPORTANTE: Estoy dejando los textos originales aquí ya que hay cosas que verdaderamente no entiendo y pareciera que hay incluso errores en el texto. Invito a un experto en pwsafe para que revise y ajuste la traducción y luego borrar la parte en inglés.

First issue: the random seed of the DBs is now the same. More exactly, the random, the salt and the iv. The random is fixed at creation of the DB. Apparently the seed & iv are renewed at every edition of the DB and depend only on a fresh random. Data encryption depend only on hash and seed/iv so even with different random, if the fresh random for seed is the same, the encrypted data is the same. A practical attack against a pwsafe DB is e.g. to construct a generic rainbow with the possible random seeds and your favorite character class. Once done it could attack any pwsafe DB generated with a broken OpenSSL or even edited with a broken OpenSSL (to be confirmed).

/!\ Estoy dejando la palabra random (valor aleatorio) en varios sitios para que se entienda mejor la traducción.

Primer problema: la semilla aleatoria de las bases de datos es ahora la misma. Más precisamente, la aleatoriedad, la semilla y el iv (el texto original dice salt pero creo que debería decir seed). El random se arregla en la creación de la BD. Aparentemente la semilla y el iv son renovados con cada edición de la BD y dependen solamente de un rendom fresco. La encriptación de datos dependen solo de hash y semilla/iv por lo tanto aunque sea un random diferente, si el random para la semilla es el mismo, la data encriptada es la misma. Una ataque práctico contra una BD de pwsafe consistiría, por ejemplo, en construir un arcoiris genérico las posibles semillas aleatorias y su clase de caracteres favorito. Una vez hecho, puedo atacar cualquier BD de pwsafe que haya sido generada usada una versión rota de OpenSSL o tan siquiera editada con una versión tal (a ser confirmado).

Second issue: all nice passwords proposed by pwsafe when creating a new entry are now broken! So are all the accounts you created around based on those passwords. No matter the DB/user/group/... you are using. Of course no matter how decently you seeded the RANDFILE ~/.rnd (cf man). To rekey your pwsafe, create a new one, import the old one then delete the old one:

Segundo problema: todas las claves nice propuestas por pwsafe cuando se crea una nueva entrada están rotas! Así mismo, todas las cuentas creadas a partir de estas claves. No importa el BD/user/group/... que esté usando. Por supuesto no importa que tan decentemente haya semillado el RANDFILE ~/.rnd (cf man). Para regenerar las llaves de su pwsafe, cree uno nuevo, importe el viejo y luego bórrelo:

$ pwsafe -f newdb --create
Enter passphrase for newdb: 
Reenter passphrase for newdb: 
$ pwsafe -f newdb --mergedb=/home/myself/.pwsafe.dat
Enter passphrase for newdb: 
Enter passphrase for /home/myself/.pwsafe.dat: 
Merged 247 entries; skipped 0; 0 duplicates.
$ wipe /home/myself/.pwsafe.dat
$ mv newdb /home/myself/.pwsafe.dat

And if you generated your account passwords with pwsafe, you should renew all those passwords...

Y si generó sus claves de cuentas con pwsafe, debe renovar todas esas claves...

(información de pwsafe obtenida de http://wiki.yobi.be/wiki/Debian_OpenSSL#pwsafe )

slurm-llnl

Remueva los archivos de llaves vulnerables SLURM:

rm -f /etc/slurm-llnl/slurm.key /etc/slurm.cert

Generar nuevo par de llaves con los comandos:

openssl genrsa -out /etc/slurm-llnl/slurm.key 1024
openssl rsa -in /etc/slurm-llnl/slurm.key -pubout -out \
        /etc/slurm-llnl/slurm.cert

Copiar los archivos de llaves al controlador y el controlador de respaldo y el archivo de certificado en todos los nodos de su cluster, luego reinicie SLURM con el comando:

invoke-rc.d slurm-llnl restart

Re-Emisión de Certificados SSL

Si usted ha pagado buen dinero para firmar una llave vulnerable con una Autoridad Certificadora (Certificate Authority - CA), hay altas probabilidades que su CA puede re-emitir un certificado de manera gratuita, siempre y cuando toda la información en el CSR sea idéntica al CSR original. Solo debe crear una nueva llave con una versión no vulnerable de OpenSSL, re-crear el CSR con la misma información que la de llave original del CSR, y re-enviar esto a su CA según so política particular de re-emisión.

/!\ Nota del traductor: A continuación está la lista de los CA más conocidos y sus políticas de re-emisión. No estoy traduciendo esto ya que asumo que quien haya firmado un certificado con una autoridad domina el tema de todas formas:

Probando llaves con ssh-vulnkey

En los últimos paquetes de openssh-client para etch, se incluye ssh-vulnkey así como una lista negra de llaves vulnerables conocidas. Esta herramienta parece ser similar a dowkd.pl (abajo) aunque está restringida a revisar solo llaves ssh (no implica que dowkd.pl haga mucho más que esto de todas formas).

Ejecute ssh-vulnkey como usuario para revisar su máquina y sus propias llaves.

Ejecute ssh-vulnkey -a como root para revisar todas las llaves de todos los usuarios (así como la llave de la máquina).

Salida de ejemplo:

ssh-vulnkey -a
Not blacklisted: 2048 fa:2e:1d:a6:84:64:a1:80:c4:31:68:5a:b0:1a:cb:fe /etc/ssh/ssh_host_rsa_key.pub
Not blacklisted: 1024 f4:34:04:85:58:a0:6b:0a:a1:b9:2d:3b:e6:19:5a:76 /etc/ssh/ssh_host_dsa_key.pub
COMPROMISED: 2048 5c:10:8a:c0:55:8c:1f:d9:4b:05:f0:35:0a:0d:2f:5c /home/someuser/.ssh/authorized_keys
Not blacklisted: 2048 a7:b4:3e:41:18:cb:f7:68:5e:4f:ae:30:14:d2:17:fd /home/someuser/.ssh/authorized_keys

/!\ Nota: la salida es una linea por llave, no se corta en varias líneas como en el wiki.

/!\ Nota: openssh-blacklist-0.1.1 provisto para Debian Etch no incluye huellas digitales RSA de 4096bit o 1024bit. En vez, obtenga el paquete openssh-blacklist-0.3 de Debian Unstable y haga un backport, u obtenga los deb listos para Etch aquí: http://love.hole.fi/atte/openssh-blacklist/

Probando las llaves usando dowkd.pl

El equipo de seguridad ha preparado un utilitario para comprobar sus laves y determinar si tienen una huella que coincida con la lista de huellas que se saben son vulnerables. Descargue: [http://security.debian.org/project/extra/dowkd/dowkd.pl.gz dowkd.pl.gz ] ([http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg signature]) /!\ Atención: Esta versión no es la misam que la herramienta original que publicó Florian Weimer. Así que los parches abajo no aplican!

Cambios a la versión original:

  • Nota de copyright añadida
  • Nota mejorada
  • Se añadió salida más detallada (verbose)
  • Mejor revisión para el matcheo tipodellave/longitud
  • Más robusto
  • Se integró soporte PEM (Disponible con la opción archivo)
  • Soporte integrado para los parches abajo (implementación diferente)
  • Se añadió soporte para otros tamaños de llaves

Tal y como yo (Klaus Ethgen) puedo ver, la herramienta hace lo que debe (Versión sha1:027adef3b86991661394b6ab6159d75dde3c3087 0.9). Pero por favor revise usted mismo. Así mismo si alguien cambia el script, por favor informar en esta misma página para no confundir a otros usuarios.

/!\ Nota de traductor: esta es una sección que seguramente va a cambiar. Solicito ayuda para mantenerla al día y suguiero que revise la versión original en inglés contínuamente

cd /tmp
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc
gpg --keyserver subkeys.pgp.net --recv-keys 02D524BE
gpg --verify dowkd.pl.gz.asc
gunzip dowkd.pl.gz

/!\ Note que dowkd.pl puede producir falsos negativas. Desde 2008-05-19, la versión actual de dowkd.pl imprime warnings si un falso negativo es probable, exceptuando si la llave en cuestión ha sido generada en una arquitectura big-endian (ver arriba definición de big-endian). Si tiene dudas, re-genere sus llaves de todas formas.

Use dowkd.pl de las siguientes formas:

SSH Server Host Key

Key is OK:

perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9

Key is weak:

perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9
localhost: weak key
localhost: weak key

A remote check based on the keys generated by HD Moore (http://metasploit.com/users/hdm/tools/debian-openssl/ ) is available at http://itsecurity.net. debian_ssh_scan_v3 now includes fingerprints of all weak DSA 1024, RSA 2048 and RSA 4096 bit keys.

Una revisión remota de llaves generada por HD Moore (http://metasploit.com/users/hdm/tools/debian-openssl/ ) está disponible en http://itsecurity.net. debian_ssh_scan_v3 ahora incluye huellas para todas las llaves débiles DSA 1024, RSA 2048 y RSA 4096 bit.

root@box:~/debian_ssh_scan_v2# ./debian_ssh_scan_v2.py 10.128.15.110
65536 fingerprints loaded.
10.128.15.110:22 sshd fingerprint 9cf71acb1b0dff0dceef4f755f721e9d VULNERABLE (RSA 2048 bit key, pid 5252)

Llave SSH de Usuario

Para revisar a un usuario (someuser):

perl dowkd.pl user someuser
/home/someuser/.ssh/authorized_keys:1: warning: unparsable line
/home/someuser/.ssh/authorized_keys:3: warning: unparsable line
/home/someuser/.ssh/authorized_keys:4: weak key
/home/someuser/.ssh/authorized_keys:5: weak key

Notas:

  • Las quejas sobre las líneas 1 y 3 son porque son comentarios.
  • La línea 2 no tiene una llave dsa no-vulnerable pero debería ser reemplazada de todas formas.
  • Las líneas 4 y 5 contienen llaves rsa débiles (nota que tanto las rsa como las dsa son afectas por la vulnerablidad)

Para revisar a todos los usuario:

perl dowkd.pl user

perl dowkd.pl user > /tmp/weak 2>/tmp/weak.err
./gethk.sh /tmp/weak
==== FILE: /root/.ssh/known_hosts:6:
10.0.0.4 ssh-rsa AAAAB3NzaC1[....]

==== FILE: /home/joe/.ssh/known_hosts:13:
10.0.0.1 ssh-rsa AAAAB3NzaC1[....]

Llaves PEM (Certificados SSL)

Los certificados SSS, también conocidos como llaves PEM, pueden ser utilizados en varias herramientas (Apache + mod SSL, etc.)

El equipo de Ubuntu ha creado un paquete que verifica si los archivos PEM son vulnerables. Yo lo usé contra llaves PEM creadas en un sistema de control vulnerable y efectivamente las resaltó como vulnerables. El paquete se llama "openssl-blacklist". El paquete está disponible [http://security.ubuntu.com/ubuntu/pool/main/o/openssl-blacklist/openssl-blacklist_0.1-0ubuntu0.8.04.1_all.deb aquí]. Puede ser instalado en etch usando dpkg -i --force-all.

openssl-blacklist empaquetado para Debian: attachment:openssl-blacklist_0.1-0%7Edebian-1_all.deb . Creado para etch/stable aunque debe instalar limpiamente en cualquier versión posterior. No estoy cargando esto presentemente en Debian como tal, porque no he revisado si hay alguna otra persona haciendo esto. Para las fuentes firmadas, ver see http://xillion.org/openssl-blacklist/ . -- PaulCannon

Existe una forma de convertir archivos PEM a llaves públicas de tipo SSH, que la herramienta puede procesar. No he verificado este método completamente, viene con información disponible en: http://webjob.sourceforge.net/Files/Recipes/openssl-convert-ssl-key-to-ssh-keypair.txt

cp /etc/apache/ssl.key/your.keyfile.key ~/.ssh/id_ssl
ssh-keygen -y -f ~/.ssh/id_ssl  > ~/.ssh/id_ssl.pub
./dowkd.pl file ~/.ssh/id_ssl.pub

No he determinado aún que tan preciso es este método, pero parece funcionar de forma consistente. Alguien que esté más familiarizado con el funcionamiento de ssh-keygen puede confirmar la confiabilidad de este método. Hacer un script de esta prueba debería ser suficiente.

  • Si el código para generar la llave en su archivo PEM usó el generador de números aleatorios de OpenSSL aunque sea ligeramente diferente de ssh-keygen de openssh, es probable que obtenga llaves igualmente débiles pero que no estén contenidas en la lista negra. No recomendaría cualquier conclusión de este método. -- ?MarshRay


LEGUE HASTA AQUI


  • Can you tell us how you tested this? We are unable to reproduce your results as none of the keys we generate with the known-weak version of openssl are flagged as being weak by dowkd.pl or dowkd.pl with RichiH's patch (below). Details of how those certificates were generated are below; are you doing the same? -- StuartPrescott

someone who actually understands this tool and its output, please insert details here!

  • I don't know what kind of information is being requested, but it seems fairly easy. On first invocation of the tool, it generates a DB file from the "blacklist" contained in the __DATA__ section of the script. If the DB exists, it is opened for reading. Once the DB exists, it uses ssh-keygen to retrieve the fingerprint of the public key presented to it by the executor of the script, and compares the fingerprint that it retrieves to the blacklist. If there is a match, then the script prints 'weak key'.

    • This is perhaps irrelevant now -- an earlier version of this tool didn't say "weak key" but just printed the key name. It also completely failed to parse correctly formed authorized_key files. Perhaps it has now been sufficiently refined as to now be understandable. This page has been a work in progress throughout the day and getting the bones of the content here so that it could then be added to by others was the priority. -- StuartPrescott

I created a patch to parse PEM files. fw told me to look at the Modulus of the RSA key, so I am doing that. Even though I tested more than 20 certificates generated on an affected machine, I did not find a single weak key. This could mean that

  • the list is incomplete
  • I am looking in the wrong place
  • the certificates are not, in fact, affected by this. Note that I did not generate them myself as I do not have any vulnerable hosts left

As I manually verified the results against, I do not think there is an error in my patch. It is worth noting that none of the certs showed any hits when I converted them into SSH format. Please test this and report back to me!

  • The Patch attachment:dowkd.pl.rh.patch.gz is not needed anymore!

To test this for yourself, do this

for i in $(seq 1 100)
do
    openssl genrsa 1024 > server$i.key 2>/dev/null
    echo -e "\n\n\n\n\n\n\n\n\n\n" | \
            openssl req -new -key server$i.key -days 365 -out server$i.req 2>/dev/null
    openssl x509 -req -days 365 -in server$i.req -signkey server$i.key -out server$i.crt 2>/dev/null
    chmod 600 server$i*
    ssh-keygen -y -f server$i.key > server$i.pub 2>/dev/null
    perl dowkd.pl file server$i.pub
    perl dowkd.pl pem server$i.crt
done

and please post your results.

  • When we were throwing test cases around on #debian (approx 2008-05-14 02:00 UTC for those who have logs), I threw together this script to run on an unpatched etch box. None of the keys were marked as weak by dowkd.pl when tested by either method even though the keys were generated by a known weak version of openssl. I can only conclude that these methods of testing this class of key for weakness must be incorrect. -- StuartPrescott

    • I think the existing blacklist works only for keys generated with ssh-keygen and a keylength oh 2048 bits. I tried to produce vulnerable keys on a vulenrable system with ssh-keygen and did not get any weak keys as per dowkd.pl for 1024 bits while 2048 bits worked every time. I also tried to generate 2048 bit keys with openssl genrsa and had no success either. I had a look at the generated keys and found that ssh-keygen uses 35 as public exponent while openssl uses 65535. So probably the blacklists don't fit again. Unfortunately this means we cannot use the script for checking keys generated with openssl until we get updated blacklists or a description how these were generated. -- Joachim Ring

The Patch for authorized_keys2 and known_hosts (attachment:dowkd.pl.ke.patch.gz) is not needed anymore. -- Klaus Ethgen

I have hacked a little shell script using the tables from openssl-blacklist from ubuntu which allows the user to check the ssl key of a webhost from remote by just calling "chksslkey hostname". You can find it here: attachment:chksslkey.tar.bz2 -- Michael Holzt

I threw together a little script that combines everyone elses and lets you test a cert, ssl rsa key, pem file, or remote https against the blacklist's. You can find it at [http://www.gokickrocks.us/wp-content/uploads/2008/05/audit-ssl.tar.gz]. Super easy to use, just take a peek at the README. Basic usage is just "chkssl testtype fileorurl". -- Florian Hines

Scope of the blacklists

The current official blacklists (in "openssh-blacklist") cover RSA-2048 and DSA-1024 keys as generated on 32-bit little-endian, 64-bit little-endian and 32-bit big-endian systems. That's sufficient to cover users who used the default key length, but not if some of your users decided they wanted a longer keylength. For non-default keys, see "openssh-blacklist-extra" which contains RSA-1024, RSA-4096, and (an empty) DSA-2048 for all three architectures.

  • I have made a blacklist for RSA-4096 keys as generated on 32/64-bit little-endian systems and posted it at http://www.red-bean.com/~maxb/ . The 64-bit keys I generated, the 32-bit ones I took from the metasploit site linked earlier on this page. The format is full fingerprints:

    • suitable for appending to dowkd.pl, if you also edit the body of the script so that it tries to check 4096 bit keys too
    • or, if you remove the first 12 characters from each line, suitable for use with ssh-vulnkey

    (There are also RSA-1024 and RSA-1023 versions there, potentially useful for the paranoid evaluation of older keys.) --?MaxBowsher

    I used MaxB's RSA-4096 fingerprint list for my unofficial openssh-blacklist-0.1.2, but it seems there is now openssh-blacklist-0.3 in Debian Unstable which includes these, and RSA-1024 which is also missing from the Etch package. I backported it for Debian Etch, grab it from http://love.hole.fi/atte/openssh-blacklist/ or backport yourself. --Atte Peltomäki

Technical Summary

(If you want to add more technical details that an end-user doesn't need to know or isn't likely to understand, please add them here rather than making the above summary impossible for the average user to understand.)

Causes

It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. This was done to try to make it easier to debug C applications that use the openssl libraries which is a good thing to do.

A discussion of why this change was made can be found at [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 #363516] and also on the [http://marc.info/?t=114651088900003&r=1&w=2 openssl-dev list]. Judging from the [http://www.links.org/?p=327#comment-176642 discussion there], the main culprit seems to be a misunderstanding about which is the right list to ask this question on, followed by misleading answers from the list.

A bit more detail

In an effort to clear up confusion about this bug, here's a bit more technical description. This was caused by an overzealous, well-intentioned elimination of code that was believed to have no impact on security. (Please do note from the above links that this was discussed with the !OpenSSL team and that no objections were raised at the time.)

So here's the problem: the Debian maintainer wanted very much to get rid of valgrind errors while using OpenSSL; certainly a noble cause, right? As you can see here, there are two identical lines,  MD_Update(&m, buf, j);  in SSL's md_rand.c file that were commented out way back in 2006: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

The second of these is in  ssleay_rand_bytes  where  buf  is used as an output buffer. It had already been marked as a bad idea when -DPURIFY was in effect, because Purify (and valgrind, naturally) dislike this use of an output buffer as input. This use of  MD_Update  is dubious but shouldn't hurt as long as the mixing function of the PRNG is "sufficiently good". The removal of this call to MD_Update should not meaningfully alter the entropy available in the pool -- that is, OpenSSL does not depend upon uninitialized memory for its correct operation.

The first call, however, is in  ssleay_rand_add  where  buf  is used as an INPUT buffer, to add entropy to the pool. Failing to call  MD_Update  there means that the pool will never actually get the entropy intended for it.

Acknowledgements

This document was put together by the folks on [:] to help with user support. It would have been nice to have had the chance to prepare this (and the key rollover page) in the 5 days between the commit being made to pkg-openssl and the DSA being released. Particular credit to themill, dondelelcaro, stew, Maulklin, iobound for reading, writing and suggesting bits for this page. No thanks to the people who keep using the wiki's GUI editor and keep generating 15 to 20 KB diffs from when it randomly reformats the entire page when you only change one line.

See Also

http://www.debian.org/security/key-rollover/


CategorySystemSecurity