Notas de estudo | Um artigo mostra todo o processo do protocolo TLS

TLS (Inglês: Transport Layer Security, abreviado como TLS) protocolo de segurança da camada de transporte, e seu antecessor Secure Sockets Layer (Secure Sockets Layer, abreviado como SSL) é um protocolo de segurança, o objetivo é fornecer segurança e integridade de dados para comunicações na Internet Garantir .

Quando a Netscape lançou a primeira versão do navegador web, o Netscape Navigator, em 1994, lançou o protocolo HTTPS, criptografado com SSL, que é a origem do SSL. O IETF padroniza o SSL e publicou a primeira versão do documento padrão TLS em 1999. Isto foi seguido pelo RFC 5246 (agosto de 2008) e RFC 6176 (março de 2011). Esse protocolo é amplamente suportado em aplicativos como navegadores, caixas de correio, mensagens instantâneas, VoIP e fax via Internet. Grandes sites, como Google e Facebook, também usam esse protocolo para criar conexões seguras e enviar dados. Tornou-se o padrão da indústria para comunicação segura na Internet.

História do Desenvolvimento

protocolo	anos
SSL 1.0	desconhecido
SSL 2.0	1995
SSL 3.0	1996
TLS 1.0	1999
TLS 1.1	2006
TLS 1.2	2008
TLS 1.3	2018

Protocolo de Registro TLS

O protocolo de registro Transport Layer Security (TLS) protege os dados do aplicativo usando chaves criadas durante o handshake. O protocolo de registro é responsável por proteger os dados do aplicativo e verificar sua integridade e proveniência. Ele gerencia o seguinte:

Divida as mensagens enviadas em partes gerenciáveis e reúna as mensagens recebidas.
Compactar blocos de saída e descompactar blocos de entrada (opcional)
Aplica um código de autenticação de mensagem (MAC) às mensagens de saída e usa o MAC para autenticar as mensagens de entrada.
Criptografe as mensagens enviadas e descriptografe as mensagens recebidas.

Após a conclusão do protocolo de registro, os dados criptografados de saída são passados para a camada TCP (Transmission Control Protocol) para transmissão.

O protocolo de registro TLS é um encapsulamento simples do protocolo de alto nível TLS e o formato de dados é o seguinte:

 enum {
    invalid(0),
    change_cipher_spec(20),
    alert(21),
    handshake(22),
    application_data(23),
    (255)
} ContentType;

