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

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

Agora, veremos como os protocolos criptográficos são usados ​​para proteger as conexões de rede na Internet e como eles geralmente interagem com os fatores da rede. Antes de nos aprofundarmos nos detalhes, quero lembrá-lo de que haverá um teste na quarta-feira, mas não nesta audiência, mas em Walker, no terceiro andar, durante o horário habitual da aula.



Então, hoje falaremos sobre como a Internet usa criptografia para proteger uma conexão de rede e consideraremos dois tópicos intimamente relacionados.

A primeira é como proteger conexões criptograficamente em uma escala maior do que o sistema Kerberos, que abordamos na última palestra, protege. O segundo é como integrar essa proteção criptográfica, fornecida no nível da rede, a todo o aplicativo e como o navegador garante o uso da proteção fornecida pelo protocolo criptográfico. Esses tópicos estão intimamente relacionados, portanto, a proteção das comunicações de rede é bastante fácil de fornecer, porque a criptografia sempre funciona. Mas integrá-lo ao navegador é uma tarefa muito mais difícil do que construir um sistema em torno da criptografia.

Antes de mergulharmos nessa discussão, quero lembrá-lo dos elementos básicos da criptografia que usaremos.

Em nossa última palestra sobre Kerberos, usamos criptografia simétrica, ou
criptografia e descriptografia. Seu significado é que você tem uma chave secreta K e duas funções. Assim, você pode pegar alguns dados, vamos chamá-lo de P, este é um texto simples ao qual você pode aplicar a função de criptografia, e esta é a função de alguma chave K. E se você criptografar esse texto sem formatação, obterá o texto criptografado C. Da mesma forma, temos existe uma função de descriptografia D que usa a mesma chave K, como resultado da qual o texto criptografado C se transformará em texto sem formatação P. Essa é a primitiva em torno da qual o Kerberos foi construído.



Mas acontece que existem outras primitivas que serão úteis para a discussão de hoje e são chamadas de criptografia e descriptografia assimétricas. A idéia aqui é ter chaves diferentes para criptografia e descriptografia. Vamos ver por que isso é tão útil.

Aqui existe uma função E, que pode criptografar um determinado conjunto de mensagens P com uma certa chave pública pk, como resultado, para obter o texto criptografado C. Para descriptografá-lo com a função D, você só precisa especificar a chave secreta correspondente sk e obter o texto de origem P.



A conveniência da criptografia assimétrica é que você pode publicar uma chave pública na Internet e as pessoas podem criptografar mensagens para você, mas você precisa de uma chave secreta para descriptografar as mensagens. Hoje vamos ver como isso é usado no protocolo. Na prática, você frequentemente usará a criptografia de chave pública de uma maneira ligeiramente diferente. Por exemplo, em vez de criptografar e descriptografar mensagens, pode ser necessário assinar ou verificar as mensagens.

Acontece que no nível de implementação, essas são operações relacionadas, mas no nível do aplicativo da API elas podem parecer um pouco diferentes. Por exemplo, você pode assinar a mensagem M com sua chave secreta sk e obter alguma assinatura S. Em seguida, você pode verificar essa mensagem com a chave pública correspondente pk e, como resultado, obter um sinalizador lógico informando se a assinatura S está correta para a mensagem M.



Aqui estão algumas garantias relativamente intuitivas que fornecem esses recursos. Se, por exemplo, você recebeu essa assinatura e ela foi verificada corretamente, significa que ela teve que ser gerada por alguém com a chave secreta correta. Isso está claro?

Então, vamos tentar descobrir como proteger as conexões de rede em uma escala maior do que o Kerberos. No Kerberos, tínhamos um modelo bastante simples, em que todos os usuários e servidores usavam algum tipo de conexão com um objeto KDC que possuía uma tabela gigante de usuários, serviços e suas chaves. Sempre que um usuário deseja conversar com algum servidor, ele deve solicitar ao KDC para criar o ticket necessário com base nessa tabela gigante.



Portanto, este parece ser um modelo bastante simples. Então, por que precisamos de outra coisa? Por que o Kerberos não é bom o suficiente para trabalhar com sites? Por que a Internet não usa o Kerberos exclusivamente para proteger todas as conexões?

