Criptografar Conexões da Rede

Criptografar Conexões da Rede Projeto Libertas-BR http://www.libertasbr.org.br 8 de setembro de 2005 Este documento descreve processos para criptografar as conexões da rede para sistemas operacionais Windows e Linux. 1 Introdução Historicamente na elaboração dos projetos para desenvolvimento de aplicações numa instituição qualquer, são levantados diversos requisitos e funcionalidades consideradas essênciais à instituição. Mas ao final do desenvolvimento da aplicação, talvez por falta de tempo ou talvez por não estar contemplado no texto do projeto inicial, muitas destas aplicações acabam sendo finalizadas sem que exista o mínimo de cuidado com a segurança dos dados utilizados por ela. Informações estritamente confidenciais como nomes de usuários e senhas acabam trafegando pela rede em texto puro, prontas para serem facilmente capturadas por qualquer um que tenha acesso à rede. Este documento, tem a finalidade de mostrar de forma didática, como contornar este tipo de problema sem que seja necessária a alteração da implementação das aplicações da rede. Serão mostradas algumas ferramentas para tornar mais seguras as conexões de rede tentaremos exibir os passos de como criar conexões seguras entre aplicativos nos sistemas operacionais windows e linux. 2 Problema abordado Para facilitar a compreensão das instruções dadas, usaremos um problema real de uma rede. Considere a seguinte situação: Uma instituiç~ao possui uma rede de grande proporç~ao. Nesta instituiç~ao, o suporte a maioria dos problemas dos usuários n~ao pode ser feito presencialmente, por isso optou-se pela utilizaç~ao do aplicativo VNC e fazer este suporte remotamente. 1

Porém, a vers~ao livre do VNC n~ao possui suporte à criptografia nas conex~oes. O que torna o aplicativo muito vulnerável e acaba comprometendo a segurança de toda a rede, já que normalmente os usuários que d~ao este tipo de suporte possuem permiss~ao de administradores da rede e suas senhas podem ser facilmente capturadas por qualquer ferramenta de monitoraç~ao de rede. Veja a ilustraç~ao: Neste documento, ser~ao mostradas ferramentas para proteger esta vulnerabilidade e tornar este tipo de conex~ao segura. A idéia fundamental da utilizaç~ao destas ferramentas é a criaç~ao de túneis de criptografia para que se os dados trafegados na rede forem capturados por terceiros, n~ao possam ser recuperados ao estado original. Veja a ilustraç~ao: 3 Ferramentas Existem basicamente 2 tipos de ferramentas utilizadas para criptografar o trafego de dados na rede. 2

ˆ Túnel para aplicações específicas: ferramentas para criar um túnel de criptografia de aplicações específicas que funcionam em máquinas específicas. Limitação: Não são boas ferramentas para fazer um túnel para todo o tráfego entre redes. ˆ Túnel para todo o tráfego: ferramentas capazes de criar túneis de criptografia para todo o tráfego entre 2 máquinas ou entre 2 redes inteiras. Limitação: Como a criptografia é uma camada a mais na comunicação de rede da aplicação e nem sempre a criptografia se faz necessária, esse tipo de ferramenta pode comprometer o desempenho das aplicações de rede em geral. 3.1 OpenSSH OpenSSH é uma versão livre do protocolo SSH (Secure Shell). Ele se assemelha muito ao serviço telnet e rlogin com a diferença que a comunicação entre o cliente e o servidor é feita de forma encriptada usando chaves públicas/privadas RSA ou DSA para criptografia, garantindo como consequência, uma transferência segura de dados na rede. Na seção seguinte será demonstrado como estabelecer uma conexão segura em uma comunicação servidor/cliente: 3.1.1 Autenticação utilizando chaves Públicas (no linux [debian]) Umas das formas de autenticação do SSH é através do uso de chaves públicas (que ficam na máquina servidor) e chaves privadas (que ficam nas máquinas clientes). O processo de encriptação e desencriptação são feitos em chaves separadas, portanto não é possível conseguir a chave de encriptação a partir da chave de desencriptação. Nesse método que apresentaremos abordaremos a criação de chaves que não utilizam senha para efetuar o login, sendo este método muito utilizado em scripts. Para gerar chaves de encriptação e desencriptação execute os seguintes comandos: ssh-keygen -t rsa ou ssh-keygen -t dsa O comando ssh-keygen é um comando shell, e a opção -t define qual método de criptografia será utilizado para produzir as chaves. Ambas opções RSA e DSA são compatíveis com a versão ssh2, que é a versão atualmente utilizada. Para facilitação usaremos nesta documentação todo processo da criação de uma chave RSA. Um par de chaves será criado, vale observar que não será definida nenhuma passphrase, para isso ignore as questões relacionadas a tal no instante da geração das chaves. Esse processo define que a autenticação ocorrerá sem o uso de senhas. Copie ambas chaves para o diretório.ssh/ usando o comando cp. A chave com o sulfixo.pub é a chave pública, que como dito anteriomente, será destinada ao host servidor. Para isso envie a chave para o host servidor utilizando o comando: 3

