Curso MIT "Segurança de sistemas de computadores". Palestra 14: “SSL e HTTPS”, parte 3

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3
Palestra 10: “Execução Simbólica” Parte 1 / Parte 2 / Parte 3
Aula 11: “Linguagem de Programação Ur / Web” Parte 1 / Parte 2 / Parte 3
Aula 12: Segurança de rede Parte 1 / Parte 2 / Parte 3
Aula 13: “Protocolos de Rede” Parte 1 / Parte 2 / Parte 3
Palestra 14: “SSL e HTTPS” Parte 1 / Parte 2 / Parte 3

Penso que a aplicação do HTTPS se deve à preocupação de usuários que têm muita discrição ao decidir se devem usar certificados.

Outro problema que se manifesta na prática e que também força o uso de HTTPS é um anexo inseguro ou conteúdo misto em uma página da web. O ponto desse problema é que um site seguro ou qualquer site, nesse caso, pode incorporar outras partes do conteúdo em uma página da web.

Portanto, se você tem algum tipo de site, por exemplo, foo.com/index.html, ele pode ser veiculado usando o protocolo HTTPS, mas dentro da página HTML você pode ter muitas tags que obrigam o navegador a ir a algum lugar e fazer parte dele Esta página possui algum tipo de conteúdo estranho.



A tag para este cenário é semelhante a esta:

<script scr = «http://jquery.com/…”> 

E aponta para a fonte do jquery.com. Assim, a popular biblioteca JavaScript facilita a interação de muitas coisas no seu navegador. Mas muitos desenvolvedores da web simplesmente vinculam ao URL de outro site. Isso facilita as coisas, mas qual poderia ser o problema? Suponha que você tenha um site seguro e faça o download do jQuery a partir daí.

Aluno: pode ser jQuery falso.

Professor: sim, é. Na verdade, existem duas maneiras de obter a coisa errada que você não espera receber. Uma possibilidade é que o próprio jQuery possa estar comprometido. Você obteve algo semelhante ao que solicitou. Se o jQuery estiver comprometido, isso será muito ruim. Outra possibilidade é que essa solicitação seja enviada pela rede sem nenhuma criptografia ou autenticação. Portanto, se o adversário controlar sua conexão de rede, ele poderá interceptar essa solicitação e enviar outro código JavaScript em resposta, e agora esse código JavaScript funcionará como parte da sua página. E como ele trabalha neste domínio HTTPS foo.com, ele tem acesso aos cookies protegidos foo.com e qualquer outra coisa nesta página. Isso parece uma coisa muito ruim, então tenha cuidado. E o desenvolvedor da web também precisa ter cuidado para não cometer esse tipo de erro.

Portanto, uma das soluções é garantir a segurança de todo o conteúdo incorporado em uma página segura. Esta é uma boa diretriz para muitos desenvolvedores da web seguirem. Então, talvez você deva usar jquery.com nesta linha em vez de jquery.com . Ou se os URLs suportarem a política de origem, isso significa que você pode omitir parte do HTTPS e apenas dizer que a origem desse script é //jquery.com/, ou seja, scr = "//jquery.com / ..."



E isso significa que essa tag o enviará para jquery.com, se estiver na página HTTPS, e para jquery.com, se não estiver em HTTPS, mas em um URL HTTP comum. Essa é uma maneira de evitar esse problema.

No entanto, as pessoas estão constantemente tentando melhorar tudo, portanto, uma das maneiras alternativas de resolver esse problema talvez seja incluir um hash ou algo como um indicador aqui na tag:

 <script scr = «http://jquery.com/…”> 

Porque se você souber que tipo de conteúdo deseja baixar, provavelmente não precisará fazer o download completo usando o protocolo HTTPS. Na verdade, você não se importa com quem fornece esse conteúdo, desde que ele corresponda a um hash específico.

Portanto, há uma nova especificação que permite configurar hashes para tags desse tipo. Portanto, em vez de vincular ao jquery.com com um URL HTTPS, você pode simplesmente dizer que a origem do script é jquery.com ou mesmo HTTP, mas no final do script você adiciona algum tipo de atributo de tag, por exemplo, hash é igual ao que você espero obter do servidor.



Aluno: qual é o nome dessa especificação?

Professor: ele tem um nome complexo, está nas notas das notas da aula, algo como “integridade do sub-recurso”, integridade do sub-recurso. Ele está sendo implementado lentamente, mas espero que, no futuro próximo, seja aplicado em vários navegadores. Isso é semelhante a outra maneira de autenticar o conteúdo sem depender da criptografia de dados no nível da rede.

Portanto, temos esse plano geral que usa SSL e TLS para autenticar conexões com um servidor específico. Essa é uma maneira alternativa de proteger sua conexão de rede. Se você se preocupa com a integridade, pode não precisar de um canal de rede criptografado e seguro. Tudo o que você precisa fazer é especificar o que exatamente você deseja obter no final.

