Resumo:
A criptografia SSL/TLS é usada para proteger os dados trocados entre dois nós pela Internet ou uma rede de computadores. Ele garante a confidencialidade e a integridade dos dados usando a criptografia assimétrica e simétrica. O processo de aperto de mão SSL/TLS estabelece uma sessão segura entre o cliente e o servidor, permitindo que eles trocem dados com segurança. No entanto, o SSL/TLS não oculta os endereços IP de origem e destino, mas criptografa o conteúdo da comunicação.
1. Como funciona a criptografia SSL/TLS?
A criptografia SSL/TLS usa uma combinação de criptografia assimétrica e simétrica. Começa com o cliente que entra em contato com o servidor usando um URL seguro (https). O servidor envia seu certificado e chave pública para o cliente, que é então verificado por uma autoridade de certificação raiz confiável. O cliente e o servidor negociam a criptografia mais forte que eles podem apoiar e trocar uma chave de sessão. Esta chave de sessão é usada para criptografar e descriptografar os dados transmitidos entre o cliente e o servidor.
2. Como é HTTPS/SSL capaz de ocultar o site de destino?
HTTPS/SSL não oculta o site de destino de possíveis atacantes. Quando um cliente estabelece uma conexão SSL padrão, um invasor que pode farejar o tráfego poderá ver a conexão da máquina cliente ao servidor de destino e determinar o endereço IP do servidor. No entanto, o SSL/TLS se concentra em proteger os dados que estão sendo transmitidos, em vez de ocultar o destino.
3. Qual é a diferença entre segurança e privacidade no SSL/TLS?
O SSL/TLS fornece segurança para os dados trocados entre o cliente e o servidor, criptografando o conteúdo, protegendo -os contra farejando e manipulação. No entanto, não fornece privacidade completa. Metadados como endereços IP de origem e destino, nome de host, tamanho da carga útil e tempo não são criptografados e podem ser usados para criar um perfil de navegação do usuário. Para melhor privacidade, o SSL/TLS pode ser combinado com ferramentas como o Tor, mas mesmo isso não pode garantir a privacidade total.
4. O SSL/TLS oculta o nome do site conectado?
Por padrão, SSL/TLS oculta o nome do site conectado. A fase de handshake SSL inclui uma extensão chamada “Indicação de nome do servidor” (SNI), que revela o nome do site conectado no texto simples. No entanto, esse recurso não foi introduzido até vários anos após a pergunta, então, na época, a resposta estava correta.
5. O SSL/TLS pode ser descriptografado por um atacante de homem no meio?
A própria criptografia SSL/TLS não pode ser descriptografada por um atacante de homem no meio (MITM). No entanto, um ataque do MITM envolve o invasor tocando o destino para o cliente e reproduzindo o cliente para o servidor, usando teclas diferentes e diferentes sessões SSL/TLS. Este ataque é independente da descriptografia SSL e envolve representação em vez de descriptografia.
6. O SSL/TLS oculta os endereços IP de origem e destino?
SSL/TLS não oculta os endereços IP de origem e destino. Os endereços IP devem ser válidos para uma conexão TCP em funcionamento. Enquanto SSL/TLS criptografa o conteúdo da comunicação, os endereços IP permanecem visíveis.
7. Existem tecnologias que aprimoram a privacidade fornecida pelo SSL/TLS?
Existem tecnologias como SNI criptografado (indicação de nome do servidor) e olá criptografado que aprimoram a privacidade fornecida pelo SSL/TLS. No entanto, essas tecnologias não são amplamente adotadas e não são comuns na maioria dos navegadores ou servidores.
8. O SSL/TLS pode garantir a privacidade completa?
Não, o SSL/TLS não pode garantir a privacidade completa. Enquanto criptografa o conteúdo da comunicação, outros metadados, como endereços IP, tamanho da carga útil e tempo, ainda podem ser visíveis, permitindo a criação de perfis de navegação e possíveis violações de privacidade.
9. O que acontece com as chaves de criptografia depois de deixar um site?
As chaves de criptografia usadas durante uma sessão são descartadas quando o usuário sair do site. Quando o usuário revisita o site, um novo aperto de mão e a geração de um novo conjunto de chaves ocorrem para estabelecer uma sessão segura novamente.
10. Como os proprietários do site podem implementar a criptografia SSL/TLS?
Os proprietários do site devem ter um certificado SSL/TLS para seu nome de servidor/domínio da web para usar a criptografia SSL/TLS. Depois de instalado, o certificado permite que o cliente e o servidor negociem o nível de criptografia durante o processo de aperto de mão.
Como é HTTPS/SSL capaz de ocultar o site de destino que se está conectando
Se você quiser esconder sua conexão com ele, use o Tor, como mencionado por Madhatter. Todos até (e incluindo) o nó de entrada do Tor pode saber que você está usando o Tor, mas não o que você está se conectando. Todos depois (e incluindo) o nó de saída do Tor saberão que um usuário do TOR conectado ao seu servidor, mas não quem.
O que é criptografia SSL/TLS?
Criptografia SSL (Secure Sockets Layer) e sua substituição mais moderna e segura, criptografia de TLS (Segurança da Camada de Transporte), proteja os dados enviados pela Internet ou em uma rede de computadores. Isso impede que os invasores (e provedores de serviços de Internet) visualizem ou adulterem os dados trocados entre dois nós – normalmente um usuário’S Navegador da Web e um servidor da Web/App. A maioria dos proprietários e operadores de sites tem a obrigação de implementar o SSL/TLS para proteger a troca de dados sensíveis, como senhas, informações de pagamento e outras informações pessoais consideradas privadas.
Como funciona a criptografia SSL/TLS?
O SSL/TLS usa criptografia assimétrica e simétrica para proteger a confidencialidade e a integridade de dados em trânsito. A criptografia assimétrica é usada para estabelecer uma sessão segura entre um cliente e um servidor, e a criptografia simétrica é usada para trocar dados na sessão garantida.
Um site deve ter um certificado SSL/TLS para seu nome de servidor/domínio da web para usar a criptografia SSL/TLS. Depois de instalado, o certificado permite que o cliente e o servidor negociem com segurança o nível de criptografia nas seguintes etapas:
- O cliente entra em contato com o servidor usando um URL seguro (https…).
- O servidor envia ao cliente seu certificado e chave pública.
- O cliente verifica isso com uma autoridade de certificação de raiz confiável para garantir que o certificado seja legítimo.
- O cliente e o servidor negociam o tipo mais forte de criptografia que cada um pode suportar.
- O cliente criptografa uma chave de sessão (segredo) com o servidor’s chave pública e a envia de volta ao servidor.
- O servidor descriptografa a comunicação do cliente com sua chave privada e a sessão é estabelecida.
- A chave da sessão (criptografia simétrica) agora é usada para criptografar e descriptografar dados transmitidos entre o cliente e o servidor.
O cliente e o servidor agora estão usando HTTPS (SSL/TLS + HTTP) para sua comunicação. Navegadores da web validam isso com um ícone de bloqueio na barra de endereço do navegador. Funções HTTPS sobre a porta 443.
Depois de sair do site, essas chaves são descartadas. Em sua próxima visita, um novo aperto de mão é negociado e um novo conjunto de chaves é gerado.
Como é HTTPS/SSL capaz de ocultar o site de destino que se está conectando?
Entendo como é capaz de criar uma conexão segura através do aperto de mão, mas como é capaz de iniciar uma conexão segura sem primeiro enviar uma solicitação não criptografada, revelando assim o site de destino (mas não os dados enviados ou recebidos de/para o destino. ) para um possível atacante “homem no meio”. ou não está escondendo?
Daniel Valland
Perguntado em 7 de fevereiro de 2015 às 20:19
Daniel Valland Daniel Valland
235 2 2 crachás de prata 6 6 crachás de bronze
Basicamente, não é. Com uma conexão SSL padrão, um invasor que pode cheirar o tráfego poderá ver uma conexão da máquina cliente para o servidor de destino e, a partir disso, poderá saber a que endereço IP do servidor está sendo conectado.
7 de fevereiro de 2015 às 20:22
3 respostas 3
Não confunda segurança com a privacidade.
A tarefa do SSL/TLS é a segurança, não a privacidade. Isso significa que os dados em si são criptografados, mas meta dados como fonte e destino IP, nome do host (com SNI usado por todos os navegadores modernos), tamanho da carga útil e tempo etc. E tudo isso pode ser usado para criar um perfil de navegação, que inclua os sites que você visita e às vezes até quais páginas você visita no site (com base no tamanho do tempo e na carga útil). Mas o SSL/TLS garante que o conteúdo não público (como cookies, dados de formulário etc.) esteja protegido contra farejo e manipulação.
Se você deseja melhor privacidade, precisa combinar SSL/TLS com algo como Tor, mas mesmo isso não pode garantir a privacidade total.
respondeu 7 de fevereiro de 2015 às 20:49
Steffen Ullrich Steffen Ullrich
193K 29 29 Crachás de ouro 386 386 Crachás de prata 439 439 Crachás de bronze
Sni e hello criptografado criptografado são uma coisa, embora eles não sejam de todo comum. Você pode verificar se está configurado para usá -lo aqui. Procure por sni = criptografado .
5 de abril às 20:23
@9072997: você está certo – mas: a primeira versão do rascunho da ESNI é de 2018 e, por volta da época, o suporte experimental foi adicionado aos navegadores. A pergunta aqui e a resposta são de 2015, eu.e. 3 anos antes disso. Então, na época, a pergunta foi feita, essa resposta aqui estava certa.
5 de abril às 20:30
SSL/TLS não esconde a fonte e os endereços IP de destino. É impossível (pelo menos, com uma solução puramente SSL/TLS), porque os endereços SRC/DST devem ser válidos para uma conexão TCP em funcionamento.
O nome do site conectado, está oculto por padrão – Ou, pelo menos, foi até os últimos anos.
Desde então, há uma extensão do TLS chamado “Indicação do nome do servidor”, que fornece o nome do site conectado não criptografado, No entanto, na fase do aperto de mão.
Site de homem no meio é uma coisa diferente. Com o MITM, um invasor pode reproduzir destino para o cliente e reproduzir o cliente para o servidor, usando teclas diferentes e sessões SSL/TTLS diferentes. Mas não tem nada a ver com a descriptografia SSL.
respondeu 7 de fevereiro de 2015 às 20:41
2.978 6 6 Distintivos de ouro 26 26 Crachás de prata 33 33 crachás de bronze
Como o outro declarou, a conexão inicial não é garantida e contém pelo menos o endereço IP (embora seja cada vez mais o nome do servidor, graças ao SNI). O servidor de destino responde com um certificado de chave pública e eles negociam a sessão SSL/TLS.
A chave para evitar o homem nos ataques intermediários é o certificado e o fato de ter sido aprovado por uma autoridade de certificação que seu navegador confia.
Digamos que você tenha um hacker interceptando comunicações entre um cliente e um servidor. O cliente pediu uma conexão segura com o site https: // www.exemplo.com (por exemplo). O hacker pode enviar na solicitação para o site real e retransmitir respostas de volta. O hacker também poderá ler a primeira resposta de volta do servidor para o cliente, já que é um texto simples. No entanto, ele não pode ler a próxima mensagem do cliente para o servidor, pois é criptografada com a chave pública do site e, portanto, só pode ser descriptografada com a chave privada (que o hacker não possui). Como essas mensagens subsequentes são usadas para negociar a chave a ser usada para a conexão SSL/TLS real, o hacker é basicamente bloqueado após a primeira mensagem.
Como alternativa, em vez de agir como um revezamento reto, o hacker pode dar um certificado falso (ao qual conhece a chave privada) para a conexão do cliente-hacker e, em seguida, pode configurar sua própria conexão hacker-servidor e passar mensagens entre os dois. No entanto, nesse cenário, a menos que eles tenham conseguido comprometer um dos principais emissores do certificado que o navegador do cliente aceita automaticamente, haveria um grande cadeado vermelho dizendo que o certificado que o hacker enviou de volta ao cliente é 1) não é real ou 2) não para este site.
O SSL criptografa o IP [fechado]
É difícil dizer o que está sendo perguntado aqui. Esta pergunta é ambígua, vaga, incompleta, excessivamente ampla ou retórica e não pode ser razoavelmente respondida em sua forma atual. Para obter ajuda para esclarecer esta pergunta para que ela possa ser reaberta, visite o centro de ajuda.
Fechado há 10 anos .
Estou construindo um servidor pessoal. Eu quero poder acessar este servidor de qualquer lugar e não quero que este servidor seja bloqueado. Entendo que o HTTPS criptografa meu tráfego, mas também ouvi dizer que não o criptografaram completamente. Ouvi dizer que, se você for a um site com um domínio, uma pesquisa DNS é realizada sem criptografia e, portanto, um ISP poderia descobrir em qual domínio meu servidor pessoal está (e o que é IP é). Mas e se eu acessasse meu servidor de seu endereço IP? Pergunta: Se eu acessar um servidor, indo ao seu endereço IP e uso https (então o URL seria algo como https: // ###.###.###.###/), é possível qualquer um (incluindo ISPs e pessoas “por trás do mesmo roteador que eu”) para descobrir o endereço IP do servidor que estou acessando? Nesse caso, devo usar SSL1/SSL2/SSL3 ou devo usar TLS1/TLS1.1/tls1.2 ou não importa? A propósito, o certificado do servidor será auto-inscrito e este servidor será acessado apenas na porta 443 (https).
Perguntado em 13 de agosto de 2012 às 16:05
JamesCostian JamesCostian
45 1 1 crachá de prata 3 3 crachás de bronze
en.Wikipedia.org/wiki/osi_model Observe as posições relativas de IP, TCP e SSL. Se você pensa em termos de envelopes, o envelope interno é SSL. Fora disso está o TCP One, que especificará coisas como o número da porta, o número da sequência, etc. O mais externo é o envelope IP, que terá o endereço IP. Observe que o TCP e o IP não podem ser criptografados; caso contrário, o envelope que contém a carga útil do SSL não será entregue. Não vamos entrar em proxies e VPNs aqui.
13 de agosto de 2012 às 18:05
Uma analogia simples. Como a companhia telefônica seria capaz de conectar uma chamada de você se você codificasse o número de telefone com algum sistema de codificação aleatório que você inventou?
13 de agosto de 2012 às 19:59
3 respostas 3
Responder: sim. Seu navegador ainda se envolverá imediatamente no handshake de três vias TCP com o servidor em ###.###.###.###, e seu ISP pode ver que. Depois que a conexão está configurada, seu navegador terá um aperto de mão SSL com o servidor, e seu ISP pode ver que. Depois que as chaves da sessão forem negociadas, seu navegador continuará trocando pacotes criptografados com SSL com o servidor, e seu ISP pode vê-los. Não pode ver o que há neles, mas o endereço de origem e destino é – e tem que permanecer – não criptografado.
Se você quiser navegar isso em particular, procure privado + tor.
respondeu 13 de agosto de 2012 às 16:07
79.4K 20 20 Crachás de ouro 183 183 Crachás de prata 231 231 Crachás de bronze
Ambos expõem o endereço IP até que você atinja o servidor proxy ou o nó Tor.
11 de agosto de 2013 às 7:36
Isso é verdade, mas eles não expõem o endereço IP do servidor que você está solicitando conteúdo, que é o que o OP pediu para se proteger de si mesmo.
24 de agosto de 2013 às 5:57
Sim, isso é totalmente possível e, de fato, necessário para que qualquer tráfego chegue ao seu servidor.
respondeu 13 de agosto de 2012 às 16:07
115K 20 20 Crachás de ouro 211 211 Crachás de prata 294 294 Crachás de bronze
“Criptografar o IP” é tecnicamente absurdo. Um fluxo HTTPS TCP criptografado por SSL ainda é um fluxo TCP e a conexão não pode ser feita sem endereços IP. Todos Na posição de observar o tráfego, pode registrar facilmente o IP de origem, a porta de origem, o IP de destino, a porta de destino e os bytes enviados em cada direção. O que é registrado e por quanto tempo depende de quem está assistindo, e se eles estão comprometidos ou agindo sob uma intupana.
Supondo que você esteja se conectando a um ponto de acesso Wi-Fi que, por sua vez, está conectado a um ISP que está roteando seu tráfego pelo backbone para o seu ISP de hospedagem que está fornecendo um host virtual ou co-localizado, isso se resume a:
- Seu roteador wifi (e todos também anexados a ele) podem ver:
- Seu endereço MAC, que identifica seu hardware físico exclusivamente.
- IP, porta do seu servidor e quanto tráfego você trocou com ele.
- IP público do seu roteador. Se essa é uma conexão residencial dos EUA, eles provavelmente registram o IP público e o titular da conta e mantêm esses registros por 6 meses.
- IP, porta do seu servidor e quanto tráfego você trocou com ele.
- O IP público do seu roteador, porto e quanto tráfego você trocou com seu servidor.
Se você quiser esconder sua conexão com ele, use o Tor, como mencionado por Madhatter. Todos até (e incluindo) o nó de entrada do Tor pode saber que você está usando o Tor, mas não o que você está se conectando. Todos depois (e incluindo) o nó de saída do Tor saberão que um usuário do TOR conectado ao seu servidor, mas não quem.
Em circunstâncias normais, existe algum perigo em um registro de nó de saída comprometido ou modificando o conteúdo da sua sessão, mas isso é principalmente mitigado usando SSL.
Visão geral do protocolo TLS VPN
A segurança da camada de transporte (TLS) é um Protocolo baseado em navegador que criptografa a passagem de dados entre sites e servidores. Se você precisar navegar na web com segurança, estiver criando um site de comércio eletrônico seguro ou usar seu navegador da web para acesso remoto a uma rede de empresas, a criptografia TLS pode ajudar.
Muitos provedores de VPN incluem o TLS Tunneling em seus serviços. Esta forma de proteção VPN usa a criptografia TLS para bloquear os dados de tráfego dos usuários do navegador. Também pode proteger os portais baseados na Web entre trabalhadores domésticos e redes locais.
Este artigo do Glossário analisará o trabalho de serviços VPN da TLS e se o TLS fornece proteção suficiente no ambiente de segurança cibernética de hoje.
O que é TLS VPN?
TLS é um protocolo VPN que Substituído a camada de soquetes seguros existente (SSL) Protocolo em 1999. O SSL foi o primeiro protocolo de segurança a bloquear o tráfego da web na camada de transporte do modelo de rede OSI (camada 4). No entanto, os hackers logo encontraram maneiras de comprometer a criptografia de dados SSL. O mesmo ainda não aconteceu com o protocolo TLS.
O TLS chegou agora à versão 1.3. Como o SSL, ele opera na camada de transporte. Isso o torna útil para proteger os dados de tráfego transmitidos por navegadores da web, aplicativos de voz, clientes de email e aplicativos de mensagens.
A combinação de autenticação e criptografia de dados também torna o TLS um bom ajuste para os serviços VPN, que protegem os dados da camada 4.
Uma rede privada virtual (VPN) é um serviço que Cria uma rede virtual sobre os fluxos de dados físicos. Os pacotes de dados se movem túneis criptografados que embrulhe as cargas úteis em código inquebrável. Servidores também Anonimize identidades do usuário, Atribuindo novos endereços IP a cada pacote. Isso permite que os usuários mudem sua localização digital e evitem a vigilância ou os criminosos cibernéticos.
TLS VPNs são geralmente sem cliente. Não há necessidade de software separado para estabelecer conexões e controlar o acesso. Esse estilo de VPN também funciona com HTTP, permitindo que ele funcione perfeitamente com a maioria dos sites modernos. Funciona em segundo plano, adicionando outra barreira de segurança cibernética para usuários da Web.
Como funciona o tunelamento VPN da camada de transporte (TLS)?
TLS VPNs protegem os dados criando Túneis VPN. Esses túneis são conexões entre dois dispositivos definidos que criptografaram dados e autenticam transferências para garantir a integridade dos dados. Os tipos de VPN criam túneis de maneiras diferentes, e a técnica usada é a seguinte:
1. Conexão
Em primeiro lugar, o protocolo TLS deve estabelecer uma conexão através de uma negociação de suíte cifra. Isso informa o cliente e o servidor envolvidos que o protocolo TLS será usado na transferência de dados. Os navegadores podem fazer uma solicitação direta ou podem simplesmente abrir uma porta usada pelo TLS. Isso geralmente é porta 443.
2. TLS Handshake
O segundo estágio do processo é o TLS Handshake. Isso envolve a troca de chaves entre o cliente VPN e o servidor VPN usando a infraestrutura de chave pública assimétrica (PKI). A troca de chaves permite que os dispositivos criem um segredo mestre que é exclusivo para cada transferência. Este mestre secreto forma a base do código MAC, que autentica todo o processo. O PKI também cria chaves de sessão que são usadas na criptografia simétrica para os dados de hash à medida que passa entre os dois dispositivos.
3. Record TLS
Quando o TLS Handshake criou as chaves de criptografia, Record TLS aplica criptografia e envia dados com segurança através do túnel TLS. O registro divide a carga útil em pacotes e usa certificados digitais para autenticar cada pacote em cada extremidade da transferência. O registro do TLS aplica -se forte criptografia a cada pacote e processa a transferência por meio do Protocolo de Controle de Transporte (TCP).
Este processo se aplica Criptografia de ponta a ponta (E2ee). Os dados em forma de hash são ilegíveis para pessoas de fora enquanto estão em trânsito. O túnel da VPN garante, mesmo que informações confidenciais sejam interceptadas, os atacantes não poderão usá -las. Os únicos pontos fracos são nas duas extremidades da transferência, onde os dados são criptografados ou descriptografados.
Ao mesmo tempo, o servidor VPN Anonimiza as informações de endereço IP. Os dados enviados pela Web não serão diretamente vinculados ao dispositivo do usuário. Uma boa VPN deve até esconder os sites envolvidos. Em vez disso, observadores externos veem pacotes de dados anônimos e podem aprender muito pouco sobre o comportamento online do usuário.
Prós e contras do protocolo de criptografia TLS
Nenhum método de transferência de dados é impecável. Os usuários precisam equilibrar fatores como força de criptografia, estabilidade, velocidade e compatibilidade. Mas onde a segurança da camada de transporte está a esse respeito? Muitos benefícios da TLS tornam uma opção VPN viável, mas também existem alguns contras que os usuários precisam saber.
Prós
Aplicativos adequados para Web. Uma das maiores vantagens do TLS é que ele funciona com o navegador e os portais da web. Todos os usuários precisam de um cliente baseado em navegador, e os clientes geralmente são integrados a navegadores como Firefox ou Chrome. O TLS lida com a criptografia para a maioria dos sites e também usa o protocolo HTTPS, que raramente é bloqueado no wifi público.
Controles de acesso granular. Os administradores podem usar o protocolo TLS para definir controles de acesso refinados no gateway da web. As equipes de segurança podem criar políticas de segurança especificando quais sites filtrar e os aplicativos da Web disponíveis para cada usuário. O controle de acesso pode ser adaptado a todos os usuários, todos os objetos da Web e até da Web. Isso é mais difícil de alcançar com estilos alternativos de VPN.
Gerenciamento de servidor mais eficiente. Controles de acesso via TLS também têm benefícios de eficiência. Por exemplo, os gerentes de rede podem definir políticas uniformes de acesso para cada aplicativo no gateway da web. Com outros estilos de VPN, os gerentes podem precisar criar políticas de acesso para cada usuário no nível do sistema operacional. O TLS também pode proteger os gateways para os serviços SaaS – simplificar o uso de recursos nos servidores de aplicativos.
Acesso sem cliente. VPNs SSL/TLS são incorporadas em navegadores da Web e aplicativos baseados na Web. Os usuários não precisam comprar, instalar e configurar clientes VPN separados. Quaisquer transferências através da Web são protegidas por criptografia e os usuários podem acessar facilmente os serviços de que precisam. Com o IPSEC, os administradores precisam criar políticas para cada conexão. Esse não é o caso do TLS.
Forte segurança. TLS 1.2 é classificado como altamente seguro pelos vigilantes do setor e possui poucas vulnerabilidades de segurança conhecidas. AES de criptografia de chave privada de 256 bits contra roubo de dados, enquanto a certificação fornece autenticação a estanque. O resultado é um link criptografado que garante que os dados atinjam seu destino sem interceptação.
Contras
TLS apenas protege os recursos da Web. Uma das maiores desvantagens do TLS é que ele é restrito a contextos da Web. Ao contrário do IPSEC, o TLS não fornece proteção completa do perímetro de rede fora deste contexto. Em situações com um mix de aplicativos diversificado, lacunas de segurança podem colocar dados em risco. Os usuários podem instalar agentes de desktop para cobrir aplicativos específicos, mas isso aumenta as despesas gerais de manutenção. Nem todos os aplicativos são compatíveis com Java não assinado, o que também pode representar problemas de compatibilidade.
Os usuários podem experimentar problemas de velocidade de conexão. Quando você envolve o TLS em um navegador da web, a VPN faz solicitações de acesso toda vez que você clicar em um link e altera sites. Isso inicia o processo de aperto de mão e criptografia, adicionando latência. Novas técnicas como TLS false start e tls session têm tempos de acesso reduzidos, mas se você precisar de alto desempenho da VPN, o IPSec pode ser preferível.
A implementação pode ser complexa. Enquanto o uso do TLS como VPN é simples, a configuração de proteção contra VPN pode ser complicada. Criar certificados TLS é um processo complexo e vem com altos custos iniciais. Os proprietários de sites também devem garantir que todos os subdomínios e aplicativos da web estejam configurados para segurança TLS.
Vulnerabilidade a ataques de DDoS. A negação de ataques de serviço pode causar problemas com o protocolo TLS. Os invasores podem montar inundações de TCP que tornam inoperante as mesas de sessão e podem causar tempo de inatividade no site ou rede.
História dos protocolos SSL e TLS VPN
A história da camada de soquetes seguros se estende de volta ao nascimento da World Wide Web. A empresa de navegador Netscape introduziu o SSL em 1994 como uma maneira de garantir o tráfego da Web por meio de um link criptografado. SSL 2.0 seguido em 1995 e SSL 3.0 em 1996.
Infelizmente, o SSL se mostrou vulnerável a ataques de homem no meio. Em 2011, a Força -Tarefa de Engenharia da Internet depreciou o SSL 2.0 e SSL 3.0 foi obsoleto em 2015. Ambos agora são considerados quase completamente inseguros pelo governo dos EUA e especialistas do setor.
TLS chegou em 1999 à medida que as preocupações de segurança sobre o SSL cresciam. TLS 1.1 apareceu em 2006 e TLS 1.2 em 2008, antes de TLS 1.3 estreou em 2018. Protocolos e cifras obsoletos foram removidos em todas as etapas, enquanto os desenvolvedores simplificaram o procedimento de aperto de mão. O resultado é um protocolo de transferência amigável à Web que oferece segurança e privacidade de dados, enquanto luta pela velocidade máxima.
SSL e TLS são iguais?
Embora SSL e TLS tenham a mesma árvore genealógica, eles definitivamente não são iguais. A diferença mais importante é a eficácia. O SSL foi excluído como um protocolo de transferência recomendado, enquanto o TLS continua a melhorar e encontrar novos usos. Mas existem outras diferenças que tornam o TLS superior:
Compatibilidade. Muitos navegadores e aplicativos agora não têm suporte para SSL 3.0. O TLS é amplamente reconhecido e usado para proteger o conteúdo da Web. A certificação TLS é até usada pelo algoritmo de pesquisa do Google como uma métrica positiva ao classificar sites.
Chaves de criptografia. SSL suportou muito poucos formatos de chave de criptografia. Isso mudou com o TLS. Os usuários podem escolher entre muitos formatos -chave diferentes, proporcionando mais flexibilidade e interoperabilidade. O SSL também usou a criptografia de autenticação de mensagem (MAC). O TLS usa a criptografia de autenticação de mensagem (HMAC) mais forte baseada em hash (HMAC).
OpenVPN. OpenVPN tornou -se uma base padrão para VPNs em todo o mundo, mas não funciona com SSL. Por outro lado, os usuários podem combinar o OpenVPN com o TLS para criar configurações de privacidade baseadas na Web.
É importante observar que o termo “certificados SSL” ainda é comum. Mas esses certificados são não baseado na criptografia SSL. Quase todos usam TLs em vez disso. O nome “SSL” foi simplesmente retido devido a familiaridade.
Casos de uso mais frequentes do SSL/TLS VPN
SSL/TLS é um dos pilares do mundo da segurança cibernética. Você provavelmente o usou hoje ao navegar na web sem perceber. Existem muitos casos de uso em potencial para a segurança do TLS, incluindo:
VPN de acesso remoto
As empresas podem querer garantir que os usuários remotos tenham acesso seguro a recursos centralizados. Nesse caso, uma rede privada virtual baseada na Web pode ser útil. Os trabalhadores podem acessar conexões seguras por meio de navegadores padrão. A VPN funciona em quase qualquer dispositivo e sistema operacional, e a proteção segue os usuários em todo o mundo.
Usando wifi público
Às vezes, precisamos trabalhar remotamente em redes públicas. A cobertura da VPN é essencial, pois as redes de Wi-Fi públicas são notoriamente vulneráveis a ataques cibernéticos de homem no meio. Com uma VPN baseada em TLS, a navegação do usuário permanecerá privada, bloqueando os possíveis atacantes.
Conectando -se nos firewalls
Os TLs podem atravessar facilmente roteadores e firewalls. A porta 443 está aberta em quase todos os firewalls padrão, permitindo que o tráfego de VPN criptografado passas. Este não é o caso de VPNs com base em dados UDP como IPSEC.
TLS – Criptografia da Web forte para usuários de negócios
A segurança da camada de transporte oferece criptografia quase inquebrável e autenticação confiável para usuários da Web. Com uma VPN TLS em vigor, os usuários podem acessar sites e trocar informações confidenciais com riscos mínimos de perda de dados. As empresas podem criar gateways seguros para aplicativos da Web, incluindo ferramentas SaaS.
TLS tem algumas fraquezas. As VPNs TLS podem não cobrir todos os aplicativos em uso em uma rede corporativa. O IPSEC pode vencer o TLS em termos de velocidade e também é mais resistente a ameaças como ataques de DDoS. Mas o TLS continua sendo uma opção de segurança líder para proteger o tráfego da camada 4.
