{"id":53317,"date":"2019-11-29T00:00:00","date_gmt":"2019-11-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/domen-fronting-na-baze-tls-1-3-chast-2"},"modified":"2020-02-18T14:01:12","modified_gmt":"2020-02-18T11:01:12","slug":"domen-fronting-na-baze-tls-1-3-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","title":{"rendered":"Domain Fronting baseado em TLS 1.3. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introdu\u00e7\u00e3o<\/h3>\n

\nNa primeira parte artigo<\/a><\/noindex> demos uma breve descri\u00e7\u00e3o do mecanismo encrypted SNI (eSNI). Mostramos de que forma, com base nele, \u00e9 poss\u00edvel evitar a detec\u00e7\u00e3o por sistemas DPI modernos (com o exemplo do DPI da Beeline e o proibido RKN Rutracker) e tamb\u00e9m investigamos uma nova variante de domain fronting com base neste mecanismo.<\/p>\n

Na segunda parte do artigo, abordaremos quest\u00f5es mais pr\u00e1ticas que ser\u00e3o \u00fateis para especialistas da RedTeam em seu trabalho desafiador. Afinal, nosso objetivo n\u00e3o \u00e9 apenas obter acesso a recursos bloqueados (para essas coisas banais, temos o velho e bom VPN). Felizmente, existem muitos provedores de VPN, como se diz, para todos os gostos, cores e or\u00e7amentos.<\/p>\n

Tentaremos aplicar o mecanismo de domain fronting a ferramentas modernas da RedTeam, como Cobalt Strike, Empire, etc., e oferecer a elas mais possibilidades de mimetiza\u00e7\u00e3o e de evitar sistemas contempor\u00e2neos de filtragem de conte\u00fado.
\n<\/a><\/noindex>
\nNa \u00faltima vez, implementamos o mecanismo eSNI na biblioteca OpenSSL e o utilizamos com sucesso na conhecida ferramenta curl. Mas s\u00f3 com curl, como se diz, n\u00e3o se consegue se satisfazer. Claro que gostar\u00edamos de implementar algo semelhante em linguagens de alto n\u00edvel. Mas, infelizmente, uma pesquisa r\u00e1pida pela rede nos decepciona, pois o suporte ao mecanismo eSNI est\u00e1 completamente implementado apenas no GOLANG. Assim, nossas op\u00e7\u00f5es n\u00e3o s\u00e3o muito amplas: ou escrevemos em C ou C++ puro usando a biblioteca OpenSSL patchada, ou utilizamos um fork separado do GOLANG da CloudFlare e tentamos portar nossas ferramentas para l\u00e1. Na verdade, h\u00e1 outra op\u00e7\u00e3o, mais cl\u00e1ssica, mas tamb\u00e9m trabalhosa \u2013 implementar suporte ao eSNI para Python. Afinal, o Python tamb\u00e9m usa OpenSSL para trabalhar com https. Mas deixaremos essa op\u00e7\u00e3o para o desenvolvimento de outra pessoa, enquanto n\u00f3s ficamos satisfeitos com a implementa\u00e7\u00e3o em GOLANG, especialmente porque nosso querido Cobalt Strike lida muito bem com canais de comunica\u00e7\u00e3o estabelecidos por meios externos (External C2 channel) \u2013 isso ser\u00e1 abordado no final do artigo.<\/p>\n

Try Harder\u2026<\/h3>\n

\nUma das ferramentas implementadas em Go \u2013 nosso desenvolvimento para pivotar dentro da rede \u2013 tunnel rsockstun<\/a><\/noindex>, que, ali\u00e1s, agora \u00e9 detectada por ferramentas da Microsoft e Symantec como um software malicioso muito prejudicial, destinado a desestabilizar o mundo\u2026<\/p>\n

\"Domain
\n
\nSeria \u00f3timo usar o desenvolvimento anterior tamb\u00e9m neste caso. Mas aqui surge um pequeno problema. O fato \u00e9 que o rsockstun originalmente pressup\u00f5e o uso de um canal de comunica\u00e7\u00e3o SSL s\u00edncrono com o servidor. Isso significa que a conex\u00e3o \u00e9 estabelecida uma vez e existe durante todo o tempo de funcionamento do tunelador. E, como voc\u00ea deve entender, o protocolo https n\u00e3o \u00e9 exatamente projetado para esse modo de opera\u00e7\u00e3o \u2013 ele funciona no modo de solicita\u00e7\u00e3o-resposta, onde cada nova solicita\u00e7\u00e3o http existe no \u00e2mbito de uma nova conex\u00e3o tcp.<\/p>\n

A principal desvantagem desse esquema \u00e9 que o servidor n\u00e3o pode transmitir dados ao cliente at\u00e9 que o cliente envie uma nova solicita\u00e7\u00e3o http. Mas, felizmente, existem muitas op\u00e7\u00f5es para resolver esse problema \u2013 transmiss\u00e3o de dados via protocolo http (afinal, conseguimos assistir nossas s\u00e9ries favoritas e ouvir m\u00fasica em portais que funcionam com https, e a transmiss\u00e3o de v\u00eddeo e \u00e1udio nada mais \u00e9 do que uma transmiss\u00e3o de dados). Uma das tecnologias para emular o funcionamento de uma conex\u00e3o tcp completa sobre o protocolo http \u00e9 a tecnologia de web sockets (WebSockets), cuja ess\u00eancia \u00e9 organizar uma conex\u00e3o de rede completa entre o cliente e o servidor web.<\/p>\n

Por nossa sorte (ura-ura!!!), essa tecnologia est\u00e1 habilitada por padr\u00e3o em todos os planos da CloudFlare e funciona muito bem em conjunto com eSNI. \u00c9 exatamente isso que usaremos para ensinar nosso tunelador a utilizar domain fronting e se esconder de DPi modernos. <\/p>\n

Um pouco sobre WebSockets<\/h3>\n

\nAntes de tudo, vamos explicar brevemente e de forma simples o que s\u00e3o web sockets, para que todos tenham uma ideia do que estaremos trabalhando. <\/p>\n

A tecnologia de web sockets permite mudar temporariamente de uma conex\u00e3o http para uma transmiss\u00e3o de dados padr\u00e3o atrav\u00e9s de um socket de rede, sem quebrar a conex\u00e3o tcp estabelecida. Quando o cliente deseja mudar para um web socket, ele inclui alguns cabe\u00e7alhos http em sua solicita\u00e7\u00e3o. Dois cabe\u00e7alhos obrigat\u00f3rios s\u00e3o Connection: Upgrade<\/b><\/i> e Upgrade: websocket<\/b><\/i>. Ele tamb\u00e9m pode for\u00e7ar a vers\u00e3o do protocolo websocket (Sec-Websocket-Version: 13<\/b><\/i>) e algo parecido com um identificador base64 de websocket (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==<\/b><\/i>). O servidor responde com o c\u00f3digo http 101 Switching Protocols e tamb\u00e9m define os cabe\u00e7alhos Connection, Upgrade<\/b><\/i> e Sec-WebSocket-Accept<\/b><\/i>. O processo de troca \u00e9 ilustrado na tela abaixo:<\/p>\n

\"Domain
\n
\nAp\u00f3s isso, a conex\u00e3o WebSocket pode ser considerada estabelecida. Quaisquer dados, tanto do cliente quanto do servidor, agora ser\u00e3o fornecidos com cabe\u00e7alhos de WebSocket, n\u00e3o http (eles come\u00e7am com o byte 0x82). Agora o servidor n\u00e3o precisa esperar um pedido do cliente para enviar dados, pois a conex\u00e3o tcp n\u00e3o \u00e9 interrompida.<\/p>\n

Em Go, existem v\u00e1rias bibliotecas para trabalhar com websockets. As mais populares s\u00e3o Gorilla WebSocket<\/a><\/noindex> e a padr\u00e3o WebSocket<\/a><\/noindex>. N\u00f3s utilizaremos a \u00faltima, pois \u00e9 mais simples, menor e, dizem, um pouco mais r\u00e1pida.<\/p>\n

No c\u00f3digo do cliente rsockstun, precisamos substituir as chamadas net.dial ou tls.dial pelas respectivas chamadas de WebSocket:<\/p>\n

\"Domain
\n
\n\"Domain
\n
\nQueremos tornar a parte cliente do nosso t\u00fanel universal e capaz de funcionar tanto atrav\u00e9s de uma conex\u00e3o ssl direta quanto atrav\u00e9s do protocolo WebSockset. Para isso, criaremos uma fun\u00e7\u00e3o separada func connectForWsSocks(address string, proxy string) error {\u2026}<\/b><\/i> por analogia com connectForSocks()<\/b><\/i> e a utilizaremos para trabalhar com websockets no caso de o endere\u00e7o do servidor, definido ao iniciar o cliente, come\u00e7ar com ws: ou wss: (no caso de WebSocket Seguro).<\/p>\n

Para a parte servidor do t\u00fanel, tamb\u00e9m faremos uma fun\u00e7\u00e3o separada para trabalhar com websockets. Nela, ser\u00e1 criado um exemplo da classe http e definido um manipulador de conex\u00e3o http (fun\u00e7\u00e3o wsHandler): <\/p>\n

\"Domain
\n
\nE toda a l\u00f3gica de tratamento da conex\u00e3o (autentica\u00e7\u00e3o do cliente por senha, cria\u00e7\u00e3o e finaliza\u00e7\u00e3o da sess\u00e3o yamux) ser\u00e1 colocada no manipulador de conex\u00e3o WebSocket:<\/p>\n

\"Domain
\n
\nCompilamos o projeto, iniciamos a parte do servidor:<\/p>\n

.\/rsockstun \u2013listen ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nE depois a parte cliente:<\/p>\n
.\/rsockstun -connect ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nE verificamos o funcionamento no host local:<\/p>\n
\"Domain
\n
\n\"Domain
\n<\/p>\n
Vamos para o domain fronting<\/h3>\n
\nCom os websockets, parece que j\u00e1 entendemos. Agora vamos passar diretamente para eSNI e domain fronting. Como mencionado anteriormente, para trabalhar com DoH e eSNI, precisamos obter um ramo especial do Go da empresa CloudFlare<\/a><\/noindex>. Precisamos da vers\u00e3o com suporte para eSNI (pwu\/esni).<\/p>\n
Clone-a localmente ou baixe e descompacte o zip correspondente:<\/p>\n
git clone -b pwu\/esni https:\/\/github.com\/cloudflare\/tls-tris.git<\/code><\/pre>\n
\nEm seguida, precisamos copiar o diret\u00f3rio GOROOT, substituir os arquivos correspondentes da branch clonada e configur\u00e1-lo como o principal. Para livrar o desenvolvedor de dor de cabe\u00e7a, a equipe da CloudFlare preparou um script especial \u2013 _dev\/go.sh. \u00c9 s\u00f3 execut\u00e1-lo. O script, junto com o makefile, far\u00e1 tudo automaticamente. Para curiosidade, voc\u00ea pode olhar dentro do makefile para mais detalhes.<\/p>\n
Ap\u00f3s a execu\u00e7\u00e3o do script, ao compilar o projeto, precisaremos indicar como GOROOT o diret\u00f3rio local preparado pelo script. No nosso caso, isso fica assim:<\/p>\n
GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" go build ....<\/code><\/pre>\n
\nEm seguida, precisamos implementar no t\u00fanel a funcionalidade de solicita\u00e7\u00e3o e parsing de chaves eSNI p\u00fablicas para o dom\u00ednio desejado. No nosso caso, essas ser\u00e3o as chaves eSNI p\u00fablicas dos servidores front-end da CloudFlare. Para isso, criaremos tr\u00eas fun\u00e7\u00f5es:<\/p>\n
func makeDoTQuery(dnsName string) ([]byte, error)\nfunc parseTXTResponse(buf []byte, wantName string) (string, error)\nfunc QueryESNIKeysForHost(hostname string) ([]byte, error)<\/code><\/pre>\n
\nOs nomes das fun\u00e7\u00f5es falam por si s\u00f3. O conte\u00fado, por sua vez, pegaremos do arquivo esni_query.go, que faz parte do tls-tris. A primeira fun\u00e7\u00e3o cria um pacote de rede com a solicita\u00e7\u00e3o ao servidor DNS da CloudFlare, utilizando o protocolo DoH (DNS-over-HTTPS), a segunda faz o parsing dos resultados da solicita\u00e7\u00e3o e obt\u00e9m os valores das chaves p\u00fablicas do dom\u00ednio, enquanto a terceira \u00e9 um cont\u00eainer para as duas primeiras.<\/p>\n
Em seguida, incorporamos em nossa nova fun\u00e7\u00e3o de conex\u00e3o WebSocket connectForWsSocks<\/b><\/i> a funcionalidade de solicita\u00e7\u00e3o de chaves eSNI para o dom\u00ednio. Onde a parte do servidor funciona, definimos os par\u00e2metros TLS, al\u00e9m de especificar um nome de \"dom\u00ednio de encobrimento\" falso:<\/p>\n
\"Domain
\n
\nAqui vale a pena notar que, inicialmente, a branch tls-tris n\u00e3o foi projetada para uso de domain-fronting. Portanto, n\u00e3o foi dada aten\u00e7\u00e3o ao nome falso do servidor (no pacote client-hello um campo serverName vazio \u00e9 transmitido). Para corrigir isso, teremos que adicionar o campo correspondente FakeServerName \u00e0 estrutura TlsConfig. N\u00e3o podemos usar o campo padr\u00e3o ServerName da estrutura, pois ele \u00e9 utilizado por mecanismos internos do TLS e, se diferir do original, a handshake TLS terminar\u00e1 com erro. A descri\u00e7\u00e3o da estrutura TlsConfig est\u00e1 contida no arquivo tls\/common.go<\/b> \u2013 e \u00e9 neste arquivo que teremos que fazer ajustes:<\/p>\n
\"Domain
\n
\n\"Domain
\n
\nAl\u00e9m disso, teremos que fazer mudan\u00e7as no arquivo tls\/handshake_client.go<\/b>, para usar nosso campo FakeServerName ao formar o handshake TLS:<\/p>\n
\"Domain
\n
\n\u00c9 isso! Voc\u00ea pode compilar o projeto e verificar se tudo est\u00e1 funcionando. Mas antes de iniciar o teste, \u00e9 necess\u00e1rio configurar a conta do CloudFlare. Bem, n\u00e3o \u00e9 bem configurar \u2013 \u00e9 s\u00f3 criar uma conta no CloudFlare e vincular seu dom\u00ednio a ela. Todos os recursos relacionados ao DoH, WebSocket e ESNI est\u00e3o ativados no CloudFlare por padr\u00e3o. Depois que os registros DNS forem atualizados \u2013 voc\u00ea pode testar o funcionamento do dom\u00ednio fazendo a solicita\u00e7\u00e3o das chaves eSNI:<\/p>\n
dig +short txt _esni.df13tester.info <\/code><\/pre>\n
\n\"Domain
\n
\nSe voc\u00ea ver algo semelhante para seu dom\u00ednio \u2013 significa que tudo est\u00e1 funcionando e voc\u00ea pode passar para os testes.<\/p>\n
Iniciamos um VPS Ubuntu, por exemplo, na DigitalOcean. P.S. No nosso caso, o endere\u00e7o IP do VPS fornecido recentemente estava em listas negras do RKN. Ent\u00e3o, n\u00e3o se surpreenda se algo semelhante acontecer com voc\u00ea. Tive que usar um VPN para acessar meu VPS.<\/p>\n
Copiamos o rsockstun j\u00e1 compilado para o VPS (a prop\u00f3sito, essa \u00e9 mais uma vantagem do Go \u2013 voc\u00ea pode compilar o projeto localmente e execut\u00e1-lo em qualquer Linux, respeitando apenas a arquitetura do sistema) e iniciamos a parte do servidor:<\/p>\n
\"Domain
\n
\nE ent\u00e3o a parte do cliente:<\/p>\n
\"Domain
\n
\nComo podemos ver, o cliente conseguiu se conectar ao servidor atrav\u00e9s do servidor frontend do CloudFlare usando WebSocket. Para verificar se o t\u00fanel funciona realmente como um t\u00fanel, voc\u00ea pode fazer uma solicita\u00e7\u00e3o curl atrav\u00e9s do socks5 local, aberto no servidor:<\/p>\n
\"Domain
\n
\nAgora vamos ver o que o DPI v\u00ea no canal de comunica\u00e7\u00e3o:<\/p>\n
\"Domain
\n
\nPrimeiro, o tunnel, usando o mecanismo DoH, consulta o servidor DNS do Cloudflare em busca das chaves eSNI para o dom\u00ednio de destino (pacotes n\u00ba 1-19), e depois se conecta ao servidor frontend e estabelece uma conex\u00e3o TLS, ocultando-se sob o dom\u00ednio www.google.com<\/a><\/noindex> (esse \u00e9 o valor padr\u00e3o, quando ao iniciar o cliente n\u00e3o foi especificado um dom\u00ednio falso). Para especificar seu pr\u00f3prio dom\u00ednio falso \u00e9 necess\u00e1rio usar o par\u00e2metro -fronfDomain:<\/p>\n
\"Domain
\n
\n\"Domain
\n
\nAgora, mais um ponto. Por padr\u00e3o, nas configura\u00e7\u00f5es da conta do CloudFlare, o modo de opera\u00e7\u00e3o SSL Flex\u00edvel est\u00e1 ativado. Isso significa que as solicita\u00e7\u00f5es https aos servidores frontend do Cloudflare por clientes ser\u00e3o redirecionadas em formato n\u00e3o criptografado (http) para nosso servidor. \u00c9 por isso que iniciamos a parte do servidor do tunnel em modo non-ssl (-listen ws:0.0.0.0), e n\u00e3o (-listen wss:0.0.0.0).<\/p>\n
\"Domain
\n
\nPara mudar para o modo de criptografia total, \u00e9 necess\u00e1rio selecionar Completo<\/b>, ou Full (strict)<\/b> em caso de um certificado real no servidor. Ap\u00f3s mudar o modo, poderemos aceitar conex\u00f5es da CloudFlare pelo protocolo https. N\u00e3o se esque\u00e7a de gerar um certificado autoassinado para a parte do servidor do tunelador.<\/p>\n
\"Domain
\n
\nUm leitor perspicaz perguntar\u00e1: \"E quanto ao cliente para Windows? Afinal, a principal aplica\u00e7\u00e3o do tunelador \u00e9 estabelecer uma conex\u00e3o de retorno com m\u00e1quinas e servidores corporativos, e l\u00e1, como regra, sempre h\u00e1 Windows. Como posso compilar o tunelador para Windows, ainda mais com uma pilha de TLS espec\u00edfica?\" E agora, vamos apresentar mais uma funcionalidade que mostra o qu\u00e3o conveniente \u00e9 o Go. Compilamos para Windows diretamente do Kali, apenas adicionando o par\u00e2metro GOOS=windows:<\/p>\n
GOARCH=amd64 GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" GOOS=windows  go build -ldflags=\"-s -w\"<\/code><\/pre>\n
\nOu a vers\u00e3o de 32 bits:<\/p>\n
GOARCH=386 GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" GOOS=windows  go build -ldflags=\"-s -w\"<\/code><\/pre>\n
\n\u00c9 isso! E mais nenhuma complica\u00e7\u00e3o \u00e9 necess\u00e1ria. Isso realmente funciona! <\/p>\n
\"Domain
\n
\nAs flags do compilador \u2013w e \u2013s s\u00e3o necess\u00e1rias para remover lixo desnecess\u00e1rio do arquivo execut\u00e1vel, tornando-o alguns megabytes menor. Al\u00e9m disso, pode ser empacotado com o UPX para ainda reduzir o tamanho.<\/p>\n
Em conclus\u00e3o<\/h3>\n
\nNeste artigo, demonstramos, com o exemplo do tunelador escrito em Go, a aplica\u00e7\u00e3o da nova tecnologia de domain fronting, implementada em uma caracter\u00edstica bastante interessante do protocolo TLS 1.3. Da mesma forma, \u00e9 poss\u00edvel adaptar ferramentas existentes escritas em Go para funcionar atrav\u00e9s de servidores CloudFlare, por exemplo, Merlin<\/a><\/noindex> \u2014 um conhecido C2, ou fazer o CobaltStrike Beacon usar o domain fronting eSNI ao operar com o Teamserver atrav\u00e9s de External C2 Channel<\/a><\/noindex>, implementado em Go, ou mesmo em C++ padr\u00e3o usando uma vers\u00e3o patchada do OpenSSL, sobre a qual falamos na parte anterior do artigo. Em geral, a criatividade n\u00e3o tem limites.<\/p>\n
O exemplo com o tunelador e CloudFlare \u00e9 apresentado como um conceito e, por enquanto, \u00e9 dif\u00edcil dizer sobre as perspectivas futuras desse tipo de domain fronting. No momento, o suporte ao eSNI \u00e9 oferecido apenas pela CloudFlare e, em teoria, nada impede que eles desativem esse tipo de fronting e, por exemplo, interrompam as conex\u00f5es tls em caso de discrep\u00e2ncia entre SNI e eSNI. Em geral, o futuro dir\u00e1. Mas, por enquanto, a perspectiva de operar sob a \"cobertura de kremlin.ru\" parece bastante atraente. N\u00e3o parece?<\/p>\n
O c\u00f3digo atualizado do tunelador, assim como os arquivos execut\u00e1veis compilados, est\u00e3o dispon\u00edveis em um ramo separado do projeto em github<\/a><\/noindex>. Para quaisquer problemas relacionados ao tunelador, \u00e9 melhor registrar uma issue na p\u00e1gina do projeto no GitHub.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043c\u044b \u0434\u0430\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430 encrypted SNI (eSNI). \u041f\u043e\u043a\u0430\u0437\u0430\u043b\u0438 \u043a\u0430\u043a\u0438\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043d\u0430 \u0435\u0433\u043e \u043e\u0441\u043d\u043e\u0432\u0435 \u043c\u043e\u0436\u043d\u043e \u0443\u043a\u043b\u043e\u043d\u044f\u0442\u044c\u0441\u044f \u043e\u0442 \u0434\u0435\u0442\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c\u0438 DPI-\u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438 (\u043d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 \u0431\u0438\u043b\u0430\u0439\u043d\u043e\u0432\u0441\u043a\u043e\u0433\u043e DPI \u0438 \u0437\u0430\u043f\u0440\u0435\u0449\u0435\u043d\u043d\u043e\u0433\u043e \u0420\u041a\u041d \u0440\u0443\u0442\u0440\u0435\u043a\u0435\u0440\u0430), \u0430 \u0442\u0430\u043a\u0436\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043b\u0438 \u043d\u043e\u0432\u044b\u0439 \u0432\u0430\u0440\u0438\u0430\u043d\u0442 \u0434\u043e\u043c\u0435\u043d-\u0444\u0440\u043e\u043d\u0442\u0438\u043d\u0433\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u0430\u043d\u043d\u043e\u0433\u043e \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430. \u0412\u043e \u0432\u0442\u043e\u0440\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u0435\u0440\u0435\u0439\u0434\u0435\u043c \u043a \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u0435\u0449\u0430\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u0443\u0434\u0443\u0442 \u043f\u043e\u043b\u0435\u0437\u043d\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53317","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Domain Fronting baseado em TLS 1.3. Parte 2 | ProHoster","description":"Introdu\u00e7\u00e3o Na primeira parte do artigo, fornecemos uma breve descri\u00e7\u00e3o do mecanismo de encrypted SNI (eSNI).","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u043e\u043c\u0435\u043d-\u0444\u0440\u043e\u043d\u0442\u0438\u043d\u0433 \u043d\u0430 \u0431\u0430\u0437\u0435 TLS 1.3. \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043c\u044b \u0434\u0430\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430 encrypted SNI (eSNI).","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-28T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:12+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53317","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 06:55:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:27:38","updated":"2026-01-24 06:55:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/53317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=53317"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/53317\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=53317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=53317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=53317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}