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

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

A primeira razão é que o protocolo OCSP adiciona um atraso a cada solicitação que você faz. Cada vez que você deseja se conectar a um servidor, primeiro você precisa se conectar ao OCSP, aguardar que ele responda e depois fazer outra coisa. Portanto, os atrasos na conexão não contribuem para a popularidade deste protocolo.

O segundo motivo é que você não deseja que o OCSP afete sua capacidade de navegar na web. Suponha que o servidor OSCP esteja inoperante e você possa perder completamente a Internet, porque o protocolo considera que, como não é possível verificar o certificado de alguém, é possível que todos os sites na Internet sejam ruins e você não deve ir lá. Como ninguém precisa disso, a maioria dos clientes vê a não interferência do servidor OCSP como um desenvolvimento positivo.



Isso é realmente ruim do ponto de vista da segurança. Como se você é um invasor e deseja convencer alguém de que possui um certificado legal, mas, na realidade, esse certificado foi revogado, tudo o que você precisa fazer é impedir que o cliente se comunique com o servidor OCSP.

O cliente dirá o seguinte: "Estou tentando solicitar uma verificação de certificado do site de que preciso, mas esse OCSP, ao que parece, não está próximo, então apenas vou a este site". Portanto, usar o OCSP não é um bom plano.

Na prática, as pessoas tentam criar essa alternativa, porque os clientes tendem a cometer erros graves. Assim, por exemplo, o navegador Chrome é entregue ao cliente, já tendo em si uma lista de certificados que o Google realmente deseja revogar. Portanto, se alguém emitir um certificado incorretamente para o Gmail ou outro site importante, como o Facebook ou a Amazon, a próxima versão do Chrome já conterá essas informações na lista de verificação interna. Dessa forma, você não precisa acessar o servidor CRL e se comunicar com o OCSP. Se o navegador tiver verificado que o certificado não é mais válido, o cliente o rejeitará.

Aluno: digamos que roubei a chave secreta da CA, porque nem todas as chaves públicas são criptografadas?

Professor: Sim, isso terá consequências ruins. Eu não acho que exista solução para esse problema. Obviamente, houve situações em que os centros de certificação foram comprometidos; por exemplo, em 2011, havia duas CAs comprometidas que de alguma forma emitiram certificados para o Gmail, Facebook e assim por diante. Não está claro como isso aconteceu, talvez alguém realmente tenha roubado sua chave secreta. Mas, independentemente dos motivos do comprometimento, essas CAs foram removidas da lista de autoridades de certificação confiáveis, incorporadas aos navegadores, de modo que não estavam mais na próxima versão do Chrome.

De fato, isso causou problemas para os titulares legítimos de certificados emitidos por esses centros, porque seus certificados anteriores se tornaram inválidos e eles tiveram que obter novos certificados. Então, na prática, todo esse barulho com certificados é um assunto bastante confuso.

Então, examinamos o princípio geral dos certificados. Eles são melhores que o Kerberos no sentido de que você não precisa mais desse cara para ficar online o tempo todo. Além disso, eles são mais escaláveis, porque você pode ter vários KDCs e não precisa se comunicar com eles sempre que estabelecer uma conexão.

Outro recurso interessante desse protocolo é que, diferentemente do Kerberos, você não precisa autenticar os dois lados da conexão. Você pode se conectar ao servidor da web sem ter um certificado para si mesmo, e isso acontece o tempo todo. Se você acessar o site amazon.com, verificará se o site da Amazon é o certo, mas a Amazon não tem idéia de quem você é e não saberá até que você se autentique no site. Portanto, no nível do protocolo de criptografia, você não possui um certificado, mas a Amazon possui um.

Isso é muito melhor que o Kerberos, porque você deve ter uma entrada em seu banco de dados para se conectar aos serviços Kerberos. O único inconveniente de usar este protocolo é que o servidor deve ter um certificado. Portanto, você não pode se conectar ao servidor e dizer: "Ei, vamos criptografar nossas coisas. Não tenho idéia de quem você é, mas você não tem idéia de quem eu sou, mas vamos criptografá-lo de qualquer maneira. Isso é chamado de criptografia oportunista e, é claro, é vulnerável a ataques intermediários. Você pode criptografar coisas comuns com alguém, sem conhecê-lo; em seguida, um invasor que está se preparando para atacar você também pode criptografar seus pacotes mais tarde e se proteger de bisbilhoteiros.

