path: root/portuguese/security/key-rollover/index.wml

#use wml::debian::template title="Substituição de Chaves"
#use wml::debian::translation-check translation="5011f532637dc7820b79b151eecfda4ab65aa22f" maxdelta="1"

<p>
No <a href="$(HOME)/security/2008/dsa-1571">Alerta de Segurança Debian 1571</a>,
o Time de Segurança do Debian revelou uma falha no gerador de números
aleatórios usado pelo OpenSSL no Debian e seus derivados. Como resultado desta
falha, certas chaves criptográficas são muito mais comuns do que elas deveriam
ser, de tal forma que um atacante poderia adivinhar a chave através de um
ataque de força bruta com conhecimento mínimo do sistema. Isto afeta
particularmente o uso de chaves criptográfica no OpenSSH, OpenVPN e
certificados SSL.
</p>

<p>
Esta página documento como realizar os procedimentos de substituição de
chaves para pacotes cujas chaves foram afetadas pela vulnerabilidade do
OpenSSL.
</p>

<ul>
<li><b><a href="#openssh">OpenSSH</a></b></li>
<li><b><a href="#openssl">OpenSSL: instruções para geração de chave PEM
    genérica</a></b></li>

<li><a href="#bincimap">bincimap</a></li>
<li><a href="#boxbackup">boxbackup</a></li>
<li><a href="#cryptsetup">cryptsetup</a></li>
<li><a href="#dropbear">dropbear</a></li>
<li><a href="#ekg">ekg</a></li>
<li><a href="#ftpd-ssl">ftpd-ssl</a></li>
<li><a href="#gforge">gforge</a></li>
<li><a href="#kerberos">MIT Kerberos (krb5)</a></li>
<li><a href="#nessus">Nessus</a></li>
<li><a href="#openswan">OpenSWAN / StrongSWAN</a></li>
<li><a href="#openvpn">OpenVPN</a></li>
<li><a href="#proftpd">Proftpd</a></li>
<li><a href="#puppet">puppet</a></li>
<li><a href="#sendmail">sendmail</a></li>
<li><a href="#ssl-cert">ssl-cert</a></li>
<li><a href="#telnetd-ssl">telnetd-ssl</a></li>
<li><a href="#tinc">tinc</a></li>
<li><a href="#tor">tor</a></li>
<li><a href="#xrdp">xrdp</a></li>
</ul>

<p>
Outros softwares usam chaves criptográficas, mas
<a href="notvuln">não são vulneráveis</a> pois o OpenSSL não é usado para
gerar ou trocar suas chaves.
</p>

<ul>
<li><a href="notvuln#ckermit">ckermit</a></li>
<li><a href="notvuln#gnupg">GnuPG</a></li>
<li><a href="notvuln#iceweasel">Iceweasel</a></li>
<li><a href="notvuln#mysql">MySQL</a></li>
</ul>

<p>
Para instruções de substituição de chaves para outros softwares, você pode
estar interessado em checar as informações enviadas por usuários em
<url https://wiki.debian.org/SSLkeys> (em inglês).
</p>

<h1><a name="openssh">OpenSSH</a></h1>

<p>
Um pacote atualizado já foi lançado via
<a href="$(HOME)/security/2008/dsa-1576">DSA-1576</a>, que facilita a
transformação de chaves.
</p>

<p>1. Instale as atualizações de segurança no DSA-1576</p>

   <p>Uma vez que a atualização esteja aplicada, chaves fracas de usuários
   serão automaticamente rejeitadas quando possível (embora elas não possam
   ser detectadas em todos os casos). Se você está usando tais chaves para
   autenticação de usuário, elas deixarão de funcionar imediatamente e terão
   que ser substituídas (veja o passo 3).</p>

   <p>Chaves de host do OpenSSH podem ser automaticamente regeradas quando
   a atualização de segurança do OpenSSH é aplicada. A atualização pedirá
   uma confirmação antes de aceitar este passo.</p>

<p>2. Atualize arquivos known_hosts do OpenSSH</p>

   <p>A re-geração das chaves de host fará com que um aviso seja exibido
   quando conectar-se ao sistema usando SSH até que a chave do host seja
   atualizada no arquivo known_hosts do cliente. O aviso será parecido
   com este:</p>

