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

Introducci\u00f3n<\/h3>\n

\nEn la primera parte art\u00edculo<\/a><\/noindex> dimos una breve descripci\u00f3n del mecanismo encrypted SNI (eSNI). Mostramos c\u00f3mo se puede evadir la detecci\u00f3n de los modernos sistemas DPI (tomando como ejemplo el DPI de Beeline y el prohibido RKN rutracker), as\u00ed como investigamos una nueva variante de domain fronting basada en este mecanismo.<\/p>\n

En la segunda parte del art\u00edculo pasaremos a cosas m\u00e1s pr\u00e1cticas que ser\u00e1n \u00fatiles para los especialistas de RedTeam en su dif\u00edcil trabajo. Al final, nuestro objetivo no es obtener acceso a recursos bloqueados (para tales cosas banales tenemos el viejo y querido VPN). Afortunadamente, existen una gran cantidad de proveedores de VPN, como se dice, para todos los gustos, colores y presupuestos.<\/p>\n

Intentaremos aplicar el mecanismo de domain fronting a las herramientas modernas de RedTeam, como Cobalt Strike, Empire, etc., y darles capacidades adicionales para mimetizarse y evadir los modernos sistemas de filtrado de contenido.
\n<\/a><\/noindex>
\nLa \u00faltima vez implementamos el mecanismo eSNI en la biblioteca OpenSSL y lo utilizamos con \u00e9xito en la conocida utilidad curl. Pero con solo curl, como se dice, no basta. Por supuesto, queremos implementar algo similar en lenguajes de alto nivel. Sin embargo, desafortunadamente, una b\u00fasqueda r\u00e1pida por la red nos decepciona, ya que el soporte del mecanismo eSNI est\u00e1 completamente implementado solo en GOLANG. As\u00ed que, nuestras opciones no son muchas: o escribimos en C o C++ puro utilizando la biblioteca OpenSSL parchada, o utilizamos un fork separado de GOLANG de CloudFlare e intentamos portar nuestras herramientas all\u00ed. En principio, hay otra opci\u00f3n, m\u00e1s cl\u00e1sica, pero al mismo tiempo laboriosa: implementar soporte para eSNI en Python. Al final, Python tambi\u00e9n utiliza OpenSSL para trabajar con https. Pero dejaremos esta opci\u00f3n para que alguien m\u00e1s la desarrolle, mientras nosotros estaremos satisfechos con la implementaci\u00f3n en golang, especialmente porque nuestro querido Cobalt Strike puede trabajar con canales de comunicaci\u00f3n construidos por herramientas externas (canal C2 externo) \u2013 de esto hablaremos al final del art\u00edculo.<\/p>\n

Try Harder\u2026<\/h3>\n

\nUna de las herramientas implementadas en Go es nuestro desarrollo para pivoting dentro de la red \u2013 el t\u00fanel rsockstun<\/a><\/noindex>, que, por cierto, hoy en d\u00eda es detectada por las herramientas de Microsoft y Symantec como un software malicioso que tiene como objetivo comprometer la estabilidad mundial\u2026<\/p>\n

\"Domain
\n
\nSer\u00eda genial utilizar el desarrollo anterior en este caso. Pero aqu\u00ed surge un peque\u00f1o problema. El hecho es que rsockstun originalmente implica el uso de un canal de comunicaci\u00f3n SSL s\u00edncrono con el servidor. Esto significa que la conexi\u00f3n se establece una vez y existe durante todo el tiempo de funcionamiento del t\u00fanel. Y, como entender\u00e1s, el protocolo https no est\u00e1 realmente dise\u00f1ado para este modo de operaci\u00f3n; funciona en modo de solicitud-respuesta, donde cada nueva solicitud http existe en el marco de una nueva conexi\u00f3n tcp.<\/p>\n

