Por que o SSL / TLS não está incorporado nos sistemas operacionais modernos?

Muitos dos protocolos básicos de rede que compõem a infraestrutura da Internet são incorporados à maioria dos principais sistemas operacionais. Por exemplo, TCP, UDP e DNS são todos integrados no Linux, UNIX e Windows e disponibilizados ao programador por meio de APIs de sistema de baixo nível.

Mas quando se trata de SSL ou TLS, é necessário recorrer a uma biblioteca de terceiros, como o OpenSSL ou o Mozilla NSS.

O SSL é um protocolo relativamente antigo e é basicamente um padrão da indústria tão onipresente quanto o TCP / IP; então, por que não está incorporado na maioria dos sistemas operacionais?

Eu acho que depende principalmente do que você vê como "o SO". Se for o kernel, minha resposta seria: por que deveria? Posso estar errado, mas o DNS não faz parte da glibc nos sistemas Linux, que é uma biblioteca de terceiros?

Se não se trata de espaço do kernel ou do usuário, quase todos os sistemas operacionais / plataformas têm uma pilha SSL / TLS, alguns podem ter mais de um.

Pode até ser visto como uma vantagem. Se não houvesse o OpenSSL, você teria que se adaptar à API do Windows, Mac e Linux (e ...). O TLS que não faz parte do sistema operacional permite gravar aplicativos TLS de plataforma cruzada. Basta escolher uma biblioteca TLS, que suporte suas plataformas de destino.

Para mim, o verdadeiro problema com o TLS é que você não pode simplesmente "ativá-lo". Em vez disso, você precisa gerenciar um conjunto de certificados confiáveis, listas de revogação de certificados, certificados autoassinados e assim por diante. Tudo isso exige muita interação do usuário.

Infelizmente, a segurança nunca vem de graça. É um esforço para programadores e inconveniente para os usuários.

Existe um problema legal. Alguns países colocam a criptografia no mesmo grupo que as armas. A inserção de código criptográfico no kernel dificulta a exportação de qualquer código do kernel.

Existem benefícios óbvios na criação do TCP no sistema operacional. O TCP requer tempo preciso e resposta rápida aos pacotes de rede, mesmo quando não há dados do aplicativo envolvidos. Se você tentasse implementar o TCP no espaço do usuário sobre uma API IP genérica, seria muito pior. Não há vantagens semelhantes à integração do SSL no kernel.

Por outro lado, existem algumas desvantagens. Por exemplo, o SSL requer a manipulação de conjuntos de chaves e listas de certificados e similares. Fazer isso por meio de um kernel ou API do sistema operacional seria deselegante. Portanto, mesmo que fosse fornecido com o sistema operacional, seria apenas uma biblioteca (exatamente como no Windows). De qualquer forma, essas bibliotecas já estão disponíveis, portanto, é apenas uma mudança de embalagem.

Existem várias razões, mas talvez a mais convincente seja que a criptografia é muito, muito difícil de acertar . Não é aconselhável implementá-lo, a menos que você possa dedicar recursos importantes para verificar se está correto e forte. A maioria das pessoas que trabalha com software criptográfico não tem tempo, conhecimento ou desejo de se atolar nisso; eles confiam em bibliotecas de terceiros para que seus desenvolvedores possam lidar com essa parte do trabalho, enquanto os desenvolvedores de aplicativos podem voltar a fazer o que desejam.

Os desenvolvedores de SO não são tão diferentes. Às vezes, há um interesse primordial - por exemplo, seu modelo de negócios ou advogados exigem que você mantenha o código fechado - e assim você não tem muita escolha: se não encontrar alguém que o permita o que você precisa, então você tem que rolar o seu próprio. Outros já mencionaram como a Microsoft faz isso. Mas, de um modo geral, os desenvolvedores de sistemas operacionais que podem usar bibliotecas de terceiros preferem fazê-lo dessa maneira, pelos mesmos motivos que os desenvolvedores de aplicativos.

Eu sou desenvolvedor de Windows, então não posso falar por outros sistemas operacionais, mas no Windows eles tinham SSL embutido por muito tempo. Eles o chamam de SChannel e, embora seja suportado, é uma das APIs mais enigmáticas que alguém precisaria descobrir.

SSL é uma camada sobre um protocolo de nível inferior. Por exemplo, o SSL é executado na parte superior do TCP (que é na parte superior do IP).

Onde o sistema operacional para?

É muito fácil argumentar que o sistema operacional fornece serviços básicos, como redes até um ponto em que um cliente do sistema operacional "faz coisas". E esse material pode ser o que você quiser.

É muito improvável que o SSL no kernel leve a um enorme ganho de desempenho, então por que se preocupar?

Os kernels modernos do SO são executados em milhões de linhas de código, adicionando mais apenas adicionando complexidade e mais tempo de depuração. Deixar coisas como protocolos de camada superior fora do sistema operacional facilita o desenvolvimento do sistema operacional e, no final, faz pouca diferença para a função ou o desempenho de um aplicativo final. (Isso pode fazer com que os desenvolvedores trabalhem no aplicativo final um pouco mais doloroso.)

Há algum suporte do Kernel para Crypto e SSL. Isso faz sentido porque o Kernel pode interagir com mais eficiência com o hardware e também é conveniente proteger credenciais de qualquer aplicativo. Bons exemplos são o kssl, um proxy SSL reverso no nível do kernel no Solaris ou as várias bibliotecas de criptografia no kernel (usadas por exemplo para VPNs). Um mecanismo criptográfico acelerado por hardware típico também possui um módulo do kernel (e pode ser acessado por interfaces criptográficas específicas do PKCS # 11 ou SO).

Algumas razões pelas quais você não vê com mais frequência é que alguns protocolos de aplicativos não estão em camadas apropriados (pense em STARTLS) ou exigem decisões de aplicativos durante o handshake (pense em certificado de cliente e verificação de CRL) ou estão simplesmente em uma evolução regular.