Information Center

Autenticação do servidor

Ao definir uma conexão segura, o Host On-Demand oferece três opções na guia Segurança: Ativar Segurança, Protocolo de Segurança e Enviar um Certificado (autenticação de clientes). 

Ativar Segurança

Clique em Ativar Segurança para permitir a autenticação do servidor e do cliente.

Protocolo de Segurança

O Protocolo de Segurança especifica o método utilizado para a autenticação do cliente e do servidor.   Selecione uma das seguintes opções:

TLS
Protocolo TLS (Transparent Layer Security).   A opção TLS cria uma conexão TLS padrão entre o cliente e o servidor.   O cliente contacta o servidor enviando uma comunicação conhecida como protocolo de reconhecimento, que permite que o cliente e o servidor autentiquem-se e especifiquem o tipo de criptografia utilizado durante a sessão.   Todos os dados trocados entre o cliente e o servidor durante a sessão são criptografados e não podem ser lidos por terceiros.   Além disso, o protocolo inclui uma verificação de integridade de mensagem para assegurar a integridade e confiança dos dados transmitidos.
SSL
Protocolo SSL (Secure Sockets Layer).   A opção SSL cria uma conexão SSL padrão entre o cliente e o servidor.   O cliente contacta o servidor e certifica-se de que o servidor possui um certificado válido. Esse tipo de conexão garante que todos os dados trocados entre cliente e servidor estão criptografados e não podem, portanto, ser lidos por terceiros na Internet.

Autenticação do Servidor (SSL)

O próprio SSL não garante que o cliente esteja se comunicando com o servidor correto.   Para ilustrar os riscos envolvidos com este protocolo, considere o seguinte cenário. Há dois servidores, Servidor1 (hod.S1.com) e Servidor2 (hod.S2.com) e um cliente, Cliente.Ambos os servidores possuem certificados válidos de um CA no qual o cliente confia. O Cliente deseja uma sessão segura com Servidor1, mas Servidor2 deseja espiar sua comunicação e está localizado fisicamente em um local que permite isso. O cenário é o seguinte:

O cliente envia um pedido para uma sessão SSL O Cliente envia um pedido de uma sessão SSL para Servidor1. O pedido (e todo o tráfego subseqüente) realmente passa pelo Servidor2. Em vez de encaminhar o pedido do Cliente para o Servidor1, o Servidor2 responde diretamente ao pedido, enviando seu próprio certificado ao Cliente.
O cliente recebe o certificado e verifica sua lista de CAs confiáveis O Cliente recebe o certificado de Servidor2 e verifica sua lista de CAs confiáveis. Como o certificado do Servidor2 é assinado pelo mesmo CA como certificado do Servidor1, o Cliente aceita o certificado e cria uma sessão segura com Servidor2.
O servidor solicita e cria sua própria sessão SSL Tendo concluído a sessão segura com Cliente, Servidor2 solicita e cria sua própria sessão de SSL com Servidor1. Sendo assim, Cliente envia informações criptografadas para Servidor2. O Servidor2 decriptografa as informações, criptografa-as novamente e as envia ao Servidor1. Faz o mesmo para as informações que fluem na direção oposta. O resultado é que, apesar de todos os dados serem criptografados durante o fluxo na Internet, o Servidor2 consegue ler e até alterar tais dados.

Para ajudar a evitar esse perigo, a opção Autenticação do Servidor (SSL) é fornecida. Quando ativada, o cliente, depois de ter certeza que o certificado do servidor pode ser confiável, verifica se o nome Internet no certificado corresponde ao nome Internet do servidor. Se corresponderem, a negociação SSL continuará. Se não, a conexão termina imediatamente.

Para essa verificação ser válida e fornecer um resultado positivo, duas condições devem ser atendidas:

  1. O cliente deve estar instalado localmente. Um cliente do qual foi feito download utilizando http não pode ser confiável para autenticação do servidor. Se a autenticação do servidor for de vital importância, você deve utilizar apenas clientes instalados localmente ou utilizar https no servidor da Web.
  2. O nome comum no certificado do servidor deve corresponder ao nome na Internet.

Com Autenticação do Servidor (SSL) ativada, o cenário de segurança continuaria como a seguir:

O cliente envia um pedido para uma sessão SSL 1. O cliente envia um pedido de uma sessão SSL para o Servidor1. O pedido (e todo o tráfego subseqüente) realmente passa pelo Servidor2. Em vez de encaminhar o pedido do Cliente para Servidor1, o Servidor2 responde diretamente ao pedido, enviando seu próprio certificado para o Cliente.
O cliente recebe o certificado e verifica sua lista de CAs confiáveis 2. O cliente recebe o certificado do Servidor2 e verifica sua lista de CAs confiáveis. Como o certificado do Servidor2 é assinado pelo mesmo CA como certificado do Servidor1, o Cliente aceita o certificado e cria uma sessão segura com Servidor2.
O cliente compara o nome de Internet no certificado com o nome do servidor 3. Após a sessão segura ter sido concluída, mas antes de qualquer dado real ter sido enviado ou recebido, o Cliente compara o nome de Internet no certificado recebido (hod.S2.com) com o nome do servidor com o qual ele deseja conversar (hod.S1.com). Se não corresponderem, o Cliente saberá que a conexão não deve continuar e a desconectará.

Tópicos Relacionados