Você respondeu corretamente - porque o único KDC deve confiar em todos, e isso é ruim. Você pode ter problemas se considerar que uma determinada máquina é absolutamente segura.

Talvez as pessoas do MIT estejam dispostas a confiar em alguém na rede local gerenciada pelo KDC, mas não em todos na Internet.

E a resposta do segundo aluno também está correta - é muito difícil gerenciar um número tão grande de chaves. De fato, pode ser muito difícil criar um único KDC que possa gerenciar um bilhão de chaves ou dez bilhões de chaves para todas as pessoas no mundo. Outra complicação do uso do Kerberos para toda a Internet é que todos os usuários devem ter uma chave ou ser conhecidos pelo KDC. Você não pode usar o Kerberos em nosso instituto para se conectar a alguns servidores se você não tiver uma conta no banco de dados Kerberos. Embora para toda a Internet seja bastante razoável esperar que, quando você vá ao computador, ele não saiba quem você é, mas permitirá que você acesse o site da Amazon, protegido por criptografia.



Hein?

Há várias outras coisas que você espera de um protocolo criptográfico e veremos como elas aparecem no SSL. Mas a idéia principal é que esta solução seja a mesma para o Kerberos e para SSL ou TLS. Você está certo quando menciona que os protocolos Kerberos originais sobre os quais lemos nos materiais das palestras foram desenvolvidos há muito tempo. E se quisermos usá-los para a Internet moderna, eles precisarão mudar alguma coisa. Que outros pensamentos você tem, por que não devemos usar o Kerberos?

É isso mesmo, existe um problema de dimensionamento ao restaurar o acesso e, possivelmente, ao registrar novos usuários, porque você precisará ir pessoalmente a algum escritório de contas e obter uma conta lá. O que mais?

Aluno: O servidor Kerberos deve estar sempre online.

Professor: Sim, este é outro problema. Listamos alguns tipos de problemas de gerenciamento, mas no nível do protocolo, o KDC deve estar sempre online, porque na verdade serve como intermediário para qualquer uma de suas interações com os serviços. Isso significa que toda vez que você visita um novo site, precisa conversar com a KDC. Em primeiro lugar, será um gargalo em termos de desempenho. Como outros tipos de escalabilidade, esse princípio leva à escalabilidade do desempenho, enquanto os princípios listados acima levam apenas à escalabilidade do gerenciamento.



Então, como podemos resolver esse problema usando esses princípios? A idéia é usar a criptografia de chave para parar de usar o KDC.

Vamos primeiro descobrir se você pode estabelecer uma conexão segura se apenas conhecer algumas das chaves públicas do outro lado. E então veremos como conectamos a versão da chave pública KDC à autenticação das partes neste protocolo. Se você não quiser usar o KDC, poderá fazer o seguinte com criptografia de chave pública: de alguma forma, descubra a chave pública do parceiro do outro lado da conexão. Portanto, no Kerberos, se eu quiser conectar-me a um servidor de arquivos, apenas conheço a chave pública do servidor de arquivos de algum lugar. Como calouro, recebo uma impressão dizendo que a chave pública do servidor de arquivos é tal e qual, e posso usá-la para conectar.

Você pode simplesmente criptografar a mensagem da chave pública do servidor de arquivos ao qual deseja se conectar. Mas, na prática, essas operações com essas chaves públicas são bastante lentas. São várias ordens de magnitude mais lentas que as chaves de criptografia simétricas. Portanto, na prática, você geralmente sempre quer se recusar a usar criptografia pública.

Assim, um protocolo típico pode se parecer com isso. Você tem A e B, eles querem se comunicar e A conhece a chave pública B. Ao mesmo tempo, A gera algum tipo de chave de sessão S, apenas escolhendo um número aleatório para ela. Então, A está prestes a enviar a chave de sessão S B, para que pareça com o Kerberos. Vamos criptografar a chave de sessão S para B.

Se você se lembra, no Kerberos, para fazer isso, precisávamos de um KDC porque A não conhecia a chave para B ou ele não tinha permissão para conhecê-la, porque é um segredo que apenas B. pode saber. Mas com uma chave pública, você pode fazer isso imediatamente, apenas criptografando o segredo com essa chave pública Bspk e envie a mensagem B. Agora B pode descriptografar esta mensagem e dizer: Preciso usar essa chave secreta. Agora temos um canal de comunicação onde todas as mensagens são simplesmente criptografadas com essa chave secreta S.