struct {
    ContentType type;
    ProtocolVersion legacy_record_version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

Tipo de conteúdo: 1 byte, que registra o tipo 1 do protocolo da camada interna (protocolo da camada superior) :
- 0:campo ilegal
- 20:Protocolo de Troca de Chaves (change_cipher_spec)
- 21:Protocolo de alarme (alerta)
- 22:Protocolo de handshake (aperto de mão)
- 23: :Dados da camada de aplicativo (application_data)
Versão principal: 1 byte, normalmente 0x03, para SSL 3
Versão secundária: 1 byte, dependendo da versão, pode ser 0x01, 0x02, 0x03, que representam TLS 1.1, TLS 1.2 e TLS 1.3 respectivamente (daqui também reflete a herança de TLS e SSL)
Comprimento dos dados: 2 bytes
Código de verificação de mensagem: é mencionado em muitos lugares que existe um campo de código de verificação de mensagem no protocolo da camada de registro, que ocupa 0, 16 e 20 bits de comprimento

Protocolo de handshake TLS

A fase de handshake é implementada usando o protocolo de handshake TLS. O formato do protocolo de handshake é o seguinte

Tipo de aperto de mão: 1 byte
- 1: cliente olá (client_olá)
- 2: Servidor olá (servidor_olá)
- 4: nova sessão (new_session_ticket)
- 5: fim dos primeiros dados (end_of_early_data)
- 8: Extensões criptografadas (encrypted_extensions)
- 11: certificado
- 13: solicitação de certificado (certificate_request)
- 15: verificação de certificado (certificate_verify)
- 20: Aperto de mão finalizado (concluído)
- 24: atualização de chave (key_update)
- 254: hash da mensagem (message_hash)
Comprimento: 3 bytes
contente

De acordo com diferentes sub-protocolos, seu formato será diferente

enum {
    client_hello(1),
    server_hello(2),
    new_session_ticket(4),
    end_of_early_data(5),
    encrypted_extensions(8),
    certificate(11),
    certificate_request(13),
    certificate_verify(15),
    finished(20),
    key_update(24),
    message_hash(254),
    (255)
} HandshakeType;

struct {
    HandshakeType msg_type;    /* handshake type */
    uint24 length;             /* remaining bytes in message */
    select (Handshake.msg_type) {
        case client_hello:          ClientHello;
        case server_hello:          ServerHello;
        case end_of_early_data:     EndOfEarlyData;
        case encrypted_extensions:  EncryptedExtensions;
        case certificate_request:   CertificateRequest;
        case certificate:           Certificate;
        case certificate_verify:    CertificateVerify;
        case finished:              Finished;
        case new_session_ticket:    NewSessionTicket;
        case key_update:            KeyUpdate;
    };
} Handshake;

O processo de toda a fase de aperto de mão é o seguinte:

Cliente Olá

A requisição deve ser iniciada a partir do cliente, então o primeiro passo deve ser a mensagem Hello enviada pelo cliente.

Client Hello é um tipo de protocolo de registro TLS, então sua camada externa deve ser

Nesta etapa, o cliente precisa informar ao servidor sua própria versão, componentes suportados e outras informações

Após o protocolo de handshake original, o Client Hello tem as seguintes partes:

versão: 2 bytes, contém versão principal e secundária
Número aleatório: 32 bytes, incluindo carimbo de data/hora de 4 bytes
Duração da sessão: 1 byte
identificação de sessão
Número de conjuntos de cifras: 2 bytes
Lista de conjuntos de cifras: 2 bytes por conjunto
Número de métodos de compactação: 1 byte
Lista de métodos de compactação: 1 byte por método
Número de plug-ins: 2 bytes
Lista de plug-ins:
- Tipo de plug-in: 2 bytes
- Comprimento: 2 bytes
- contente

Se a conexão for estabelecida pela primeira vez, o ID da sessão aqui estará vazio. E se uma conexão for estabelecida dentro de um determinado período de tempo, as duas extremidades irão armazenar em cache as informações correspondentes e reutilizar os parâmetros anteriores.Esta forma que não requer todos os handshakes é chamada de recuperação de sessão SSL .

Olá servidor

Quando o servidor recebe a saudação do cliente, ele precisa retornar sua própria saudação. Da lista de parâmetros suportados pelo cliente, o servidor precisa escolher o mais seguro. Se uma determinada lista de parâmetros não for suportada pelo servidor e o servidor não puder suportá-la, ela precisará retornar uma falha de handshake.

Voltando a discutir a recuperação de sessão SSL mencionada acima , há um problema aqui: para servidores com alto tráfego, eles precisam manter uma lista de sessões muito grande. Como esta parte é uma limitação da camada de protocolo, é difícil de otimizar.
Para resolver esse problema, você pode usar o Session Ticket para armazenar os dados relevantes no cliente. Como o conteúdo é criptografado pelo servidor, não haverá vazamento de dados.

Neste ponto, as duas extremidades da comunicação determinaram quais conjuntos de cifras precisam ser usados posteriormente e os pré-parâmetros relevantes (dois números aleatórios)

Certificado

O servidor do sistema SSL/TLS precisa de um certificado X.509 para verificar sua identidade

De um modo geral, o certificado raiz da cadeia de certificados deve ser o certificado raiz reconhecido por todos. O certificado raiz geralmente não emite certificados diretamente para comunicação, mas emite alguns certificados secundários para emissão de certificados de comunicação. Durante o processo de comunicação, a cadeia de certificados, exceto o certificado raiz, deve ser enviada junto com a solicitação de verificação por pares.

Neste ponto, o cliente pode pensar que o servidor é o servidor que realmente deseja solicitar, não falsificado por terceiros (a confirmação da identidade precisa usar o nome de domínio, ip e outras informações do certificado)

Troca de chave do servidor

Na etapa de saudação anterior, os vários algoritmos usados foram determinados, e os métodos correspondentes (RSA, DH) e dois números aleatórios são usados aqui para troca de chaves.

Se a troca de chaves DH for usada, há uma base fixa 3 para cada método de cálculo específico, como para comum secp256r1, G não compactado é:

04 
6B17D1F2 E12C4247 F8BCE6E5 63A440F2 
77037D81 2DEB33A0 F4A13945 D898C296 
4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 
2BCE3357 6B315ECE CBB64068 37BF51F5

E o G comprimido é:

03 
6B17D1F2 E12C4247 F8BCE6E5 63A440F2 
77037D81 2DEB33A0 F4A13945 D898C296

O servidor calcula a chave pública e a chave privada de acordo com a base definida e envia a curva selecionada (ou outros parâmetros) e a chave pública para o cliente.

solicitação de certificado de cliente

Se o servidor ainda precisar verificar a identidade do cliente, o servidor subsequente precisará enviar uma "Solicitação de certificado" para solicitar um certificado

Informe ao cliente o tipo de certificado compatível e a lista de certificados raiz compatíveis

Fim da saudação do servidor

Neste ponto, a saudação do servidor acabou

certificado de cliente

Se um certificado de cliente precisar ser enviado, o cliente precisará seguir as mesmas etapas do servidor para enviar o certificado e o servidor o verificará

Troca de chave do cliente

Igual ao servidor, o cliente usa os mesmos parâmetros para calcular sua própria chave pública e chave privada e envia a chave pública para a outra parte

protocolo de troca de chaves

Quando a negociação de chave entre as duas partes é concluída, o cliente precisa enviar um acordo de acordo de chave, declarando que mudou para o conjunto de cifras negociado e, em seguida, usa o novo conjunto de cifras para transmissão criptografada

extremidade do cliente

Antes do final da fase de handshake, o cliente precisa enviar uma notificação de conclusão do cliente (criptografada usando o conjunto de cifras negociado)

fim do servidor

Em resposta ao fim da resposta do cliente, o servidor precisa enviar o fim do servidor (ele também precisa enviar um acordo de acordo de chave para informar o cliente para trocar o conjunto de cifras)

protocolo de troca de chaves

O protocolo de troca de chaves é usado para informar ao par que está pronto para mudar para um novo protocolo, que possui apenas um byte. Mas como na verdade são dados redundantes, eles foram removidos no TLS 1.3

protocolo de alarme

O protocolo de alarme é um protocolo de notificação que informa à outra parte que ocorreu um erro e não receberá mais dados