Aluno: Esse código SRC não vem do cliente?

Professor: ele trabalha no lado do cliente, mas o cliente recebe esse código de algum servidor.

Aluno: ninguém pode inserir o código JavaScript em uma página?

Professor: Eu acho que pode. Portanto, o significado do hash é proteger o conteúdo da página contra invasores que estão tentando inserir código JavaScript diferente. Para o jQuery, isso é muito importante porque o jQuery é bem conhecido, porque você não está tentando ocultar o código-fonte do jQuery. Portanto, você deseja garantir que um invasor de rede não possa interceptar sua conexão e inserir uma versão maliciosa do jQuery, o que levará ao vazamento de cookies. É verdade que qualquer um pode descobrir o hash dessas coisas por si mesmo. Portanto, é uma solução para problemas de integridade, não privacidade.

Eu acho que os desenvolvedores devem ficar de olho nisso quando escrevem páginas ou incluem o conteúdo de suas páginas HTML em URLs HTTPS. Outra preocupação que temos é com cookies. É aqui que a diferença entre cookies com sinalizadores de segurança e apenas cookies com origem e origem entra em jogo. A única coisa que o desenvolvedor pode estragar aqui é simplesmente esquecer de definir o sinalizador de cookies em primeiro lugar, isso acontece. Talvez ele pense apenas em usuários que acessarão apenas o URL HTTPS e considere a configuração desnecessária de sinalizadores. Isso é um problema? Se seus usuários forem muito cuidadosos e sempre visitarem URLs HTTPS, não há problema. Você acha que faz sentido deixar uma bandeira de segurança em seus cookies?

Aluno: é provável que um invasor consiga se conectar ao seu URL e redirecioná-lo para um site malicioso?

Professor: sim. Mesmo que o usuário não vá explicitamente manualmente para algum URL na forma de texto sem formatação, o invasor ainda poderá fornecer um link para um site inseguro ou solicitar que faça o download de uma imagem com um URL que não seja HTTPS. E então cookies inseguros serão enviados junto com a solicitação de rede. Portanto, isso é um problema e você realmente precisa de um sinalizador, mesmo que seus usuários e seus aplicativos sejam muito cuidadosos.

Aluno: Presumo que haja URLs HTTP seguros.
Professor: sim, é verdade. Suponha que eu tenha um site que nem esteja escutando na porta 80 e que não haja maneira de conectar-me através da porta 80; então, por que poderia haver um problema se eu usar cookies não seguros?

Aluno: porque o navegador não poderá enviar seus cookies para outro domínio.

Professor: Isso mesmo, o navegador não envia cookies para outro domínio, mas ainda existe o perigo de um invasor fazer o download de seu URL. Portanto, suponha que o amazon.com use apenas SSL, nem escute na porta 80. Como resultado, eles não definem seu sinalizador seguro nos cookies. Então, como um hacker pode roubar seus cookies se a Amazon nem escuta na porta 80?

Aluno: o navegador ainda pode pensar que esta é uma conexão HTTP?

Professor: bem, se você se conectar à porta 443 e usar SSL ou TLS, a conexão sempre será criptografada, portanto isso não é um problema.

Aluno: Um invasor pode interceptar a conexão.

Professor: sim, um invasor pode interceptar seus pacotes que estão tentando se conectar ao Amazon através da porta 80 e fingir que você se conectou com êxito ao site. Portanto, se um invasor tiver controle sobre sua rede, ele poderá redirecionar seus pacotes direcionados para a Amazon para a porta 80 de sua própria máquina, e o cliente não poderá ver a diferença. Parece que a Amazon estava escutando na porta 80, mas, na realidade, seus cookies serão enviados para o servidor da web desse hacker.

Aluno: porque o cliente é desconhecido.

Professor: Isso mesmo, já que o HTTP não tem como verificar a autenticidade do host ao qual você está conectado. É exatamente isso que está acontecendo. HTTP não tem autenticação. Portanto, se você presumir que há um adversário na rede, você deve primeiro impedir que seus cookies sejam enviados via HTTP, porque você não tem idéia para quem essa conexão HTTP irá.

Aluno: para isso, você precisa controlar a rede.

Professor: sim, claro. Se você tem controle total sobre sua rede, sabe que os oponentes não poderão interceptar seus pacotes. No entanto, mesmo com controle total sobre a rede, você pode ter problemas, veja os materiais da palestra sobre TCP, vários tipos de ataques à rede foram considerados lá.

Público-alvo: neste caso, não é possível impedir um ataque de redirecionamento?