<pre>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
</pre>

   <p>Neste caso, a chave de host simplesmente foi trocada, e você deverá
   atualizar o arquivo known_hosts relevante conforme indicado na mensagem
   de aviso.

   É recomendado que você use um canal confiável para trocar a chave do
   servidor. Ela encontra-se no arquivo /etc/ssh/ssh_host_rsa_key.pub no
   servidor; sua impressão digital (<q>fingerprint</q>) pode ser impresso
   usando o comando:</p>

      <p>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</p>

   <p>Em adição aos arquivos known_hosts específicos dos usuários, pode
   existir um arquivo de sistemas /etc/ssh/ssh_known_hosts. Este arquivo é
   usado tanto pelo cliente ssh quanto pelo sshd para a funcionalidade
   de <q>hosts.equiv</q>. Este arquivo também precisa ser atualizado.</p>

<p>3. Verifique todas as chaves OpenSSH de usuário</p>

   <p>A rota de ação mais segura é re-gerar todas as chaves OpenSSH de usuário,
   exceto onde é possível estabelecer com elevado grau de certeza que a chave
   foi gerada em um sistema não afetado.</p>

   <p>Verifique se sua chave é afetada executando a ferramenta ssh-vulnkey,
   incluída na atualização de segurança. Por padrão, o ssh-vulnkey checará
   o local padrão para chaves de usuário (~/.ssh/id_rsa, ~/.ssh/id_dsa e
   ~/.ssh/identity), seu arquivo authorized_keys (~/.ssh/authorized_keys e
   ~/.ssh/authorized_keys2) e as chaves de host do sistema
   (/etc/ssh/ssh_host_dsa_key e /etc/ssh/ssh_host_rsa_key).</p>

   <p>Para verificar todas as suas chaves, assumindo que elas estão no local
   padrão (~/.ssh/id_rsa, ~/.ssh/id_dsa, ou ~/.ssh/identity):</p>

     <p>ssh-vulnkey</p>

   <p>Para verificar todas as chaves no seu sistema:</p>

     <p>sudo ssh-vulnkey -a</p>

   <p>Para verificar uma chave em um local não-padrão:</p>

     <p>ssh-vulnkey /caminho/para/a/chave</p>

   <p>Se o ssh-vulnkey disse <q>Unknown (no blacklist information)</q>
   (<q>Desconhecida (sem informação de lista negra)</q>), então não há
   informação se a chave é afetada. Em caso de dúvida, destrua a chave
   e gere uma nova.
   </p>

<p>4. Regerar quaisquer chaves de usuário afetadas</p>

   <p>Chaves OpenSSH usadas para autenticação de usuário devem ser
   manualmente regeradas, incluindo aquelas que podem ter sido transferidas
   para um sistema diferente após terem sido geradas.</p>

   <p>Novas chaves podem ser geradas usando ssh-keygen, e.g.:</p>

   <pre>
   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/user/.ssh/id_rsa.
   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
   </pre>

<p>5. Atualize arquivos authorized_keys (se necessário)</p>

   <p>Uma vez que as chaves de usuário tenham sido regeradas, as chaves
   públicas relevantes devem ser propagadas para os arquivos authorized_keys
   (e arquivos authorized_keys, se aplicável) em sistemas remotos. Tenha
   certeza que excluiu a chave afetada.</p>

<h1><a name="openssl">OpenSSL: instruções para geração de chave PEM
    genérica</a></h1>

<p>
Isto é apenas um lembre para aqueles (re-)geraram certificados codificados PEM.
Seu site provavelmente possui outras políticas implementadas que você deveria
seguir sobre como gerenciar chaves. Adicionalmente, você pode precisar obter
certificados assinados novamente por uma Autoridade Certificadora externa ao
invés de usar um certificado auto-assinado como exibido abaixo:
</p>

<pre>
cd /etc/ssl/private
openssl genrsa 1024 &gt; meusite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/meusite.pem -x509 -days 9999 -out meusite.pem
</pre>

<h1><a name="bincimap">bincimap</a></h1>

<p>
O pacote bincimap cria automaticamente um certificado auto-assinado
através do programa openssl para o serviço bincimap-ssl, e coloca-o
em /etc/ssl/certs/imapd.pem. Para regerá-lo, execute:
</p>

