Supondo que minha página não tenha SSL. Suponhamos os seguintes passos:
O usuário faz uma solicitação para minha página (vamos chamá-la de www.mypage.com ).
JS do lado do cliente cria um SYMMETRIC KEY .
JS do lado do cliente faz uma solicitação para minha página de back-end, solicitando a CHAVE PÚBLICA do meu servidor.
JS do lado do cliente criptografa a SYMMETRIC KEY que foi gerada anteriormente dentro da PUBLIC KEY obtida .
JS do lado do cliente envia os dados ENCRYPTED para o SERVIDOR.
O servidor descriptografa os dados recebidos.
O servidor começa a enviar/ler todas as seguintes informações criptografadas na CHAVE SIMÉTRICA gerada no PASSO 2.
JS do lado do cliente também começa a enviar/ler todas as informações criptografadas a seguir na CHAVE SIMÉTRICA gerada na ETAPA 2.
Pelo que sei, mesmo que o invasor esteja ouvindo todas as informações das etapas 1 a 8, ele não consegue descriptografar nada e o usuário está seguro.
Vocês concordam comigo? Estou correcto? Se sim, podemos assumir que o SSL nativo nos navegadores existe devido a páginas "mal escritas"?
O TLS protege a comunicação entre um cliente e um servidor contra um invasor intermediário capaz de interceptar e modificar a comunicação . Este pode ser o ISP, pode ser o proprietário de um ponto de acesso WiFi público ou pode ser um invasor em sua LAN ou ponto de acesso WiFi que redireciona seu tráfego usando ARP ou falsificação de DNS. Vamos ver como essa abordagem proposta funciona neste caso.
De onde vem esse JS do lado do cliente? Esperamos que não seja do servidor, porque não há garantia de que um invasor não o tenha modificado. Mas supondo que isso foi transferido para o cliente com algum tipo de conexão segura...
Como essa solicitação ao servidor não está protegida contra interceptação e modificação, um invasor intermediário pode simplesmente substituir a chave pública pela sua própria e enviá-la ao cliente. Como o cliente não possui nenhum tipo de validação da chave pública (ou seja, nenhuma autenticação do servidor), ele a aceitará.
A partir daí o cliente acreditará trocar a chave simétrica e o tráfego criptografado com o servidor, enquanto na verdade os troca com o invasor. O invasor pode descriptografar a chave simétrica e o tráfego e construir a partir disso sua própria conexão com o servidor, desta vez com a chave original do servidor.
Em resumo: está faltando um ponto crítico do TLS - a autenticação do servidor. Isso permite que um homem ativo no meio quebre facilmente a proteção.
Observe que há mais falhas em sua abordagem, como nenhuma transparência de encaminhamento, nenhuma integridade de mensagem, nenhuma proteção de reprodução. Mas a falta de autenticação do servidor é o problema mais óbvio e crítico.
Ele está integrado aos navegadores, pois é fácil errar na criptografia, portanto, não confie que os usuários façam a sua própria criptografia. E é enviado com CA raiz como âncoras de confiança, já que a criptografia com uma parte remota anteriormente desconhecida precisa de alguma forma para validar se a parte é realmente a pretendida (a autenticação do servidor que está faltando), o que é feito verificando o certificado do servidor em TLS contra a CA raiz confiável integrada.
Veja também Por que não deveríamos lançar o nosso próprio? sobre por que você não deveria tentar inventar seu próprio protocolo criptográfico, mas sim confiar em padrões estabelecidos.