 enum { warning(1), fatal(2), (255) } AlertLevel;
  
  struct {
      AlertLevel level;
      AlertDescription description;
  } Alert;

protocolo de aplicação

Os dados reais a serem enviados são criptografados e enviados no protocolo do aplicativo

O protocolo da camada de aplicação original segmentará, calculará o MAC, criptografará e transmitirá

certificado X.509

Normalmente, os certificados são armazenados no formato e o conteúdo do certificado .cer pode ser visualizado com openssl

openssl x509 -in F2giRo29iMlijZg5U.cer -inform der -text -noout

Um certificado contém as seguintes informações importantes

emissor
do utilizador
Tempo de emissão
Expiração
número de série
algoritmo de assinatura
Algoritmo de criptografia

Para verificar um certificado, faça o seguinte recursivamente:

Verificar se o certificado expirou?
Se o certificado não expirou, verifique se o emissor está na lista de certificados confiáveis
Se o emissor estiver na lista de certificados confiáveis, use a chave pública do certificado correspondente para verificar a validade do certificado; se não estiver na lista confiável, você precisa verificar o certificado anterior da cadeia de certificados de 1 (enviado pelo servidor)
Verifique se o número de série do certificado está na lista de expiração

troca de chaves

chave RSA

Como as próprias chaves pública e privada podem garantir a segurança, depois que o cliente seleciona uma cifra de chave simétrica, ele pode usar a chave pública no certificado para criptografar a cifra simétrica e, após enviá-la ao servidor, o servidor usa sua própria chave privada para decifrá-lo

Com a premissa de que o próprio sistema RSA é seguro, esse esquema pode garantir a segurança

Troca de chaves Diffie-Hellman

Se não houver necessidade de considerar a autenticação, o Diffie-Hellman pode ser usado para trocar chaves em um canal inseguro

Ambas as partes da comunicação trocam uma base pública GG, número primo pp, e então ambas as partes definem um número aleatório aa e bb respectivamente. Ambas as partes
trocam suas próprias informações públicas A = (g^{a} \mod p)A=(gamodp) e B = ( g^{b } \mod p)B=(gbmodp)

Dessa forma, ambas as partes podem usar os dados uma da outra para calcular uma chave simétrica idêntica s = B^a \mod p = A^b \mod ps=Bamodp=Abmodp

Como pp é um grande número primo e resolver logaritmos discretos é muito complicado, mesmo que seja observado por terceiros, ainda pode ser seguro

No entanto, o próprio sistema Diffie-Hellman não pode garantir a autenticação, portanto, geralmente requer a cooperação do RSA

Para aumentar ainda mais a dificuldade de cálculo, existe também o Diffie-Hellman baseado em curvas elípticas, conhecido como EC-DH