<pre>
rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap
</pre>

<h1><a name="boxbackup">boxbackup</a></h1>

<p>
Boxbackup não está presente no Debian estável (<q>stable</q>), somente
no testing/Lenny.
</p>

<p>
O autor original publicou uma análise de impacto inicial das chaves
criadas em sistemas com aleatoriedade insuficiente no PRNG. Você pode
ler os detalhes <a
href="http://lists.warhead.org.uk/pipermail/boxbackup/2008-May/004476.html">\
aqui</a>.
</p>

<p>
Se o PRNG em seu OpenSSL foi insuficientemente aleatório, você precisa:
</p>

<ul>
<li>Regerar todos os certificados afetados, que tenham sido gerados
ou assinados em um sistema afetado</li>
<li>Regerar todas as chaves de dados (*-FileEncKeys.raw)</li>
<li>Destruir os dados armazenados em seu servidor com um nível apropriado de
segurança (no mínimo, sobrescrever com zeros, mais se você for paranoico)</li>
<li>Enviar tudo novamente</li>
<li>Tomar as medidas apropriadas sob a assunção que você esteve
armazenando seus dados em texto simples em um servidor público
sem autenticação. (i.e., iniciar do zero, destruindo todos os rastros
dos dados que foram copiados (<q>back up</q>), e tomar outras medidas
para mitigar a exposição de seus segredos).</li>
</ul>

<h1><a name="cryptsetup">cryptsetup</a></h1>

<p>
O cryptsetup não usa openssl para criptografia (isto aplica-se para
dispositivos LUKS e dm-crypt).
</p>

<p>
<em>Se</em> o cryptsetup foi configurado para usar arquivos-chave
criptografados com SSL (uma configuração não-padrão que deve ser
explicitamente definida pelo usuário) e uma versão quebrada do
openssl foi usada para gerar o arquivo-chave, a criptografia do
arquivo-chave por ser mais fraca do que o esperado (pois o salto
não é verdadeiramente aleatório).
</p>

<p>
A solução é re-criptografar o arquivo-chave (se você está razoavelmente
certo de que o arquivo criptografado não foi revelado para terceiros)
ou limpar e reinstalar a(s) partição(ões) afetadas usando uma nova chave.
</p>

<p>
Instruções para re-criptografar um arquivo-chave:
</p>

<p>
Faça os passos a seguir para cada arquivo-chave criptografado com SSL,
substituindo &lt;caminho_chave_criptografada_ssl&gt; com o caminho para o
arquivo real:
</p>

<pre>
tmpkey=\$(tempfile)
openssl enc -aes-256-cbc -d -salt -in &lt;caminho_chave_criptografada_ssl&gt; -out "$tmpkey"
shred -uz &lt;caminho_chave_criptografada_ssl&gt;
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out &lt;caminho_chave_criptografada_ssl&gt;
shred -uz "$tmpkey"
</pre>

<h1><a name="dropbear">dropbear</a></h1>