La principal desventaja de este esquema es que el servidor no puede enviar datos al cliente hasta que el cliente env\u00ede una nueva solicitud http. Pero, afortunadamente, hay muchas soluciones a este problema: la transmisi\u00f3n de datos a trav\u00e9s del protocolo http (al fin y al cabo, logramos ver nuestras series favoritas y escuchar m\u00fasica de portales que operan con https, y la transmisi\u00f3n de video y audio no es m\u00e1s que una transmisi\u00f3n de datos). Una de las tecnolog\u00edas para emular el funcionamiento de una conexi\u00f3n tcp completa sobre el protocolo http es la tecnolog\u00eda de WebSockets, cuya esencia est\u00e1 en organizar una conexi\u00f3n de red completa entre el cliente y el servidor web.<\/p>\n

Para nuestra suerte (\u00a1hurra!), esta tecnolog\u00eda est\u00e1 habilitada por defecto en todos los planes de CloudFlare y funciona perfectamente junto con eSNI. Precisamente esta es la que utilizaremos para ense\u00f1arle a nuestro t\u00fanel a usar el fronting de dominio y ocultarse de los DPI modernos. <\/p>\n

Un poco sobre los WebSockets<\/h3>\n

\nPrimero que nada, explicaremos brevemente y con palabras simples qu\u00e9 son los WebSockets, para que todos tengan una idea de con qu\u00e9 estaremos trabajando. <\/p>\n

La tecnolog\u00eda de WebSockets permite alternar temporalmente de una conexi\u00f3n http a una transmisi\u00f3n de datos est\u00e1ndar a trav\u00e9s de un socket de red, sin romper la conexi\u00f3n tcp establecida. Cuando el cliente desea cambiar a WebSocket, establece varios encabezados http en su solicitud http. Dos encabezados obligatorios son Connection: Upgrade<\/b><\/i> y Upgrade: websocket<\/b><\/i>. Tambi\u00e9n puede especificar por fuerza la versi\u00f3n del protocolo WebSocket (Sec-Websocket-Version: 13<\/b><\/i>) y algo como un identificador base64 de WebSocket (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==<\/b><\/i>). El servidor responde con el c\u00f3digo http 101 Switching Protocols y tambi\u00e9n establece los encabezados Connection, Upgrade<\/b><\/i> y Sec-WebSocket-Accept<\/b><\/i>. El proceso de cambio se ilustra claramente en la imagen a continuaci\u00f3n:<\/p>\n

\"Domain
\n
\nTras esto, la conexi\u00f3n WebSocket se puede considerar completa. Cualquier dato tanto del cliente como del servidor ahora ser\u00e1 suministrado no con encabezados http, sino con encabezados WebSocket (que comienzan con el byte 0x82). Ahora el servidor no necesita esperar a que el cliente haga una solicitud para transmitir datos, ya que la conexi\u00f3n tcp no se rompe.<\/p>\n

En Go, hay varias bibliotecas para trabajar con WebSockets. Las m\u00e1s populares son Gorilla WebSocket<\/a><\/noindex> y la est\u00e1ndar WebSocket<\/a><\/noindex>. Vamos a utilizar esta \u00faltima, ya que es m\u00e1s sencilla, m\u00e1s ligera y, como dicen, funciona un poco m\u00e1s r\u00e1pido.<\/p>\n

En el c\u00f3digo del cliente rsockstun, necesitamos reemplazar las llamadas net.dial o tls.dial por las correspondientes a WebSocket:<\/p>\n

\"Domain
\n
\n\"Domain
\n
\nQueremos hacer la parte del cliente de nuestro t\u00fanel universal y capaz de funcionar tanto a trav\u00e9s de una conexi\u00f3n ssl directa como mediante el protocolo WebSocket. Para ello, crearemos una funci\u00f3n separada func connectForWsSocks(address string, proxy string) error {\u2026}<\/b><\/i> por analog\u00eda con connectForSocks()<\/b><\/i> y la utilizaremos para trabajar con WebSockets en caso de que la direcci\u00f3n del servidor proporcionada al iniciar el cliente comience con ws: o wss: (en el caso de WebSocket seguro).<\/p>\n

