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

15

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 ao Linux, UNIX e Windows e disponibilizados para o programador por meio de APIs de sistema de baixo nível.

Mas quando se trata de SSL ou TLS, é preciso 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 ele não é incorporado à maioria dos sistemas operacionais?

    
por Channel72 20.03.2011 / 01:15
fonte

7 respostas

8

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

Se não for sobre o kernel ou o espaço 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 OpenSSL, você teria que se adaptar à API do Windows, Mac e Linux (e ...). O TLS que não faz parte do sistema operacional permite a gravação de aplicativos TLS de plataforma cruzada. Basta escolher uma biblioteca TLS que suporte suas plataformas de destino.

Para mim, o problema real 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 auto-assinados e assim por diante. Tudo isso requer muita interação do usuário.

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

    
por 20.03.2011 / 02:06
fonte
6

Existe um problema legal. Alguns países colocam a criptografia no mesmo grupo das armas. Colocar código criptográfico no kernel faz com que a exportação de qualquer código do kernel seja mais difícil.

    
por 20.03.2011 / 08:50
fonte
2

Existem benefícios óbvios para a construção do TCP no sistema operacional. O TCP requer precisão de tempo e resposta rápida aos pacotes de rede, mesmo quando não há dados de aplicativos envolvidos. Se você tentou implementar o TCP no espaço do usuário sobre uma API IP genérica, seria muito pior. Não há vantagens semelhantes em integrar SSL no kernel.

Por outro lado, existem algumas desvantagens. Por exemplo, o SSL requer a manipulação de chaveiros e listas de certificados e similares. Fazer isso através de um kernel ou API do sistema operacional seria deselegante. Então, mesmo se ele veio com o sistema operacional, seria apenas uma biblioteca (assim como é no Windows). Essas bibliotecas já estão disponíveis de qualquer maneira, então, em última análise, é apenas uma mudança na embalagem.

    
por 13.08.2011 / 10:06
fonte
1

Existem várias razões, mas talvez a mais convincente é que a criptografia é muito, muito difícil de conseguir correta . É insensato implementá-lo a menos que você consiga dedicar grandes recursos para verificar se está correto e strong. A maioria das pessoas que trabalha com software criptográfico não tem tempo, experiência ou desejo de atolar isso; eles confiam em bibliotecas de terceiros para que os seus desenvolvedores possam lidar com essa parte do trabalho, enquanto os desenvolvedores de aplicativos podem voltar a fazer o que eles querem fazer.

Os desenvolvedores do 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 você não consegue encontrar alguém que lhe permita fazer o que você tem que, então você tem que rolar o seu próprio. Outros já mencionaram como a Microsoft faz isso. Mas, de modo geral, os desenvolvedores de SO que podem usar bibliotecas de terceiros preferem fazer isso dessa maneira, pelos mesmos motivos que os desenvolvedores de aplicativos.

    
por 19.09.2013 / 17:11
fonte
0

Sou um desenvolvedor do Windows, portanto não posso falar por outros sistemas operacionais, mas no Windows eles tinham SSL embutido por um longo tempo. Eles chamam de SChannel e, embora seja suportado, é um dos APIs mais enigmáticas que alguém teria que descobrir.

    
por 20.03.2011 / 06:28
fonte
0

SSL é uma camada por cima de um protocolo de nível inferior. Por exemplo, o SSL é executado na parte superior do TCP (que está no topo do IP).

Onde o sistema operacional pára?

É 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 essa coisa pode ser o que você quiser.

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

Os kernels OS modernos são executados em milhões de linhas de código, adicionando mais apenas aumenta a complexidade e mais tempo de depuração. Deixar coisas como o protocolo de camada mais alta fora do sistema operacional torna o desenvolvimento do SO mais fácil e, no final, faz pouca diferença na função ou no desempenho de uma aplicação final. (Isso pode fazer com que os desenvolvedores trabalhem com o aplicativo final um pouco mais doloroso.)

    
por 20.03.2011 / 10:36
fonte
0

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

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

    
por 19.09.2013 / 01:31
fonte