HTTPS (HyperText Transfer Protocol Secure - protocolo de transferência de hipertexto seguro) é uma implementação do protocolo HTTP sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS. Essa camada adicional permite que os dados sejam transmitidos por meio de uma conexão criptografada e que se verifique a autenticidade do servidor e do cliente por meio de certificados digitais. A porta TCP usada por norma para o protocolo HTTPS é a 443.
O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como por exemplo no caso de compras online. A existência na barra de tarefas de um cadeado (que pode ficar do lado esquerdo ou direito, dependendo do navegador utilizado) demonstra a certificação de página segura (SSL). A existência desse certificado indica o uso do protocolo HTTPS e que a comunicação entre o browser e o servidor se dará de forma segura. Para verificar a identidade do servidor é necessário abrir esse certificado com um duplo clique no cadeado para exibição do certificado.
Nas URLs dos sites o início ficaria 'https://'. Consulte a ajuda do seu navegador para mais informações de como ele avisa sobre sites seguros.
Um exemplo de conexão via HTTPS são os próprios sites da Wikimedia Foundation, em que é possível acessar e editar o conteúdo dos sites através de uma conexão segura. Através da URL https://secure.wikimedia.org/wikipedia/pt/wiki/Página_principal é possível editar a wikipédia em língua portuguesa.
Conexões HTTPS são frequentemente usadas para transações de pagamentos na World Wide Web e para transações sensíveis em sistemas de informação corporativos. Porém, o HTTPS não deve ser confundido com o menos utilizado protocolo "Secure HTTP" (S-HTTP), especificado na RFC 2660.
Diferenças para o HTTP
As URLs HTTPS começam com "https://" e utilizam a porta 443 como padrão, enquanto as URLs HTTP começam com "http://" e utilizam a porta 80 como padrão. HTTP é inseguro e sujeito a ataques de homem-no-meio e escutas ilegais, que podem levar a atacantes ganharem acesso a contas de páginas na web e a informações sensíveis. O HTTPS foi projetado para proteger contra esses ataques e é considerado seguro contra eles (com exceção de versões mais antigas e obsoletas do SSL).
Camadas de rede
HTTP opera na camada superior do Modelo OSI, a camada de aplicação, mas o protocolo de segurança opera em uma sub-camada inferior, criptografando uma mensagem HTTP antes de sua transmissão e decriptando a mensagem assim que ela chega. Estritamente falando, HTTPS não é um protocolo separado, mas se refere ao uso do HTTP sobre uma camada encriptada de conexão SSL/TLS.
Tudo na mensagem HTTPS é criptografado, incluindo os cabeçalhos, as requisições e respostas. Com a exceção de possíveis ataques criptográficos CCA descritos na seção de limitações abaixo, o atacante pode apenas conhecer o fato de que a conexão está sendo feita entre duas partes já conhecidas por ele, o nome do domínio e o endereço IP.
Configuração do Servidor
Para preparar uma página web de modo a aceitar conexões HTTPS, o administrador deve criar um certificado de chave pública para o servidor web. Esse certificado deve ser assinado por uma autoridade de certificação confiável para que o navegador aceite a conexão e não exiba avisos. A autoridade certifica que o proprietário do certificado é o operador do servidor web que o apresenta. Os navegadores web são geralmente distribuídos com uma lista de autoridades de certificação de assinatura para que elas possam verificar certificados assinados por eles.
Adquirindo certificados
Certificados assinados por autoridades podem ser de graça 3 4 ou custar entre 13 5 dólares e 1.500 6 dólares por ano.
Organizações podem também ter sua própria autoridade de certificação, particularmente se são responsáveis por configurar navegadores para acessar suas próprias páginas (por exemplo, páginas de uma rede interna ou de uma grande universidade). Elas podem facilmente adicionar cópias de seus próprios certificados na lista de certificados distribuída no navegador.
Existe também uma autoridade de certificação ponto-a-ponto, a CACert .
Uso como controle de acesso
O sistema pode também ser utilizado para autenticação de clientes, com o objetivo de limitar o acesso a servidores web a usuários autorizados. Para fazê-lo, o administrador da página tipicamente cria um certificado para cada usuário, que é carregado em seu navegador. Normalmente, o certificado contém o nome e endereço de e-mail do usuário autorizado e é automaticamente verificado pelo servidor em cada reconexão para verificar a identidade do usuário, muitas vezes sem a necessidade de utilização de senhas.
Caso uma chave privada tenha sido comprometida[editar | editar código-fonte]
O certificado pode ser revogado antes de expirar, por exemplo por conta da chave privada ter sido comprometida. Versões mais novas de navegadores populares como o Google Chrome, Firefox 8 , Opera 9 , e o Internet Explorer no Windows Vista implementam o OCSP (Protocolo de Certificação Online de Estado) para verificar essa possível falha. O navegador envia, então, o número de série do certificado a uma autoridade de certificação via OCSP e a autoridade responde, informando ao navegador se o certificado ainda é válido. 10
Limitações
O SSL se apresenta em duas versões: simples e mútua. A versão mútua é mais segura, porém requer que o usuário instale um certificado pessoal em seu navegador para que possa se autenticar. Independente da estratégia utilizada (simples ou mútua), o nível de proteção depende fortemente da corretude da implementação do navegador, da implementação do servidor e dos algoritmos critográficos suportados.
O SSL não previne a página inteira de ser indexada utilizando um web crawler e, em alguns casos, a URI do recurso criptografado pode ser inferida sabendo-se apenas o tamanho da requisição ou da resposta . Isso permite a um atacante ter acesso ao texto plano (o conteúdo propriamente dito) e ao texto encriptado (a versão criptografada do texto plano), permitindo um ataque criptográfico.
Por conta do SSL operar abaixo do HTTP e não ter conhecimento de protocolos de níveis superiores, servidores SSL podem apenas apresentar um certificado para uma combinação particular de IP/porta 12 . Isto significa que, na maioria dos casos, não é factível usar Hospedagem Virtual Baseada em Nome com HTTPS. Existe uma solução denominada Indicação de Nomes para Servidores (SNI), que envia o nome do host ao servidor antes de encriptar a conexão, embora muitos navegadores mais antigos não suportem essa extensão. Suporte para o SNI está disponível desde o Firefox 2, Opera 8, Safari 2.1, Google Chrome 6 e Internet Explorer 7 no Windows Vista.
Se controles parentais são ativados no Mac OS X, páginas HTTPS devem ser explicitamente permitidas utilizando a lista Always Allow (Sempre Permitir).
De um ponto de vista arquitetural:
Uma conexão SSL/TLS é gerenciada pela máquina que inicializa a conexão SSL. Se. por algum motivo (roteamento, otimização de tráfego etc), essa máquina não é a aplicação do servidor e ela tem que decifrar dados, soluções têm de ser encontradas para propagar as informações de autenticação - ou certificado - do usuário para a aplicação do servidor, que necessita saber quem irá se conectar.
Para um SSL com autenticação mútua, a sessão SSL/TLS é gerenciada pelo primeiro servidor que inicializa a conexão. Em situações em que encriptação necessita ser propagada por servidores em cadeia, se torna mais difícil gerenciar o timeOut da sessão.
Com SSL/TLS com autenticação mútua, a segurança é maximal, mas no lado do cliente não há uma maneira de finalizar apropriadamente a conexão SSL e se desconectar. É preciso esperar que a sessão SSL expire ou finalize todas as aplicações do cliente.
Por motivos de desempenho, conteúdo estático que não é específico ao usuário ou à transação e, por isso, não privado, é normalmente entregue a um servidor não encriptado ou a uma outra instância sem SSL do servidor. Como consequência, esse conteúdo não fica protegido. Muitos navegadores alertam o usuário quando uma página misturou recursos criptografados e não criptografados.
Um ataque sofisticado de homem-no-meio foi apresentado na Blackhat Conference 2009. Esse tipo de ataque derrota a segurança fornecida pelo HTTPS modificando um link https: para um link http:, tirando proveito do fato de que poucos usuários da Internet digitam "https" nos seus navegadores. Os usuários normalmente alcançam páginas seguras clicando em um link, podendo ser, assim, levados a pensar que estão usando HTTPS quando de fato estão usando HTTP. O atacante, então, consegue se comunicar de modo não criptografado com o cliente. 17
História
A Netscape Communication criou o HTTPS em 1994 para seu navegador Netscape. 18 Originalmente, o HTTPS foi utilizado com o protocolo SSL. À medida que o SSL evoluiu para o TLS (Protocolo de Segurança de Transporte), a versão atual do HTTPS foi especificada formalmente pela RFC 2818 em maio de 2000.
O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como por exemplo no caso de compras online. A existência na barra de tarefas de um cadeado (que pode ficar do lado esquerdo ou direito, dependendo do navegador utilizado) demonstra a certificação de página segura (SSL). A existência desse certificado indica o uso do protocolo HTTPS e que a comunicação entre o browser e o servidor se dará de forma segura. Para verificar a identidade do servidor é necessário abrir esse certificado com um duplo clique no cadeado para exibição do certificado.
Nas URLs dos sites o início ficaria 'https://'. Consulte a ajuda do seu navegador para mais informações de como ele avisa sobre sites seguros.
Um exemplo de conexão via HTTPS são os próprios sites da Wikimedia Foundation, em que é possível acessar e editar o conteúdo dos sites através de uma conexão segura. Através da URL https://secure.wikimedia.org/wikipedia/pt/wiki/Página_principal é possível editar a wikipédia em língua portuguesa.
Conexões HTTPS são frequentemente usadas para transações de pagamentos na World Wide Web e para transações sensíveis em sistemas de informação corporativos. Porém, o HTTPS não deve ser confundido com o menos utilizado protocolo "Secure HTTP" (S-HTTP), especificado na RFC 2660.
Diferenças para o HTTP
As URLs HTTPS começam com "https://" e utilizam a porta 443 como padrão, enquanto as URLs HTTP começam com "http://" e utilizam a porta 80 como padrão. HTTP é inseguro e sujeito a ataques de homem-no-meio e escutas ilegais, que podem levar a atacantes ganharem acesso a contas de páginas na web e a informações sensíveis. O HTTPS foi projetado para proteger contra esses ataques e é considerado seguro contra eles (com exceção de versões mais antigas e obsoletas do SSL).
Camadas de rede
HTTP opera na camada superior do Modelo OSI, a camada de aplicação, mas o protocolo de segurança opera em uma sub-camada inferior, criptografando uma mensagem HTTP antes de sua transmissão e decriptando a mensagem assim que ela chega. Estritamente falando, HTTPS não é um protocolo separado, mas se refere ao uso do HTTP sobre uma camada encriptada de conexão SSL/TLS.
Tudo na mensagem HTTPS é criptografado, incluindo os cabeçalhos, as requisições e respostas. Com a exceção de possíveis ataques criptográficos CCA descritos na seção de limitações abaixo, o atacante pode apenas conhecer o fato de que a conexão está sendo feita entre duas partes já conhecidas por ele, o nome do domínio e o endereço IP.
Configuração do Servidor
Para preparar uma página web de modo a aceitar conexões HTTPS, o administrador deve criar um certificado de chave pública para o servidor web. Esse certificado deve ser assinado por uma autoridade de certificação confiável para que o navegador aceite a conexão e não exiba avisos. A autoridade certifica que o proprietário do certificado é o operador do servidor web que o apresenta. Os navegadores web são geralmente distribuídos com uma lista de autoridades de certificação de assinatura para que elas possam verificar certificados assinados por eles.
Adquirindo certificados
Certificados assinados por autoridades podem ser de graça 3 4 ou custar entre 13 5 dólares e 1.500 6 dólares por ano.
Organizações podem também ter sua própria autoridade de certificação, particularmente se são responsáveis por configurar navegadores para acessar suas próprias páginas (por exemplo, páginas de uma rede interna ou de uma grande universidade). Elas podem facilmente adicionar cópias de seus próprios certificados na lista de certificados distribuída no navegador.
Existe também uma autoridade de certificação ponto-a-ponto, a CACert .
Uso como controle de acesso
O sistema pode também ser utilizado para autenticação de clientes, com o objetivo de limitar o acesso a servidores web a usuários autorizados. Para fazê-lo, o administrador da página tipicamente cria um certificado para cada usuário, que é carregado em seu navegador. Normalmente, o certificado contém o nome e endereço de e-mail do usuário autorizado e é automaticamente verificado pelo servidor em cada reconexão para verificar a identidade do usuário, muitas vezes sem a necessidade de utilização de senhas.
Caso uma chave privada tenha sido comprometida[editar | editar código-fonte]
O certificado pode ser revogado antes de expirar, por exemplo por conta da chave privada ter sido comprometida. Versões mais novas de navegadores populares como o Google Chrome, Firefox 8 , Opera 9 , e o Internet Explorer no Windows Vista implementam o OCSP (Protocolo de Certificação Online de Estado) para verificar essa possível falha. O navegador envia, então, o número de série do certificado a uma autoridade de certificação via OCSP e a autoridade responde, informando ao navegador se o certificado ainda é válido. 10
Limitações
O SSL se apresenta em duas versões: simples e mútua. A versão mútua é mais segura, porém requer que o usuário instale um certificado pessoal em seu navegador para que possa se autenticar. Independente da estratégia utilizada (simples ou mútua), o nível de proteção depende fortemente da corretude da implementação do navegador, da implementação do servidor e dos algoritmos critográficos suportados.
O SSL não previne a página inteira de ser indexada utilizando um web crawler e, em alguns casos, a URI do recurso criptografado pode ser inferida sabendo-se apenas o tamanho da requisição ou da resposta . Isso permite a um atacante ter acesso ao texto plano (o conteúdo propriamente dito) e ao texto encriptado (a versão criptografada do texto plano), permitindo um ataque criptográfico.
Por conta do SSL operar abaixo do HTTP e não ter conhecimento de protocolos de níveis superiores, servidores SSL podem apenas apresentar um certificado para uma combinação particular de IP/porta 12 . Isto significa que, na maioria dos casos, não é factível usar Hospedagem Virtual Baseada em Nome com HTTPS. Existe uma solução denominada Indicação de Nomes para Servidores (SNI), que envia o nome do host ao servidor antes de encriptar a conexão, embora muitos navegadores mais antigos não suportem essa extensão. Suporte para o SNI está disponível desde o Firefox 2, Opera 8, Safari 2.1, Google Chrome 6 e Internet Explorer 7 no Windows Vista.
Se controles parentais são ativados no Mac OS X, páginas HTTPS devem ser explicitamente permitidas utilizando a lista Always Allow (Sempre Permitir).
De um ponto de vista arquitetural:
Uma conexão SSL/TLS é gerenciada pela máquina que inicializa a conexão SSL. Se. por algum motivo (roteamento, otimização de tráfego etc), essa máquina não é a aplicação do servidor e ela tem que decifrar dados, soluções têm de ser encontradas para propagar as informações de autenticação - ou certificado - do usuário para a aplicação do servidor, que necessita saber quem irá se conectar.
Para um SSL com autenticação mútua, a sessão SSL/TLS é gerenciada pelo primeiro servidor que inicializa a conexão. Em situações em que encriptação necessita ser propagada por servidores em cadeia, se torna mais difícil gerenciar o timeOut da sessão.
Com SSL/TLS com autenticação mútua, a segurança é maximal, mas no lado do cliente não há uma maneira de finalizar apropriadamente a conexão SSL e se desconectar. É preciso esperar que a sessão SSL expire ou finalize todas as aplicações do cliente.
Por motivos de desempenho, conteúdo estático que não é específico ao usuário ou à transação e, por isso, não privado, é normalmente entregue a um servidor não encriptado ou a uma outra instância sem SSL do servidor. Como consequência, esse conteúdo não fica protegido. Muitos navegadores alertam o usuário quando uma página misturou recursos criptografados e não criptografados.
Um ataque sofisticado de homem-no-meio foi apresentado na Blackhat Conference 2009. Esse tipo de ataque derrota a segurança fornecida pelo HTTPS modificando um link https: para um link http:, tirando proveito do fato de que poucos usuários da Internet digitam "https" nos seus navegadores. Os usuários normalmente alcançam páginas seguras clicando em um link, podendo ser, assim, levados a pensar que estão usando HTTPS quando de fato estão usando HTTP. O atacante, então, consegue se comunicar de modo não criptografado com o cliente. 17
História
A Netscape Communication criou o HTTPS em 1994 para seu navegador Netscape. 18 Originalmente, o HTTPS foi utilizado com o protocolo SSL. À medida que o SSL evoluiu para o TLS (Protocolo de Segurança de Transporte), a versão atual do HTTPS foi especificada formalmente pela RFC 2818 em maio de 2000.
Nenhum comentário:
Postar um comentário