Por isso, é uma pena que esses protocolos que estamos considerando aqui - SSL, TLS - não ofereçam esse tipo de criptografia oportunista. Mas assim é a vida.



Aluno: Estou apenas curioso. Digamos que uma vez por ano, eles criem pares de chaves com novos nomes. Por que não tentar usar essa chave específica o ano todo?

Professor: Eu acho que eles fazem isso. Mas algo parece estar errado com este circuito. Aqui, como no Kerberos, as pessoas começam usando criptografia forte, mas, com o tempo, fica cada vez pior. Os computadores estão se tornando mais rápidos, novos algoritmos estão sendo desenvolvidos para quebrar com êxito essa criptografia. E se as pessoas não se importam em melhorar a confiabilidade, os problemas aumentam. Por exemplo, acontece quando um grande número de certificados é assinado.

Existem duas nuances aqui. Existe um esquema de assinatura de chave pública. Além disso, como a chave pública criptografada tem algumas limitações, ao assinar uma mensagem, na realidade, apenas o hash dessa mensagem é assinado, porque é difícil assinar uma mensagem gigantesca, mas é fácil assinar um hash compacto.

O problema surgiu porque as pessoas usavam o MD5 como uma função de hash, transformando a assinatura de uma mensagem enorme em algo de 128 bits criptografado. Talvez o MD5 tenha sido bom há 20 anos, mas com o tempo, as pessoas descobriram pontos fracos que poderiam ser explorados por um invasor.

Suponha que, em algum momento, alguém realmente solicite um certificado com um hash MD5 específico e analise cuidadosamente outra mensagem que foi hash com o mesmo valor MD5. Como resultado, ele tinha uma assinatura de CA com hash e, em seguida, outra mensagem apareceu, ou uma chave diferente ou um nome diferente, e agora ele pode convencer alguém de que está assinada com o certificado correto. E isso está realmente acontecendo. Por exemplo, se você gastar muito tempo tentando quebrar uma chave, terá êxito. Se este certificado usar criptografia, ele poderá ser quebrado usando o método de força bruta.

Outro exemplo de uso malsucedido da criptografia é o algoritmo RSA. Não falamos sobre o RSA, mas o RSA é um desses sistemas criptográficos de chave pública que permite criptografar e assinar mensagens. Hoje em dia, você pode gastar muito dinheiro, mas no final, quebra as chaves RSA de 1000 bits. Você provavelmente terá que fazer uma quantidade gigantesca de trabalho, mas isso é fácil de fazer ao longo do ano. Você pode solicitar à autoridade de certificação para assinar uma mensagem ou até mesmo pegar a chave pública existente de alguém, tentar encontrar a chave secreta apropriada para ela ou cortá-la manualmente.
Portanto, você deve acompanhar o invasor, usar chaves RSA maiores ou usar um esquema de criptografia diferente.

Por exemplo, agora as pessoas não usam hashes e certificados MD5. Eles usam o algoritmo de hash criptográfico SHA-1. Por algum tempo, forneceu a segurança necessária, mas hoje é uma defesa fraca. Agora, o Google está ativamente tentando forçar desenvolvedores da Web e desenvolvedores de navegadores a abandonar o uso do SHA-1 e usar uma função de hash diferente, porque é claro que, talvez depois de 5 ou 10 anos, atacar com êxito o SHA-1 não será difícil. Sua fraqueza já foi comprovada.

Então, eu acho que a bala mágica, como tal, não existe. Você só precisa ter certeza de que continua desenvolvendo em paralelo com os hackers. Claro, o problema existe. Portanto, todas as coisas sobre as quais falamos devem se basear na criptografia adequada ou no fato de ser muito difícil de decifrar. Portanto, você deve escolher as opções apropriadas. Pelo menos, existe uma data de validade, portanto, é melhor escolher uma data de validade de 1 ano, em vez de 10 anos.



Essa chave de CA cria um problema mais sério, pois não tem uma data de validade. Portanto, você deve escolher configurações de segurança mais agressivas, por exemplo, chaves RSA de 4000 ou 6000 bits ou outra coisa. Ou um esquema de criptografia diferente, ou todos juntos, mas não use SHA-1 aqui.

Agora vamos ver como integramos esse protocolo em um aplicativo específico, a saber, um navegador da web. Se você deseja fornecer comunicação de rede ou comunicação com sites usando criptografia, há três coisas no navegador que devemos proteger.