scp -r "id_rsa.pub" usuario@host_servidor:~/.ssh O diretório.ssh/ é onde são armazenadas as chaves de autenticação utilizadas pelo ssh. Quando conectamos em um servidor remoto, o servidor checa se a chave pública está no arquivo.ssh/authorized keys portanto é necessário copiar a chave pública para esse arquivo. Para isso proceda da forma abaixo: cat "id_rsa.pub" >>.ssh/authorized_keys Para verificar a sua chave pública, o servidor cripatografa algum dado aleatório com a chave pública do usuário em questão e envia para ele. Ele (o host usuário) desencriptografa esse dado, criptografa o mesmo com a chave pública do servidor remoto e manda-os de volta. Se o servidor descriptografar e ver que é idêntico ao que ele enviou anteriormente então ele sabe quem é o usuário e portanto não é necessário o autenticar com senha. 3.1.2 Túnel SSH entre máquinas linux [debian] O ssh é capaz de criar um túnel criptografado entre máquinas para ser usado como canal de comunicação de rede. A idéia do túnel é basicamente criar uma comunicação segura com um servidor remoto através da abertura de uma porta na máquina local e encaminhar toda a informação que se recebe nessa porta para uma outra porta específica no servidor. Esse procedimento tem o nome de ssh port-forward. Ao utilizar esse processo de tunelamento é possivel tornar seguro vários serviços como vnc, telnet, rlogin entre outros, que sem o uso do túnel permitem interceptação de dados. Para criar o túnel ssh primeiramente é preciso definir quais portas serão utlizadas na máquina local e no servidor remoto. É aconselhado para o uso do port-forward a seleção de portas acima de 1024, visto que apenas o root tem acesso às portas exclusivas, isto é, as portas abaixo dessa numeração. Outro lembrete importante é que o servidor remoto precisa dar suporte ao serviço que você deseja utilizar, seja por exemplo o telnet, vnc ou qualquer outro. A sintaxe do comando para a criação do túnel SSH é a seguinte: ssh -f -N -L porta_local:localhost:porta_do_servidor usuario@nome_servidor * A opç~ao -f define que o processo ssh será executado em background; ** A opç~ao -N define que n~ao será executado um comando remoto. Por exemplo: N~ao será aberto um novo terminal. *** A opç~ao -L especifica que todos os requests que chegam a porta local ser~ao redirecionados para a porta do servidor remoto. Para exemplificar a utilização do túnel ssh, utilizaremos a criptografia do vnc. 4

ˆ Iniciar o servidor vnc na máquina servidor remoto. Para isso conecte na máquina e execute o seguinte comando abaixo, defina uma senha e confirme-a. vncserver ˆ Definir as portas que serão utilizadas no túnel. O servidor vnc escuta na porta 5900 + o número do display no qual o vnc executará. Ex.: 5901, 5902, 5903, etc.. ssh -f -N -L 7777:localhost:5901 nome_usuario@servidor ˆ Iniciar a conexão no túnel ssh vncviewer localhost:7777 * utilize a senha definida no vnc Para terminar a conexão basta finalizar o processo do ssh responsável pelo túnel. ps -ef grep nome_do servidor kill -9 num_do_processo 3.1.3 Túnel ssh entre uma máquina cliente Windows e um servidor linux [debian] Para execução deste procedimento utilizaremos o software gratuito SSH Secure Shell Client para Windows e uma máquina servidor linux. Caso o software não esteja instalado no sistema faça o download em: http://ftp.ssh.com/priv/secureshell/329wks+srv-lt49ldrk/windows/ SSHSecureShellClient-3.2.9.exe As chaves públicas de autenticação serão geradas no Windows e transportadas para servidor linux. Para isso execute os seguites comandos: ˆ Inicie o programa SSH Secure Shell Client; ˆ Escolha a opção Edit --> Settings --> User --> Authentication Keys ˆ Clique em Generate New. Serão definidos alguns passos para a criação de duas chaves, uma pública e outra privada, escolha o método de criptografia (RSA OU DSA), o tamanho default das chaves é 1024 bits e elas são geradas randomicamente. ˆ Defina um nome para salvar as chaves ˆ Não é necessário definir uma Passphrase visto que não queremos digitar nenhuma senha para autenticar. Para isso clique em Yes. 5

