Saltar para o conteúdo

Hyper Text Transfer Protocol Secure: diferenças entre revisões

Origem: Wikipédia, a enciclopédia livre.
Explorar interativamente o histórico
← Ver a alteração anteriorVer a alteração posterior →
Conteúdo apagado Conteúdo adicionado
VisualTexto wiki
Profvalente (discussão | contribs)
2 631 edições
m
Linha 13: Linha 13:
==Visão geral==
==Visão geral==
{{detalhes|Transport Layer Security}}
{{detalhes|Transport Layer Security}}
HTTPS é um esquema URI, isto é, com exceção do esquema de tokens, é sintaticamente idêntico ao esquema HTTP utilizado para conexões normais HTTP, mas sinaliza o navegador para utilizar uma camada adicional de criptografia utilizando SSL/TLS para proteger o tráfego. SSL é especialmente adequado a HTTP porque pode fornecer proteção mesmo se apenas uma das partes comunicantes esteja [[autenticação|autenticada]]. Este é o caso das transações HTTP na Internet, em que tipicamente apenas o servidor está autenticado, através da verificação de seu [[Certificado_digital|certificado]] realizada pelo cliente.
HTTP é um protoncolo de redes baseado em um sistema de transferencia de arquivo HTML criardo em 1991 por um Filandes jogador de basquete. Em fevereiro de 1991 ele teve a ideia de criação do HTTP quando observava o voo de gansos rozas, neste dia ele escreveu um artigo sobre sua ideia que foi totalmente rejeitada. Em 1992 Bill Gates, vendo esta ideia, implementou seu navegador (que se chamava Safari e seu nome foi mudado para Internet Explorer) este protoncolo, que acabou bombando no orkut da epoca (ICQ).HTTPS é um esquema URI, isto é, com exceção do esquema de tokens, é sintaticamente idêntico ao esquema HTTP utilizado para conexões normais HTTP, mas sinaliza o navegador para utilizar uma camada adicional de criptografia utilizando SSL/TLS para proteger o tráfego. SSL é especialmente adequado a HTTP porque pode fornecer proteção mesmo se apenas uma das partes comunicantes esteja [[autenticação|autenticada]]. Este é o caso das transações HTTP na Internet, em que tipicamente apenas o servidor está autenticado, através da verificação de seu [[Certificado_digital|certificado]] realizada pelo cliente.


A ideia principal do HTTPS é criar um canal seguro sobre uma rede insegura. Isso garante uma proteção razoável de pessoas que realizam escutas ilegais (os chamados [[Eavesdropping|eavesdroppers]]) e de ataques de homem-no-meio ([[Ataque_man-in-the-middle|man-in-the-middle]]), dado que a cifragem foi adequadamente utilizada e que o certificado do servidor é verificável e confiável.
A ideia principal do HTTPS é criar um canal seguro sobre uma rede insegura. Isso garante uma proteção razoável de pessoas que realizam escutas ilegais (os chamados [[Eavesdropping|eavesdroppers]]) e de ataques de homem-no-meio ([[Ataque_man-in-the-middle|man-in-the-middle]]), dado que a cifragem foi adequadamente utilizada e que o certificado do servidor é verificável e confiável.

Revisão das 13h46min de 4 de outubro de 2013

Pilha de protocolos TCP/IP
Camada de aplicação
Camada de transporte
Camada de rede
Camada de enlace de dados

HTTPS (HyperText Transfer Protocol Secure), é 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.

Visão geral

Ver artigo principal: Transport Layer Security

HTTP é um protoncolo de redes baseado em um sistema de transferencia de arquivo HTML criardo em 1991 por um Filandes jogador de basquete. Em fevereiro de 1991 ele teve a ideia de criação do HTTP quando observava o voo de gansos rozas, neste dia ele escreveu um artigo sobre sua ideia que foi totalmente rejeitada. Em 1992 Bill Gates, vendo esta ideia, implementou seu navegador (que se chamava Safari e seu nome foi mudado para Internet Explorer) este protoncolo, que acabou bombando no orkut da epoca (ICQ).HTTPS é um esquema URI, isto é, com exceção do esquema de tokens, é sintaticamente idêntico ao esquema HTTP utilizado para conexões normais HTTP, mas sinaliza o navegador para utilizar uma camada adicional de criptografia utilizando SSL/TLS para proteger o tráfego. SSL é especialmente adequado a HTTP porque pode fornecer proteção mesmo se apenas uma das partes comunicantes esteja autenticada. Este é o caso das transações HTTP na Internet, em que tipicamente apenas o servidor está autenticado, através da verificação de seu certificado realizada pelo cliente.

A ideia principal do HTTPS é criar um canal seguro sobre uma rede insegura. Isso garante uma proteção razoável de pessoas que realizam escutas ilegais (os chamados eavesdroppers) e de ataques de homem-no-meio (man-in-the-middle), dado que a cifragem foi adequadamente utilizada e que o certificado do servidor é verificável e confiável.

