Este blog convidado faz parte de uma série e foi criado em parceria com a F5.
CSR, PEM, DER, X509… não é de se admirar que os certificados sejam frequentemente vistos como algum tipo de mágica.
A primeira vez que precisei obter um certificado para trabalhar, eu não tinha ideia do que estava fazendo! Copiei um monte de comandos sem rumo e torci para que funcionassem. Mas quando se trata de segurança, esperar que alguém copie comandos cegamente é algo arriscado. Nenhum mais do que certificados.
Os certificados são a base das conexões TLS (e mais comumente HTTPS, que utiliza TLS). Se você errar isso, estará se expondo ao risco de a conexão ser interceptada por um invasor (negando efetivamente a proteção que a conexão TLS fornece).
Este blog faz parte de uma série que revelará o papel dos certificados e, especialmente, o gerenciamento de certificados. Na primeira parte, exploraremos a finalidade dos certificados e por que eles desempenham um papel importante na proteção de conexões (ou seja, conexões TLS).
Quando um cliente se conecta a um servidor, há dois princípios de segurança que precisamos considerar.
A primeira é a confidencialidade. Isso é essencial para que os dados transmitidos de e para o cliente não fiquem visíveis para ninguém fora desse tráfego. Uma página de login é um bom exemplo. Queremos garantir que o nome de usuário e a senha que você digitar não fiquem visíveis para ninguém quando forem transportados com o servidor no qual você está tentando fazer login. Também vale a pena notar que a confidencialidade também influencia o aspecto da privacidade, evitando que olhares curiosos vejam quais ações ou informações você está visualizando.
O segundo princípio é integridade. Muitas pessoas esquecem ou não sabem disso quando se trata de TLS. Por integridade, queremos dizer que ninguém pode adulterar os dados que estão sendo transmitidos de e para o cliente. Mesmo que o recurso seja público, ainda queremos garantir a integridade desses dados.
Considere um site de notícias de acesso público. Não estamos muito preocupados com o aspecto da confidencialidade (além da privacidade, mas para este exemplo vamos deixar isso de lado), pois esta página está disponível publicamente. No entanto, queremos ter certeza de que os dados enviados ao cliente (o navegador do usuário) do servidor não foram manipulados. Sem considerar a integridade de um servidor, um invasor pode editar o conteúdo de um artigo de notícias (pense em notícias falsas) ou injetar conteúdo malicioso na página, como um gancho do Browser Exploitation Framework.
Então, qual o papel dos certificados em tudo isso? Quando um cliente se conecta a um servidor, ele precisa garantir que esteja se conectando primeiro ao servidor pretendido. Não é um servidor que um invasor imitou. Também queremos garantir que a conexão seja criptografada de ponta a ponta. Com isso, queremos dizer que a conexão não foi encerrada em algum lugar para permitir a inspeção e modificação do tráfego e encaminhada para o servidor original. Isso é conhecido como ataque de máquina no meio .
Para deixar claro, há casos de uso válidos para isso, especialmente em um ambiente corporativo onde o tráfego da internet é frequentemente inspecionado para ajudar a melhorar a segurança da organização. É aqui que os certificados entram em cena. Quando um cliente se conecta a um servidor TLS, o servidor terá que fornecer seu certificado (servidor) ao cliente. O cliente então validará esse certificado para garantir que ele pertença ao servidor correto ao qual o cliente estava tentando se conectar originalmente. Uma vez que isso tenha sido estabelecido — uma parte do handshake TLS — as comunicações entre o cliente e o servidor podem começar.
Na próxima parte desta série, continuarei explorando este tópico no meu próprio blog. Lá, abordaremos o processo de validação de certificados. É aqui que nos aprofundaremos no lado humano do gerenciamento de certificados e sua importância.
Até lá, recomendo fortemente que você confira uma sessão informativa do F5 myForum ( Esteja preparado para o cenário SSL em mudança ) de David Warburton e Nigel Ashworth. É uma ótima visão geral dos cenários SSL e TLS em constante evolução e vale muito a pena o seu tempo.
Sean Wright é um engenheiro experiente em segurança de aplicativos que começou como desenvolvedor de software. Ele se concentra principalmente em segurança de aplicativos baseados na web, com interesse especial em TLS e assuntos relacionados à cadeia de suprimentos. Sean também tem experiência em fornecer liderança técnica em relação à segurança de aplicativos, bem como em se envolver com equipes para melhorar a segurança dos sistemas e aplicativos que eles desenvolvem e mantêm. Você pode ler o blog dele aqui .