ˆ Clique em Concluir para finalizar a criação. Envie a chave pública para o servidor linux. Para isso utilize a versão scp do SSH Secure Shell Client, seguindo os passos a seguir; ˆ Conecte com o servidor linux por ssh. ˆ Escolha a opção New file Transfer Window ˆ Encontre a chave pública criada e transfira para o servidor linux. Geralmente a chave pública se encontra no diretório: C:\Documents and Settings\[nome_do_usuário]\Application Data\SSH\UserKeys Depois que a chave já se encontra no servidor unix é preciso converter a chave criada no SSH Secure Shell para a uma chave do tipo OpenSSH. ssh-keygen -i -f.ssh/nome_da_chave.pub >>.ssh/authorized_keys Quando se conecta pela primeira vez na máquina servidor remoto, ela interroga a possibilidade de salvar a chave no diretório local do usuário, responda yes a esta questão. Já não é necessário a utilização de uma senha de autentucação. Para criar o túnel seguro entre as máquinas execute a sequência abaixo: ˆ Inicie o servidor vnc na máquina servidor remoto. Utilize o comando vncserver. ˆ Defina as portas do Cliente windows e do servidor linux, lembre-se que o vnc utiliza portas acima de 5900 + display, assim como foi explicado anteriormente. ˆ Abra um prompt de comando e procure o diretório onde se encontra o executável ssh do windows. Geralmente ele se encontra em: C:\Arquivos de Programas\SSH Communications Security\SSH Secure Shell ˆ Execute o comando abaixo para iniciar o túnel ssh; ssh2.exe -x -L porta_local:localhost:porta_servidor nome_usuario@servidor * utilizaremos de exemplo o comando: ssh2.exe -x -L 60000:localhost:5901 nome_usuario@servidor ˆ Em um outro prompt de comando execute o cliente windows do vnc, a localização do diretório do vnc vai depender de qual vnc está instalado na máquina cliente windows, no caso abordado estava insatalado o RealVNC. Geralmente o diretório do RealVNC encontra-se em: 6

C:\Arquivos de Programas\RealVNC\VNC4 O comando de execução do cliente vnc é o seguinte: vncviewer.exe localhost:porta_local * como exemplo utilizaremos o comando: vncviewer.exe localhost:60000 ** utilize a senha definida para o servidor vnc. 3.2 Stunnel Conceitualmente, o Stunnel é um envoltório SSL assim como o redirecionamento de portas do SSH. Serão mostrados os passos para a criação de túneis SSL em clientes e servidores no windows e no linux, estes túneis conseguem se comunicar uns com os outros sem problemas. Serão mostrados nesta seção, os passos necessários para criar uma conexão segura entre aplicativos cliente e servidor: 3.2.1 Criptografia com certificação do servidor A implementação desta solução, já é suficiente para tornar a conexão entre as máquinas segura, pois a identidade do servidor da aplicação estará assegurada e os dados transmitidos na conexão são criptografados. Siga os passos: 1 1. Criar uma Autoridade Certificadora (CA): 1 O processo inteiro será mostrado aqui, desde a criação da Autoridade Certificadora (CA) até a execução do daemon de criação do túnel SSL. Caso já tenha uma CA, pule para o passo??. 7

mkdir -p chaves cd /var/tmp/chaves /usr/lib/ssl/ca.sh -newca *lembre-se de guardar a senha utilizada neste processo. 2. Copiar o certificado do CA para /etc/ssl/certs: cp -f democa/cacert.pem /etc/ssl/certs 3. Criar certificado do servidor (a) Fazer a requisição de um certificado para o servidor: /usr/lib/ssl/ca.sh -newreq *na seç~ao Common Name, coloque o caminho completo do servidor (ex.: fuzil01.cluster-speed.ufmg.br) **esse comando cria uma chave privada e uma requisiç~ao para um certificado. (b) Assinar a requisição do certificado: /usr/lib/ssl/ca.sh -sign *para assinar este certificado, é necessário informar a senha utilizada no CA (c) Remover a senha da chave privada: openssl rsa -in newreq.pem -out chave.pem *esse passo é opcional, serve para automatizar a inicializaç~ao do stunnel. Mas, pode-se optar por ter que digitar a senha da chave toda vez que o túnel for iniciado. (d) Concatenar a chave e o certificado no mesmo arquivo: cat chave.pem newcert.pem > certificado_servidor.pem (e) Copiar o certificado+chave final para o diretório /etc/ssl/cert: 8

