Mais um caderno de notas que reúne experiências no mundo de TI. Focado em infraestrutura de redes; sempre adaptando para evoluir, pois "Resistir é inútil, você será assimilado" (frase BORG - Star Trek)
I already did a post aboutIPv6 on Mikrotikbut with RouterOS 7 going out, some things have slightly changed. So, it’s time for an updated guide. And, as one might expect, things are pretty much the same.
As before, prerequisite is that you get at least /64 prefix from your ISP (Comcast in my case) via DHCPv6. Also assumed is empty IPv6 configuration.
The first thing I like doing is disabling the default neighbor discovery interface. Blasting IPv6 router advertisements on all interfaces is not necessarily a good idea:
Terminal
/ipv6 nd set [ find default=yes ] disabled=yes
The next step is to setup DHCP client. Within a few seconds, you should see the prefix being allocated:
Now it should be possible to ping its address from external computer (in this example address would be 2601:db8:9780:ee2c::1). If this doesn’t work, do check if you have link-local addresses. If none are present, reboot the router and they will be regenerated.
With router reachable, it is time to delegate IPv6 prefix to internal machines too. For this purpose, setup RA (router announcement) over the bridge. While default interval settings are just fine, I like to make them a bit shorter (20-60 seconds):
And that’s all. Now your computers behind the router will have direct IPv6 route to the Internet. Do not forget to setup both router firewall and firewall of individual devices. There is no NAT to save your butt here.
PS: Here is the basic IPv6 firewall allowing all connections out while allowing only established back in:
TLS vs SSL: Qual é a diferença? Qual você deve usar?
Tanto o TLS como o SSL são protocolos que o ajudam a autenticar e transportar dados na Internet de forma segura. Mas qual é a diferença entre TLS vs SSL?E é algo com que precisa de se preocupar?
Neste artigo, você aprenderá as principais diferenças entre TLS vs SSL, assim como como ambos os protocolos se conectam ao HTTPS. Você também vai aprender porque, como usuário final, você provavelmente não precisa se preocupar muito com TLS vs SSL ou se você está usando um “certificado SSL” ou um “certificado TLS”.
Você pode clicar abaixo para saltar para uma seção específica ou ler o artigo inteiro:
TLS, abreviação de Transport Layer Security, e SSL, abreviação de Secure Socket Layers, são ambos protocolos criptográficos que criptografam dados e autenticam uma conexão ao mover dados na Internet.
Por exemplo, se você estiver processando pagamentos com cartão de crédito em seu website, TLS e SSL podem ajudá-lo a processar esses dados com segurança para que atores maliciosos não possam colocá-los em suas mãos.
Então qual é a diferença entre TLS vs SSL?
Bem, TLS na verdade é apenas uma versão mais recente do SSL. Ele corrige algumas vulnerabilidades de segurança nos protocolos SSL anteriores.
Antes de aprender mais sobre as especificidades, é importante entender a história básica do SSL e do TLS.
O SSL 2.0 foi lançado pela primeira vez em Fevereiro de 1995 (o SSL 1.0 nunca foi lançado publicamente por causa de falhas de segurança). Embora o SSL 2.0 tenha sido lançado publicamente, também continha falhas de segurança e foi rapidamente substituído pelo SSL 3.0 em 1996.
Então, em 1999, a primeira versão do TLS (1.0) foi lançada como uma atualização para SSL 3.0. Desde então, houve mais três lançamentos de TLS, sendo o mais recente o TLS 1.3 em agosto de 2018.
Neste ponto, ambos os lançamentos públicos SSL foram depreciados e conheceram vulnerabilidades de segurança (mais sobre isso mais tarde).
Aqui está o histórico completo de lançamentos de SSL e TLS:
SSL 1.0 – nunca divulgado publicamente devido a questões de segurança.
SSL 2.0 – lançado em 1995. Depreciado em 2011. Conheceu problemas de segurança.
SSL 3.0 – lançado em 1996. Depreciado em 2015. Conheceu problemas de segurança.
TLS 1.0 – lançado em 1999 como uma atualização para SSL 3.0. Depreciação planejada para 2020.
TLS 1.1 – lançado em 2006. Depreciação planejada para 2020.
Quando você instala um certificado SSL/TLS no seu servidor web (muitas vezes chamado apenas de “certificado SSL”), ele inclui uma chave pública e uma chave privada que autenticam o seu servidor e deixam o seu servidor criptografar e decodificar dados.
Quando um visitante vai ao seu site, o seu navegador irá procurar o certificado SSL/TLS do seu site. Em seguida, o navegador irá executar um “aperto de mão” para verificar a validade do seu certificado e autenticar o seu servidor.
Quando o navegador de um visitante determina que seu certificado é válido e autentica seu servidor, ele essencialmente cria um link criptografado entre ele e seu servidor para transportar dados com segurança.
É também aqui que entra HTTPS (HTTPS significa “HTTP over SSL/TLS”).
HTTP, e o HTTP/2 mais recente, são protocolos de aplicação que desempenham um papel essencial na transferência de informações pela Internet.
Com o HTTP simples, essa informação é vulnerável a ataques. Mas quando você usa HTTP sobre SSL ou TLS (HTTPS), você criptografa e autentica esses dados durante o transporte, o que os torna seguros.
É por isso que você pode processar com segurança os detalhes do cartão de crédito sobre HTTPS, mas não sobre HTTP, e também por que o Google Chrome está pressionando tanto para a adoção de HTTPS.
Por que é chamado de certificado SSL se o SSL é depreciado?
Acima, você aprendeu que o TLS é a versão mais recente do SSL e que ambas as versões públicas do SSL foram depreciadas por vários anos e contêm vulnerabilidades de segurança conhecidas.
Isso pode deixá-lo a pensar: porque se chama um certificado SSL e não um certificado TLS? Afinal de contas, TLS é o protocolo moderno de segurança.
Por exemplo, se você olhar na página de características Kinsta, você verá que Kinsta anuncia um certificado SSL gratuito, não um certificado TLS gratuito.
Não se preocupe: Kinsta não está usando tecnologia ultrapassada!
Não, a razão pela qual a maioria das pessoas ainda se refere a eles como certificados SSL é basicamente uma questão de marca. A maioria dos principais provedores de certificados ainda se referem aos certificados como certificados SSL, razão pela qual a convenção de nomes persiste.
Ou seja, você pode usar ambos os protocolos SSL e TLS com o seu certificado.
Não existe tal coisa como apenas um certificado SSL ou apenas um certificado TLS, e você não precisa se preocupar em substituir seu certificado SSL por um certificado TLS.
Você deve usar TLS ou SSL? A TLS está substituindo o SSL?
Sim, o TLS está a substituir o SSL. E sim, você deve usar o TLS em vez do SSL.
Como você aprendeu acima, ambos os lançamentos públicos de SSL são depreciados em grande parte por causa das conhecidas vulnerabilidades de segurança neles. Como tal, o SSL não é um protocolo totalmente seguro em 2019 e nos anos seguintes.
O TLS não só é mais seguro e mais eficiente como a maioria dos browsers modernos já não suporta SSL 2.0 e SSL 3.0. Por exemplo, o Google Chrome deixou de suportar SSL 3.0 em 2014, e a maioria dos principais navegadores planeja deixar de suportar o TLS 1.0 e o TLS 1.1 em 2020.
Quer saber como aumentamos nosso tráfego em mais de 1000%?
Junte-se a mais de 20.000 outros que recebem nossa newsletter semanal com dicas privilegiadas do WordPress!
Na verdade, o Google começou a mostrar notificações de aviso ERR_SSL_OBSOLETE_VERSION no Chrome.
Então, como você garante que está usando as versões mais recentes do TLS e não os protocolos SSL mais antigos e inseguros?
Primeiro, lembre-se que o seu certificado não é o mesmo que o protocolo que o seu servidor utiliza. Você não precisa alterar o seu certificado para usar o TLS. Mesmo que possa ser marcado como um “certificado SSL”, o seu certificado já suporta os protocolos SSL e TLS.
Em vez disso, você controla qual protocolo seu site usa no nível do servidor.
Se você está hospedado na Kinsta, Kinsta já habilita o TLS 1.3 para você, que é a versão mais moderna, segura e performante, assim como o TLS 1.1 e o TLS 1.2.
Se você estiver hospedando em outro lugar, você pode usar a ferramenta SSL Labs para verificar quais protocolos estão habilitados para o seu site.
Por exemplo, se você testar um site hospedado na Kinsta, você pode ver como Kinsta habilita o TLS 1.1, TLS 1.2 e TLS 1.3, mas desabilita as versões mais antigas e inseguras do SSL:
Como testar quais protocolos SSL/TLS o seu servidor usa
Se você descobrir que o seu servidor ainda suporta os protocolos SSL depreciados, você pode procurar ajuda no seu host ou seguir estas instruções para desabilitar o SSL nos dois servidores web mais populares (Apache and Nginx):
Por que a Kinsta habilita múltiplos protocolos de TLS?
Se o TLS 1.3 é o protocolo mais moderno e performante, porque é que a Kinsta também se preocupa em permitir os protocolos ligeiramente mais antigos TLS 1.1 e TLS 1.2?
Em outras palavras: qual é a vantagem de ter múltiplos protocolos habilitados?
Cansado do suporte a hospedagem de WordPress nível 1 sem respostas? Experimente nossa equipe de suporte de classe mundial! Confira os nossos planos
Como você aprendeu acima, há duas partes do aperto de mão SSL/TLS:
Seu webserver
O cliente (geralmente um navegador de internet do visitante)
Para que o aperto de mão funcione, ambos precisam de suportar o mesmo protocolo.
Portanto, o principal benefício de ter múltiplos protocolos é a compatibilidade.
Por exemplo, enquanto o Chrome e o Firefox adicionaram suporte ao TLS 1.3 quase imediatamente após o seu lançamento em 2018, a Apple e a Microsoft demoraram um pouco mais para adicionar o suporte ao TLS 1.3.
Mas enquanto o TLS 1.3 ainda não tem adoção total, todos os principais navegadores suportam o TLS 1.2 em 2019:
TLS 1.2 suporte a navegador web
Ao ter o TLS 1.3 e o TLS 1.2 habilitados no seu servidor, você pode garantir a compatibilidade não importa o que aconteça, enquanto ainda obtém os benefícios do TLS 1.3 para navegadores que o suportam, como o Chrome e o Firefox.
Em resumo, TLS e SSL são ambos protocolos para autenticar e criptografar a transferência de dados na Internet.
Os dois estão estreitamente ligados e TLS é realmente apenas a versão mais moderna e segura do SSL.
Embora o SSL ainda seja o termo dominante na Internet, a maioria das pessoas realmente querem dizer TLS quando dizem SSL, porque ambas as versões públicas do SSL não são seguras e foram depreciadas há muito tempo.
Não precisa de se preocupar em “mudar” o seu certificado SSL para um certificado TLS. Se você já instalou um “certificado SSL”, você pode estar confiante de que ele também suporta TLS.
É importante utilizar as últimas versões do TLS porque o SSL já não é seguro, mas o seu certificado não determina o protocolo que o seu servidor utiliza. Em vez disso, uma vez que você tenha um certificado, você pode escolher quais protocolos usar em um nível de servidor.
Se você está hospedado na Kinsta, Kinsta atualmente permite o TLS 1.1, TLS 1.2 e TLS 1.3, todos eles seguros e suportados por todos os principais navegadores.
Desde da criação da Internet, os protocolos SSL e seu sucessor, TLS, forneceram criptografia e segurança que tornam possível o comércio de internet [e transações eletrônicas de todos os tipos.]
A história de décadas desses protocolos foi marcada por atualizações contínuas que visam acompanhar os atacantes cada vez mais sofisticados. A próxima versão principal do protocolo, TLS 1.3, em breve será finalizada – e a maioria de quem roteia um site irá querer atualizar, porque os cibercriminosos estão se preparando.
O que é SSL?
Secure Sockets Layer, ou SSL, foi o nome original do protocolo quando foi desenvolvido em meados da década de 1990 pela Netscape, a empresa que fez o navegador mais popular na época. O SSL 1.0 nunca foi lançado ao público, e o SSL 2.0 teve falhas graves. O SSL 3.0, lançado em 1996, foi completamente reformulado, e preparou o cenário para o que se seguiu.
A versão do protocolo TLS foi lançada em 1999, foi padronizada pela Internet Engineering Task Force (IETF) e recebeu um novo nome: Transport Layer Security, ou TLS. Como observa a especificação TLS , “as diferenças desse protocolo e SSL 3.0 não são dramáticas”. Assim, não é realmente uma questão de TLS vs. SSL; Em vez disso, os dois formam uma série de protocolos continuamente atualizados, e geralmente são agrupados como SSL / TLS.
O protocolo TLS criptografa o tráfego de internet de todos os tipos. O mais comum é o tráfego da web; Você sabe que seu navegador está conectado via TLS se a URL no seu endereço começar com “https”, e há um indicador com um cadeado informando que a conexão é segura, como nesta captura de tela do Chrome.
Mas TLS também pode ser usado por outros aplicativos, incluindo e-mail, por exemplo.
Como funciona o TLS
A criptografia é necessária para se comunicar de forma segura pela internet: se seus dados não são criptografados, qualquer um pode examinar seus pacotes e ler informações confidenciais. O método mais seguro de criptografia é chamado de criptografia assimétrica; isso requer duas chaves criptográficas – informações, geralmente muito grandes – para funcionar corretamente, um público e um privado.
A matemática aqui é complexa, mas, em essência, você pode usar a chave pública para criptografar os dados, mas precisa da chave privada para decriptografar. As duas chaves estão relacionadas umas com as outras por alguma fórmula matemática complexa que é difícil de engenharia reversa por força bruta.
Pense na chave pública como informação sobre a localização de uma caixa de correio bloqueada com um slot na frente e a chave privada como a chave que desbloqueia a caixa de correio. Qualquer pessoa que saiba onde a caixa de correio se encontra pode colocar uma mensagem nela, mas para outras pessoas acessem a mensagem dentro da caixa precisam da chave privada.
Como a criptografia assimétrica envolve esses problemas matemáticos difíceis, é preciso uma grande quantidade de recursos de computação, tanto que, se você o usasse para criptografar toda a informação em uma sessão de comunicação, o computador e a conexão parariam.
O TLS contorna esse problema apenas usando criptografia assimétrica no início de uma sessão de comunicação para criptografar a conversa que o servidor e o cliente devem concordar em uma única chave de sessão que ambos usarão para criptografar seus pacotes a partir desse ponto.
A criptografia usando uma chave compartilhada é chamada de criptografia simétrica.
Como essa chave de sessão foi estabelecida usando criptografia assimétrica, a sessão de comunicação como um todo é muito mais segura do que seria de outra forma.
O processo pelo qual essa chave de sessões é acordada é chamado de handshake – aperto de mão, já que é o momento em que os dois computadores comunicantes se apresentam um ao outro, e está no coração do protocolo TLS.
Artigo em SSL.com tem apresenta esse diagrama descrevendo cada passo de comunicação ao longo do processo de handshake TLS.
Processo de handshake TLS
O processo de handshake TLS é bastante complexo, e há várias variações permitidas pelo protocolo. As etapas a seguir fornecem um amplo esquema que deve dar uma ideia de como ele funciona.
1 – O cliente entra em contato com o servidor e solicita uma conexão segura. O servidor responde com a lista de conjuntosde cifras – kits de ferramentas algorítmicas de criação de conexões criptografadas – que ele sabe como usar. O cliente compara isso com sua própria lista de conjuntos de cifras suportados, seleciona um, e permite que o servidor saiba que ambos estarão usando.
2 – O servidor então fornece seu certificado digital,um documento eletrônico emitido por uma autoridade certificadora de terceiros que confirma a identidade do servidor. A informação mais importante no certificado é a chave criptográfica pública do servidor. O cliente confirma a autenticidade do certificado.
3 – Usando a chave pública do servidor, o cliente e o servidor estabelecem uma chave de sessão que ambos usarão para o resto da sessão para criptografar a comunicação.
Existem várias técnicas para fazer isso.
O cliente pode usar a chave pública para criptografar um número aleatório que é enviado ao servidor para decriptografar, e ambas as partes usam esse número para estabelecer a chave da sessão. Alternativamente, as duas partes podem usar o que é chamado de troca de chaves Diffie-Hellman para estabelecer a chave da sessão.
Como o próprio nome indica, a chave da sessão só é boa para o curso de uma sessão de comunicação única e ininterrupta. Se, por algum motivo, as comunicações entre o cliente e o servidor são interrompidas – devido a um problema de rede, por exemplo, ou porque o cliente está ocioso por muito tempo – será necessário um novo aperto de mão para estabelecer uma nova chave de sessão quando a comunicação for restabelecida.
Vulnerabilidades TLS 1.2 e TLS 1.2
TLS 1.2 é a versão mais atual do protocolo, e tem sido por vários anos. Ele estabeleceu uma série de novas opções criptográficas para comunicação. No entanto, como algumas versões anteriores do protocolo, também permitiu a utilização de técnicas criptográficas antigas, de modo a suportar computadores mais antigos. Infelizmente, isso abriu caminho para vulnerabilidades, já que essas técnicas antigas se tornaram mais vulneráveis à medida que o tempo passou e o poder de computação se tornou mais barato.
Em particular, o TLS 1.2 tornou-se cada vez mais vulnerável aos chamados ataques do “man-in-the-middle” , nos quais um hacker intercepta pacotes na comunicação média e os envia depois de lê-los ou alterá-los. Ele também está aberto aos ataques POODLE, SLOTH, e DROWN. Muitos desses problemas surgiram nos últimos dois anos, aumentando a sensação de urgência para atualizar o protocolo.
TLS 1.3
Felizmente, a ajuda está a caminho. A versão 1.3 do protocolo TLS, atualmente em forma de rascunho, mas em breve finalizada, conecta muitos desses buracos descartando o suporte para sistemas de criptografia legados . Existe uma compatibilidade com versões anteriores, no sentido de que as conexões retornarão ao TLS 1.2 se uma extremidade não for capaz de usar os sistemas de criptografia mais recentes na lista 1.3 aprovada.
No entanto, se, por exemplo, um ataque “man-in-the-middle” tentar forçar um retorno para 1,2 para bisbilhotar os pacotes, será detectado e a conexão cai.
Ainda existem servidores que utilizam versões do TLS ainda mais antigos do que 1.2 – alguns ainda estão usando o protocolo SSL original. Se seu servidor é um desses, você deve fazer as atualizações agora.
TLware crimeware
Uma última nota sobre TLS e segurança: os bons não são os únicos que usam! Muitos cibercriminosos usam TLS para criptografar o tráfego de comando e controle entre seus servidores e Malware instalados nos computadores da vítima.
Existem várias técnicas para lidar com esse tipo de ataque criptografado, incluindo o uso de metadados de rede sobre o tráfego criptografado e para ter uma ideia do que os atacantes estão fazendo sem realmente ler nada disso.
