Resumo:

Neste artigo, exploraremos as diferenças entre os protocolos SSL e SSH. Discutiremos pontos -chave sobre como eles funcionam, o conceito de criptografia, criptografia simétrica e assimétrica, troca de chaves, assinaturas digitais e autoridades de certificação. Também explicaremos o uso de hashes criptográficos em protocolos seguros.

Pontos chave:

1. O SSL usa a autenticação baseada em certificado, enquanto o SSH conta com um processo de autenticação de nome de usuário/senha.
2. Criptografia é o processo de codificação de informações para mantê -la segura do acesso não autorizado.
3. A criptografia de chave simétrica usa a mesma chave para criptografia e descriptografia.
4. A criptografia de chave assimétrica, também conhecida como criptografia de chave pública, usa um par de chaves que consiste em uma chave privada e uma chave pública.
5. A criptografia de chave pública permite troca de chaves seguras e mensagens seguras entre as partes.
6. A criptografia simétrica é mais rápida que a criptografia de chave pública, por isso é frequentemente usada para criptografia de dados em massa.
7. As assinaturas digitais usam a criptografia de chave pública para verificar a autenticidade e a integridade de uma mensagem.
8. As autoridades de certificação garantem a Associação de Chaves Públicas com seus legítimos proprietários.
9. Algoritmos de hash criptográfico são usados ​​para verificações de integridade de dados em protocolos seguros.
10. SSL/TLS e SSH são amplamente usados ​​protocolos de rede seguros para proteger dados durante a transmissão.

Questões:

1. Como o SSL difere do SSH em termos de autenticação?

O SSL usa a autenticação baseada em certificado, enquanto o SSH conta com um processo de autenticação de nome de usuário/senha.

2. O que é criptografia e qual é o seu objetivo?

Criptografia é o processo de codificação de informações para mantê -la segura do acesso não autorizado. Seu objetivo é garantir a confidencialidade e a integridade dos dados.

3. O que é criptografia de chave simétrica?

A criptografia de chave simétrica usa a mesma chave para criptografia e descriptografia de dados.

4. Como funciona a criptografia de chave pública?

Criptografia de chave pública, também conhecida como criptografia assimétrica, usa um par de chaves que consiste em uma chave privada e uma chave pública. A chave pública é usada para criptografia, enquanto a chave privada é usada para descriptografia.

5. Qual é a vantagem da criptografia de chave pública?

A criptografia de chave pública permite mensagens seguras e troca de chaves entre as partes sem a necessidade de compartilhar uma chave secreta.

6. Por que a criptografia simétrica é usada para criptografia de dados em massa?

A criptografia simétrica é mais rápida que a criptografia de chave pública, tornando -a mais eficiente para criptografar grandes quantidades de dados.

7. O que são assinaturas digitais?

As assinaturas digitais usam a criptografia de chave pública para verificar a autenticidade e a integridade de uma mensagem. Eles têm garantia de que uma mensagem não foi adulterada e foi de fato assinada pelo remetente reivindicado.

8. ?

As autoridades de certificação garantem a Associação de Chaves Públicas com seus legítimos proprietários. Eles emitem certificados digitais que contêm informações de chave pública e verificam a identidade do titular do certificado.

9. O que são algoritmos de hash criptográfico usados ​​para?

Algoritmos de hash criptográfico são usados ​​para verificações de integridade de dados em protocolos seguros. Eles geram um valor único de hash para uma determinada entrada, permitindo que o destinatário verifique se os dados foram adulterados.

10. O que são SSL/TLS e SSH usados ​​para?

SSL/TLS e SSH são amplamente usados ​​protocolos de rede seguros para proteger dados durante a transmissão. SSL/TLS é comumente usado para comunicações da Web segura, enquanto o SSH é usado para acesso remoto e transferências de arquivos seguras.

SSL vs SSH-uma comparação não tão técnica

4. SSH usa um processo de autenticação de nome de usuário/senha para estabelecer uma conexão segura, enquanto o SSL não o considera.

Como SSL, TLS, SSH trabalham

Este artigo explora como os protocolos de rede seguros funcionam. Ele explicará conceitos -chave, como criptografia, hashes criptográficos e criptografia de chave pública. Os dois protocolos de rede seguros mais populares, SSL/TLS e SSH, serão examinados, e seus colegas seguros de transferência de arquivos, FTPs e SFTP serão descritos e comparados.

O que é criptografia?

Criptografia é o processo de codificação de informações de tal maneira que apenas as partes que estão autorizadas a ler as informações criptografadas podem lê -las. Seu objetivo é manter as informações seguras de escutas ou segredos.

A informação não criptografada é conhecida como texto simples, enquanto as informações criptografadas são chamadas de texto cifra. Para obter o texto simples do texto cifra, é necessária uma chave de criptografia e apenas partes autorizadas têm uma cópia da chave de criptografia. O processo de codificação é conhecido como algoritmo de criptografia. O algoritmo é projetado de modo que descriptografar o texto simples sem a chave não seja praticamente possível.

Existem dois tipos principais de criptografia – criptografia de chave simétrica e criptografia assimétrica ou de chave pública.

Criptografia de chave simétrica

Na criptografia simétrica, a chave usada para criptografar o texto simples e a chave usada para descriptografar o texto cifrado é o mesmo. Isso significa que as duas partes (o remetente e o receptor) devem compartilhar a chave (que deve ser mantida em segredo). Obviamente, descobrir como compartilhar a chave com segurança é outra instância do que a criptografia foi projetada para – compartilhar informações com segurança. Então, como as duas partes compartilham sua chave secreta? Felizmente, isso pode ser alcançado pela criptografia assimétrica (ou chave pública), explicada abaixo. Algoritmos de chave simétricos populares incluem AES, Blowfish, RC4 e 3DES.

Criptografia de chave pública

A criptografia de chave pública é baseada em um conjunto especial de algoritmos que exigem duas chaves separadas. Uma chave, conhecida como chave privada, é mantida em segredo e a outra chave, a chave pública, é amplamente disponível. Juntos, eles são conhecidos como o par de chave. Geralmente, qualquer um pode usar a chave pública para criptografia, mas apenas o proprietário da chave privada pode descriptografar.

A vantagem de um sistema de criptografia de chave pública é o seguinte: segredo (i.e. Criptografado) As mensagens podem ser enviadas a qualquer pessoa que tenha publicado sua chave pública, e apenas o destinatário poderá descriptografar a mensagem. Então, desde que sua chave pública possa ser confiável para ser deles (uma ressalva importante!), um sistema seguro para a troca de mensagens secretas pode ser facilmente configurado. Cada parte pode publicar sua chave pública e enviar mensagens secretas para a outra usando a outra’. Eles usam sua própria chave privada para descriptografar as mensagens que recebem.

Mas não’t publicando a chave pública Torne mensagens criptografadas mais vulneráveis ​​à descriptografia não autorizada? Não, não é praticamente possível derivar a chave privada de um par de chaves da chave pública e, sem a chave privada, o texto cifra não pode ser descriptografado. Portanto, a publicação da chave pública não facilita a descriptografia das mensagens criptografadas pela chave pública.

RSA e Diffie -Hellman foram os primeiros algoritmos de chave pública. Por um longo tempo, pensou -se que eles foram inventados em 1976/1977, mas quando a pesquisa secreta do GCHQ foi desclassificada em 1997, eles foram concebidos de forma independente alguns anos antes. Elgamal e DSS são outros algoritmos de chave pública conhecidos.
Existem vários usos importantes da criptografia de chave pública descrita abaixo.

Distribuição de chaves

A criptografia simétrica usa uma única chave secreta que ambas as partes exigem e garantir que essa chave secreta seja comunicada com segurança à outra parte é difícil. Isso é conhecido como o principal problema de distribuição.

A criptografia de chave pública é ideal para resolver este problema. A parte receptora, que exige o remetente’S Chave Secreta Symetric, gera um par de chaves e publica a chave pública. O remetente usa o receptor’s Chave para criptografar sua chave simétrica e a envia para o receptor. Agora, o remetente e o receptor têm a mesma chave simétrica secreta, e ninguém mais o faz, como nunca foi transmitido como texto claro. Isso é frequentemente conhecido como troca -chave.

Uma pergunta óbvia é perguntar por que não usar a criptografia de chave pública para tudo e evitar ter que enviar uma chave secreta? Acontece que a criptografia simétrica é ordens de magnitude mais rápida na criptografia e descriptografia. Portanto, é muito mais eficiente usar a criptografia de chave pública para distribuir a chave simétrica e depois usar a criptografia simétrica.