A primeira coisa, A é a proteção de dados na rede. Isso é relativamente fácil, porque apenas vamos executar um protocolo muito semelhante ao que eu descrevi até agora. Vamos criptografar todas as mensagens, assiná-las, garantir que elas não tenham sido adulteradas; em geral, faremos todas essas coisas maravilhosas. É assim que protegeremos os dados.

Mas há mais duas coisas no navegador da Web com as quais realmente precisamos nos preocupar. Portanto, o primeiro, B, é o código usado no navegador, por exemplo, JavaScript ou dados importantes armazenados no navegador, nos cookies ou no armazenamento local, tudo isso deve estar protegido de alguma forma contra hackers. Em um segundo, vou lhe dizer como protegê-los.

O último, C, no qual você geralmente não pensa, mas o que pode se tornar um problema real na prática, é proteger a interface do usuário. E a razão para isso é que, em última instância, a maioria dos dados confidenciais com os quais nos preocupamos com proteção vem do usuário. Portanto, o usuário imprime dados em algum site e ele provavelmente tem várias guias de sites diferentes abertas simultaneamente, para poder distinguir com qual site ele está realmente interagindo, a qualquer momento.



Se ele acidentalmente digitar a senha da Amazon em algum fórum da web, isso não levará a conseqüências desastrosas, dependendo de quanto ele se preocupa com a senha da Amazon, mas ainda assim será desagradável. Portanto, você realmente deseja ter uma boa interface do usuário que ajude o usuário a entender o que está fazendo, se ele imprime dados confidenciais no site certo e se algo acontece com esses dados depois que ele os envia. Portanto, essa é uma questão muito importante para proteger aplicativos da Web.

Então, vamos falar sobre o que os navegadores modernos fazem com essas coisas A, B e C. Como mencionei, para proteger os dados na rede, simplesmente usaremos esse protocolo, chamado SSL ou TLS, se criptografia e autenticação de dados forem usadas.



Isso é muito semelhante ao que discutimos e inclui autoridades de certificação e assim por diante. E então, é claro, há muitos mais detalhes. Por exemplo, o TLS é extremamente complexo, mas não o consideraremos desse ponto de vista. Vamos nos concentrar na proteção do navegador, que é muito mais interessante. Precisamos garantir que qualquer código ou dado entregue através de conexões não criptografadas não seja capaz de alterar o código e os dados recebidos de uma conexão criptografada, porque nosso modelo de ameaça é tal que todos os dados não criptografados podem ser falsificados por um invasor na rede.

Portanto, se tivermos algum tipo de código JavaScript não criptografado que é executado em nosso navegador, devemos assumir que ele pode ter sido violado por um invasor porque não foi criptografado. Não foi autenticado pela rede. E, portanto, devemos impedir sua interferência de qualquer página entregue por meio de uma conexão não criptografada.

Portanto, o plano geral é que, para isso, introduzamos um novo esquema de URL, que chamaremos de HTTPS. Você costuma ver isso nos URLs. O novo esquema de URL é que agora esses URLs são simplesmente diferentes dos endereços HTTP. Portanto, se você tiver um URL com este HTTPS: //, ele terá uma origem de origem diferente dos URLs HTTP comuns, porque os últimos passam por patches não criptografados, eles passam por SSL / TLS. Dessa forma, você nunca confundirá esses tipos de endereços se a mesma política de origem funcionar corretamente.

Portanto, esta é uma peça do quebra-cabeça. Mas também é necessário garantir a distinção correta entre sites criptografados, porque, por motivos históricos, eles usam políticas de cookies diferentes. Então, vamos falar primeiro sobre como distinguiremos diferentes sites criptografados um do outro.

O plano é que o nome do host através da URL seja o nome no certificado. De fato, as autoridades de certificação assinam o nome do host, que aparece no URL como o nome da chave pública do servidor da web. Como tal, a Amazon supostamente possui um certificado para www.amazon.com . Este é o nome em nossa tabela que possui a chave pública correspondente à sua chave privada.



É isso que o navegador procurará. Portanto, se ele recebe um certificado, se ele tenta se conectar ou obter o URL foo.com , significa que o servidor representa com precisão o certificado autêntico foo.com. Caso contrário, digamos, tentamos entrar em contato com um cara e contatamos outro, porque ele tem um nome completamente diferente no certificado ao qual nos conectamos. Isso será uma incompatibilidade de certificado.

