{"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\/it\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","title":{"rendered":"Domain fronting basato su TLS 1.3. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduzione<\/h3>\n

\nNella prima parte sul CommunityHelpWiki (sullo stesso dominio<\/a><\/noindex> abbiamo fornito una breve descrizione del meccanismo dell'eSNI (encrypted SNI). Abbiamo mostrato come, sulla base di esso, sia possibile eludere il rilevamento da parte dei moderni sistemi DPI (prendendo come esempio il DPI di Beeline e il tracker RuNet bloccato dal Roskomnadzor), e abbiamo esaminato una nuova variante del domain fronting basata su questo meccanismo.<\/p>\n

Nella seconda parte dell'articolo passeremo a questioni pi\u00f9 pratiche, che saranno utili agli specialisti della RedTeam nel loro difficile lavoro. Dopotutto, il nostro obiettivo non \u00e8 ottenere accesso a risorse bloccate (per tali cose banali abbiamo il buon vecchio VPN). Fortunatamente, ci sono un gran numero di provider VPN, come si suol dire, per tutti i gusti, colori e budget.<\/p>\n

Cercheremo di applicare il meccanismo del domain fronting agli strumenti moderni della RedTeam, come Cobalt Strike, Empire, ecc., e fornire loro ulteriori possibilit\u00e0 di mimetizzazione ed elusione dai moderni sistemi di filtraggio del contenuto.
\n<\/a><\/noindex>
\nL'ultima volta abbiamo integrato il meccanismo dell'eSNI nella libreria OpenSSL e l'abbiamo utilizzato con successo nell'utility di curl conosciuta a tutti. Ma con un semplice curl, come si dice, non ci si nutre. Certamente vogliamo realizzare qualcosa di simile in linguaggi di alto livello. Purtroppo, una rapida ricerca nelle vastit\u00e0 della rete ci delude, poich\u00e9 il supporto del meccanismo dell'eSNI \u00e8 implementato pienamente solo in GOLANG. Pertanto, le nostre opzioni non sono poi cos\u00ec molte: o scriviamo in C o C++ puro utilizzando una libreria OpenSSL patchata, oppure utilizziamo un fork separato di GOLANG da CloudFlare e proviamo a portare il nostro toolkit l\u00ec. In linea di principio, c'\u00e8 anche un'altra opzione, pi\u00f9 classica, ma allo stesso tempo laboriosa: implementare il supporto per l'eSNI in Python. Dopotutto, anche Python utilizza OpenSSL per lavorare con https. Ma lasceremo questa opzione a qualcun altro per lo sviluppo e noi ci accontenteremo dell'implementazione in Golang, soprattutto perch\u00e9 il nostro amato Cobalt Strike lavora perfettamente con i canali di comunicazione costruiti con mezzi esterni (External C2 channel) \u2013 di questo parleremo alla fine dell'articolo.<\/p>\n

Try Harder\u2026<\/h3>\n

\nUno degli strumenti realizzati in Go \u00e8 il nostro sviluppo per il pivoting all'interno della rete: il tunneling rsockstun<\/a><\/noindex>, che, tra l'altro, al giorno d'oggi viene rilevato dai prodotti di Microsoft e Symantec come software molto dannoso, volto a compromettere la stabilit\u00e0 globale\u2026<\/p>\n

\"Domain
\n
\nSarebbe fantastico utilizzare il precedente sviluppo anche in questo caso. Ma qui sorge un piccolo problema. Il fatto \u00e8 che inizialmente rsockstun implica l'uso di un canale di comunicazione SSL sincrono con il server. Questo significa che la connessione viene stabilita una sola volta e rimane attiva per tutta la durata del funzionamento del tunneler. E, come puoi immaginare, il protocollo https non \u00e8 proprio concepito per questo tipo di modalit\u00e0 operativa \u2013 funziona in modalit\u00e0 request-response, dove ogni nuova richiesta http esiste nel contesto di una nuova connessione tcp.<\/p>\n

Il principale svantaggio di questo schema \u00e8 che il server non pu\u00f2 trasferire dati al cliente fino a quando il cliente non invia una nuova richiesta http. Ma, per fortuna, ci sono molte soluzioni a questo problema \u2013 il trasferimento dei dati tramite il protocollo http (dopotutto, riusciamo in qualche modo a guardare le nostre serie preferite e ascoltare musica da portali che funzionano su https, e il trasferimento di video e audio non \u00e8 altro che un trasferimento dati in streaming). Una delle tecnologie per emulare il funzionamento di una connessione tcp completa sopra il protocollo http \u00e8 la tecnologia dei websocket (WebSockets), il cui principio fondamentale \u00e8 l'organizzazione di una connessione di rete completa tra cliente e server web.<\/p>\n

Per nostra fortuna (evviva!!!), questa tecnologia \u00e8 attivata per impostazione predefinita in tutti i piani tariffari di CloudFlare e funziona perfettamente in combinazione con eSNI. Proprio questa la utilizzeremo per insegnare al nostro tunneler a usare il domain fronting e a nascondersi dai moderni DPI. <\/p>\n

Un po' sui WebSockets<\/h3>\n

\nPrima di tutto, spiegheremo brevemente e in termini semplici cosa sono i websocket, affinch\u00e9 tutti abbiano un'idea chiara di cosa stiamo per affrontare. <\/p>\n

La tecnologia dei websocket consente di passare temporaneamente da una connessione http a un normale trasferimento dati tramite socket di rete, senza interrompere la connessione tcp stabilita. Quando il cliente desidera passare ai websocket, invia nel suo richiesta http alcuni header http. Due header obbligatori sono Connection: Upgrade<\/b><\/i> e Upgrade: websocket<\/b><\/i>. Pu\u00f2 anche specificare forzatamente la versione del protocollo websocket (Sec-Websocket-Version: 13<\/b><\/i>) e qualcosa simile a un identificatore base64 per il websocket (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==<\/b><\/i>). Il server risponde con il codice http 101 Switching Protocols e imposta anche le intestazioni Connection, Upgrade<\/b><\/i> e Sec-WebSocket-Accept<\/b><\/i>. Il processo di switch \u00e8 ben illustrato nello schermo qui sotto:<\/p>\n

\"Domain
\n
\nDopo di che si pu\u00f2 considerare completata l'installazione della connessione WebSocket. Qualsiasi dato, sia dal client che dal server, ora sar\u00e0 accompagnato non da intestazioni http, ma da intestazioni WebSocket (iniziano con il byte 0x82). Ora il server non ha bisogno di aspettare una richiesta dal client per trasmettere i dati, poich\u00e9 la connessione tcp non si interrompe.<\/p>\n

In Go ci sono diverse librerie per lavorare con i websocket. Le pi\u00f9 popolari sono Gorilla WebSocket<\/a><\/noindex> e la standard WebSocket<\/a><\/noindex>. Utilizzeremo quest'ultima, poich\u00e9 \u00e8 pi\u00f9 semplice, pi\u00f9 leggera e funziona, come si dice, un po' pi\u00f9 velocemente.<\/p>\n

Nel codice cliente rsockstun, dobbiamo sostituire le chiamate net.dial o tls.dial con le corrispondenti chiamate WebSocket:<\/p>\n

\"Domain
\n
\n\"Domain
\n
\nVogliamo rendere la parte client del nostro tunneller universale e capace di funzionare sia attraverso una connessione ssl diretta che attraverso il protocollo WebSocket. Per questo creeremo una funzione separata func connectForWsSocks(address string, proxy string) error {\u2026}<\/b><\/i> per analogia con connectForSocks()<\/b><\/i> e useremo questa funzione per lavorare con i websocket nel caso in cui l'indirizzo del server specificato all'avvio del client inizi con ws: o wss: (nel caso di Secure WebSocket).<\/p>\n

Per la parte server del tunneller faremo anche una funzione separata per lavorare con i websocket. Qui creeremo un'istanza della classe http e imposteremo un gestore per la connessione http (funzione wsHandler): <\/p>\n

\"Domain
\n
\nE tutta la logica di gestione della connessione (autenticazione del client tramite password, impostazione e chiusura della sessione yamux) la metteremo nel gestore della connessione WebSocket:<\/p>\n

\"Domain
\n
\nCompiliamo il progetto, avviamo la parte server:<\/p>\n

.\\\/rsockstun \u2013listen ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nE poi la parte client:<\/p>\n
.\\\/rsockstun -connect ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nE verifichiamo il funzionamento sul host locale:<\/p>\n
\"Domain
\n
\n\"Domain
\n<\/p>\n
Passiamo al domain-fronting<\/h3>\n
\nCon i websocket sembriamo averci capito. Ora passiamo direttamente a eSNI e al domain-fronting. Come gi\u00e0 detto prima, per lavorare con DoH e eSNI abbiamo bisogno di prendere un ramo speciale di Go della compagnia CloudFlare<\/a><\/noindex>. Abbiamo bisogno di un ramo con supporto per eSNI (pwu\/esni).<\/p>\n
Cloniamolo localmente o scarichiamo e estraiamo il relativo zip:<\/p>\n
git clone -b pwu\/esni https:\/\/github.com\/cloudflare\/tls-tris.git<\/code><\/pre>\n
\nDopo, dobbiamo copiare la directory GOROOT, sostituire i file corrispondenti dal branch clonato e impostarlo come principale. Per sollevare il developer da questo grattacapo, i ragazzi di CloudFlare hanno preparato uno script speciale \u2013 _dev\/go.sh. Basta eseguirlo. Lo script, insieme al makefile, far\u00e0 tutto da solo. Per curiosit\u00e0, puoi dare un'occhiata al makefile per ulteriori dettagli.<\/p>\n
Dopo l'esecuzione dello script, durante la compilazione del progetto, dovremo specificare come GOROOT la directory locale preparata dallo script. Nel nostro caso appare cos\u00ec:<\/p>\n
GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" go build \u2026.<\/code><\/pre>\n
\nSuccessivamente, dobbiamo implementare nella tunnel la funzionalit\u00e0 per richiedere e analizzare le chiavi eSNI pubbliche per il dominio desiderato. Nel nostro caso, queste sono le chiavi eSNI pubbliche dei server frontend di CloudFlare. A tal fine, creeremo tre funzioni:<\/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
\nI nomi delle funzioni, in effetti, parlano da soli. Prenderemo il contenuto dal file esni_query.go, che fa parte di tls-tris. La prima funzione crea un pacchetto di rete con una richiesta al server DNS di CloudFlare, utilizzando il protocollo DoH (DNS-over-HTTPS), la seconda analizza i risultati della richiesta e ottiene i valori delle chiavi pubbliche del dominio, mentre la terza funge da contenitore per le prime due.<\/p>\n
Successivamente, aggiungiamo nella nostra nuova funzione il collegamento WebSocket connectForWsSocks<\/b><\/i> la funzionalit\u00e0 per richiedere le chiavi eSNI per il dominio. Dove funziona la parte server, impostiamo i parametri TLS e definiamo anche il nome del \u00abdominio di copertura\u00bb fittizio:<\/p>\n
\"Domain
\n
\n\u00c8 importante notare che inizialmente, il branch tls-tris non \u00e8 progettato per utilizzare il domain fronting. Di conseguenza, non presta attenzione al nome di server fittizio (nel pacchetto client-hello viene inviato un campo serverName vuoto). Per correggere questo, dovremo aggiungere al modello TlsConfig il campo corrispondente FakeServerName. Non possiamo utilizzare il campo ServerName standard della struttura, in quanto \u00e8 usato dai meccanismi interni di tls e se differisce dall'originale, l handshake tls terminer\u00e0 con un errore. La descrizione della struttura TlsConfig si trova nel file tls\/common.go<\/b> \u2013 e sta a noi modificarlo:<\/p>\n
\"Domain
\n
\n\"Domain
\n
\nInoltre, dovremo apportare modifiche al file tls\/handshake_client.go<\/b>, per utilizzare il nostro campo FakeServerName nella generazione del handshake TLS:<\/p>\n
\"Domain
\n
\nFatto! Puoi compilare il progetto e verificare il funzionamento. Ma prima di avviare il controllo, \u00e8 necessario configurare l'account CloudFlare. Come dire, configurare: \u00e8 sufficiente creare un account su CloudFlare e associare il proprio dominio ad esso. Tutte le funzionalit\u00e0 relative a DoH, WebSocket ed ESNI sono abilitate su CloudFlare di default. Dopo che i record DNS sono stati aggiornati, puoi verificare il funzionamento del dominio effettuando una richiesta per le chiavi eSNI:<\/p>\n
dig +short txt _esni.df13tester.info <\/code><\/pre>\n
\n\"Domain
\n
\nSe vedi qualcosa di simile per il tuo dominio, significa che tutto funziona e puoi procedere con il test.<\/p>\n
Avviamo un VPS Ubuntu, ad esempio, su DigitalOcean. P.S. Nel nostro caso, l'indirizzo IP appena rilasciato dal provider VPS si \u00e8 trovato nelle blacklist del RKN. Quindi non sorprenderti se ti succede qualcosa di simile. Ho dovuto utilizzare una VPN per accedere al mio VPS.<\/p>\n
Copiamo su VPS il rsockstun gi\u00e0 compilato (questo, tra l'altro, \u00e8 un'altra bellezza del Golang: puoi compilare il progetto sul tuo sistema e avviarlo su qualsiasi Linux, rispettando solo l'architettura di sistema) e avviamo la parte server:<\/p>\n
\"Domain
\n
\nE poi avviamo la parte client:<\/p>\n
\"Domain
\n
\nCome vediamo, il client si \u00e8 connesso con successo al server attraverso il server frontend di CloudFlare utilizzando un websocket. Per verificare che il tunnel funzioni effettivamente come tale, puoi effettuare una richiesta curl attraverso il socks5 locale aperto sul server:<\/p>\n
\"Domain
\n
\nOra vediamo cosa vede il DPI nel canale di comunicazione:<\/p>\n
\"Domain
\n
\nInizialmente, il tunnel, utilizzando il meccanismo DoH, si rivolge al server DNS di Cloudflare per ottenere le chiavi eSNI per il dominio di destinazione (pacchetti n. 1-19), quindi si rivolge al server frontend e stabilisce una connessione TLS, nascondendosi dietro il dominio www.google.com<\/a><\/noindex> (questo \u00e8 il valore predefinito quando, all'avvio del client, non viene specificato un dominio falso). Per specificare il proprio dominio falso \u00e8 necessario utilizzare il parametro -fronfDomain:<\/p>\n
\"Domain
\n
\n\"Domain
\n
\nOra un altro punto. Di default, nelle impostazioni dell'account su CloudFlare \u00e8 attivata la modalit\u00e0 Flexible SSL. Ci\u00f2 significa che le richieste https ai server frontend di CloudFlare da parte dei client verranno reindirizzate in modalit\u00e0 non crittografata (http) al nostro server. \u00c8 per questo che abbiamo avviato la parte server del tunnel in modalit\u00e0 non-ssl (-listen ws:0.0.0.0), e non (-listen wss:0.0.0.0).<\/p>\n
\"Domain
\n
\nPer passare alla modalit\u00e0 di crittografia completa, \u00e8 necessario scegliere Completo<\/b>, o Full (strict)<\/b> in caso di presenza di un certificato valido sul server. Dopo aver cambiato la modalit\u00e0, saremo in grado di accettare connessioni da CloudFlare tramite il protocollo https. Non dimenticate di generare un certificato self-signed per la parte server del tunneler.<\/p>\n
\"Domain
\n
\nIl lettore pignolo chieder\u00e0: \u00abE per il client su Windows? \u00c8 certo che l'uso principale del tunneler \u00e8 sollevare il back-connect da macchine e server aziendali, e l\u00ec di solito c'\u00e8 sempre Windows. Come posso compilare il tunneler per Windows, e anche con uno stack TLS specifico?\u00bb Ora presentiamo un'altra funzionalit\u00e0 che dimostra quanto sia comodo Go. Compiliamo per Windows direttamente da Kali, aggiungendo semplicemente il parametro GOOS=windows:<\/p>\n
GOARCH=amd64 GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" GOOS=windows  go build -ldflags=\"-s -w\"<\/code><\/pre>\n
\nO la versione a 32 bit:<\/p>\n
GOARCH=386 GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" GOOS=windows  go build -ldflags=\"-s -w\"<\/code><\/pre>\n
\nTutto qui! E non servono ulteriori complicazioni. Funziona davvero! <\/p>\n
\"Domain
\n
\nLe opzioni del compilatore \u2013w e \u2013s sono necessarie per rimuovere i rifiuti indesiderati dal file eseguibile, rendendolo pi\u00f9 leggero di alcuni megabyte. Successivamente, pu\u00f2 essere impacchettato utilizzando UPX per ridurre ulteriormente la dimensione.<\/p>\n
In conclusione<\/h3>\n
\nNell'articolo, abbiamo dimostrato l'applicazione di una nuova tecnologia di domain fronting utilizzando un tunneler scritto in Go, basandoci su una caratteristica piuttosto interessante del protocollo TLS 1.3. Analogamente, \u00e8 possibile adattare gli strumenti esistenti scritti in Go per funzionare attraverso i server CloudFlare, ad esempio Merlin<\/a><\/noindex> \u2014 un noto C2, o costringere CobaltStrike Beacon a utilizzare domain fronting eSNI quando lavora con Teamserver tramite External C2 Channel<\/a><\/noindex>, realizzato in Go, oppure utilizzare la versione standard in C++ con una versione di OpenSSL patchata, di cui abbiamo parlato nella parte precedente dell'articolo. Insomma, non c'\u00e8 limite alla fantasia.<\/p>\n
L'esempio con il tunneler e CloudFlare \u00e8 presentato come un concetto, ed \u00e8 ancora difficile dire quali siano le prospettive future di questo tipo di domain fronting. Al momento, il supporto per eSNI \u00e8 implementato solo su CloudFlare e, in teoria, niente impedisce loro di disattivare questo tipo di fronting e, ad esempio, interrompere le connessioni tls in caso di non corrispondenza tra SNI ed eSNI. Insomma, il futuro lo dir\u00e0. Ma per ora, la prospettiva di operare sotto \"copertura di kremlin.ru\" appare piuttosto allettante. Non \u00e8 cos\u00ec?<\/p>\n
Il codice aggiornato del tunneller, cos\u00ec come i file exe compilati, sono disponibili in un ramo separato del progetto su github<\/a><\/noindex>. Per eventuali problemi con il tunneller, \u00e8 meglio riportare un issue sulla pagina del progetto su 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\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 basato su TLS 1.3. Parte 2 | ProHoster","description":"Introduzione Nella prima parte dell'articolo abbiamo fornito una breve descrizione del meccanismo di encrypted SNI (eSNI).","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/53317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=53317"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53317\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=53317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=53317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=53317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}