Professor: o hacker provavelmente interceptará a solicitação http do cliente no amazon.com , e essa solicitação incluirá todos os seus cookies para amazon.com ou cookies para qualquer outro domínio ao qual você enviar a solicitação. Portanto, se você não marcar esses cookies como seguros, eles poderão ser enviados por uma conexão criptografada e não criptografada.

Aluno: como esse pedido é iniciado?

Professor: talvez você possa fazer com que o usuário visite newyorktimes.com, onde pagou por um anúncio que carregava uma imagem do amazon.com . E não há nada que impeça o usuário de perguntar: "faça o download da imagem deste URL". Mas quando o navegador tenta se conectar ao site, ele envia cookies se a conexão for bem-sucedida.

Existe uma extensão HTTPS Everywhere, muito semelhante ao Force HTTPS, ou HTTPS forçado, e que tenta impedir esse tipo de erro. Quando você seleciona um site no modo HTTPS forçado, o navegador impede principalmente as conexões HTTP com este host.



Portanto, não há como não marcar seus cookies como seguros ou cometer um erro semelhante. Se o desenvolvedor esqueceu de definir um sinalizador de segurança nos cookies, nesse caso a solução é óbvia - ele apenas precisa corrigir o erro. Mas há um problema mais delicado: quando um servidor da Web seguro recebe o cookie do cliente de volta, não faz ideia se esse cookie foi enviado por uma conexão criptografada ou de texto sem formatação. Porque, de fato, o servidor recebe apenas alguns valores-chave para o cookie.

A partir do plano de ação discutido acima, segue-se que, ao enviar uma solicitação para um servidor seguro, o navegador incluirá cookies seguros e inseguros, pois, por sua vez, está preocupado com a confidencialidade. Porém, no lado do servidor, não há garantias de confidencialidade e, quando o servidor recebe cookies do usuário, eles podem ser enviados por meio de conexões criptografadas e de texto. Isso leva à possibilidade de ataques como a fixação da sessão.

Isso significa que um invasor, por exemplo, deseja ver quais emails você envia. Para fazer isso, ele definirá seus próprios cookies, que são uma cópia dos cookies de sua conta do Gmail. E quando você enviar sua carta, ela aparecerá na pasta Itens Enviados, e não na sua pasta. Será como se você estivesse usando uma conta de invasor, para que ele pudesse extrair sua correspondência da caixa de correio dele. Portanto, se um hacker colocar à força cookies de sessão no seu navegador, ele forçará você a usar a conta dele. Portanto, esse é outro problema que surge devido a mal-entendidos com a separação incompleta de cookies HTTP e HTTPS.

Aluno: mas, para inserir seus cookies no navegador de outra pessoa, você precisa ter uma vulnerabilidade lá.

Professor: não, para definir seu cookie, a vulnerabilidade não é necessária. Você está simplesmente enganando o navegador para se conectar à URL normal do host HTTP. E se o navegador não tiver uma extensão, como Force HTTPS ou HTTPS Everywhere, você, como invasor, poderá definir a chave no navegador do usuário. Este é um cookie inseguro, mas será enviado de volta, mesmo para solicitações seguras.

Aluno: como você pode fazer o navegador pensar que esse domínio é o mesmo?
Professor: para isso, você deve interceptar a conexão de rede e realizar um dos tipos de ataques de que falamos há alguns minutos atrás.

Então, o que o HTTPS forçado realmente faz? Ele está tentando evitar alguns dos muitos problemas. Estudos sobre o protocolo Force HTTPS foram publicados há 5 ou 6 anos. Desde então, foi padronizado e realmente adotado. Parece um plugin superficial que armazena algumas coisas e alguns cookies. Hoje, a maioria dos desenvolvedores de navegadores acredita que a criação foi uma boa ideia. É melhor integrá-lo diretamente no navegador. Existe algo chamado HTTP Strict Transport Security, ou HSTS, um mecanismo para forçar uma conexão segura pelo protocolo HTTPS. Este é um bom exemplo de como a pesquisa científica afeta a segurança de aplicativos e navegadores da web.

Vamos ver o que o Force HTTPS faz por um site. O HTTPS forçado permite que um site defina esse bit para um nome de host específico e há três fatores que forçam o HTTPS a afetar o comportamento do navegador.

A primeira é que qualquer erro de certificado é sempre fatal. Portanto, o usuário não tem chance de aceitar o certificado errado com o nome do host errado ou expirado, e assim por diante. Isso é uma coisa que muda o navegador.

A segunda coisa é que o Force HTTPS redireciona todas as solicitações HTTP para HTTPS. Esta é uma boa ideia. Se você sabe que o site sempre usa legitimamente HTTPS, provavelmente deve proibir quaisquer solicitações HTTP regulares, porque isso pode ser um sinal de algum tipo de erro ou evidência de que um invasor está tentando induzi-lo a oferecer a conexão ao site sem criptografia . Você deseja garantir que isso realmente ocorra antes da solicitação HTTP ser executada, caso contrário, qualquer solicitação HTTP já entraria na rede.