cp certificado_servidor.pem /etc/ssl/cert/stunnel.pem 4. Iniciar os túneis: (a) Iniciar túnel do servidor (fuzil01.cluster-speed.ufmg.br): stunnel -d 7777 -r 5900 *este comando direciona todas as conex~oes para a porta 7777 do servidor para a porta 5900. (b) Iniciar túnel do cliente (fuzil02.cluster-speed.ufmg.br): stunnel -c -d 5900 -r fuzil01:7777 *este comando direciona todas as conex~oes para a porta 5900 do cliente para a porta 7777 do servidor fuzil01. 5. Conectar ao servidor VNC (na fuzil01), utilizando a conexão segura: vncviewer localhost *este comando deve ser executado na máquina cliente. 3.2.2 Criptografia com certificação de cliente e de servidor (no linux [debian]) A identidade do servidor da aplicação está assegurada e os dados transmitidos na conexão são criptografados. Mas, para algumas aplicações é necessário certificar-se também da identidade do cliente. Um exemplo disso é a aplicação VNC em que é necessário certificar-se que apenas determinados clientes podem ter acesso ao servidor VNC. Nesta seção mostraremos os passos para a criação e utilização de certificados no lado do cliente. 2 1. Criar certificado para o cliente: *os passos de criaç~ao do certificado do cliente s~ao os mesmos passos da criaç~ao do certificado do servidor, utilize o mesmo host que foi usado para a criaç~ao do certificado do servidor. (a) Fazer a requisição de um certificado: /usr/lib/ssl/ca.sh -newreq 2 As informações desta seção são uma continuação dos passos da seção anterior, sem a inicialização dos túneis. 9

*na seç~ao Common Name, coloque o caminho completo do cliente (ex.: fuzil02.cluster-speed.ufmg.br) **esse comando cria uma chave privada e uma requisiç~ao para um certificado. (b) Assinar a requisição do certificado: /usr/lib/ssl/ca.sh -sign *para assinar este certificado, é necessário informar a senha utilizada no CA (c) Copiar o certificado do cliente para o diretório /etc/ssl/certs do servidor: cp newcert.pem /etc/ssl/certs/ (d) Encontrar a hash dos arquivos de certificados no servidor: c_rehash /etc/ssl/certs/ (e) Remover a senha da chave privada: openssl rsa -in newreq.pem -out chave.pem *esse passo é opcional, serve para automatizar a inicializaç~ao do stunnel. Mas, pode-se optar por ter que digitar a senha da chave toda vez que o túnel for iniciado. (f) Concatenar a chave e o certificado no mesmo arquivo: cat chave.pem newcert.pem > certificado_cliente.pem (g) Copiar o certificado+chave final para o diretório /etc/ssl/cert na máquina cliente: scp certificado_cliente.pem fuzil02:/etc/ssl/cert/stunnel.pem 2. Iniciar os túneis: (a) Iniciar túnel do servidor (fuzil01.cluster-speed.ufmg.br): stunnel -v 3 -d 7777 -r 23 *este comando direciona todas as conex~oes na porta 7777 do servidor, para a porta 5900 e pede a identificaç~ao dos clientes. 10