Assinaturas digitais

A criptografia de chave pública é um componente importante das assinaturas digitais. Uma mensagem pode ser assinada (criptografada) com um usuário’s chave privada, e qualquer pessoa pode usar sua chave pública para verificar se o usuário assinou a mensagem e que a mensagem não foi adulterada com. Esta aplicação da criptografia de chave pública é explicada em mais detalhes na próxima seção, Hashes criptográficos.

Autoridades de certificação

Um requisito crítico para um sistema usando a criptografia de chave pública é fornecer uma maneira de associar confiabilidade as chaves públicas a seus proprietários. Há um valor limitado em poder usar alguém’S Chave para criptografar uma mensagem destinada a eles se puder’Estamos determinados que realmente é a chave pública deles. É para isso que servem as autoridades de certificados, e eles e certificados são explicados abaixo.

Hashes criptográficos

Os algoritmos criptográficos de hash são importantes funções matemáticas usadas amplamente em software, particularmente em protocolos seguros, como SSL/TLS e SSH.

Um bloco de dados é passado através de um algoritmo de hash para produzir um valor de hash muito menor, conhecido como digestão da mensagem, ou simplesmente o resumo. A mesma mensagem sempre resultará no mesmo resumo. Mensagens diferentes produzem digestões diferentes.

Uma característica importante dos algoritmos de hash é que, dado um resumo específico, é extremamente difícil gerar uma mensagem que a produzirá. Eles são “Mão Única” Algoritmos – o resumo de uma mensagem é fácil de calcular, mas uma mensagem pode’não ser deduzido do resumo. .

Os algoritmos populares de hash incluem MD5 e SHA-1, embora agora estejam sendo eliminados em favor de algoritmos mais fortes, como o SHA-2.

.

Uma assinatura por escrito demonstra que um documento foi criado por um autor conhecido e os representa com precisão. Uma assinatura digital é semelhante – garante que a mensagem tenha sido criada por um remetente conhecido (autenticação) e que a mensagem não foi adulterada em trânsito (integridade).

Para assinar uma mensagem requer dois estágios. Em primeiro lugar, o resumo da mensagem é calculado, produzindo um hash único que normalmente é muito menor que a mensagem. Em seguida, o resumo é criptografado usando o signatário da mensagem’s chave privada. Esta é a assinatura digital da mensagem.

Para verificar o signatário de uma mensagem também requer dois estágios. Em primeiro lugar, o assinante’S Chave Pública (que está amplamente disponível) é usada para descriptografar a assinatura digital, produzindo o resumo da mensagem. Em seguida. Se a mensagem não foi adulterada, os resumo devem ser idênticos. E porque o assinante’S Chave Public foi usado para descriptografar a assinatura, o signatário’A chave privada deve ter sido usada para criptografá -la.

Por que usar a mensagem’S digerir de tudo? Por que não apenas criptografar a mensagem com o assinante’s chave privada e use a mensagem criptografada como a assinatura? Embora isso certamente funcionasse, é impraticável – ele dobraria o tamanho da mensagem quando a assinatura for incluída. O digesto é muito pequeno e de tamanho fixo, portanto, criptografar o resumo produz uma assinatura que é muito menor.

Códigos de autenticação de mensagem (MAC)

Um código de autenticação de mensagem, ou Mac, é uma pequena informação anexada a uma mensagem que pode verificar se a mensagem não foi adulterada e autenticar quem a criou.

Um tipo especial de Mac é o HMAC, que é construído usando um hash criptográfico e uma chave secreta. A chave secreta é acolchoada e concatenada com a mensagem, e a digestão, ou hash, é calculada. Este resumo é então concatenado novamente com a chave secreta acolchoada para produzir o valor HMAC. É impossível para um invasor produzir o mesmo HMAC sem ter a chave secreta.

O remetente e o receptor compartilham a chave secreta. Quando o receptor recebe uma mensagem, eles calculam o HMAC e a comparam ao HMAC fornecido com a mensagem. Se os hmacs correspondem, apenas alguém que possui a chave secreta poderia ter produzido a mensagem. A chave secreta em si nunca é transmitida.

Senhas, hashes de senha e sais

Os hashes criptográficos são extremamente úteis para sistemas que requerem verificação de senha. É um risco de segurança injustificável para armazenar o usuário’s senhas, mesmo que sejam criptografadas. Em vez disso, o resumo de cada senha é armazenado. Quando o usuário fornece a senha, ela é hash e comparada com o resumo que é armazenado. Isso é preferível porque a senha não pode ser recuperada de seu hash.

Uma desvantagem desse método é que, se os usuários tiverem a mesma senha, eles terão o mesmo valor de hash. Tabelas de digestas pré-calculadas para senhas comuns podem ser usadas para atacar um sistema se o arquivo que contém os digestos puder ser obtido. Essas mesas são conhecidas como mesas de arco -íris.

Por esse motivo, um sal-um valor aleatório e não secreto-é concatenado com a senha antes que o resumo seja calculado. Como todo usuário tem um sal diferente, não é viável usar tabelas pré-calculadas-precisaria haver uma tabela para cada valor possível de sal. Para que os sais sejam eficazes, eles devem ser o mais aleatórios possível e de tamanho adequado – de preferência pelo menos 32 bits.

O que são certificados?

Ao discutir a criptografia de chave pública, foi explicado que é preciso haver uma maneira de associar confiáveis ​​chaves públicas a seus proprietários. Usando alguém’A chave pública para criptografar uma mensagem destinada a eles exige saber que é realmente a chave pública deles.

As autoridades de certificação são a solução para este problema. Uma autoridade de certificado (a “Ca”) é uma organização que emite certificados digitais. Um certificado digital é um documento eletrônico que certifica a propriedade de uma chave pública.

Um certificado digital contém uma série de campos – a chave pública da qual está certificando a propriedade, o nome do proprietário (o sujeito), o nome do emissor (I.e. a CA), as datas de início e fim e o emissor’s assinatura digital. A assinatura digital verifica se a CA realmente emitiu o certificado. As assinaturas digitais são explicadas em mais detalhes aqui.

Para que o sistema funcione, a autoridade do certificado deve ser um terceiro de confiança. Há apenas um pequeno número de CAS, incluindo Comodo, Symantec e GoDaddy. CAS emitem seus próprios certificados que contêm suas chaves públicas, conhecidas como certificados raiz confiáveis.

Para obter um certificado de uma CA, uma organização deve fornecer à CA sua chave pública e documentação suficiente para estabelecer que é uma organização genuína. A CA verifica esses detalhes antes de emitir o certificado.