Portanto, existem alguns recursos úteis neste protocolo. Primeiramente, nos livramos da necessidade de ter o KDC online e gerar uma chave de sessão para nós. Poderíamos simplesmente garantir a confidencialidade das informações transmitidas se uma das partes na conexão as gerar e depois criptografá-las para o outro lado sem usar o KDC.

Outra coisa boa é a confiança de que apenas B pode ler as mensagens enviadas de A para B, porque somente B pode descriptografar essa mensagem. Portanto, B deve ter a chave privada correspondente S.

Aluno: importa quem dá essa chave - usuário ou servidor?

Professor: talvez. Eu acho que depende das propriedades que você deseja deste protocolo. Portanto, e se A cometer um erro ou usar a aleatoriedade errada, o servidor que envia os dados de volta pensa: "Ah, agora esses são os únicos dados que A verá". Isso pode não estar totalmente certo, então você deve pensar sobre isso. Existem vários outros problemas com este protocolo.

Aluno: Um invasor pode usar uma chave para enviar mensagens repetidas?

Professor: sim, o problema pode ser que eu posso simplesmente enviar essas mensagens novamente e parecerá que é A enviando mensagem B novamente e assim por diante.

Portanto, geralmente a solução para esse problema é que os dois lados da conexão estão envolvidos na geração de S e isso garante que a chave que usamos seja "nova". Como aqui, na figura, na verdade B não gera nada, portanto essas mensagens de protocolo têm a mesma aparência sempre.

Geralmente, um lado escolhe um número aleatório como S e o outro lado B também escolhe um número aleatório, geralmente chamado nonce. Existem dois números e uma chave que não é realmente selecionada apenas por um lado; é um hash que os dois lados escolheram para interação em conjunto. Além do hash, você pode usar o protocolo Diffie-Hellman, que examinamos na última palestra, graças ao qual você obtém privacidade primeiro. Isso é matemática mais complicada do que simplesmente combinar dois números aleatórios que escolheram esses dois lados. Mas você terá uma propriedade tão boa quanto a chave secreta compartilhada original, eliminando a necessidade de transferir a chave de descriptografia ao transmitir dados criptografados.

Assim, ataques repetidos podem ser evitados da seguinte maneira. B gera nonce e, em seguida, define a chave secreta real S ', que é usada para o hash da chave secreta S com esse nonce. E, é claro, B teria que enviar nonce de volta para A para descobrir o que acontece quando os dois concordam com a chave.



Outro problema é que não há autenticação real A. A sabe quem B é, ou pelo menos sabe quem pode descriptografar os dados. Mas B não tem idéia de quem está do outro lado, seja algum tipo de adversário se passando por outro ou por outra pessoa. Como isso pode ser corrigido no mundo das chaves públicas?

Existem várias maneiras de fazer isso. Uma possibilidade é assinar essa mensagem inicialmente, porque temos esse bom princípio de sinal. Talvez pudéssemos assinar isso com uma chave secreta. Este sinal simplesmente fornece uma assinatura, mas presumivelmente você a atribui e também fornece essa mensagem.

Então B deve saber que A é uma chave pública para verificar a assinatura. Mas, se B souber que A é uma chave pública, B terá certeza de que foi ele quem enviou esta mensagem.



Outra coisa que você pode fazer é confiar na criptografia. Portanto, talvez B possa enviar nonce de volta para A, criptografando-o com a chave pública fornecida por A. E somente A pode descriptografar nonce e gerar a chave de sessão final S '. Portanto, existem alguns truques que você pode fazer. É assim que os certificados de cliente funcionam atualmente nos navegadores da Internet.

Portanto, A possui uma chave secreta e, portanto, quando você recebe um certificado MIT pessoal, seu navegador cria uma chave secreta de longa duração e recebe um certificado para ela. E toda vez que você envia uma solicitação ao servidor da Web, prova o fato de conhecer a chave secreta do seu certificado de usuário e, em seguida, define a chave secreta S para o restante da conexão.