Para la parte del servidor del t\u00fanel, tambi\u00e9n crearemos una funci\u00f3n separada para trabajar con WebSockets. En ella se crear\u00e1 una instancia de la clase http y se configurar\u00e1 el manejador de conexi\u00f3n http (funci\u00f3n wsHandler): <\/p>\n

\"Domain
\n
\nY toda la l\u00f3gica de gesti\u00f3n de la conexi\u00f3n (autenticaci\u00f3n del cliente por contrase\u00f1a, establecimiento y finalizaci\u00f3n de la sesi\u00f3n yamux) la colocaremos en el manejador de conexi\u00f3n WebSocket:<\/p>\n

\"Domain
\n
\nCompilamos el proyecto, iniciamos la parte del servidor:<\/p>\n

.\\\/rsockstun \u2013listen ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nY luego la parte del cliente:<\/p>\n
.\\\/rsockstun -connect ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nY comprobamos el funcionamiento en el host local:<\/p>\n
\"Domain
\n
\n\"Domain
\n<\/p>\n
Pasemos al dominio-fronto<\/h3>\n
\nCon los WebSockets parece que hemos resuelto el tema. Ahora pasemos directamente a eSNI y el dominio-fronto. Como se mencion\u00f3 anteriormente, para trabajar con DoH y eSNI necesitamos tomar una rama especial de Go de la empresa CloudFlare<\/a><\/noindex>. Necesitamos una rama con soporte para eSNI (pwu\/esni).<\/p>\n
La clonamos localmente o la descargamos y descomprimimos el zip correspondiente:<\/p>\n
git clone -b pwu\/esni https:\/\/github.com\/cloudflare\/tls-tris.git<\/code><\/pre>\n
\nLuego necesitamos copiar el directorio GOROOT, reemplazar los archivos correspondientes de la rama clonada y configurarlo como principal. Para liberar al desarrollador de este dolor de cabeza, los chicos de CloudFlare prepararon un script especial: _dev\/go.sh. Simplemente lo ejecutamos. El script junto con makefile se encargar\u00e1 de todo. Por curiosidad, pueden echar un vistazo al makefile para m\u00e1s detalles.<\/p>\n
Despu\u00e9s de que el script se ejecute, al compilar el proyecto, ser\u00e1 necesario indicar como GOROOT el directorio local preparado por el script. En nuestro caso, esto se ve as\u00ed:<\/p>\n
GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" go build \u2026.<\/code><\/pre>\n
\nA continuaci\u00f3n, necesitamos implementar en el t\u00fanel la funcionalidad de solicitud y an\u00e1lisis de claves eSNI p\u00fablicas para el dominio solicitado. En nuestro caso, ser\u00e1n las claves eSNI p\u00fablicas de los servidores frontend de CloudFlare. Para esto crearemos tres funciones:<\/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
\nLos nombres de las funciones, en principio, hablan por s\u00ed mismos. La implementaci\u00f3n la tomaremos del archivo esni_query.go, que forma parte de tls-tris. La primera funci\u00f3n crea un paquete de red con una solicitud al servidor DNS de CloudFlare, utilizando el protocolo DoH (DNS-over-HTTPS), la segunda analiza los resultados de la solicitud y obtiene los valores de las claves p\u00fablicas del dominio, y la tercera es un contenedor para las dos anteriores.<\/p>\n
A continuaci\u00f3n, agregamos en nuestra nueva funci\u00f3n la conexi\u00f3n de websocket connectForWsSocks<\/b><\/i> la funcionalidad de solicitud de claves eSNI para el dominio. Donde funciona la parte del servidor, establecemos los par\u00e1metros TLS y tambi\u00e9n asignamos el nombre del \"dominio ficticio\":<\/p>\n
\"Domain
\n
\nCabe mencionar que originalmente, la rama tls-tris no est\u00e1 dise\u00f1ada para el uso de dominio de cobertura. Por lo tanto, no se presta atenci\u00f3n al nombre ficticio del servidor (en el paquete client-hello se pasa un campo serverName vac\u00edo). Para corregir esto, tenemos que agregar en la estructura TlsConfig el campo correspondiente FakeServerName. No podemos usar el campo est\u00e1ndar ServerName de la estructura, ya que es utilizado por mecanismos internos de tls y si difiere del original, el handshake de tls finalizar\u00e1 con un error. La descripci\u00f3n de la estructura TlsConfig se encuentra en el archivo tls\/common.go<\/b> \u2013 y es lo que tenemos que corregir:<\/p>\n
\"Domain
\n
\n\"Domain
\n
\nAdem\u00e1s, tendremos que realizar cambios en el archivo tls\/handshake_client.go<\/b>, para utilizar nuestro campo FakeServerName al formar el handshake TLS:<\/p>\n
\"Domain
\n
\n\u00a1Eso es todo! Puedes compilar el proyecto y verificar su funcionamiento. Pero antes de ejecutar la verificaci\u00f3n, es necesario configurar tu cuenta de CloudFlare. Bueno, m\u00e1s que configurarla, simplemente crea una cuenta en CloudFlare y vincula tu dominio a ella. Todas las caracter\u00edsticas relacionadas con DoH, WebSocket y ESNI est\u00e1n habilitadas de forma predeterminada en CloudFlare. Una vez que se actualicen los registros DNS, puedes verificar el funcionamiento del dominio realizando una consulta de claves eSNI:<\/p>\n
dig +short txt _esni.df13tester.info <\/code><\/pre>\n
\n\"Domain
\n
\nSi ves algo parecido para tu dominio, significa que todo est\u00e1 funcionando y puedes pasar a las pruebas.<\/p>\n
Iniciamos un VPS de Ubuntu, por ejemplo, en DigitalOcean. P.D. En nuestro caso, la direcci\u00f3n IP recientemente asignada por el proveedor estaba en las listas negras del RKN. As\u00ed que no te sorprendas si te sucede algo similar. Tuve que usar un VPN para acceder a mi VPS.<\/p>\n
Copiamos en la VPS el rsockstun que ya fue compilado (de hecho, esta es otra ventaja de Go: puedes compilar el proyecto en tu m\u00e1quina y ejecutarlo en cualquier Linux, respetando solo la arquitectura del sistema) y ejecutamos la parte del servidor:<\/p>\n
\"Domain
\n
\nY luego la parte del cliente:<\/p>\n
\"Domain
\n
\nComo podemos ver, el cliente se ha conectado exitosamente al servidor a trav\u00e9s del servidor frontend de CloudFlare usando WebSocket. Para verificar que el t\u00fanel funciona como un t\u00fanel, puedes realizar una solicitud curl a trav\u00e9s del socks5 local, que est\u00e1 abierto en el servidor:<\/p>\n
\"Domain
\n
\nAhora veamos qu\u00e9 ve el DPI en el canal de comunicaci\u00f3n:<\/p>\n
\"Domain
\n
\nPrimero, el tunelador utiliza el mecanismo DoH para consultar al servidor DNS de Cloudflare por las claves eSNI para el dominio de destino (paquetes #1-19), y luego se conecta al servidor frontend y establece una conexi\u00f3n TLS, ocult\u00e1ndose detr\u00e1s del dominio www.google.com<\/a><\/noindex> (este es el valor predeterminado cuando al iniciar el cliente no se especifica un dominio falso). Para especificar tu propio dominio falso, debes usar el par\u00e1metro -fronfDomain:<\/p>\n
\"Domain
\n
\n\"Domain
\n
\nAhora, otro punto. De forma predeterminada, en la configuraci\u00f3n de la cuenta de CloudFlare est\u00e1 activado el modo Flexible SSL. Esto significa que las solicitudes https a los servidores frontend de Cloudflare desde los clientes se redirigir\u00e1n sin cifrado (http) a nuestro servidor. Precisamente por esto, ejecutamos la parte del servidor del tunelador en modo non-ssl (-listen ws:0.0.0.0), y no (-listen wss:0.0.0.0).<\/p>\n
\"Domain
\n
\nPara cambiar al modo de cifrado completo, es necesario seleccionar Completo<\/b>, o Completo (estricto)<\/b> en caso de que exista un certificado v\u00e1lido en el servidor. Despu\u00e9s de cambiar el modo, podremos aceptar conexiones de CloudFlare a trav\u00e9s del protocolo https. No olvide generar un certificado autofirmado para la parte del servidor del t\u00fanel.<\/p>\n
\"Domain
\n
\nUn lector curioso podr\u00eda preguntar: \"\u00bfY qu\u00e9 pasa con el cliente para Windows? Sin duda, el uso principal del t\u00fanel es establecer una conexi\u00f3n inversa desde m\u00e1quinas y servidores corporativos, y all\u00ed, por lo general, siempre es Windows. \u00bfC\u00f3mo compilo el t\u00fanel para Windows, adem\u00e1s con una pila TLS espec\u00edfica?\" Ahora vamos a presentar otra caracter\u00edstica que muestra lo conveniente que es Go. Compilamos para Windows directamente desde Kali, simplemente a\u00f1adiendo el par\u00e1metro 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 versi\u00f3n 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\u00a1Listo! Y no hay m\u00e1s complicaciones. \u00a1Esto realmente funciona! <\/p>\n
\"Domain
\n
\nLas flags del compilador \u2013w y \u2013s se utilizan para eliminar la basura innecesaria del archivo ejecutable, haci\u00e9ndolo un par de megabytes m\u00e1s peque\u00f1o. Adem\u00e1s, se puede empaquetar despu\u00e9s con UPX para reducir a\u00fan m\u00e1s el tama\u00f1o.<\/p>\n
En conclusi\u00f3n<\/h3>\n
\nEn este art\u00edculo, con el ejemplo del t\u00fanel escrito en Go, hemos demostrado claramente la aplicaci\u00f3n de la nueva tecnolog\u00eda de fronting de dominio, implementada en una caracter\u00edstica interesante del protocolo TLS 1.3. De manera similar, se puede adaptar la herramienta existente escrita en Go para trabajar a trav\u00e9s de servidores de CloudFlare, por ejemplo, Merlin<\/a><\/noindex> \u2014 conocido C2, o forzar a CobaltStrike Beacon a utilizar el fronting de dominio eSNI al trabajar con el Teamserver a trav\u00e9s de Canal C2 Externo<\/a><\/noindex>, implementado en Go, o en el est\u00e1ndar C++ utilizando una versi\u00f3n parcheada de OpenSSL, de la que hablamos en la parte anterior del art\u00edculo. En general, la imaginaci\u00f3n no tiene l\u00edmites.<\/p>\n
El ejemplo con el t\u00fanel y CloudFlare se presenta como un concepto y por ahora es dif\u00edcil decir sobre las perspectivas a largo plazo de este tipo de fronting de dominio. En este momento, el soporte para eSNI solo se ha implementado en CloudFlare y, en teor\u00eda, nada les impide desactivar este tipo de fronting y, por ejemplo, romper las conexiones tls si SNI y eSNI no coinciden. En general, el futuro lo dir\u00e1. Pero por ahora, la perspectiva de operar bajo \"el disfraz de kremlin.ru\" parece bastante atractiva. \u00bfNo es as\u00ed?<\/p>\n
El c\u00f3digo actualizado del t\u00fanel, as\u00ed como los archivos ejecutables compilados en formato exe, est\u00e1n disponibles en una rama separada del proyecto en github<\/a><\/noindex>. Para cualquier problema que surja con el t\u00fanel, es mejor reportar un issue en la p\u00e1gina del proyecto en GitHub.
\n
Fuente: 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\udd47Fronting de dominios basado en TLS 1.3. Parte 2 | ProHoster","description":"Introducci\u00f3n En la primera parte del art\u00edculo, proporcionamos una breve descripci\u00f3n del mecanismo encrypted SNI (eSNI).","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/53317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=53317"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/53317\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=53317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=53317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=53317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}