<p>
Se você tem chaves /etc/ssh/*host*, remova-as ou siga as
<a href="#openssh">instruções para openssh</a> primeiro, antes de atualizar
as chaves do dropbear.
</p>

<p>
O <q>postinst</q> do dropbear converte as chaves openssh existentes para
o formato dropbear, se ele não pode localizar as chaves de host dropbear.
</p>

<pre>
rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear
</pre>

<p>
Note que chaves que foram geradas pelo próprio Dropbear não são
vulneráveis (ele usa a libtomcrypt ao invés do OpenSSL).
</p>

<h1><a name="ekg">ekg</a></h1>

<p>
Usuários dos programas ekg ou ekg2 (o último só está na experimental) que
usam a funcionalidade de criptografia <q>SIM</q>, que geraram um par de
chaves usando o comando <q>/key [-g|--generate]</q> (que usa a libssl para
fazer o trabalho) deverão regerar suas chaves após atualizar a libssl e
reiniciar o programa.
</p>

<p>
Os desenvolvedores originais enviaram uma notícia em seu site web:
<a href="http://ekg.chmurka.net/index.php">http://ekg.chmurka.net/index.php</a>
</p>

<p>
Se você precisar de mais ajuda, por favor, pergunte nas listas
ekg-users@lists.ziew.org ou ekg2-users@lists.ziew.org (em inglês e polonês).
</p>

<h1><a name="ftpd-ssl">ftpd-ssl</a></h1>

<pre>
rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl
</pre>

<p>
Isto cobre a configuração padrão. Se o administrador local fez alguma
configuração de infra-estrutura SSL além disso, estas chaves também
terão que ser regeradas.
</p>

<h1><a name="gforge">gforge</a></h1>

<p>
O pacote gforge-web-apache2 no sid e lenny configura um site web com
um certificado fictício (<q>dummy</q>) se nenhum certificado existente
é localizado. Usuários são encorajados a substituí-lo com um certificado
<q>real</q>. O certificado fictício (<q>dummy</q>) em questão é o
<q>Snake Oil</q>, portanto já deveria ser considerado como fraco (mesmo
sem o bug SSL), mas alguns usuários podem aceitá-lo sem pensar duas vezes.
</p>

<h1><a name="kerberos">MIT Kerberos (krb5)</a></h1>

<p>
Nenhuma parte do MIT Kerberos no Debian 4.0 (<q>Etch</q>) usa OpenSSL, e
portanto o Kerberos no Debian 4.0 não é afetado.
</p>

<p>
No Lenny, o pacote binário separado krb5-pkinit usa OpenSSL. O próprio
MIT Kerberos não gera pares de chaves de longo prazo até mesmo quando
a extensão PKINIT é usada, portanto quaisquer pares de chaves de longo
prazo vulneráveis teriam sido geradas fora do MIT Kerberos propriamente
dito. A extensão PKINIT somente referencia pares de chaves existentes e
não é responsável pelo gerenciamento de chaves.
</p>
<p>
Pares de chaves de longo prazo usados pelo PKINIT podem ser afetadas se
geradas em um sistema Debian afetado, mas tal geração é externa ao MIT
Kerberos.
</p>
<p>
No entanto, as funções de chave aleatória do OpenSSL são usadas para a
troca DH quando a autenticação PKINIT é usada, o que significa que um
atacante pode ser capaz de usar força bruta para ganhar acesso à
resposta do KDC para uma autenticação PKINIT e subsequentemente ganhar
acesso para quaisquer sessões criadas usando tickets de serviço daquela
autenticação.
</p>
<p>
Quaisquer KDCs usando a extensão PKINIT do Lenny deverão atualizar seus
pacotes libssl0.9.8 imediatamente e reiniciar o Kerberos KDC com:
</p>
<pre>
/etc/init.d/krb5-kdc restart
</pre>
<p>
Quaisquer tickets <q>ticket-granting</q> (TGTs) do Kerberos ou sessões
criptografadas resultantes de uma autenticação PKINIT usando um Kerberos
KDC com a libssl afetada deveria ser tratados como suspeitos; é possível
que atacantes com capturas de pacotes sejam capazes de comprometes essas
chaves e sessões.
</p>

<h1><a name="nessus">Nessus</a></h1>

<p>O script de pós-instalação do pacote do servidor Nessus (nessusd) cria
algumas chaves SSL para comunicação segura entre um servidor Nessus e o
cliente. Esse canal de comunicação deveria ser considerado comprometido
uma vez que um usuário mal intencionado poderia ser capaz de interceptar
a informação trocada entre o servidor e o cliente (o que inclui informação
sobre vulnerabilidades em hosts remotos) e potencialmente enviar comandos
para os servidores como o usuário que está autenticado.</p>

<p>Adicionalmente, se o administrador criou a chave CA do Nessus ou um
certificado de usuário (com o nessus-mkcert-client) para autenticação
remota em um servidor que tinha instalada a versão do OpenSSL afetada por
este problema de segurança, essas chaves deverão ser consideradas
comprometidas. Note que os usuários remotos com acesso ao servidor Nessus
podem disparar ataques a servidores que eles têm permissão para atacar e,
se habilitado na configuração local (no Debian o padrão é <q>não</q>)
enviar extensões que poderiam ser executadas no servidor Nessus com
privilégios de root.</p>

<p>Os scripts de configuração do mantenedor regerarão os certificados OpenSSL
quando configurados se ele não puder achá-los. Você terá que remover os
certificados e gerar novos usando:</p>

<pre>
rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd
</pre>

<p>Quando isto estiver concluído, você terá que remover as antigas chaves
de usuário em /var/lib/nessus/users/NOME_DE_USUÁRIO/auth e regerá-las
novamente com nessus-mkcert-client. Antigas chaves serão invalidadas uma
vez que a chave CA tenha sido removida.
</p>

<p>Após a chave CA ter sido regerada, você também precisará distribuir o
novo certificado CA para os seus usuários, e seus usuários terão que
aceitar o novo certificado do servidor Nessus quando eles reconectarem.
As configurações do certificado para o antigo servidor deveriam ser
removidas automaticamente mas você também pode removê-las manualmente
editando o arquivo <code>.nessusrc.cert</code> (se estiver usando o cliente
Nessus) ou o arquivo <code>.openvasrc.cert</code> (se estiver usando o cliente
OpenVAS).</p>


<h1><a name="openswan">OpenSWAN / StrongSWAN</a></h1>

<pre>
rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart
</pre>

<p>
Cuidado: Reiniciar os serviços ipsec encerra todas as conexões IPSec
atualmente abertas, que podem ter que ser reiniciados na outra ponta.
</p>

<h1><a name="openvpn">OpenVPN</a></h1>

<p>
Faça um backup dos seus arquivos de chaves secretas. Embora os nomes
de chaves sejam arbitrários, eles podem ser detectados executando
</p>
<pre>grep secret /etc/openvpn/*.conf</pre>

<p>
Recrie-os usando
</p>
<pre>openvpn --genkey --secret NOME_DO_ARQUIVO_SECRETO</pre>

<p>
Então, copie as chaves secretas compartilhadas para os hosts remotos e
reinicie a VPN em cada host com
</p>
<pre>/etc/init.d/openvpn force-reload</pre>

<h1><a name="proftpd">Proftpd</a></h1>

<p>
O empacotamento Debian não inclui geração de chaves, portanto os passos
a seguir só serão necessários se chaves SSL foram criadas externamente.
</p>

<p>
O futuro pacote proftpd a ser enviado para a instável (<q>unstable</q>)
inclui um modelo tls.conf com o comentário abaixo (em inglês).
</p>

<p>
Note que a geração de certificados auto-assinados é um pouco
diferente da sugerida na seção genérica de openssl, para evitar
o uso de uma senha quando o daemon está iniciando.
</p>

<p>
Você pode (re)gerar um certificado auto-assinado usando um comando como:
</p>
<pre>
 openssl req -x509 -newkey rsa:1024 \
         -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt \
         -nodes -days 365
</pre>

<p>
Ambos os arquivos devem ter permissão de leitura somente par ao root.
os caminhos dos arquivos podem ser checados/configurados através das
seguintes diretivas de configuração:
</p>
<pre>
TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest
</pre>

<h1><a name="puppet">puppet</a></h1>

<p>
Há dois métodos de manipular certificados puppet, um é via capistrano, o
segundo é manualmente.
</p>

<p>
O processo de regerar certificados SSL do Puppet usando capistrano está
detalhado aqui:
<a href="http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL">\
http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL</a> (em inglês)
</p>

<p>
Os passos manuais são os seguintes:
</p>

<ol>
<li>Você precisa limpar e regerar suas informações de CA:
<pre>
/etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start
</pre>
<p>
No entanto, se você estiver executando o mongrel, ao invés de iniciar o
puppetmaster a partir do script de inicialização, você precisará primeiro
parar a interface web ouvinte (apache, nginx, etc.) e então fazer o
seguinte:
</p>
<pre>
puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'
</pre>
<p>
A comando acima é necessário porque por alguma razão quando executando com
o mongrel, o puppetmaster não regerará sua CA.
</p>
</li>
<li>Limpe todos os certificados clientes
<pre>
/etc/init.d/puppet stop
rm $vardir/ssl/*
</pre>
</li>
<li>Faça com que cada cliente requisite um novo certificado:
<pre>
puppetd --onetime --debug --ignorecache --no-daemonize
</pre>
</li>
<li>Uma vez que todas as requisições tenham chego, você pode assiná-las
de uma vez só:
<pre>
puppetca --sign --all
</pre>
</li>
<li>Inicie seus clientes puppet:
<pre>
/etc/init.d/puppet start
</pre>
</li>
</ol>

<p>
Você também pode habilitar auto-assinar temporariamente, se você sente-se
confortável com isso.
</p>

<h1><a name="sendmail">sendmail</a></h1>

<p>
O sendmail (tanto no Etch quanto no Lenny) opcionalmente criam certificados
OpenSSL padrões no momento da instalação.
</p>

<p>
O procedimento de substituição de chaves é trivial:
</p>
<pre>
/usr/share/sendmail/update_tls new
</pre>

<p>
Se você personalizou os modelos em /etc/mail/tls, esses
valores serão reusados para criar os novos certificados.
</p>

<h1><a name="ssl-cert">ssl-cert</a></h1>

<p>
O certificado snakeoil /etc/ssl/certs/ssl-cert-snakeoil.pem pode ser
recriado com:
</p>

<pre>make-ssl-cert generate-default-snakeoil --force-overwrite</pre>

<h1><a name="telnetd-ssl">telnetd-ssl</a></h1>

<pre>
rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl
</pre>

<p>
Isto cobre a configuração padrão. Se o administrador local fez alguma
configuração de infra-estrutura SSL além disso, estas chaves também
terão que ser regeradas.
</p>

<h1><a name="tinc">tinc</a></h1>

<p>
Remova todas os arquivos de chaves públicas e privadas que são suspeitos:
</p>
<ol>
<li>Remova rsa_key.priv.</li>
<li>Edite todos os arquivos no diretório hosts/ e remova os blocos de chaves
públicas.</li>
</ol>

<p>
Gere um novo par de chaves pública/privada:
</p>
<pre>
tincd -n &lt;netname&gt; -K
</pre>

<p>
Troque seu arquivo de configuração de host com a nova chave pública com
outros(as) membros(as) da sua VPN. Não esqueça de reiniciar seus daemons tinc.
</p>

<h1><a name="tor">tor</a></h1>

<p>
Tor não está na estável (<q>stable</q>), mas é afetado no Lenny.
</p>

<p>
Clientes executando a versão 0.1.2.x não são afetados. Os nós Tor ou
provedores de serviço ocultos executando qualquer versão, assim como
qualquer um na versão 0.2.0.x são afetados.
</p>

<p>
Por favor, veja o
<a href="http://archives.seul.org/or/announce/May-2008/msg00000.html">anúncio
de vulnerabilidade</a> na lista de anúncios do Tor.
</p>

<p>
Atualizar para 0.1.2.19-3 (disponível no testing, instável - <q>unstable</q>,
backports.org e no costumeiro <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian">\
repositório noreply.org</a>) ou 0.2.0.26-rc-1 (disponível na experimental e
no costumeiro <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian">\
repositório noreply.org</a>) é recomendado. Se você possui um<q>relay</q>
estas versões forçarão a geração de novas chaves de servidor
(/var/lib/tor/keys/secret_*).
</p>

<p>
Se você executa um nó Tor sem usar a infra-estrutura do pacote (usuário
debian-tor, /var/lib/tor como DataDirectory etc.) você precisará remover
manualmente as chaves ruins. Veja o link para o alerta postado acima.
</p>

<p>
Se você é um provedor de serviço oculto e criou sua chave no período de
tempo afetado com uma libssl ruim então por favor, exclua sua chave
privada privada do serviço oculto. Isto mudará seu nome de host do
serviço oculto e pode requerer uma reconfiguração dos seus servidores.
</p>

<p>
Se você está executando a versão 0.2.0.x, uma atualização é altamente
recomendada &mdash; 3 dos 6 servidores de autoridade v3 tinham chaves
comprometidas. Antigas versões 0.2.0.x deixarão de funcionar em uma
ou duas semanas.
</p>

<h1><a name="xrdp">xrdp</a></h1>

<p>
O xrdp usa chaves geradas. A maioria dos clientes não checa essas
chaves por padrão, portanto, mudá-las é indolor. Você só tem que fazer:
</p>

<pre>
rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart
</pre>

<p>
O xrdp não está na estável (<q>stable</q>).
</p>