E a última coisa que o Force Force HTTPS força o navegador a fazer é proibir o plano de incorporação inseguro que analisamos anteriormente - quando você incorpora um URL HTTP em um site HTTPS.



Portanto, é isso que a extensão Force HTTPS faz. Com base na terminologia usada hoje, o protocolo HSTS faz o mesmo. Agora, a maioria dos navegadores proíbe a incorporação insegura. Isso foi controverso, pois muitos desenvolvedores tiveram problemas devido ao Force HTTPS, mas acho que Firefox, Chrome e IE se recusam a carregar componentes inseguros ou, pelo menos, JavaScript e CSS inseguros na sua página, se você então faça errado.

Aluno: eles não perguntam ao usuário sobre a execução de alguma ação?

Professor: eles estão acostumados ao fato de que geralmente o usuário concorda. Por exemplo, o IE usa uma caixa de diálogo pop-up que pergunta se você deseja baixar conteúdo adicional ou algo assim. Acho que, se você tentar, poderá contornar todas essas medidas de segurança, mas não aconselho você a fazer isso. Assim, os navegadores modernos tentam resolver alguns dos problemas usando o Force HTTPS e o HSTS.

Aluno: o que acontece quando um site não suporta HTTPS?

Professor: o que você quer dizer?

Aluno: que o navegador não se conectará ao site via HTTPS.

Professor: o que acontece se você tiver um site que não suporta HTTPS, mas define esses cookies? O fato é que, se você usar essa opção no navegador, não poderá conversar com a maior parte da Internet, porque eles não usam HTTPS. Portanto, o navegador deve poder se comunicar via HTTPS com os sites que realmente desejam essa proteção.

Aluno: se bem me lembro, você não pode definir um cookie até que o site permita.

Professor: sim, é verdade. Esses caras estão preocupados com ataques de DoS, nos quais esse plug-in pode ser usado para causar problemas a outros sites. Por exemplo, se você definir o bit Force HTTPS para alguns sites inocentes, eles parariam de funcionar repentinamente, porque agora todos tentariam se conectar a eles via HTTPS, aos quais não suportam. Portanto, este é um exemplo que se preocupa com a possibilidade de usar um ataque de DoS usando HTTPS forçado para sites que não contam com isso.

Outra coisa é que esse protocolo não suporta o uso do Force HTTPS para todo o domínio. Por exemplo, eu sou um usuário mit.edu que configurou cookies Force HTTPS em todos os navegadores e agora apenas as conexões HTTPS funcionam no MIT. Isso parece um pouco catastrófico, então você provavelmente deseja evitar uma situação semelhante.

Por outro lado, o protocolo HSTS voltou a isso, dizendo que você pode definir o Force HTTPS para todo o subdomínio, porque é útil para cookies não seguros enviados junto com a solicitação, se você não souber de onde eles foram originalmente enviados. Existem várias configurações para essas coisas no nível mais baixo, mas ainda não está claro o que a escolha certa significa neste caso.

Há uma pergunta interessante que você poderia fazer: essas melhorias são fundamentais ou destinam-se apenas a ajudar os desenvolvedores a evitar erros? Suponha que você tenha um desenvolvedor muito responsável que não execute ações perigosas, atualize os certificados a tempo, elabore novos - ele precisa usar o Force HTTPS?

Aluno: é claro, porque nada impedirá o hacker de forçar o usuário a baixar algo via HTTP e interceptar a conexão.

Professor: é verdade. Mas se você acha que ele é muito diligente e todos os cookies estão marcados como seguros, se alguém visitar a versão HTTP do seu site, isso não deverá causar problemas.



No entanto, você provavelmente ainda precisa se defender contra a substituição de cookies ou ataques de injeção. Isso é cansativo, mas você provavelmente pode fazer algo a respeito.

Aluno: Acho que o desenvolvedor, em qualquer caso, não poderá verificar a autenticidade do certificado, certo?

: , : « ». , , , , , . : «, !», , , - - . , .

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

Obviamente, atualmente o Google diz que qualquer site pode ser incluído no navegador porque a lista existente é muito pequena, mas se aumentar para milhões de entradas, tenho certeza que o Google deixará de incluir todos os sites na lista de navegadores. Mas agora você pode adicionar seu domínio lá simplesmente enviando um email para os desenvolvedores do Chrome e seu site será listado nos URLs HTTPS da Força.


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps da US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD de 1Gbps até dezembro de graça quando pagar por um período de seis meses, você pode fazer o pedido aqui .

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?