O uso mais comum de certificados é validar sites HTTPS (i.e. Sites que têm um URL começando com https: //). Quando um navegador da web se conecta a um site como a Amazon, o usuário precisa saber que o site pode ser confiável, eu.e. que o URL www.Amazonas.com realmente se refere a um site controlado pela empresa chamada Amazon. Isso é feito incorporando o nome de domínio do site no certificado’SIGNE. A CA garante que o nome de domínio seja controlado pela organização antes de emitir o certificado. O navegador da web tem sua própria lista de certificados raiz e, quando se conecta ao site, o site’s certificado é enviado de volta pelo servidor da web. Usando o certificado da CA, ele verifica se o certificado enviado pelo servidor da web foi emitido por um dos CA que reconhece e que o nome de domínio corresponde ao nome do domínio no certificado.

Por que esse cheque é importante? Enquanto a Amazon possui seu nome de domínio (que sabemos), por que precisamos do navegador para verificar o certificado?

Infelizmente, é possível para o software malicioso se passar por outra máquina. Quando um URL é inserido em um navegador da web, como https: // www.Amazonas.com, ele deve ser traduzido para um endereço IP, e.g. 192.168.1.64. Esses dígitos são o que o navegador usa para se conectar ao servidor da web. O processo de tradução é chamado de pesquisa DNS e envolve verificar o registro público de nomes de domínio para obter o endereço IP que a Amazon decidiu usar. O software malicioso pode comprometer as pesquisas do DNS, retornando o endereço IP errado, que pode ser para um site falso que se parece com a Amazon e foi projetado para obter detalhes do cartão de crédito.

É aqui que a verificação de certificado prova seu valor – o site falso pode’t Retornar o certificado genuíno e o navegador da web sinalizará que o certificado devolvido não está registrado no nome de domínio usado no URL. Na maioria dos navegadores, o site genuíno exibirá um símbolo de cadeado e clicar nele com um mouse mostrará o site’s identidade verificada, como no Chrome, abaixo.

É por isso que é importante usar URLs que começam com HTTPS e não HTTP – através do certificado, o navegador pode fornecer uma garantia de que o site está conectado é um proprietário verificado do domínio.

Como funciona o SSL/TLS?

A camada de soquetes seguros (SSL) é um protocolo criptográfico projetado para garantir comunicações sobre redes TCP/IP. SSL foi desenvolvido pela Netscape durante o início de 1990’s, mas várias falhas de segurança significavam que não era’T até SSL 3.0 foi lançado em 1996 que o SSL se tornou popular.

Foi também durante esse período que uma implementação de código aberto do SSL chamado SSLEAY foi disponibilizado por Eric Young, o que ajudou a garantir sua adoção generalizada na Internet. O servidor da Web do Apache também estava ganhando popularidade, e Ben Laurie, da Apache Fame, usou o SSLEAY para produzir Apache-SSL, um dos primeiros servidores da Web seguros disponíveis gratuitamente.

SSL tornou -se segurança da camada de transporte (TLS) com a publicação do TLS 1.0 padrão em 1999, seguido pelo TLS 1.1 e TLS 1.2, a versão mais recente. Todas as versões do TLS estão em uso generalizado, e é apenas recentemente que o suporte ao SSL 3.0 foi descontinuado em resposta à vulnerabilidade do poodle. Por simplicidade, nós’ll referir -se a SSL/TLS como TLS para o restante deste artigo.

Visão geral

O TLS visa fornecer conexões seguras entre um cliente (e.g. um navegador da web) e um servidor (e.g. um servidor da web) ao criptografar todos os dados que são passados ​​entre eles.

As conexões de rede comuns não são criptografadas; portanto, qualquer pessoa com acesso à rede pode farejar pacotes, ler nomes de usuário, senhas, detalhes do cartão de crédito e outros dados confidenciais enviados em toda a rede-uma situação obviamente inaceitável para qualquer tipo de comércio eletrônico baseado na Internet.

No início deste white paper, discutimos como a criptografia funciona, incluindo criptografia de chave pública e certificados. O TLS usa a criptografia de chave pública para verificar as partes na sessão criptografada e fornecer uma maneira de o cliente e o servidor concordarem com uma chave de criptografia simétrica compartilhada.

O aperto de mão SSL

O “aperto de mão” é a parte mais crítica do SSL/TLS, pois é aqui que os parâmetros importantes para a conexão são estabelecidos. As várias etapas do aperto de mão são descritas abaixo.
Protocolos de rede seguros 12

Etapa 1 – Cliente Olá

Depois de estabelecer uma conexão TCP/IP, o cliente envia uma mensagem ClientHello para o servidor. Isso declara a versão máxima do TLS que o cliente está disposto a apoiar, um número aleatório, a lista de suítes cifras suportadas em ordem de preferência e os algoritmos de compactação. As suítes cifras são identificadoras para um grupo de algoritmos criptográficos que são usados ​​juntos. Por exemplo, TLS_RSA_WITH_AES_128_CBC_SHA significa que o servidor’A chave pública da S RSA deve ser usada, e o algoritmo de criptografia é de 128 bits AES. .

O ClientHello é enviado no ClearText, para que qualquer pessoa capaz de interceptar os pacotes de rede possa lê -lo.

Etapa 2 – Hello Server

O servidor responde ao clientHello com uma mensagem de servidorhello. Ele diz ao cliente a versão TLS para usar, juntamente com a suíte cifra e o algoritmo de compressão que ele escolheu. O servidorhello também fornece um número aleatório gerado pelo servidor e um identificador de sessão. O servidorhello também é enviado no ClearText.

Imediatamente após o envio do servidorhello, o servidor envia seu certificado, contendo sua chave pública, para o cliente. Isto é seguido por uma mensagem opcional ServerKeyExchange que contém valores necessários adicionais para a troca de chaves.

Se o servidor estiver configurado para exigir que o cliente se identifique com um certificado de cliente, o servidor solicitar.

Finalmente, o servidor envia ao cliente uma mensagem de servidorhellodone, ainda em ClearText.

Etapa 3 – Verifique os certificados do servidor

Normalmente, o cliente tem um cache de certificados ou certificados raiz da CA pelos quais pode verificar se o servidor’s certificado é genuíno (e registrado no servidor’s endereço IP). Se o servidor’S Certificado é desconhecido, o cliente pode dar a opção de aceitar o certificado de qualquer maneira (o que é potencialmente perigoso) ou pode cortar a conexão. Esta mensagem é enviada no ClearText.

Etapa 4 – Resposta ao cliente

Se o servidor solicitar um certificado do cliente, o cliente enviará seu certificado, seguido pela mensagem ClientKeyExchange.

Para a mensagem ClientKeyExchange, o cliente gera o que é chamado de segredo de mestre, composto por 48 bytes. Este segredo é enviado ao servidor como parte desta mensagem, mas é criptografado com o servidor’s chave pública (obtida do servidor’s certificado) para que apenas o servidor possa descriptografá -lo com sua chave privada (pois as mensagens ainda estão sendo enviadas como texto simples).

Depois que o cliente e o servidor compartilham o segredo do Premaster, cada um deles o usa em combinação com os dois valores aleatórios que foram trocados anteriormente para produzir o segredo principal e, posteriormente, as chaves da sessão – as chaves simétricas usadas para criptografar e descriptografar dados na sessão TLS subsequente.

A mensagem ChanGecipherspec é enviada após a mensagem ClientKeyExchange. Esta mensagem indica ao servidor que todas as mensagens subsequentes serão criptografadas usando as chaves de sessão recém -criadas. É seguido pela mensagem finalizada, a primeira a ser criptografada. A mensagem final é um hash de todo o aperto de mão até agora que permite ao servidor verificar se esse foi o cliente que está se comunicando com o servidor em todo o aperto de mão.

Etapa 5 – Verifique o certificado do cliente

Se o servidor solicitar o certificado do cliente, será verificado para garantir que esteja correto.

Etapa 6 – Servidor terminado

O servidor responde à mensagem finalizada do cliente com uma mensagem ChanGecipherspec, seguida de uma mensagem finalizada criptografada, que novamente é um hash do aperto de mão até este ponto. Isso permite que o cliente verifique se este é o mesmo servidor que está se comunicando com ele durante o aperto de mão.

Etapa 7 – comunicação segura estabelecida

A essa altura, todas as mensagens são criptografadas e, portanto, um canal de comunicação seguro em toda a rede entre cliente e servidor foi estabelecido.

Registros e alertas

Como os dados são embalados e enviados pela rede após a conclusão do handshake? Isso envolve o protocolo de registro e o protocolo de alerta.

Protocolo de registro

O protocolo de registro é responsável pela compressão, criptografia e verificação dos dados. Todos os dados a serem transmitidos são divididos em registros. Cada registro consiste em um byte de cabeçalho, seguido pela versão do protocolo, o comprimento dos dados a serem enviados (conhecido como carga útil) e a própria carga útil. Em primeiro lugar, os dados são compactados se a compressão foi acordada. Então um Mac é calculado e anexado aos dados. O MAC permite que o receptor verifique se o registro não foi adulterado. Seu cálculo inclui um número de sequência que remetente e receptor acompanham. Finalmente, os dados e o Mac anexado são criptografados usando a sessão’S chaves de criptografia, e o resultado é a carga útil para o registro. No final do recebimento, o registro é descriptografado e o Mac é calculado para verificar se o registro’s dados não foram adulterados com. Se a compressão foi usada, é descomprimida.

Alertas

Se ocorrerem erros, o SSL/TLS define um protocolo de alerta para que as mensagens de erro possam ser passadas entre o cliente e o servidor. Existem dois níveis – aviso e fatal. Se ocorrer um erro fatal, depois de enviar o alerta, a conexão é fechada. Se o alerta for um aviso, cabe à parte receber o alerta sobre se a sessão deve ser continuada. Um alerta importante é uma notificação próxima. Enviado quando uma das partes decide fechar a sessão, a Notificação Fechar é necessária para o término normal de uma sessão. Vale a pena notar que algumas implementações SSL/TLS não enviam esta mensagem – elas simplesmente encerram a conexão.

Versões

. Por exemplo, 3.1 corresponde a TLS 1.0. As versões principais atualmente em uso são mostradas aqui.
Estes são úteis para se familiarizar, pois os números de versão interna são frequentemente preferidos.

Vulnerabilidades SSL/TLS

O TLS é um protocolo de rede seguro maduro e amplamente usado que garantirá transações na Internet por muitos anos. Como qualquer protocolo seguro, no entanto, várias vulnerabilidades importantes foram descobertas ao longo dos anos. As vulnerabilidades continuarão sendo descobertas e é importante manter o software que utiliza o TLS atualizado para que os mais recentes patches de segurança sejam aplicados.

Algumas das vulnerabilidades mais conhecidas e como elas foram abordadas são discutidas abaixo.

Heartbleed

O Heartbleed é uma das vulnerabilidades mais graves já encontradas no software TLS, permitindo o roubo de chaves do servidor, IDs de sessão do usuário e senhas de usuário de sistemas comprometidos. Não foi, no entanto, uma falha de protocolo SSL, mas um bug de implementação (conhecido como um buffer super-leitura) no OpenSSL‘s biblioteca gratuita, que é amplamente usada na Internet. Milhões de máquinas foram afetadas e numerosos ataques bem -sucedidos relatados.

Os sistemas de software que não usam as versões relevantes do OpenSSL não foram afetados. O OpenSSL foi rapidamente remendado, mas corrigir milhões de máquinas leva tempo. As máquinas não apenas precisam ser corrigidas, mas as chaves privadas do servidor devem ser atualizadas, as senhas de usuário alteradas e os certificados reeditam. Um ano depois, é provável que ainda haja máquinas comprometidas na internet que não foram adequadamente modificadas.

Estima -se que o custo total do Heartbleed esteja na faixa de centenas de milhões de dólares.

POODLE

Poodle é uma vulnerabilidade em um protocolo SSL mais antigo, SSL 3.0. Enquanto a maioria dos sistemas usa TLS 1.0, 1.1 ou 1.2, o protocolo TLS possui uma provisão de caça-baixa para permitir a interoperabilidade com software mais antigo ainda usando o SSL 3.0. Então, os ataques de poodle usam esta provisão de devolução para enganar os servidores para rebaixar para SSL 3.0.
A correção mais simples é desativar o SSL 3.0 em clientes e servidores. SSL 3.0 foi publicado em 1996, há muito tempo foi substituído e não deve haver necessidade de apoiá -lo após quase 20 anos. Poodle é uma vulnerabilidade muito menos séria do que o Heartbleed.

RC4

RC4 é uma cifra TLS amplamente usada que não é mais considerada como segura. O RC4 também é conhecido como ARC4 ou Arcfour (porque o RC4 é marca registrada). Sua velocidade e simplicidade tornaram o RC4 popular, mas recentemente (fevereiro de 2015) RFC7465 recomendou que não fosse mais usado.

Protocolo de transferência de arquivos SSL/TLS: FTPS

Um dos usos mais comuns do SSL/TLS é uma forma segura de transferência de arquivo conhecida como FTPS.

FTP tradicional, conforme definido no RFC 959, não menciona a segurança. Isso é compreensível como foi escrito em 1985 e com base nas especificações da década de 1970. Foi quando as universidades e os militares eram os principais usuários da Internet e a segurança não era a preocupação de que seja hoje.

Como resultado, em nomes de usuários e senhas FTP são (ainda) enviados pela rede em texto claro, o que significa que qualquer pessoa capaz de cheirar os pacotes TCP/IP pode capturá-los. Se o servidor FTP estiver na Internet, os pacotes passam por redes públicas e devem ser consideradas disponíveis ao público.

Não foi até os anos 90 quando o Netscape desenvolveu sua camada de soquetes seguros (SSL) que uma solução se tornou prática. Um rascunho da RFC em 1996 descreveu uma extensão para FTP chamada FTPS que permitia que os comandos FTP fossem usados ​​em uma conexão SSL e, em 2005, isso foi desenvolvido em um RFC formal.

Implementado por clientes como FileZilla e servidores como o Proftpd, os FTPs rapidamente se tornaram populares.

FTPs implícitos

Existem duas formas de FTPS – modo implícito e modo explícito. O modo implícito FTPS é obsoleto e não é amplamente utilizado, mas ainda é encontrado ocasionalmente.

FTPs implícitos não têm um comando explícito para proteger a conexão de rede – em vez disso, o faz implicitamente. Nesse modo, o servidor FTPS espera que o cliente FTPS inicie imediatamente um aperto de mão SSL/TLS ao conectar. Caso contrário, a conexão é descartada. A porta do servidor padrão para conexões de modo implícito é 990 (não a porta 21 padrão usada para FTP).

Depois que a conexão SSL/TLS é estabelecida, os comandos FTP padrão são usados ​​para navegar no servidor’S Sistema de Arquivos e Transferir Arquivos. Como a conexão é segura, as senhas podem ser enviadas e os dados não podem ser inspecionados por escutas.

FTPs explícitos

No modo FTPS explícito, o cliente deve solicitar explicitamente que a conexão seja protegida enviando o comando auth tls para o servidor. Uma vez que este comando seja enviado, o shake de mão SSL/TLS começa como no TLS implícito, e a conexão de comando é protegida.

A vantagem de usar o modo explícito FTPS sobre o modo implícito é que o mesmo número da porta que o FTP padrão pode ser usado – porta 21. Usuários comuns de FTP simplesmente não enviam o comando de autenticação e, portanto, nunca protegem a conexão. O administrador do servidor pode opcionalmente exigir que o comando de autenticação seja usado se não desejar que as transferências de arquivos não garantidas sejam feitas.

Modo explícito Os FTPs sempre devem ser usados ​​em preferência ao modo implícito, principalmente porque o modo implícito foi depreciado por muitos anos.

Desvantagem dos FTPs

O FTPS tem uma desvantagem significativa, que é o uso de uma conexão de rede separada para dados, incluindo conteúdo de arquivos e listagens de diretórios. Na verdade, isso faz parte do protocolo FTP – os comandos são enviados através do inicial “ao controle” conexão na porta 21 e, sempre que os dados são transferidos, uma nova conexão de rede deve ser estabelecida para a transferência. O cliente e o servidor devem concordar com um número de porta, e uma conexão deve ser aberta.

Com FTP não criptografado, este não é’T muito problemático. Pode haver problemas com a exaustão das conexões de rede se muitas transferências forem feitas dentro de um curto período de tempo. Como cada transferência requer uma nova conexão, e os sistemas operacionais geralmente exigem alguns minutos para liberar conexões fechadas, muitas transferências de arquivos pequenos podem resultar em eventuais erros.

O problema mais significativo é passar pelos firewalls. Os firewalls são normalmente configurados para permitir o acesso via porta 21. Os firewalls modernos também são inteligentes o suficiente para poder inspecionar os comandos enviados entre cliente e servidor (porta ou PASV) para poder determinar quais portas devem ser abertas dinamicamente para permitir transferências de dados.
Com FTPs, no entanto, os comandos estão em um canal criptografado, e os firewalls não podem inspecioná -los. Isso significa que eles não podem abrir automaticamente portas de dados e, portanto, transferências e listagens de diretórios falham. Em vez disso, uma gama fixa de portas deve ser acordada com antecedência e configurada em cliente, servidor e firewall.

Futuro de FTPs

Atualmente, o FTPS tem um forte concorrente no SFTP, ou protocolo de transferência de arquivos SSH. São protocolos completamente diferentes, e seus méritos relativos serão examinados na próxima seção. No entanto, FTP e FTPs têm uma enorme base de instalação e, sem dúvida, continuarão sendo amplamente utilizados por muitos anos.

Como funciona o SSH?

História do SSH

No final de 1980’s e 1990’S, ferramentas de rede como rlogin e telnet eram comumente usadas para logins em máquinas remotas, normalmente em plataformas Unix. Essas ferramentas permitiram que os usuários abrissem conchas de comando que lhes permitissem executar comandos nas máquinas remotas como se estivessem realmente na máquina e eram extremamente úteis para administração de sistemas.

Houve uma desvantagem crítica – nenhuma dessas ferramentas era segura. As senhas foram enviadas por redes em texto simples, o que significa que qualquer pessoa capaz de farejar a rede poderia obter credenciais para a máquina remota. Esse problema é por que Tatu Ylönen, pesquisador finlandês da Universidade de Tecnologia de Helsinque, decidiu que um protocolo de rede seguro era necessário. Em 1995, ele escreveu a primeira versão do SSH, conhecida como SSH-1, e o lançou como freeware. Consistia em um servidor e cliente seguro.

À medida que sua popularidade cresceu rapidamente, Ylönen fundou a segurança da SSH Communications para comercializar e desenvolver a SSH como um produto proprietário. Em 1999, o Björn Grönvall começou a trabalhar em uma versão anterior do Freeware, e a equipe OpenBSD financiou seu trabalho para produzir o OpenSsh disponível gratuitamente. Os portos foram logo feitos para muitas outras plataformas, e o OpenSsh continua sendo a versão mais conhecida e usada do SSH.

Em 2006 SSH 2.0 foi definido na RFC 4253. O SSH-2 é incompatível com o SSH-1 e melhorou a segurança e os recursos, tornando o SSH-1 obsoleto.

Visão geral do SSH

O SSH é um protocolo de rede seguro que pode ser usado em qualquer plataforma para qualquer finalidade que exija comunicação de rede segura. Os usos típicos incluem:

• Ferramentas de login remotas seguras, como o cliente SSH;
• transferência de arquivo segura, como as ferramentas SCP e SFTP; e
• encaminhamento seguro de porta ou tunelamento seguro.

O SSH-2 usa uma arquitetura em camadas e consiste em uma camada de transporte, uma camada de autenticação de usuário e uma camada de conexão.
A camada de transporte percorre TCP/IP e fornece criptografia, autenticação do servidor, proteção de integridade de dados e compactação opcional. A camada de autenticação do usuário lida com a autenticação do cliente, enquanto a camada de conexão fornece serviços como logins interativos, comandos remotos e conexões de rede encaminhadas.

A camada de transporte

A camada de transporte é baseada em mensagens e fornece criptografia, autenticação do host e verificação de integridade. As mensagens são enviadas entre o cliente e o servidor sobre TCP/IP através do protocolo de pacote binário – “pacotes” de dados são trocados no formato definido abaixo, e a carga útil de cada pacote é a mensagem:
uint32 packet_length byte padding_length byte [n1] carga útil; n1 = packet_length – padding_length – 1 byte [n2] preenchimento aleatório; n2 = Padding_length byte [M] Mac (Código de autenticação da mensagem – Mac); M = mac_length

O Mac é um campo importante, porque é o Mac que permite que os destinatários das mensagens tenham certeza de que as mensagens não foram adulteradas – a verificação da integridade mencionada acima. O Mac é calculado sobre o restante dos dados no pacote e usa um segredo compartilhado estabelecido entre cliente e servidor, e um número de sequência que ambas as partes acompanham. Macs são descritos neste post.

Estabelecendo uma sessão

Como começa uma sessão entre um cliente e um servidor? Cada lado envia uma sequência de identificação depois que a conexão TCP/IP foi estabelecida. Esta string está no seguinte formato:
SSH-2.0-SoftwareVersion SP Comentários Cr lf

Aqui “Sp” significa um espaço, “Cr” é um personagem de retorno de carruagem e “Lf” é um personagem de alimentação de linha. A versão de software é a versão do fornecedor, e os comentários e espaço são opcionais. Portanto, no caso do Completeftp, quando um cliente se conecta ao servidor, recebe a seguinte sequência:
SSH-2.0-COMPLETEFTP_9.0.0

A extremidade da corda com o retorno obrigatório de carruagem e o feed de linha – nenhum comentário é usado.

Depois que as seqüências de identificação são trocadas, várias opções devem ser acordadas-as cifras usadas para criptografia, os algoritmos Mac usados ​​para a integridade dos dados, os métodos de troca de chaves usados ​​para configurar as chaves de sessão única para criptografia, os algoritmos de chave pública são usados ​​para autenticação e, finalmente, quais algorits de compressão são usados. O cliente e o servidor enviam uma mensagem SSH_MSG_KEXINIT Listando suas preferências para essas opções:
byte byte (bytes aleatórios) lista de nome kex_algorithms-list server_host_key_algorithms lists-list Encryption_algorithms_client_to_server Nome-list listtion MS_SERVER_TO_CLIENT-NOME-LIST COMPRESSÃO COMPRESSÃO COMPRESSÃO COMPRESSÃO COMPRESSÃO DE NOME

Esta mensagem é a carga útil de um pacote de protocolo binário cujo formato é descrito acima. Listas de nomes de algoritmos são separados por vírgula. O cliente envia listas de algoritmo em ordem de preferência, enquanto o servidor envia uma lista de algoritmos que ele suporta. O primeiro algoritmo suportado em ordem do cliente’s preferência é o algoritmo que é escolhido. Dadas as duas mensagens, cada lado pode descobrir quais algoritmos devem ser usados.

Após SSH_MSG_KEXINIT, o algoritmo de troca de chaves selecionado, o que pode resultar em várias mensagens que estão sendo trocadas. O resultado final são dois valores: um segredo compartilhado, k e um hash de troca, h. Estes são usados ​​para derivar chaves de criptografia e autenticação. Um ssh_msg_newkeys é enviado para significar o fim dessas negociações, e cada mensagem subsequente usa as novas chaves e algoritmos de criptografia.

Com a conexão SSH-2 estabelecida, o cliente solicita um “serviço” (geralmente SSH-userauth para iniciar o processo de autenticação) com a mensagem SSH_MSG_SERVICE_REQUEST.

Camada de autenticação

O próximo passo é que o cliente se identifique no servidor e seja autenticado. Isso é gerenciado através da camada de autenticação do usuário, que é executada no topo da camada de transporte. Isso significa que as mensagens de autenticação do usuário são criptografadas e trocadas usando a camada de transporte.

A autenticação do usuário é iniciada pelo cliente com um “serviço” Solicitação para o serviço SSH-Userauth. Se o servidor responder, permitindo a solicitação, o cliente envia uma solicitação de autenticação, que inclui seu nome de usuário e o método de autenticação.

Existem vários métodos de autenticação possíveis e qual é usado dependerá do cliente e do servidor’suporte para isso. O método mais popular é a autenticação de senha, que é auto -explicativa. Outro é a autenticação de chave pública. Normalmente, o cliente propõe um método, e o servidor aceita ou rejeita esse método.

Um exemplo de uma solicitação de autenticação de senha por um usuário chamado “Enterprisedt” é mostrado abaixo:
byte ssh_msg_userauth_request string “Enterprisedt” [nome do usuário] string “ssh-userauth” [nome do serviço] string “senha” [método de autenticação] boolean false “mypassword” [senha do usuário]

O servidor validará a senha enviada para este usuário contra os detalhes que ela armazenou para o usuário. O servidor não armazenará o usuário’s Senha real para validação, mas um hash de criptopica da senha, que não pode ser reverso para obter a senha.

Se a solicitação de autenticação do usuário for rejeitada (por exemplo, uma senha incorreta foi fornecida), uma mensagem de falha é enviada pelo servidor e fornece uma lista de autenticações alternativas que podem ser experimentadas.

É comum enviar “nenhum” Como o método de autenticação inicial, e o servidor geralmente responde com uma mensagem de falha que contém uma lista de todos os métodos de autenticação disponíveis. Um exemplo de resposta a “nenhum” é mostrado abaixo:

BYTE SSH_MSG_USERAUTH_FAILURE NOME-LIST Password, PublicKey Boolean False (sinalizador de sucesso parcial)

Aqui, o servidor está informando ao cliente que a senha ou a autenticação do PublicKey pode ser usada.
Se a solicitação de autenticação de senha for bem -sucedida, o servidor retornará uma mensagem de sucesso como mostrado abaixo:
BYTE SSH_MSG_USERAUTH_SUCCESS

Neste ponto, a autenticação está concluída e outros serviços podem ser solicitados. Isso pode incluir solicitações de encaminhamento TCP/IP e canais para acesso ao terminal, execução de processos e subsistemas como SFTP.

Camada de conexão

A peça final de SSH-2’S Arquitetura em camadas é a camada de conexão, que fornece serviços de rede, como sessões interativas e encaminhamento de portas no topo da camada de transporte, que fornece a segurança necessária.

Uma vez estabelecido, uma conexão SSH pode hospedar um ou mais canais SSH, que são tubos de dados lógicos multiplexados sobre a conexão. O cliente pode abrir vários canais em uma conexão com o mesmo servidor e executar diferentes tarefas de rede em diferentes canais. Na prática, as implementações SSH raramente usam vários canais em uma conexão, preferindo abrir uma nova conexão para cada canal.

Uma característica importante dos canais SSH é o controle de fluxo. Os dados só podem ser enviados em um canal quando o destinatário indicou que está pronto para recebê-lo-uma forma de controle de fluxo de janela deslizante. O tamanho da janela é estabelecido pelo destinatário quando o canal é aberto e o tamanho da janela é diminuído à medida que os dados são enviados. Periodicamente, o destinatário envia uma mensagem para aumentar o tamanho da janela.

A mensagem ssh_msg_channel_open usada para abrir uma sessão interativa é mostrada abaixo. Esta sessão pode ser usada posteriormente para uma sessão de terminal, para executar um comando remoto ou iniciar um subsistema como o SFTP.

byte ssh_msg_channel_open string “sessão” uint32 canal remetente uint32 tamanho inicial da janela uint32 tamanho máximo do pacote

O tamanho inicial da janela define o número de bytes que o destinatário desta mensagem pode enviar para o remetente, enquanto o tamanho máximo do pacote é a maior quantidade de dados que ele aceitará em uma única mensagem.

O destinatário desta mensagem responde com uma mensagem SSH_MSG_CHANNEL_OPEN_CONFIRMATION, se estiver preparado para abrir o canal solicitado:
byte ssh_msg_channel_open_confirmation uint32 canal de destinatário uint32 canal remetente uint32 tamanho inicial da janela uint32 tamanho máximo do pacote

Depois que um canal é aberto com sucesso, os dados podem ser trocados e solicitações específicas do canal podem ser enviadas. Quando o tamanho da janela deslizante para o cliente ou servidor se torna muito pequeno, o proprietário da janela envia uma mensagem ssh_msg_channel_window_adjust para aumentá-la:
byte ssh_msg_channel_window_adjust uint32 canal de destinatário uint32 bytes para adicionar

Os dados são enviados em todo o canal através da mensagem SSH_MSG_CHANNEL_DATA. Como os dados são usados ​​dependerão do tipo de canal que foi estabelecido:
BYTE SSH_MSG_CHANNEL_DATA UINT32 Dados da sequência de canais do destinatário

As solicitações de canal são usadas para executar ações específicas em um canal. Os pedidos comuns incluem iniciar um shell ou executar um comando remoto. Por exemplo, um shell remoto é iniciado pela solicitação mostrada abaixo:

BYTE SSH_MSG_CHANNEL_REQUEST UINT32 String de canal destinatário “Shell” Boolean Want Responder

Um comando remoto é executado pela seguinte solicitação:
BYTE SSH_MSG_CHANNEL_REQUEST UINT32 String de canal destinatário “Exec” Boolean Want Reply

Finalmente, um subsistema SFTP pode ser aberto por esta solicitação:
BYTE SSH_MSG_CHANNEL_REQUEST UINT32 String de canal destinatário “Subsistema” Boolean Want Reply String “SFTP-SERVER”

Subsistemas são conjuntos de comandos remotos que são predefinidos na máquina do servidor. O mais comum é o SFTP, que fornece comandos para transferir e manipular arquivos. Os comandos do subsistema (incluindo o protocolo SFTP) atropelados sobre SSH, i.e. Os dados para os comandos do subsistema são enviados em mensagens SSH_MSG_CHANNEL_DATA.

Quando uma dessas mensagens chega ao cliente ou servidor, ele é passado para o subsistema para processamento.
Uma vez que o cliente ou o servidor terminar de usar o canal, ele deve ser fechado. A mensagem ssh_msg_channel_eof é enviada para indicar que não mais dados serão enviados na direção desta mensagem. A mensagem SSH_MSG_CHANNEL_CLOSE indica que o canal agora está fechado. O destinatário deve responder com um SSH_MSG_CHANNEL_CLOSE se eles ainda não tiveram um. Uma vez fechado, o canal não pode ser reaberto.

Protocolo de transferência de arquivos SSH: SFTP

O subsistema mais comum usado com SSH é o SFTP, que fornece comandos para transferir e manipular arquivos. O SFTP também é conhecido como protocolo de transferência de arquivos SSH e é um concorrente do FTPS – FTP tradicional em uma conexão SSL/TLS.

O subsistema SFTP percorre a camada de transporte SSH, mas é um protocolo sofisticado baseado em mensagens por si só. As mensagens SFTP são transmitidas como o campo de dados da camada de transporte’ssh_msg_channel_data mensagem
As mensagens SFTP estão em formato padrão, como mostrado abaixo:
UINT32 Tipo de comprimento tipo UINT32 ID de solicitação . Digite campos específicos…

O primeiro campo é o comprimento da mensagem, excluindo o campo de comprimento e o próximo é o tipo de mensagem. O terceiro campo é o ID da solicitação – cada solicitação enviada do cliente tem um ID de solicitação e o servidor’a resposta deve incluir o ID de solicitação correspondente.

Algumas das mensagens SFTP mais importantes juntamente com seus IDs de tipo são mostradas e descritas abaixo:
Ssh_fxp_init 1 ssh_fxp_version 2 ssh_fxp_open 3 ssh_fxp_close 4 ssh_fxp_read 5 ssh_fxp_write 6 ssh_fxp_status 101 ssh_fxp_data 103

Ssh_fxp_init é a primeira mensagem enviada pelo cliente a iniciar a sessão SFTP, e o servidor responde com SSH_FXP_VERSION, indicando as versões que suporta.
Ssh_fxp_open solicita ao servidor abrir um arquivo (ou opcionalmente, crie -o se não existir), enquanto

Ssh_fxp_close fecha um arquivo. SSH_FXP_READ SOLE LEIA UM CERTO BYTE FIRE DE UM ARQUIVO, e o servidor responde com SSH_FXP_DATA, que contém os bytes solicitados. SSH_FXP_WRITE é usado para gravar dados em um arquivo, e um de seus campos é os dados a serem escritos (bem como o deslocamento no arquivo).

Se algum dos comandos acima falhar, SSH_FXP_STATUS for retornado com um código de erro indicando o tipo de erro que ocorreu. Também é usado para sinalizar uma gravação bem -sucedida em resposta a ssh_fxp_write.

Também existem comandos para outras operações de arquivo e diretório padrão, como remover arquivos (ssh_fxp_remove), renomear arquivos (ssh_fxp_rename) e criar e remover diretórios (ssh_fxp_mkdir, ssh_fxp_rmdir). Os diretórios são lidos abrindo -os (ssh_fxp_opendir) e enviando solicitações SSH_FXP_RADDIR. Novamente, SSH_FXP_STATUS é usado para indicar sucesso ou falha dessas solicitações.

Não existe uma mensagem específica do SFTP para encerrar uma sessão SFTP – em vez disso, o cliente fecha o canal SSH sendo usado.

É importante observar que o SFTP é um protocolo totalmente diferente do FTP tradicional, i.e. Não são os comandos FTP enviados por uma conexão SSH. Por outro lado, o FTPS são os comandos FTP enviados por uma conexão SSL/TLS. Os dois protocolos são facilmente confusos, pois ambos são protocolos seguros para transferir arquivos.

SFTP vs FTPS

Descrevemos como FTPS e SFTP funcionam, acima. Essencialmente, ambos os protocolos alcançam exatamente a mesma coisa-transferência de arquivos seguros e manipulação remota e segura dos sistemas de arquivos.

Eles são, no entanto, protocolos completamente diferentes, e as pessoas que implementam uma solução de transferência de arquivos segura precisarão decidir qual protocolo usar.

O uso existente é naturalmente uma consideração importante. Se SFTP e/ou SSH já forem usados ​​em outras áreas de uma organização, é prudente usar o SFTP. O conhecimento e as habilidades existentes na organização podem ser alavancados, bem como infraestrutura técnica. Da mesma forma, se FTP e/ou FTPS já for usado em outros lugares, pode ser melhor usar FTPS.

Os requisitos do projeto também podem ditar o protocolo. Se uma solução do lado do servidor estiver sendo implementada, pode ser que os clientes sejam restritos a um protocolo específico e, portanto, nenhuma decisão precisa ser tomada.

Mas e se o ponto de partida for uma lousa completamente limpa e não houver restrições sobre qual protocolo que possa ser usado? Existe um vencedor claro?

SFTP – um vencedor claro

Sim, e é SFTP. Alguns anos atrás, essa decisão não foi tão direta, principalmente por causa do domínio do protocolo FTP na maioria das organizações. Agora, clientes e software de servidor estão amplamente disponíveis para SFTP e FTPS – na verdade, muitos aplicativos, como suporte completo.

Isso significa que uma decisão pode ser tomada por motivos puramente técnicos, e o SFTP tem pelo menos duas vantagens técnicas importantes sobre o FTP e o FTPS.

SFTP é melhor com firewalls

Os FTPs podem ser dolorosos para trabalhar com firewalls. Isso ocorre porque as listagens de diretórios e transferências de arquivos são feitas em uma nova conexão de rede que é separada do canal de controle na porta 21. Por padrão, os firewalls não permitem essas conexões nos FTPs (embora geralmente funcione com FTP, pois os firewalls são capazes de inspecionar o tráfego de rede e abrir a porta apropriada com antecedência). Em vez disso, o firewall e o servidor devem ser configurados para uma certa gama de portas para transferência de dados, o que pode ser complicado.

Por outro lado, o SFTP apenas funciona com firewalls. Dados e comandos são enviados pela porta 22 padrão, que geralmente é ativada com firewalls por padrão. Esta é uma vantagem significativa sobre o FTP.

SFTP não’t Use certificados

O FTPS usa certificados para identificar o servidor para o cliente. A identificação do servidor é importante, pois é como o cliente verifica que está se conectando ao servidor correto. Para ser útil, no entanto, os certificados devem ser emitidos por uma autoridade de certificado – uma organização que está autorizada a emiti -los. Obter um certificado pode ser caro e demorado.

SFTP não’T Certificados de uso – O servidor é identificado por sua chave pública (que é o que um certificado contém, então ambos estão usando o mesmo mecanismo). Então, enquanto um cliente tiver a chave pública do servidor disponível, eles podem confirmar que o servidor é o correto. O servidor’s chave pública (diferentemente de um certificado) pode ser gerada pela organização, e uma autoridade de certificado não é necessária. Isso reduz significativamente a quantidade de administração necessária para colocar um servidor em funcionamento.

Existem algumas vantagens em ter uma organização reconhecida, como uma autoridade de certificado para emitir certificados, mas na maior parte do tempo não é necessário, principalmente para projetos internos.

Existe alguma desvantagem em usar SFTP?

A ausência de certificados pode ser um problema se você quiser o reconhecimento de uma autoridade de certificado, mas a principal desvantagem do SFTP é que é um protocolo complexo que é difícil de implementar. Escrever um cliente SFTP ou um servidor SFTP não é uma tarefa fácil.

É muito improvável que isso afete as organizações usando o SFTP como parte de sua infraestrutura – uma grande variedade de clientes e servidores está disponível em várias plataformas e eles precisam apenas selecionar os aplicativos mais adequados. Todos os clientes e servidor devem interoperar, portanto, há uma latitude considerável na escolha dos produtos. É provável que os recursos adicionais ao protocolo ditem a seleção final.

Conclusão

Este conteúdo explicou como SSL/TLS e SSH trabalham para proteger dados transferidos por uma rede e, em particular, os protocolos FTPS e SFTP. Embora em funcionalidade semelhante, FTPs e SFTP são muito diferentes na implementação. Em uma comparação frente a frente, o SFTP sai por cima, embora seja aconselhável optar por apoiar os dois protocolos na infraestrutura técnica da sua organização.

Outros artigos técnicos

• O que é transferência de arquivo gerenciada (MFT)?
• O que é SFTP?
• O que é FTP?
• O que é FTPS?
• FTPS vs SFTP

SSL vs SSH-uma comparação não tão técnica

Você sabia que SFTP e FTPs recebem sua segurança de protocolos subjacentes? Descubra as semelhanças e diferenças entre SSH e SSL hoje!

Visão geral

Os protocolos de transferência de arquivos seguros mais usados, SFTP e FTPs, recebem sua segurança de protocolos subjacentes. SFTP de SSH e FTPS da SSL. Vamos comparar os dois.

No passado, havia apenas um método popular para transferir arquivos por uma rede – FTP, que simplesmente significa protocolo de transferência de arquivos. O FTP suporta transferências de arquivos em massa e até permite que os usuários naveguem por diretórios remotos, criem diretórios, excluam diretórios e executem algumas outras tarefas semelhantes às realizadas nos sistemas de arquivos locais.

FTP é um protocolo baseado em TCP. Portanto, pode ser muito útil para baixar/fazer upload de arquivos em uma LAN ou mesmo através da Internet. No entanto, o FTP foi projetado em um momento em que o uso da Internet era limitado a algumas organizações e ameaças baseadas em rede eram inexistentes.

Hoje, já existem uma infinidade de ameaças e as conexões FTP podem ser comprometidas por ataques de sniffer, força bruta e outras formas de ataques cibernéticos. Para proteger as transferências de arquivos dessas ameaças, foram desenvolvidos protocolos seguros de transferência de arquivos. Desses protocolos, dois ganharam adoção generalizada – FTPS e SFTP.

Na verdade, os FTPs recebem sua proteção contra SSL/TLS (Segurança de camada de soquetes/camada de transporte), enquanto o SFTP recebe o seu próprio SSH (Shell Secure).

Semelhanças entre SSH e SSL

Quando você compara os atributos de segurança deles, você descobrirá que o SSH e o SSL têm semelhanças muito fortes. Ambos oferecem criptografia de dados em movimento, autenticação do servidor, autenticação do cliente e mecanismos de integridade de dados.

Criptografia de dados em movimento

A criptografia de dados em movimento é uma capacidade de segurança que impede que a escalada visualize dados enviados por uma rede. Em outras palavras, mantém os dados transmitidos confidenciais. É suportado em SSH e SSL e Atos convertendo os dados de texto simples no que é conhecido como CipherText.

Todo um espionagem veria ao ver otexto da cifra em uma conexão criptografada seria uma sequência incompreensível de caracteres.

Essas duas capturas de tela mostram o que um bisbilhoteiro vê ao cheirar uma conexão não criptografada e uma conexão criptografada. Observe como a conexão não criptografada falha em ocultar o nome de usuário e a senha. Na conexão não criptografada, essas credenciais de login já são ininteligíveis.

Conexão não criptografada (E.g. Ftp)

Conexão criptografada (E.g. Sftp ou ftps)

Tanto o SSH quanto o SSL fornecem criptografia de dados em movimento através do que é conhecido como criptografia de chave simétrica. Esse tipo de criptografia emprega uma chave compartilhada usada para criptografia e descriptografia. Algumas cifras de chave simétricas comuns incluem AES, 3DEs, Blowfish, Twofish e RC4.

Autenticação de servidor e cliente

Uma conexão criptografada se torna inútil se você, sem saber, conectado a um servidor falso ou a um cliente malicioso. Enquanto SSH e SSL usam criptografia simétrica para preservar a confidencialidade dos dados transmitidos, eles usam outra forma de criptografia para autenticação. A autenticação permite que uma parte verifique se a outra parte é realmente quem afirma que é.

Para implementar a autenticação, SSH e SSL usam criptografia assimétrica.k.a. Criptografia de chave pública. Os algoritmos populares de criptografia de chave pública são RSA, DSA e Ecdsa, todos suportados por SSH e SSL.

Ao contrário da criptografia simétrica, que usa uma única chave para criptografia e descriptografia, a criptografia assimétrica usa duas teclas – uma chave pública e uma chave privada.

A criptografia de chave pública pode ser usada por um cliente para autenticar o servidor. Isso é conhecido como autenticação do servidor. A autenticação do servidor impede que os aplicativos do cliente se conectem inadvertidamente e depois faça uma transação com um servidor malicioso que está seriamente legítimo.

Por outro lado, a criptografia de chave pública também pode ser usada por um servidor para autenticar um cliente. Isso é conhecido como autenticação do cliente. O artigo O que é uma chave SFTP Inclui uma boa introdução sobre autenticação do cliente e criptografia de chave pública.

Mecanismos de integridade de dados

Quando você está recebendo informações confidenciais, a integridade dos dados é tão importante quanto a confidencialidade dos dados. Você deve garantir que os dados que você recebe sejam exatamente os mesmos dados que foram originalmente transmitidos pelo remetente.

As empresas, em particular, exigem um alto nível de garantia para a integridade dos dados quando realizam transações pela Internet. Os dados adversários podem afetar adversamente os processos de negócios e podem até ser um sinal de atividades fraudulentas.

Os mecanismos de integridade de dados permitem que a transação das partes verifique se a mensagem transmitida foi inalterada ao longo do caminho. Algoritmos de Mac (Código de Autenticação de Mensagens) como SHA1, SHA256 (e outras versões do SHA) e MD5 são normalmente empregados pela SSH e SSL para realizar verificações de integridade de dados em mensagens transmitidas.

O Hashing de entendimento do artigo inclui uma boa discussão sobre o assunto.

Diferenças entre SSL e SSH

Uma das diferenças mais notáveis ​​entre SSL/TLS e SSH é que o SSL normalmente (sim, pode haver exceções) emprega x.509 Certificados digitais para autenticação de servidor e cliente. E como o SSL usa certificados digitais, consequentemente também requer a presença de uma infraestrutura de chave pública (PKI) e a participação de uma autoridade de certificado (CA).

Embora seja possível empregar o que são conhecidos como certificados auto-autenticados, nesse caso, o SSL se torna muito semelhante ao SSH devido à ausência de uma CA, essa não é uma prática recomendada. Certificados autônomos são aceitáveis ​​apenas em transações intra-organizacionais, exceto em grande (e.g. Distribuição globalmente) organizações.

Outra grande diferença é que o SSH tem mais funcionalidade incorporada a ele. Por exemplo, por si só, o SSH pode permitir que os usuários façam login em um servidor e executem comandos remotamente. SSL não tem esse recurso. Você precisaria emparelhá -lo com outro protocolo (e.g. Http, ftp ou webdav) para que ele tenha funções semelhantes.

O SSH também suporta prontamente multiplexação de conexão, controle de fluxo, gerenciamento de terminais e outros recursos. Obviamente, esses recursos adicionais não se enquadram mais em nossa discussão original, na qual começamos a comparar SSL e SSH em relação ao SFTP e FTPS.

Então, antes de nos afastarmos mais, vamos terminar aqui.

Iniciar

Você gostaria de experimentar o servidor de transferência de arquivos que suporta FTPs e SFTP, bem como outros protocolos? Experimente a edição de avaliação gratuita e totalmente funcional do JScape MFT Server hoje.

Artigos populares

Configurando a autenticação de chave pública do SFTP na linha de comando

6 min Read – 11 de dezembro de 2022

O SFTP permite que você autentique clientes usando chaves públicas, o que significa que eles venceram’não preciso de uma senha. Aprenda a configurar isso na linha de comando online. Leia o artigo

Ativo vs. FTP passivo simplificado: Compreendendo as portas FTP

7 min Read – 11 de dezembro de 2022

Se houver problemas para se conectar ao seu servidor FTP, verifique seu modo de transferência. Deixe o JScape ajudá -lo a entender a diferença no FTP ativo e passivo. Leia o artigo

Ativo-ativo vs. Cluster de alta disponibilidade ativo-passivo

3 min Read – 11 de dezembro de 2022

As configurações de agrupamento de alta disponibilidade mais usadas são ativas e ativas e ativas. Aprenda a diferença entre os dois online! Leia o artigo

Usando scripts do Windows FTP para automatizar transferências de arquivos

4 min Read – 11 de dezembro de 2022

Aprenda a automatizar as transferências de arquivos usando scripts do Windows FTP. Esta postagem explica o que são scripts FTP e como criar scripts simples para transferir arquivos. Leia o artigo

SSH usa TLS ou SSL

О эээ сйранibus

Ы з ззарегиgléria. С помощью этой страницы мы сможем определить, что запросы отправляете именно вы, а не робот. Почpels эээ моогitu произойth?

Эта страница отображается в тех случаях, когда автоматическими системами Google регистрируются исходящие из вашей сети запросы, которые нарушают Условия использования. Ponto. Ээth момо номттаая и оозз илэз и ээ и эз и эз и з и ззз и зз и ээз и ээз иth ээ эth ээзз эth эзз иthлз ио и зз и иth эз иээ эээо иth эз эээ ээо ээоо иth иэзз эth эзт эth эз ио эээ иth эз иэз иthлзз иоз ил иээ иээо иэээ иээо иth ио иээ эth иэ иээ эth иэ иээ эth ио иэ ээог seguir.

Ит и и и и и и и и и чззжfia м ирржжжfia м иржжжжfia м мжжжжжж<ь м м иржжжfia. não. Если вы используете общий доступ в Интернет, проблема может быть с компьютером с таким же IP-адресом, как у вас. Орратитеitivamente к с о и и с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с с а с с а с а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а а &rdquo;. ПодробнÉ.

Проверка по слову может также появляться, если вы вводите сложные запросы, обычно распространяемые автоматизированными системами, или же вводите запросы очень часто.

SSH vs SSL: Diferenças e semelhanças entre eles [dicas de minitool]

Quais são as diferenças entre SSH e SSL? Qual é o melhor? Se você está tentando encontrar essas perguntas&rsquo; Respostas, este post é o que você precisa. Este post do Minitool fornece as definições deles, bem como as informações sobre SSH vs SSL.

O que é SSH

O que significa SSH? O SSH também é conhecido como Shell Secure, que é um método de comunicação segura com computadores remotos. O SSH é usado para interagir com a concha operacional de outro sistema para executar comandos remotamente.

O SSH só pode ser usado em computadores baseados em UNIX originalmente, mas agora você pode usá-lo no Windows. SSH é um protocolo de criptografia que cria um túnel entre dois computadores remotos. Talvez, esta postagem – como configurar o cliente e o servidor SSH no Windows 10 [guia completo] é o que você precisa.

O que é SSL/TLS

O que é SSL ou o que é TLS? SSL e TLS são mecanismos para proteger a segurança dos sites. Embora o SSL e o TLS façam a mesma coisa, o TLS substitui gradualmente o SSL na implementação de rede. Eles usam assinaturas digitais geradas pelas autoridades de certificação para permitir a confiança entre você e os provedores.

Ssh vs ssl

SSH e SSL/TLS geralmente têm usos diferentes. SSH é usado para executar tarefas com as quais os usuários comuns da Internet nunca precisam lidar. Por outro lado, os usuários comuns da Internet estão usando o SSL/TLS. A seguir, são apresentadas as informações sobre SSL vs SSH.

Semelhanças

Agora deixe&rsquo;s Veja as semelhanças entre SSH e SSL. Primeiro, SSH e SSL são abreviações de três dígitos que começam com a mesma letra. Em seguida, esses são os dois protocolos usados ​​em conexões seguras. Finalmente, os dois usam criptografia para proteger os dados passados ​​entre dois dispositivos de rede.

Diferenças

Agora, você conheceu as semelhanças entre SSH e SSL. Então deixa&rsquo;s Veja as diferenças entre SSH e SSL.

1. O SSH é executado na porta 22, enquanto o SSL é executado na porta 443.

2. O SSH é baseado em túneis de rede e o SSL é baseado em certificados.

3. Tecnicamente, o SSH é usado para proteger a rede de computadores, enquanto o SSL é usado para proteger a transmissão de dados on -line.

4. SSH usa um processo de autenticação de nome de usuário/senha para estabelecer uma conexão segura, enquanto o SSL não o considera.

5. O SSL é usado para transferir informações importantes com segurança, como cartões de crédito e bancos. E SSH é usado para executar comandos com segurança na Internet.

6. SSL geralmente (exceto exceções) usa x.509 Certificados digitais para autenticação de servidor e cliente.

7. SSL é usado para criptografar a comunicação entre o navegador e o servidor. Por outro lado, o SSH é usado para criptografar a comunicação entre dois computadores na Internet.

8. No SSL, a comunicação é autenticada pelo par de chaves públicas/privadas. Em SSH, a comunicação é autenticada por pares de chave privada/pública ou pares de nome de usuário/senha.

9. Outra grande diferença é que o SSH tem mais recursos internos do que o SSL. Ajuda a fazer login no servidor e executa comandos remotamente, e o SSL não possui esse recurso. Para conseguir essa função, você precisa emparelhá -la com outros protocolos – http, ftp.

5 maneiras de resolver o erro HTTP 401 não autorizado

Ao abrir o navegador para procurar algo, você pode encontrar o erro HTTP 401 não autorizado. Esta postagem mostra como resolver este erro 401.

Palavras finais

Aqui estão todas as informações sobre ssh vs ssl. Depois de ler este post, você deve saber o que são SSH e SSL. E a partir deste post, você sabe que as semelhanças e diferenças entre SSH e SSL.

• Facebook
• Twitter
• LinkedIn
• Reddit

Sobre o autor

Daisy se formou em inglês e depois se juntou ao Minitool como editor. Ela é especializada em escrever artigos sobre backup de dados e sistemas, discos de clonagem e sincronização de arquivos, etc. Ela também é boa em escrever artigos sobre conhecimento e problemas de computador. Na vida cotidiana, ela gosta de correr e ir ao parque de diversões com os amigos para tocar alguns itens interessantes.