A confiança fornecida pelo HTTPS é baseada em autoridades de certificação que vêm pré-instaladas no navegador (isto é equivalente a dizer "Eu confio na autoridade de certificação VeriSign/Microsoft/etc para me dizer em quem devo confiar"). Portanto, uma conexão HTTPS pode ser confiável se e somente se todos os itens a seguir são verdade:

  1. O usuário confia que o navegador implementa corretamente HTTPS com autoridades de certificação pré-instaladas adequadamente;
  2. O usuário confia que as autoridades verificadoras só irão confiar em páginas legítimas, que não possuem nomes enganosos;
  3. A página acessada fornece um certificado válido, o que significa que ele foi assinado por uma autoridade de certificação confiável;
  4. O certificado identifica corretamente a página (por exemplo, quando o navegador acessa "https://exemplo.com", o certificado recebido é realmente de "Exemplo Inc." e não de alguma outra entidade).
  5. Ou o tráfego na internet é confiável, ou o usuário crê que a camada de encriptação do protocolo TLS/SSL é suficientemente segura contra escutas ilegais (eavesdropping).

Integração com o navegador

Muitos navegadores mostram um aviso se recebem um certificado inválido. Navegadores mais antigos, quando se conectam a uma página com um certificado inválido, mostravam ao usuário um aviso em uma caixa de diálogo e perguntavam se ele desejava continuar. Navegadores mais recentes mostram o aviso preenchendo a janela inteira e também exibem as informações de segurança da página na barra de endereços. Certificados de validação estendida tornam verde a barra de endereço em navegadores mais recentes. A maioria dos navegadores exibe, também, um aviso ao usuário quando a página visitada contém uma mistura de conteúdo criptografado e não criptografado (uma página que utiliza HTTPS mas faz referência a links HTTP de alguma forma na página, por exemplo no link de uma foto).

A maioria dos navegadores, incluindo o Firefox (mostrado aqui), utiliza a barra de endereços para avisar ao usuário que sua conexão é segura, frequentemente colorindo o fundo.
A maioria dos navegadores alerta o usuário quando uma página visitada possui um certificado de segurança inválido. Este exemplo é do Firefox.

A Electronic Frontier Foundation opinou que "em um mundo ideal, toda requisição na web poderia utilizar HTTPS como padrão" e forneceu um complemento para o Firefox chamado "HTTPS Everywhere" (HTTPS em todo lugar) que funciona em várias páginas muito visitadas. [1][2]

Aspectos técnicos

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 [7].

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

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 [11] . 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. [13] [14] [15]

Se controles parentais são ativados no Mac OS X, páginas HTTPS devem ser explicitamente permitidas utilizando a lista Always Allow (Sempre Permitir). [16]

De um ponto de vista arquitetural:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Referências

  1. ↑ Peter Eckersley: Encrypt the Web with the HTTPS Everywhere Firefox Extension EFF blog, 17 de junho de 2010
  2. ↑ HTTPS Everywhere
  3. ↑ «Free SSL Certificates from a Free Certificate Authority». sslshopper.com. Consultado em 24 de outubro de 2009 
  4. ↑ Justin Fielding (16 de julho de 2007). «Secure Outlook Web Access with (free) SSL: Part 1». TechRepublic. Consultado em 24 de outubro de 2009 
  5. ↑ «SSL Certificate Services». Go Daddy. Consultado em 6 de maio de 2009 
  6. ↑ «Secure Site Pro with EV». VeriSign. Consultado em 6 de maio de 2009 
  7. ↑ «Página do CACert». CACert. Consultado em 8 de dezembro de 2011 
  8. ↑ «Mozilla Firefox Privacy Policy». Mozilla Foundation. 27 de abril 2009. Consultado em 13 de maio de 2009 
  9. ↑ «Opera 8 launched on FTP». Softpedia. 19 de abril de 2005. Consultado em 13 de maio de 2009 
  10. ↑ Myers, M; Ankney, R; Malpani, A; Galperin, S; Adams, C (1999). «Online Certificate Status Protocol - OCSP». Internet Engineering Task Force. Consultado em 13 de maio de 2009 
  11. ↑ Pusep, Stanislaw (31 de julho de 2008). «The Pirate Bay un-SSL». Consultado em 6 de março de 2009 
  12. ↑ Apache FAQ: Why can't I use SSL with name-based/non-IP-based virtual hosts?
  13. ↑ Lawrence, Eric (22 de outubro de 2005). «Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2». Microsoft. Consultado em 12 de maio de 2009 
  14. ↑ Server Name Indication (SNI)
  15. ↑ Pierre, Julien. «Browser support for TLS server name indication» (10/12/2011). Bugzilla. Mozilla Foundation. Consultado em 15 de dezembro de 2010 
  16. ↑ Pierre, Julien. «Mac OS X v10.5, 10.6: About the Parental Controls Internet content filter» (30/03/2010). Support. Apple, Inc. Consultado em 15 de dezembro de 2010 
  17. ↑ «sslstrip». Consultado em 26 de novembro de 2011 
  18. ↑ Walls, Colin (2005). Embedded software. [S.l.: s.n.] 344 páginas 

Ligações externas

Obtida de "https://pt.wikipedia.org/w/index.php?title=Hyper_Text_Transfer_Protocol_Secure&oldid=37044668"