(b) Iniciar túnel do cliente (fuzil02.cluster-speed.ufmg.br): stunnel -c -p /etc/ssl/certs/stunnel.pem -d 23 -r fuzil01:7777 *este comando direciona todas as conex~oes para a porta 5900 do cliente para a porta 7777 do servidor fuzil01 e utiliza o certificado stunnel.pem para a identificaç~ao do cliente. 3. Conectar ao servidor VNC (na fuzil01), utilizando a conexão segura: vncviewer localhost *este comando deve ser executado na máquina cliente. 3.2.3 Criptografia com certificação de cliente e de servidor (no windows) Até agora fizemos as conexões seguras, mas utilizamos apenas serviços em máquinas linux. Como na grande maioria das instituições as aplicações são utilizadas em máquinas windows, nesta seção mostraremos os procedimentos de criação de túneis com o stunnel utilizando clientes e servidores windows. 1. O primeiro passo é fazer o download do servidor stunnel para o windows: Entre no endereço: http://www.stunnel.org/download/binaries.html e faça o download do arquivo: openssl.zip 2. No windows, crie o diretório: c:\program Files\Stunnel e descompacte o arquivo openssl.zip neste diretório. 3. Da mesma forma que foram criados os certificados e chaves privadas no linux, crie as respectivas chaves para o windows. 3 4. Configuração de um servidor stunnel no windows: (a) Arquivo de configuração: No diretório onde foram descompactados os arquivos do stunnel (c:\program Files\Stunnel), crie o arquivo stunnel.conf e edite da seguinte forma: CAfile = cacert.pem CApath = certs cert = stunnel.pem client = no 3 Siga os procedimentos descritos na seção?? para a criação dos certificados. 11

verify = 3 [vnc] accept = 7777 connect = 127.0.0.1:5900 *neste exemplo, foi definido um túnel com o nome [vnc] que aceita conex~oes seguras na porta 7777 e redireciona para a porta 5900, e que exige a identificaç~ao do cliente. (b) Copie o certificado do CA (criado na seção??) que assinou as chaves do servidor e dos clientes, para o diretório c:\program Files\Stunnel com o nome cacert.pem (igual à diretiva CAfile do arquivo de configuração do stunnel). (c) Depois de criada a chave e o certificado do servidor (em um mesmo arquivo) procedimento feito no linux, copie este para o diretório c:\program Files\Stunnel com o nome stunnel.pem (igual à diretiva cert do arquivo stunnel.conf). (d) Copie os certificados dos clientes para o diretório c:\program Files\Stunnel\certs, alterando o nome desses arquivos para a hash do arquivo. Para encontrar qual é a hash do arquivo, execute no linux o comando: /usr/lib/ssl/misc/c_hash certificado_cliente.pem o valor de saída desse comando deve ser o nome do arquivo. (e) Para iniciar o túnel, basta executar o comando stunnel-4.09.exe. 5. Configuração de um cliente stunnel no windows: (a) Arquivo de configuração: No diretório onde foram descompactados os arquivos do stunnel (c:\program Files\Stunnel), crie o arquivo stunnel.conf e edite da seguinte forma: CAfile = cacert.pem CApath = certs cert = stunnel.pem client = yes verify = 3 [vnc] accept = 127.0.0.1:5900 connect = demeter:7777 *neste exemplo, foi definido um túnel com o nome [vnc] que aceita conex~oes na porta 5900, criptografa os dados e redireciona para a porta 7777 do servidor (demeter). 12

(b) Copie o certificado do CA (criado na seção??) que assinou as chaves do servidor e dos clientes, para o diretório c:\program Files\Stunnel com o nome cacert.pem (igual à diretiva CAfile do arquivo de configuração do stunnel). (c) Depois de criada a chave e o certificado do cliente (em um mesmo arquivo) procedimento feito no linux, copie este para o diretório c:\program Files\Stunnel com o nome stunnel.pem (igual à diretiva cert do arquivo stunnel.conf). (d) Para iniciar o túnel, basta executar o comando stunnel-4.09.exe. 6. Para testar a conexão segura do cliente ao servidor VNC, inicie o VNC na máquina servidora (windows). Na máquina cliente, abra o cliente VNC e faça uma conexão VNC direcionada à máquina localhost. Se tudo estiver funcionando corretamente, o cliente VNC abrirá uma conexão criptografada com o servidor VNC. 3.3 OpenSSH x Stunnel A diferença principal da solução do Stunnel para o redirecionamento de portas do SSH é que o túnel do Stunnel funciona como um daemon na máquina. Outra diferença é que com a utilização do Stunnel, para fazer o redirecionamento das portas não é necessário estabelecer uma conexão previamente entre as máquinas como é feito com o SSH. Para a escolha do uso de uma ferramenta ou outra, deve-se levar em consideração o tipo de uso. Para aplicações que são usadas com uma grande frequência, o ideal é utilizar o Stunnel, pois o direcionamento de portas fica estabelecido e o uso da ferramenta é transparente ao usuário. Se a frequência de utilização da aplicação for baixa, o mais prático é utilizar o direcionamento de portas com o SSH, pois se a aplicação não é utilizada com frequência não há a necessidade de criar um túnel permanente entre os dois pontos, evitando o trabalho desnecessário, já que o processo de criação de túneis no Stunnel passa pelo processo de criação de chaves públicas e privadas para os dois pontos da conexão. 3.4 OpenVPN 3.5 PoPToP and Linux PPTP Client 13