Veja como distinguiremos sites diferentes um do outro: levaremos a CA para isso para nos ajudar a distinguir esses sites um do outro, porque os CAs prometem emitir certificados apenas para os membros de rede certos. Portanto, isso faz parte da mesma política de origem, segundo a qual dividimos o código em partes. Como você se lembra, os cookies têm uma política um pouco diferente. Eles são quase da mesma origem, mas não exatamente, os cookies têm um plano um pouco diferente. Os cookies têm o chamado sinalizador de segurança, Secure Flag. A regra é que, se os cookies tiverem esse sinalizador, eles serão enviados apenas em resposta a solicitações HTTPS ou em conjunto com solicitações HTTPS. Os cookies com e sem um sinalizador de segurança se relacionam entre si como solicitações https e http.



Isso é um pouco complicado. Seria mais fácil se um cookie simplesmente indicasse que era um cookie para o host HTTPS, e era um cookie para o host HTTP, e eles eram completamente diferentes. Isso ficaria muito claro em termos de isolamento de sites seguros de sites inseguros. Infelizmente, por razões históricas, os cookies usam esse tipo estranho de interação.

Portanto, se um cookie é marcado como seguro, ele se aplica apenas a sites HTTPS, ou seja, possui o host correto. Cookies seguros aplicam-se apenas a URLs de host HTTPS, enquanto cookies inseguros se aplicam a ambos os tipos de URLs, para https e http, portanto, em apenas um segundo, isso se tornará uma fonte de problemas para nós.

E o último toque que os navegadores da web colocam para tentar nos ajudar nesse sentido é o aspecto da interface do usuário na qual eles inserem algum tipo de ícone de cadeado para que os usuários possam vê-lo. Portanto, você deve prestar atenção ao ícone de cadeado na barra de endereços do navegador e ao URL para descobrir em qual site você está realmente localizado.

Os desenvolvedores de navegadores da Web esperam que você se comporte da seguinte maneira: depois de acessar um site, verifique primeiro o URL e verifique se esse é o nome do host com o qual deseja conversar e, em seguida, encontre o ícone de cadeado e entenda que está tudo bem. Este é um aspecto da interface do usuário do navegador.

No entanto, isso não é suficiente. Acontece que muitos sites de phishing simplesmente incluem a imagem do ícone de cadeado no próprio site, mas usam um URL diferente. E se você não souber qual deve ser o endereço deste site, poderá ser enganado. Nesse sentido, esse lado da interface do usuário é um pouco confuso, em parte porque os próprios usuários geralmente ficam confusos. Portanto, é difícil dizer o que está aqui. Portanto, focaremos principalmente o segundo aspecto, B, que certamente é muito mais fácil de discutir. Tem perguntas sobre isso?



Aluno: Percebi que alguns sites mudam ao longo do tempo de HTTP para HTTPS.

Professor: sim, os navegadores evoluem com o tempo, e isso é confirmado pelo fato de terem um ícone de cadeado. Alguns navegadores definem um ícone de cadeado apenas se todo o conteúdo ou todos os recursos da sua página também forem transmitidos via https. Portanto, um dos problemas que o HTTPS está tentando resolver à força é o conteúdo misto ou problemas com tipos de conteúdo inseguros incorporados na página. Portanto, às vezes você não poderá obter um ícone de cadeado por causa dessa verificação. Se o navegador Chrome considerar que o certificado do site não é bom o suficiente e usa criptografia fraca, ele não exibirá um ícone de cadeado. No entanto, navegadores diferentes agem de maneira diferente e, se o Chrome não fornecer um ícone de cadeado, o Firefox poderá. Portanto, novamente, não há uma definição clara do que esse ícone de cadeado significa.

Vamos ver quais problemas podem surgir ao implementar este plano. No HTTP normal, estamos acostumados a confiar no DNS, o que deve nos fornecer o endereço IP correto no servidor. DNS HTTPS URL-? DNS DNS?

: , , , IP-.

: , , , amazon.com.

: , - amazon.com, IP-.

: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?

: , HTTPS?

: , , .

: , HTTP URL.

: , HTTPS, .

: .

: , . . , CA, , , , - , .

, - https , - , , , , , , .

HTTPS , - . , . , , , . -. « , ». , , , - , . , - .

, , , . , amazon.com www.amazon.com , , , .

-, , , . , : „ , , , , ». , - , . .

, DNS, , , .

, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .

, — , ? , , ? , ?



: , - , . , .

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

: , .

: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .

, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .

52:10

MIT « ». 14: «SSL HTTPS», 3


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?