Esses são problemas que são facilmente corrigidos no nível do protocolo. No entanto, a base para tudo isso é que todas as partes conhecem as chaves públicas uma da outra. Como você pode descobrir a chave pública de alguém? Suponha que eu queira conectar-me a um site, possua uma URL à qual desejo conectar-me ou um nome de host, como descobrir qual chave pública corresponde a ela?

Da mesma forma, se eu me conectar ao servidor MIT para ver minhas notas, como o servidor sabe qual deve ser minha chave pública para distingui-la da chave pública de outro aluno do MIT?

Esse é o principal problema que o KDC abordou. De fato, o KDC resolveu dois problemas para nós. Primeiro, ele gerou uma mensagem (Ebspk (S)), criou uma chave de sessão e a criptografou para o servidor. Agora, corrigimos isso criando criptografia de chave pública. Mas também precisamos combinar os nomes principais das strings com as chaves criptográficas Kerberos fornecidas anteriormente.

Existe um protocolo TLC para essas coisas no mundo HTTPS. Seu significado é que continuaremos confiando em certos aspectos do processo que suportam essas tabelas gigantescas que mapeiam os nomes dos participantes do processo para chaves criptográficas. O plano é que teremos algo chamado autoridade de certificação, indicado pelas letras CA em todos os tipos de literatura sobre segurança de rede. Essa CA também suporta logicamente a tabela, em uma parte da qual os nomes de todos os participantes são exibidos e na outra - as chaves públicas correspondentes. A principal diferença entre esse centro e o Kerberos é que essa CA não precisa estar online para todas as transações.
No Kerberos, para conectar-se a alguém ou encontrar a chave de outra pessoa, você precisa conversar com o KDC. Em vez disso, no mundo da CA, eles fazem isso.



Se você tiver algum tipo de nome aqui e a chave de chave correspondente em outra parte da tabela, a autoridade de certificação assinará simplesmente as mensagens de que certas linhas existem nessa tabela. Portanto, a autoridade de certificação precisará ter suas próprias chaves públicas e privadas aqui. Ele usará uma chave secreta para encontrar mensagens para outros usuários no sistema em que você pode confiar.

Portanto, se você tiver um registro "nome + chave" no banco de dados da CA, a CA criará uma mensagem informando que esse nome corresponde a essa chave pública e assinará essa mensagem com sua chave privada da CA.



Isso permite que você faça coisas muito semelhantes às do Kerberos, mas, ao mesmo tempo, nos livramos da necessidade de encontrar uma CA online para todas as transações. E, na verdade, será muito mais escalável. Isso é exatamente o que geralmente é chamado de certificado. A escalabilidade é garantida pelo fato de que, para um cliente ou qualquer outra pessoa que utilize este sistema, um certificado fornecido de uma fonte não é inferior a um certificado de qualquer outra fonte. É assinado pela chave secreta da autoridade de certificação. Portanto, você pode verificar sua autenticidade sem precisar entrar em contato com uma autoridade de certificação ou qualquer outra parte listada aqui.

Funciona assim. O servidor com o qual você deseja conversar armazena o certificado que ele recebeu originalmente da autoridade de certificação. E toda vez que você se conecta, o servidor informa: “OK, aqui está o meu certificado. Foi assinado por esta CA. Você pode verificar a assinatura e apenas se certificar de que é minha chave pública e que é meu nome. ”

Por outro lado, o mesmo acontece com os certificados do cliente. Quando um usuário se conecta ao servidor da web, o certificado do cliente indica que sua chave pública corresponde à chave secreta que foi originalmente gerada no navegador. Portanto, ao se conectar ao servidor, você apresentará um certificado assinado pela autoridade de certificação do MIT, indicando que seu nome de usuário corresponde a essa chave pública. , , , , Athena.

: , ?

: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.

, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.

: ?

: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .

, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .



. , CA , , , , - , . , , . - , amazon.com, , - .

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

, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».

, , , CRL, , web-, CRL. , - , , . , , , , , .

, . , . , . , . , CRL, - .

, ? , . , CRL .

, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .

26:30 min

Curso do MIT "Computer Systems Security". Palestra 14: “SSL e HTTPS”, parte 2


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?