A Processo de criação de chaves SSL A.1 Criar uma chave primária e um certificado assinado por si mesmo Este tipo de chave não pode ser utilizado para a ferramenta stunnel. Normalmente esta chave é criada para se construir uma Autoridade Certificadora (CA). *existem várias Autoridades Certificadoras reconhecidas na Internet **se a sua Autoridade Certificadora for reconhecida pelas partes envolvidas na transaç~ao, a transaç~ao será reconhecida openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem Argumentos: -days 365 tempo de validade da chave (1 ano) -new gerar uma nova chave -x509 gerar um certificado X509 (assinado por si mesmo) -nodes não inserir senha nesta chave -out cert.pem onde será criado o certificado SSL -keyout cert.pem onde será criada a chave privada Este comando vai fazer as seguintes perguntas: 1. Country name. Exemplo de respostas: BR, UK, US, CA; 2. State or Province name. Resp.: Minas Gerais, São Paulo; 3. Locality. Resp.: Belo Horizonte; 4. Organization Name. Resp.: UFMG, CAIXA; 5. Organizational Unit Name. Resp.: Laboratório de Software Livre; 6. Common Name (FQDN). Resp.: asteria.speed.ufmg.br (deve ser o nome completo do host onde ficará a chave); A.2 Criar uma chave primária e uma requisição de certificado para ser assinado por uma Autoridade Certificadora openssl req -new -days 365 -nodes -out certreq.pem -keyout chave.pem Argumentos: req cria uma requisição de certificado -days 365 tempo de validade da chave (1 ano) -nodes não pedir senha para a chave -out certreq.pem arquivo de saída da requisição de certificado do SSL -keyout chave.pem arquivo de saída da chave privada criada 14

A.3 Verificando o conteúdo de um certicado openssl x509 -subject -dates -in cert.pem Argumentos: x509 opção para exibir informações sobre o certificado -subject mostra informações do nome do certifido. -dates mostra as datas de início e de fim da validade do certificado. A.4 Assinar uma requisição de certificado *faltam alguns argumentos!!!! ESTE PROCEDIMENTO N~AO ESTÁ COMPLETO!!! openssl ca -policy policy_anything -keyfile cakey.pem -key teste \ -cert cacert.pem -out cert.pem -infiles certreq.pem Argumentos: ca opção para utilizar a Autoridade Certificadora -policy policy_anything política adotada pela Autoridade Certificadora para verificar os campos do arquivo do certificado de requisição. -keyfile cakey.pem chave privada da Autoridade Certificadora -key teste senha da chave -out cert.pem arquivo de saída do certificado assinado -infiles certreq.pem arquivo de requisição de certificado A.5 Utilização do script para a criação das chaves A maneira mais fácil de criar estas chaves e certificados é utilizando a ferramenta criada pela equipe do OpenSSL: ˆ Criação de uma Autoridade Certificadora (CA): /usr/lib/ssl/misc/ca.sh -newca ˆ Criar um certificado assinado por ele mesmo: /usr/lib/ssl/misc/ca.sh -newcert ˆ Criar uma requisição de um certificado: /usr/lib/ssl/misc/ca.sh -newreq ˆ Assinando a requisição do certificado: 15

/usr/lib/ssl/misc/ca.sh -sign B Anexos 16

A Créditos Documento Criptografar Conexões da Rede Direitos Autorais Reservados (c) Universidade Federal de Minas Gerais Departamento de Ciência da Computação Laboratório de Software Livre: Zeniel Juliano Neves Chaves - zeniel@dcc.ufmg.br João Victor dos Anjos Barbara - jvictor@dcc.ufmg.br Esta documentação é livre; você pode redistribuí-la e/ou modificá-la sob os termos da Licença Pública Geral GNU conforme publicada pela Free Software Foundation; tanto na sua versão 2, como qualquer versão posterior (a seu critério). A distribuição desta documentação é feita na expectativa de que ela seja útil, porém, sem nenhuma garantia; nem mesmo a garantia implícita de comerciabilidade ou adequação a uma finalidade específica. Consulte a Licença Pública Geral do GNU para mais detalhes. http://creativecommons.org/licenses/gpl/2.0/ http://creativecommons.org/licenses/gpl/2.0/legalcode.pt 17