ES2971623T3 - Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación - Google Patents
Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación Download PDFInfo
- Publication number
- ES2971623T3 ES2971623T3 ES19202773T ES19202773T ES2971623T3 ES 2971623 T3 ES2971623 T3 ES 2971623T3 ES 19202773 T ES19202773 T ES 19202773T ES 19202773 T ES19202773 T ES 19202773T ES 2971623 T3 ES2971623 T3 ES 2971623T3
- Authority
- ES
- Spain
- Prior art keywords
- validation
- resource
- agent
- group
- agents
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000010200 validation analysis Methods 0.000 title claims abstract description 119
- 238000000034 method Methods 0.000 title claims abstract description 55
- 238000004891 communication Methods 0.000 claims description 36
- 238000011156 evaluation Methods 0.000 claims description 4
- 238000004590 computer program Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 description 9
- 230000004044 response Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 7
- 230000001010 compromised effect Effects 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000015654 memory Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Un método para validar la propiedad de un recurso (208), concretamente un nombre de dominio, dentro de una red, que comprende seleccionar (102) un grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) de manera que las rutas de red (212a) , 212b, 212c) entre un agente de validación del grupo (214) y entidades de un grupo de una o más entidades asociadas al recurso (208) no se cruzan. El método comprende además transmitir (104) una propiedad del recurso (208) a validar y un indicador de dirección para el recurso (208) desde un agente coordinador (210) al grupo (214) de agentes de validación (204a, 204b, 204d). Además, el método comprende consultar (106) la propiedad del recurso (208) de las entidades utilizando los agentes de validación (204a, 204b, 204d) del grupo (214) para determinar las propiedades consultadas; y evaluar (108) las propiedades consultadas para validar la propiedad del recurso (208). (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación
Campo
Los ejemplos se refieren a métodos para validar la propiedad de un recurso dentro de una red, así como a agentes de validación y un agente coordinador para llevar a cabo el método.
Antecedentes
A menudo existe la necesidad de evaluar la propiedad de un recurso dentro de una red. Por ejemplo, las Autoridades de Certificación (CA) a menudo requieren evaluar si un usuario que solicita un certificado (por ejemplo, al enviar una Solicitud de Firma de Certificado, CSR) es el legítimo propietario del dominio para el cual se emitirá el certificado. Esta evaluación se realiza a menudo mediante la Validación de Dominio (DV), que asume que solo el propietario legítimo del dominio es capaz de crear registros específicos dentro de los Servicios de Nombre de Dominio (DNS) del dominio o solo el propietario legítimo tiene la capacidad de crear archivos dentro del sistema de archivos o directorio accesible a través del dominio. Si bien pueden existir diferentes métodos de DV, como, por ejemplo, DV basado en correo electrónico, DV basado en WHOIS, DV basado en DNS o DV basado en HTTP/S, todos ellos dependen del DNS para validar el dominio. En la medida en que DNS es vulnerable a ataques maliciosos, también DV es vulnerable y puede existir la posibilidad de oscurecer la validación de dominio de manera que los atacantes, que no sean los propietarios legítimos del dominio, puedan recibir un certificado para el dominio. Por ejemplo, las respuestas de los Servidores de Nombres de Dominio del dominio pueden ser atacadas para que los resolutores DNS de la CA reciban una dirección IP incorrecta y así realizar la validación utilizando una dirección IP bajo el control de un atacante en lugar de utilizar una dirección IP del legítimo propietario del dominio. De manera similar, un ataque de Hombre en el Medio, donde un atacante controla un nodo en la ruta de red entre la CA y las entidades del Dominio (o incluso toda la red en la que se aloja la CA o el Dominio), puede resultar en una validación comprometida del dominio o recurso.
Los autores Henry Birge-Lee y otros de: "Bambooziing Certificate Authorities with BGP", Actas del 27° Simposio de Seguridad USENIX, 17 de agosto de 2018 (17-08-2018), páginas 833-849, proponen realizar la validación de dominio utilizando múltiples puntos de vista.
Asimismo, el autor de "Validating challenges from multiple network vantage Points", Comunidad de Soporte Let's Encrypt, 25 de agosto de 2017 (25-08-2017), páginas 1-1, publicado en Internet: URL: https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955 propone realizar la validación de dominio utilizando múltiples puntos de vista de red.
Por lo tanto, puede haber una demanda para aumentar la seguridad de los métodos para validar la propiedad de un recurso dentro de una red. Dicho objeto se logra mediante los métodos y aparatos de las reivindicaciones independientes.
Resumen
La presente invención se caracteriza por el objeto de las reivindicaciones independientes. Las modalidades preferidas están definidas por las reivindicaciones dependientes.
Breve descripción de las Figuras
Se describirán algunos ejemplos de aparatos y/o métodos a continuación, únicamente a modo de ejemplo, y con referencia a las figuras adjuntas, en las cuales
La Figura 1 muestra un diagrama de flujo de un método de la invención para validar la propiedad de un recurso en una red;
La Figura 2 ilustra un ejemplo de una red que comprende múltiples redes de operadores y agentes de validación; La Figura 3 ilustra un ejemplo del sistema para validar la propiedad de un recurso dentro de una red, el sistema que comprende un agente coordinador y al menos dos agentes de validación; y
La Figura 4 muestra otro ejemplo de un método para validar la propiedad de un recurso dentro de la red.
Descripción Detallada
Ahora se describirán más detalladamente varios ejemplos con referencia a las figuras adjuntas en las cuales se ilustran algunos ejemplos. En las figuras, los espesores de las líneas, capas y/o regiones pueden estar exagerados para mayor claridad.
Por lo tanto, si bien existen ejemplos adicionales que pueden sufrir diversas modificaciones y adoptar formas alternativas, algunos ejemplos particulares se muestran en las figuras y posteriormente se describirán en detalle. Sin embargo, esta descripción detallada no limita otros ejemplos a las formas particulares descritas. Otros ejemplos pueden abarcar todas las modificaciones, equivalentes y alternativas que se encuentren dentro del alcance de la descripción. Los mismos o números similares se refieren a elementos similares o iguales en toda la descripción de las figuras, los cuales pueden ser implementados de manera idéntica o en forma modificada al compararse entre sí, al mismo tiempo que proporcionan la misma o una funcionalidad similar.
Se entenderá que cuando se hace referencia a un elemento como "conectado" o "acoplado" a otro elemento, los elementos pueden estar conectados o acoplados directamente o a través de uno o más elementos intermedios. Si dos elementos A y B se combinan utilizando un "o", esto se entenderá como que describe todas las posibles combinaciones, es decir, solo A, solo B, así como A y B, a menos que se defina explícita o implícitamente lo contrario. Una formulación alternativa para las mismas combinaciones es "al menos uno de A y B" o "A y/o B". Lo mismo se aplica, mutatis mutandis, para combinaciones de más de dos elementos.
La terminología utilizada en el presente documento con el fin de describir ejemplos particulares no pretende limitar futuros ejemplos. Cuando se utiliza una forma singular como "un", "una" y "el/la" y no se define explícita o implícitamente que el uso de un solo elemento sea obligatorio, se pueden utilizar ejemplos adicionales con elementos en plural para implementar la misma funcionalidad. Asimismo, cuando se describe posteriormente una funcionalidad como implementada utilizando múltiples elementos, otros ejemplos pueden implementar la misma funcionalidad utilizando un solo elemento o entidad de procesamiento. Se entenderá además que los términos "comprende", "que comprende", "incluye" y/o "que incluye", cuando se utilizan, especifican la presencia de las características, enteros, pasos, operaciones, procesos, actos, elementos y/o componentes indicados, pero no excluyen la presencia o adición de una o más características, enteros, pasos, operaciones, procesos, actos, elementos, componentes y/o cualquier grupo de los mismos.
A menos que se defina lo contrario, todos los términos (incluyendo términos técnicos y científicos) se utilizan en la presente descripción en su significado ordinario en el campo al que pertenecen los ejemplos.
Los ejemplos siguientes describirán principalmente la validación de la propiedad de un dominio en Internet como un ejemplo particular de un recurso dentro de una red. Sin embargo, otras implementaciones adicionales también pueden servir para validar la propiedad de otros recursos dentro de una red, como por ejemplo dentro de Internet. La Internet es solo un ejemplo de una red que comprende recursos individuales, como nodos de red individuales, que pueden ser accedidos por diferentes protocolos de comunicación de datos, como por ejemplo el Protocolo de Internet. El enrutamiento dentro de Internet puede realizarse en función de la dirección de Protocolo de Internet de un recurso individual. Como alias de la dirección del protocolo de Internet, se pueden utilizar nombres, que generalmente se traducen en direcciones IP (resueltas) mediante servicios de nombres accesibles dentro de la red. Una red puede, al igual que Internet, dividirse en múltiples redes de operadores diferentes que son operadas por entidades legales distintas. Las redes de operadores tienen interfaces entre sí. Las rutas de red pueden conectar una red de operador con una o más redes de operadores adicionales. Una red de operadores puede ser, por ejemplo, una red que comprende un bloque de direcciones IP asignadas a una entidad legal (o gobiernos u entidades similares) que tiene el derecho de utilizar el bloque de direcciones IP y establecer una red física utilizando las direcciones IP. En otras palabras, Internet global puede estar constituido por múltiples redes de operadores diferentes que se interconectan con otras redes de operadores para permitir establecer rutas de red desde un dispositivo en la red de un primer operador hasta otro dispositivo en la red de un segundo operador.
La Figura 1 muestra un diagrama de flujo de un método de la invención para validar la propiedad de un recurso en una red. Dado que el método opera dentro de una red de entidades distribuidas, se describe el ejemplo del método ilustrado en la figura 1 junto con la figura 2, que ilustra un ejemplo para una red.
El método comprende seleccionar 102 un grupo de al menos dos agentes de validación de manera que las rutas de red entre un agente de validación del grupo y las entidades de un grupo de una o más entidades asociadas al recurso no se intersequen. Como se muestra en la figura 2, la red 200 puede comprender múltiples redes de operadores diferentes 202a a 202m. Varios agentes de validación pueden distribuirse arbitrariamente entre las redes de operadores. En el ejemplo particular ilustrado en la figura 2, se asume que los agentes disponibles 204a a 204e están presentes dentro de las redes de operadores 202a a 202e, respectivamente. Un agente disponible puede ser implementado como un componente de software que se ejecuta en un ordenador o en una entidad de procesamiento dentro de una red de operadores. Asimismo, un agente disponible también puede ser implementado como una entidad de hardware diseñada para realizar las funciones de un agente de validación como se describe a continuación. Un agente de validación es un agente disponible que ha sido seleccionado utilizando el criterio de la invención de que las rutas de red entre un agente de validación del grupo de agentes de validación y las entidades de un grupo de una o más entidades asociadas al recurso no se intersecan. El agente de validación tiene la capacidad de establecer una ruta de red hacia una entidad para ser consultada acerca de una propiedad de un recurso dentro de la red y de consultar la propiedad una vez que se haya establecido la ruta de red. La Figura 2 ilustra una aplicación en la que se debe validar la propiedad de un dominio, por ejemplo, consultando un registro CNAME de los servidores de nombres dentro del dominio. En el ejemplo de la figura 2, una autoridad de certificación (CA) 206 con el dominio CA.com debe verificar la propiedad del dominio víctima de un cliente 208. Con este fin, los agentes de validación seleccionados deben consultar los servidores de nombres dentro del dominio víctima para obtener el registro CNAME.
Dentro de la red del CA, se utiliza un agente coordinador 210 para coordinar el uso del grupo 214 de agentes de validación 204a, 204b y 204c seleccionados del grupo de agentes disponibles 204a a 204e, de manera que las rutas de red entre un agente de validación 204a, 204b y 204c del grupo 214 y las entidades de un grupo de una o más entidades asociadas al recurso no se intersequen. Suponiendo, por razones de simplificación, que hay un único servidor de nombres de dominio presente dentro del dominio 200a, las rutas de red 212a, 212b y 212c cumplen con este criterio, lo que lleva a la selección de los agentes de validación 204a, 204b y 204c del grupo 214.
Para permitir que los agentes de validación 204a, 204b y 204c del grupo 214 consulten la propiedad del recurso y establezcan rutas de red hacia entidades asociadas con el recurso, el método de la figura 1 además comprende transmitir 104 una propiedad del recurso a validar y un indicador de dirección para el recurso desde un agente coordinador al grupo de agentes de validación.
El método además comprende consultar 106 la propiedad del recurso 208 desde al menos una entidad utilizando los agentes de validación 204a, 204b y 204c del grupo 214 para determinar las propiedades consultadas.
Además, el método comprende evaluar 108 las propiedades consultadas para validar la propiedad del recurso. Seleccionar los agentes de validación de manera que las rutas de red entre los agentes de validación del grupo y las entidades desde las cuales se consulta la propiedad del recurso no se intersequen puede asegurar que incluso si un salto o nodo a lo largo de una sola ruta de red es comprometido, los agentes de validación restantes recibirán resultados válidos de sus consultas. Por ejemplo, la figura 2 asume que la red del operador 202k está bajo el control de un atacante malicioso que puede corromper la consulta, por ejemplo, dirigiendo la consulta a otra red que no sea la del legítimo propietario del dominio 208. Mientras que la ruta de red 212a está comprometida, las rutas de red 212b y 212c no están comprometidas, de manera que los agentes de validación 204b y 204d reciben resultados no corrompidos de la consulta, lo que lleva a una validación confiable de la propiedad para el dominio 208.
Si bien se puede requerir un número mínimo de al menos dos agentes de validación para ser sensibles a un atacante malicioso, el número de agentes de validación dentro del grupo puede ser elegido arbitrariamente y, por ejemplo, coordinado por el agente coordinador 210. Dependiendo de la topología de la red, ya puede ser suficiente un número de tres agentes de validación adecuadamente seleccionados para alcanzar una fiabilidad de validación superior al 90 %. Otras implementaciones, sin embargo, también pueden utilizar números más altos, como por ejemplo cuatro, cinco, seis, siete u ocho agentes de validación.
Según ejemplos adicionales del método, el grupo de agentes de validación se selecciona además de manera que al menos dos agentes de validación se localicen en diferentes redes de operadores. Un ejemplo de dicha implementación ya se ilustra en la figura 2. Una selección de los agentes de validación de esta manera puede asegurar que incluso un atacante a gran escala que pueda tener control sobre redes de operadores completas que alojen un agente de validación elegido (por ejemplo, la red de operadores 202e de la figura 2) no pueda oscurecer las consultas de todos los agentes de validación.
Según algunos ejemplos, se confirma la propiedad del recurso si una fracción predefinida de las propiedades consultadas corresponden o son iguales a una propiedad esperada. Si, por ejemplo, en el entorno de la figura 2, dos de cada tres agentes de validación obtienen la entrada CNAME que se espera que se cree en el servicio de nombres de dominio para el dominio 208 por su legítimo propietario, se puede concluir que la validación se ha realizado con éxito. Una evaluación previa de la topología de la red puede servir para asegurar que la probabilidad de que un único atacante pueda controlar saltos o redes de operadores a lo largo de más de una ruta sea insignificante. Si, por ejemplo, el propietario de un dominio crea la entrada CNAME "success" (que es la propiedad esperada) y dos de cada tres consultas CNAME resultan en la entrada "success", se puede asumir una validación exitosa.
Como ya se ha explicado anteriormente, según algunos ejemplos, la selección del grupo de al menos dos agentes de validación comprende transmitir un indicador de dirección para el recurso 208 desde el agente coordinador 210 a un grupo de agentes disponibles 204a a 204e y utilizar el indicador de dirección para determinar un grupo de una o más entidades asociadas al recurso. Además, el método comprende transmitir las rutas de red entre los agentes disponibles 204a a 204e del grupo y las entidades asociadas al recurso 208 al agente coordinador 210. Incluso en el caso de una única entidad, el número de rutas de red transmitidas por cada agente disponible puede ser mayor que uno debido a la posibilidad de que el enrutamiento dinámico dentro de la red proporcione diferentes rutas de red en diferentes intentos de acceder a la única entidad. Otros ejemplos pueden estar limitados a un único intento de acceso a una entidad por agente disponible, lo que resulta en una única ruta de red transmitida para cada agente disponible 204a a 204e. Sin embargo, si hay más de una entidad asociada al recurso, lo cual es normalmente el caso en servidores de nombres (un dominio típicamente utiliza más de un servidor de nombres para la resolución DNS), múltiples rutas de red pueden ser transmitidas para cada agente disponible que establece rutas de red hacia diferentes entidades.
El proceso de selección se finaliza seleccionando el grupo de al menos dos agentes de validación en el agente coordinador basado en las rutas de red, de manera que los agentes de validación resultantes cumplan con el requisito de que las rutas de red entre los agentes de validación del grupo y las entidades desde las cuales se consulta la propiedad del recurso no se intersequen.
Según algunos ejemplos, una comunicación entre el agente coordinador y los agentes de validación se encuentra cifrada para mejorar la seguridad, por ejemplo, mediante HTTPS.
Mientras que la figura 2 ilustra un dominio como un ejemplo particular para un recurso, otros ejemplos pueden validar otros recursos, como por ejemplo una dirección IP, un servidor de correo electrónico o un dispositivo.
La figura 3 ilustra un ejemplo de un sistema para validar la propiedad de un recurso dentro de una red, el sistema que comprende un agente coordinador 310 y al menos dos agentes de validación 320 y 330. Como se muestra en la figura 2, el sistema de la figura 3 utiliza la validación de dominio como un ejemplo particular para la validación de la propiedad de un recurso dentro de la red.
El agente coordinador 310 comprende una primera interfaz de comunicación 312 para un servicio de validación, la primera interfaz de comunicación 312 está configurada para recibir información sobre un recurso 345 dentro de una red y una propiedad del recurso 345 a ser consultada. El agente coordinador 310 además comprende una segunda interfaz de comunicación 314 para agentes de validación, la segunda interfaz de comunicación está configurada 314 para transmitir un indicador de dirección para el recurso 345 a un grupo de agentes disponibles 320, 330 y 340, y para recibir rutas de red entre los agentes disponibles 320, 330 y 340 y entidades 354 de un grupo de una o más entidades asociadas al recurso 345. En caso de validación de dominio, el indicador de dirección puede ser el nombre de dominio principal y la propiedad puede ser la entrada de un registro CNAME, por ejemplo. La primera interfaz de comunicación 312 está configurada para recibir la información utilizada para la validación desde el servicio de validación 316. En el ejemplo de la figura 3, se asume que una autoridad de certificación es el servicio de validación 316, que puede, por ejemplo, emitir una solicitud de validación al recibir una solicitud de un propietario 352 de un dominio para firmar un certificado para el dominio (Solicitud de Firma de Certificado 318).
Para seleccionar los agentes de validación de acuerdo con los criterios previamente discutidos, el agente coordinador 310 además comprende circuitos de selección configurados para seleccionar un grupo de al menos dos agentes de validación del grupo de agentes disponibles en base a las rutas de red recibidas.
La segunda interfaz de comunicación 314 está configurada además para transmitir la propiedad del recurso 345 a los agentes de validación y recibir propiedades consultadas de los agentes de validación una vez que se haya establecido el grupo de agentes de validación.
El circuito de evaluación dentro del agente coordinador 310 está configurado para concluir sobre la validación exitosa del recurso si una fracción predeterminada de las propiedades consultadas corresponde a una propiedad esperada, por ejemplo, al contenido esperado de un registro CNAME del servidor DNS.
Para enviar el resultado de la validación al servicio de validación solicitante 316, la primera interfaz de comunicación 312 está configurada además para indicar la validación exitosa o no exitosa al servicio de validación 316. Tanto el agente coordinador como los agentes de validación pueden ser implementados en hardware o en software.
Como se ilustra además en la figura 3, un agente de validación 320 comprende una primera interfaz de comunicación 322 para un agente coordinador, la primera interfaz de comunicación 322 está configurada para recibir el indicador de dirección para el recurso 345 en la red y la propiedad del recurso que debe ser consultada por el agente de validación 320. Una segunda interfaz de comunicación 324 está configurada para establecer una ruta de red hacia entidades 354 de un grupo de una o más entidades asociadas al recurso 345. Para poder proporcionar un criterio de selección al agente coordinador 310, la primera interfaz de comunicación 322 está configurada además para transmitir rutas de red al agente coordinador 310. Las rutas de la red pueden, por ejemplo, ser determinadas por el agente de validación 320 utilizando trazarrutas o herramientas o métodos similares. Asimismo, el agente coordinador 310 puede ser capaz de detectar en qué red de operador se encuentra para transmitir la información al agente coordinador 310 como un criterio adicional de selección. Alternativamente, el agente coordinador 310 puede ser capaz de determinar en qué red de operadores se encuentra un agente disponible, por ejemplo, mediante su dirección IP.
La segunda interfaz de comunicación también puede estar configurada para consultar la propiedad del recurso 345 desde una entidad 354 del grupo para determinar una propiedad consultada una vez que el agente de validación ha sido seleccionado para la consulta por el agente coordinador 310. Asimismo, la primera interfaz de comunicación 322 puede estar configurada además para enviar la propiedad consultada al agente coordinador 314. Para aumentar aún más la seguridad, la comunicación entre el agente coordinador 310 y el agente de validación 320 puede estar encriptada, es decir, la segunda interfaz de comunicación 314 del agente coordinador 310 y la primera interfaz de comunicación 322 del agente de validación 320 pueden intercambiar mensajes encriptados, por ejemplo, mediante HTTPS. En caso de validación de dominio, por ejemplo, la comunicación en la segunda interfaz de comunicación 324 del agente de validación 320 puede ser sin cifrar, sin embargo, dado que la comunicación con los servidores de nombres de dominio puede requerir que sea sin cifrar.
La Figura 4 ilustra otro ejemplo de un método para validar la propiedad de un recurso que puede, por ejemplo, llevarse a cabo dentro de un agente coordinador 310.
El método comprende seleccionar 410 un grupo de al menos dos agentes de validación de manera que las rutas de red entre un agente de validación del grupo y las entidades de un grupo de una o más entidades asociadas con el recurso no se intersequen. Además, el método comprende transmitir 420 una propiedad del recurso a consultar a los agentes de validación.
El método además comprende recibir 430 propiedades consultadas de los agentes de validación; y validar 440 la propiedad del recurso en base a las propiedades consultadas de acuerdo a, por ejemplo, los criterios elaborados anteriormente.
Mientras que consultar las entradas CNAME de un dominio ha sido predominantemente utilizado como un ejemplo de una propiedad consultada durante la validación de dominio, también se pueden consultar otras propiedades en implementaciones posteriores, ya que existen varios métodos para realizar la validación de dominio DV.
- DV basado en correo electrónico. Al completar un CSR, se emite un correo electrónico al contacto administrativo del dominio seleccionado por el solicitante de entre las direcciones de correo electrónico registradas para ese dominio en Whois. El correo electrónico típicamente contiene un código de validación y un enlace, que el destinatario debe hacer clic e ingresar el código para demostrar el control sobre el dominio. Si se ingresa el código correcto, el proceso continúa con la emisión del certificado.
- DV basado en WHOIS. Similar al DV basado en correo electrónico, excepto que el cliente no puede seleccionar qué correo electrónico (de entre los registrados como administrativos para el dominio) se utilizará en la validación. Durante el procedimiento de DV, el CA selecciona por sí mismo la dirección de correo electrónico y puede utilizar cualquier dirección de correo electrónico de contacto de Administrador, Registrante, Técnico o Zona que aparezca en el registro WHOIS del dominio.}
- DV basado en DNS. Al enviar un CSR, se proporciona un valor hash que debe ingresarse como un Registro de Recurso (RR) CNAME de DNS para el dominio en el archivo de zona. Por ejemplo, supongamos que el dominio del solicitante es vict.im y el dominio de las CA es ca-domain.com. Un registro CNAME puede ser hash1.www.vict.im. El CNAME hash2.ca-domain.com. El resolver DNS de la CA consulta el dominio del solicitante y verifica la presencia del registro CNAME. Si el registro correcto está presente, la CA procede a emitir el certificado solicitado.
- DV basado en HTTP/S. Tras la presentación de un CSR, se devuelve al cliente un valor hash. Se debe crear un archivo y colocarlo en la raíz del servidor web con el valor hash como nombre, de la siguiente manera: http://www.vict.im/hash-value1.txt. El contenido del archivo debe contener hash-value2 y el dominio cadomain.com. El CA realiza una solicitud HTTP/HTTPS para recuperar el archivo. Si es correcto, la CA procede a emitir el certificado.
En resumen, los ejemplos descritos en la presente descripción pueden preservar los beneficios de DV al mismo tiempo que proporcionan resistencia contra atacantes de MitM. Por lo tanto, los ejemplos de la presente descripción también pueden ser referidos como DV++. La integración de los nuevos ejemplos en los sistemas convencionales no requiere ningún cambio en la infraestructura y funcionalidad de la CA, por lo que el uso de ejemplos por parte de una CA resulta de bajo costo y esfuerzo. Un aspecto de los ejemplos es utilizar nodos distribuidos (agentes de validación) que realizan DV desde múltiples puntos de vista. La seguridad contra los atacantes MitM se logra colocando los nodos en diferentes redes, que no atraviesan rutas superpuestas.
A diferencia de un atacante de escucha criptográfica, que es un espía global, un atacante realista de MitM puede estar presente solo en algunas redes (del operador) pero no controla todo Internet. El atacante puede ser un ISP malicioso, que recopila de forma pasiva el tráfico que atraviesa sus redes de operadores. Un atacante también puede intentar activamente atraer tráfico de otras redes mediante la realización de secuestro de prefijos BGP. Los ejemplos descritos en este documento (DV++) proporcionan un mecanismo descentralizado, que puede utilizar la infraestructura existente de Internet para validar las reclamaciones de propiedad de dominio. A diferencia de la validación centralizada realizada por las Autoridades de Certificación (CA) con el DV convencional, el DV++ se basa en una jerarquía plana con varios agentes de certificación igualmente confiables. Para pasar una validación, los propietarios de dominios deben demostrar su propiedad a la mayoría de los agentes, por ejemplo, de manera completamente automatizada, respondiendo a las consultas enviadas por los agentes de validación para los registros de recursos en el dominio. Los agentes de validación están sincronizados con un agente coordinador, que también se conoce como módulo orquestador. El orquestador puede estar ubicado en la red de CA. El orquestador y los agentes pueden utilizar HTTPS para su comunicación mutua. Durante el proceso de validación de dominio, todos los agentes reciben del orquestador el dominio y el registro que deben consultar. Los agentes envían solicitudes DNS a los servidores de nombres en el dominio solicitando el registro. Tan pronto como llega la respuesta, el agente envía la respuesta al orquestador. Si, por ejemplo, más del 50 % de las respuestas llegan y coinciden, el orquestador devuelve éxito, de lo contrario, devuelve fracaso. El número de respuestas correctas de los agentes es un parámetro que el CA puede configurar.
Al enviar una solicitud DNS, cada agente selecciona de forma independiente un puerto de origen al azar, así como un TXID aleatorio. Para llevar a cabo un ataque exitoso, el atacante tiene que falsificar respuestas correctas a más del 50 % de los agentes. Esta es una tarea imposible incluso para atacantes fuertes de estados nacionales. Los agentes pueden configurarse en diferentes redes de disponibilidad física de la nube de AWS. La selección de las redes en la nube se realiza de manera que los agentes se localicen ubicados en diferentes redes, cuyas rutas no se intersequen. Para seleccionar las redes donde colocar los agentes, se puede utilizar un gráfico de nivel AS de CAIDA derivado empíricamente del año 2016. Similar a DV, la autenticación DV++ es iniciada por la CA después de recibir una solicitud de CSR por parte del solicitante. Durante este proceso, se envían consultas a los agentes, que realizan búsquedas en el dominio objetivo. Una vez que el orquestador recibe la mayoría de las respuestas, estas son procesadas.
Aunque el atacante pueda corromper algunos agentes, controlar algunas redes o rutas, no puede controlar todos los caminos y todas las redes en Internet ni corromper a todos los agentes. Por ejemplo, incluso los atacantes de naciones fuertes, como las agencias de seguridad, no controlan todas las redes y rutas de Internet.
Si se considera a un atacante que intenta pasar la autenticación de DV++ para emitir un certificado fraudulento. Para tener éxito, el atacante debe proporcionar respuestas falsificadas correctas para la mayoría de las solicitudes DNS emitidas por los agentes DV++.
Si el atacante se localiza en una red del servidor de nombres de la víctima, puede secuestrar las solicitudes en la red del servidor de nombres y enviar respuestas falsificadas a los agentes de DV++. Afortunadamente, los dominios tienen más de un servidor de nombres y los servidores de nombres se encuentran en diferentes redes; esto sigue las mejores prácticas para evitar un único punto de fallo para los dominios. Las mediciones de 1 millón de dominios principales de Alexa muestran que el número promedio de servidores de nombres por dominio es 5, y el mínimo es 2. Además, los servidores de nombres pertenecientes al mismo dominio están alojados en diferentes redes. Esto asegura que el atacante no pueda secuestrar y reemplazar las respuestas de todos los servidores de nombres.
Considerando un atacante pasivo MitM, que controla un ISP grande, y un atacante activo, que además intenta atraer tráfico de otras redes, se demuestra la robustez de la validación tal como se describe en la presente descripción. Utilizando un número diferente de agentes, se puede demostrar que incluso con 3 agentes en redes de proveedores de servicios de Internet de primer nivel, se garantiza una fuerte seguridad contra atacantes de MitM.
Además de los casos de uso presentados anteriormente, se pueden utilizar otros ejemplos de la descripción contenida en la presente descripción (DV++) para iniciar otros mecanismos con seguridad. Por ejemplo, los ataques pueden aplicarse contra los procedimientos de recuperación de contraseñas en servicios web populares. En el procedimiento de recuperación de contraseña, la contraseña o un enlace para restablecer la contraseña se envía de vuelta al correo electrónico que inició la recuperación de contraseña. Si el resolutor DNS en la red del servicio es atacado y almacena en caché un registro incorrecto (asociando el correo electrónico de la víctima a una dirección IP controlada por un atacante), la contraseña sería enviada al atacante. DV++ puede ser utilizado por los servicios web para validar el registro DNS del correo electrónico que solicita la recuperación de contraseña, bloqueando así las solicitudes maliciosas que no pasen la verificación de DV++.
Ejemplos pueden además ser o estar relacionados con un programa informático que tiene un código de programa para llevar a cabo uno o más de los métodos anteriores, cuando el programa informático se ejecuta en un ordenador o procesador. Los pasos, operaciones o procesos de los diversos métodos descritos anteriormente pueden ser realizados por ordenadores o procesadores programados. Los ejemplos también pueden incluir dispositivos de almacenamiento de programas, como medios de almacenamiento de datos digitales, que son legibles por máquinas, procesadores u ordenadores y codifican programas de instrucciones ejecutables por máquinas, procesadores u ordenadores. Las instrucciones realizan o causan la realización de algunos o todos los actos de los métodos descritos anteriormente. Los dispositivos de almacenamiento del programa pueden comprender o ser, por ejemplo, memorias digitales, medios de almacenamiento magnéticos como discos magnéticos y cintas magnéticas, discos duros o medios de almacenamiento de datos digitales legibles ópticamente. Además, otros ejemplos pueden incluir ordenadores, procesadores o unidades de control programadas para realizar las acciones de los métodos descritos anteriormente o matrices lógicas programables (FPLA) o arreglos de compuertas programables (FPGA), programados para realizar las acciones de los métodos descritos anteriormente.
La descripción y los dibujos simplemente ilustran los principios de la divulgación. Además, todos los ejemplos mencionados en la presente descripción están principalmente destinados expresamente a ser solo con fines ilustrativos para ayudar al lector a comprender los principios de la descripción y los conceptos aportados por el(los) inventor(es) para avanzar en la técnica. Todas las declaraciones en la presente descripción que mencionan principios, aspectos y ejemplos de la descripción, así como ejemplos específicos de los mismos, tienen la intención de abarcar sus equivalentes.
Funciones de varios elementos mostrados en las figuras, incluyendo cualquier bloque funcional etiquetado como "medios", "medios para proporcionar una señal", "medios para generar una señal", etc., pueden ser implementadas en forma de hardware dedicado, como "un proveedor de señal", "una unidad de procesamiento de señal", "un procesador", "un controlador", etc., así como hardware capaz de ejecutar software en asociación con el software adecuado. Cuando son proporcionadas por un procesador, las funciones pueden ser proporcionadas por un único procesador dedicado, por un único procesador compartido o por una pluralidad de procesadores individuales, algunos de los cuales o todos ellos pueden ser compartidos. Sin embargo, el término "procesador" o "controlador" no se limita exclusivamente al hardware capaz de ejecutar software, sino que puede incluir hardware de procesador de señal digital (DSP), procesador de red, circuito integrado de aplicación específica (ASIC), matriz de compuertas programable en campo (FPGA), memoria de solo lectura (ROM) para almacenar software, memoria de acceso aleatorio (RAM) y almacenamiento no volátil. Otros componentes hardware, convencionales y/o personalizados, también pueden ser incluidos.
Un diagrama de bloques puede, por ejemplo, ilustrar un diagrama de circuito de alto nivel que implementa los principios de la descripción. De manera similar, un diagrama de flujo, un diagrama de flujo, un diagrama de transición de estados, un pseudocódigo y otros similares pueden representar varios procesos, operaciones o pasos, los cuales pueden, por ejemplo, estar sustancialmente representados en un medio legible por ordenador y ser ejecutados por un ordenador o procesador, ya sea que dicho ordenador o procesador se muestre explícitamente o no. Los métodos descritos en la especificación o en las reivindicaciones pueden ser implementados por un dispositivo que tenga medios para llevar a cabo cada uno de los actos respectivos de estos métodos.
Se entiende que la descripción de múltiples actos, procesos, operaciones, pasos o funciones revelados en la especificación o reivindicaciones no debe interpretarse como que se encuentran en un orden específico, a menos que se indique explícita o implícitamente lo contrario, por ejemplo, por razones técnicas. Por lo tanto, la descripción de múltiples actos o funciones no los limitará a un orden particular, a menos que dichos actos o funciones no sean intercambiables por razones técnicas. Además, en algunos ejemplos, un solo acto, función, proceso, operación o paso puede incluirse o puede dividirse en múltiples subactos, subfunciones, subprocesos, suboperaciones o subpasos, respectivamente. Tales subactos pueden estar incluidos y formar parte de la descripción de este único acto, a menos que se excluyan explícitamente.
Claims (13)
1. Un método para validar la propiedad de un recurso (208) dentro de una red, que comprende:
seleccionar (102) un grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) de manera que las rutas de red (212a, 212b, 212c) entre un agente de validación del grupo (214) y entidades de un grupo de una o más entidades a consultar sobre una propiedad del recurso (208) no se intersequen;
transmitir (104) una propiedad del recurso (208) a validar y un indicador de dirección para el recurso (208) desde un agente coordinador (210) al grupo (214) de agentes de validación (204a, 204b, 204d); consultar (106) la propiedad del recurso (208) de las entidades utilizando los agentes de validación (204a, 204b, 204d) del grupo (214) para determinar las propiedades consultadas; y
evaluar (108) las propiedades consultadas para validar la propiedad del recurso (208).
2. El método de reivindicación 1, en donde el grupo (214) de agentes de validación (204a, 204b, 204d) se selecciona además de manera que al menos dos agentes de validación (204a, 204b, 204d) se localicen en diferentes redes de operadores (202a, 202b, 202d).
3. El método de la reivindicación 1 o 2, en donde se confirma la propiedad del recurso (208) si una fracción predeterminada de las propiedades consultadas corresponde a una propiedad esperada.
4. El método de una de las reivindicaciones 1 a 3, en donde seleccionar el grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) comprende:
transmitir un indicador de dirección para el recurso (208) desde el agente coordinador (210) a un grupo de agentes disponibles (204a, 204b, 204c, 204d, 204e);
utilizar el indicador de dirección para determinar un grupo de una o más entidades sobre las cuales se consultará acerca de una propiedad del recurso (208);
transmitir rutas de red entre los agentes disponibles (204a, 204b, 204c, 204d, 204e) del grupo y las entidades de los agentes disponibles (204a, 204b, 204c, 204d, 204e) al agente coordinador (210); y
seleccionar el grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) en el agente coordinador (210) basado en las rutas de la red.
5. El método de una de las reivindicaciones anteriores, en donde la comunicación entre el agente coordinador (210) y los agentes de validación (204a, 204b, 204d) está cifrada.
6. El método de una de las reivindicaciones anteriores, en donde el recurso (208) es uno de un Dominio, un Servidor de Correo Electrónico y un dispositivo.
7. Un agente coordinador (310), que comprende:
una primera interfaz de comunicación (312) para un servicio de validación (316), la primera interfaz de comunicación (312) está configurada para recibir información sobre un recurso (345) dentro de una red y una propiedad del recurso (345);
una segunda interfaz de comunicación (314) para agentes de validación (320, 322), la segunda interfaz de comunicación (314) está configurada para transmitir un indicador de dirección para el recurso (345) a un grupo de agentes disponibles (320, 330, 340) y para recibir rutas de red entre los agentes disponibles y entidades de un grupo de una o más entidades a consultar sobre una propiedad del recurso (345); circuitos de selección configurados para seleccionar un grupo de al menos dos agentes de validación (320, 330) del grupo de agentes disponibles (320, 330, 340) en base a las rutas de red recibidas, de manera que las rutas de red entre un agente de validación del grupo y las entidades sobre las que se realizarán las consultas no se intersequen;
la segunda interfaz de comunicación (314) está configurada además para transmitir la propiedad del recurso (345) a los agentes de validación (320, 330) y para recibir propiedades consultadas de los agentes de validación (320, 330); y
circuitos de evaluación configurados para concluir sobre la validación exitosa del recurso (345) si una fracción predeterminada de las propiedades consultadas corresponde a una propiedad esperada.
8. El agente coordinador de la reivindicación 7, en donde la primera interfaz de comunicación (312) está configurada además para indicar la validación exitosa o no exitosa al servicio de validación (316).
9. Un agente de validación (320, 330), que comprende:
una primera interfaz de comunicación (322) para un agente coordinador, la primera interfaz de comunicación (322) está configurada para recibir un indicador de dirección para un recurso (345) en una red y una propiedad del recurso (345); y
una segunda interfaz de comunicación, la segunda interfaz de comunicación está configurada para establecer una ruta de red hacia entidades de un grupo de una o más entidades a consultar sobre una propiedad del recurso (345); en donde
la primera interfaz de comunicación (322) está configurada además para transmitir la ruta de red al agente coordinador,
en donde la segunda interfaz de comunicación está configurada además para consultar la propiedad del recurso (345) a una entidad del grupo para determinar una propiedad consultada; y en donde
la primera interfaz de comunicación (322) está configurada además para enviar la propiedad consultada al agente coordinador.
10. Un sistema para validar la propiedad de un recurso (345) dentro de una red, que comprende:
un agente coordinador (310) según una de las reivindicaciones 7 u 8;
un primer agente de validación (320) según la reivindicación 9;
un segundo agente de validación (330) según la reivindicación 9.
11. El sistema de la reivindicación 10, en donde el primer agente de validación (320) se localiza dentro de una primera red de operadores, y en donde el segundo agente de validación (330) se localiza dentro de una segunda red de operadores.
12. El sistema de la reivindicación 10 o 11, en donde el agente coordinador (310) se localiza dentro de la red de una Autoridad de Certificación.
13. Programa informático que tiene código de programa para, cuando se ejecuta por un procesador programable, realizar el método de una de las reivindicaciones 1 a 6.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP18200254 | 2018-10-12 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2971623T3 true ES2971623T3 (es) | 2024-06-06 |
Family
ID=63915180
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES19202773T Active ES2971623T3 (es) | 2018-10-12 | 2019-10-11 | Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación |
Country Status (3)
Country | Link |
---|---|
US (1) | US11700263B2 (es) |
EP (1) | EP3637739B1 (es) |
ES (1) | ES2971623T3 (es) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11571626B2 (en) | 2020-11-02 | 2023-02-07 | Microsoft Technology Licensing, Llc | Software ownership validation of optical discs using secondary device |
US11934393B2 (en) * | 2021-01-12 | 2024-03-19 | Sap Se | Input validation API using machine learning and database input validation framework |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1259882A1 (en) * | 2000-03-27 | 2002-11-27 | Network Security Systems, Inc. | Internet/network security method and system for checking security of a client from a remote facility |
US7457823B2 (en) * | 2004-05-02 | 2008-11-25 | Markmonitor Inc. | Methods and systems for analyzing data related to possible online fraud |
US9002923B2 (en) * | 2008-07-01 | 2015-04-07 | Thomson Licensing | Transparent web proxy |
EP2317733A1 (en) * | 2009-10-29 | 2011-05-04 | British Telecommunications public limited company | Communications system |
US8370902B2 (en) * | 2010-01-29 | 2013-02-05 | Microsoft Corporation | Rescuing trusted nodes from filtering of untrusted network entities |
US9300625B1 (en) * | 2013-01-02 | 2016-03-29 | Amazon Technologies, Inc. | Network address verification |
US9712381B1 (en) * | 2014-07-31 | 2017-07-18 | Google Inc. | Systems and methods for targeted probing to pinpoint failures in large scale networks |
US20170279681A1 (en) * | 2016-03-28 | 2017-09-28 | Facebook, Inc. | Methods and Systems for Distributed Testing of Network Configurations for Zero-Rating |
US9774626B1 (en) * | 2016-08-17 | 2017-09-26 | Wombat Security Technologies, Inc. | Method and system for assessing and classifying reported potentially malicious messages in a cybersecurity system |
US20190158276A1 (en) * | 2017-11-17 | 2019-05-23 | Simmonds Precision Products, Inc. | Encryption key exchange with compensation for radio-frequency interference |
US10608868B2 (en) * | 2017-11-29 | 2020-03-31 | International Business Machines Corporation | System and method for proactive distributed agent based network diagnosis |
-
2019
- 2019-10-11 EP EP19202773.8A patent/EP3637739B1/en active Active
- 2019-10-11 ES ES19202773T patent/ES2971623T3/es active Active
- 2019-10-11 US US16/599,218 patent/US11700263B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US11700263B2 (en) | 2023-07-11 |
US20200296109A1 (en) | 2020-09-17 |
EP3637739A1 (en) | 2020-04-15 |
EP3637739C0 (en) | 2023-12-06 |
EP3637739B1 (en) | 2023-12-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230035336A1 (en) | Systems and methods for mitigating and/or preventing distributed denial-of-service attacks | |
US20240129290A1 (en) | Authenticated name resolution | |
EP3844657B1 (en) | Distributed data authentication and validation using blockchain | |
Brandt et al. | Domain validation++ for mitm-resilient pki | |
US7930428B2 (en) | Verification of DNS accuracy in cache poisoning | |
Ahmed et al. | IPv6 neighbor discovery protocol specifications, threats and countermeasures: a survey | |
US10951577B2 (en) | Device and method for resolving domain names | |
Wachs et al. | A censorship-resistant, privacy-enhancing and fully decentralized name system | |
Ambrosin et al. | Security and privacy analysis of national science foundation future internet architectures | |
US9973590B2 (en) | User identity differentiated DNS resolution | |
US20180115520A1 (en) | Dark virtual private networks and secure services | |
Schmid | Thirty years of DNS insecurity: Current issues and perspectives | |
ES2971623T3 (es) | Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación | |
CN109067768B (zh) | 一种域名查询安全性的检测方法、系统、设备和介质 | |
Bates et al. | Forced perspectives: Evaluating an SSL trust enhancement at scale | |
Zou et al. | Survey on domain name system security | |
CN103747005B (zh) | Dns缓存投毒的防护方法和设备 | |
Scaife et al. | OnionDNS: A seizure-resistant top-level domain | |
Abdou et al. | Server location verification (SLV) and server location pinning: Augmenting TLS authentication | |
Grothoff et al. | NSA’s MORECOWBELL: knell for DNS | |
Rajendran et al. | Domain name system (dns) security: Attacks identification and protection methods | |
JP6763605B2 (ja) | データ通信システム、キャッシュdns装置及び通信攻撃防止方法 | |
CN118435556A (zh) | 在零信任访问模型中限制对受保护资源的发现 | |
Bator et al. | Security of the DNSSEC protocol and its impact on online privacy protection | |
ROSTAMPOUR | Deploying DNS Security Extensions |