Network security system to validate a server certificate

In one embodiment, a Domain Name Service (DNS) server pre-fetches domain information regarding a domain that includes certificate information for the domain. The DNS server receives a DNS request that includes a security request for the domain in metadata of a Network Service Header (NSH) of the DNS request. The DNS server retrieves the certificate information for the domain from the pre-fetched information regarding the domain, in response to receiving the security request. The DNS server sends, to a Transport Layer Security (TLS) proxy, a DNS response for the domain that includes the certificate information in metadata of an NSH of the DNS response.

TECHNICAL FIELD

The present disclosure relates generally to computer networks, and, more particularly, to a network security system to validate a server certificate.

BACKGROUND

Transport Layer Security (TLS) proxy functionality is a key security mechanism for many networks. In particular, a TLS proxy allows security systems such as firewalls and intrusion protection systems (IPSs) to inspect encrypted traffic between the enterprise network and the Internet. Notably, the TLS proxy may act as a “man in the middle” between a device in the enterprise network and the remote server, to obtain the cryptographic information needed to decrypt any encrypted traffic communicated between the device and the remote server, such as Hypertext Transfer Protocol Secure (HTTPS) traffic. In turn, the TLS proxy may intercept the encrypted traffic, decrypt the traffic using the obtained cryptographic information, and provide the decrypted traffic to the firewall, IPS, etc.

As part of its proxy functions, a TLS proxy validates the certificate of the remote server, to ensure that the device on the enterprise network is communicating with a trusted entity. This certificate validation generally involves checking whether the certificate contains the desired domain name of the remote server and whether the certificate was issued by a trusted certificate authority. Typically, a TLS proxy uses a default trust anchor list (e.g., a list of one or more entities that are already trusted by default), to validate the server certificate. However, this gives rise to several potential security vulnerabilities that could be exploited as part of a certificate validation attack: 1.) the TLS proxy has no way of knowing which trust anchor should vouch for the specific domain associated with the server certificate, and 2.) since any domain can be vetted by any certificate authority, all domains will be vulnerable to a man-in-the middle attack if a certificate authority becomes compromised.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

According to one or more embodiments of the disclosure, a Domain Name Service (DNS) server pre-fetches domain information regarding a domain that includes certificate information for the domain. The DNS server receives a DNS request that includes a security request for the domain in metadata of a Network Service Header (NSH) of the DNS request. The DNS server retrieves the certificate information for the domain from the pre-fetched information regarding the domain, in response to receiving the security request. The DNS server sends, to a Transport Layer Security (TLS) proxy, a DNS response for the domain that includes the certificate information in metadata of an NSH of the DNS response.

In further embodiments, a Transport Layer Security (TLS) proxy receives, from a Domain Name Service (DNS) server, a DNS response for a domain that includes certificate information in metadata of a Network Service Header (NSH) of the DNS response. The TLS proxy stores the certificate information. The TLS proxy performs a TLS handshake with a network device and receives a certificate for the domain as part of the TLS handshake. The TLS proxy validates the certificate for the domain using the certificate information.

Description

FIG. 1is a schematic block diagram of an example computer network100illustratively comprising nodes/devices200, such as a plurality of routers/devices interconnected by links or networks, as shown. For example, customer edge (CE) routers (e.g., CE1and CE2) may be interconnected with provider edge (PE) routers (e.g., PE1and PE2, respectively), to communicate across a core network, such as an illustrative core network104. Core network104may be a Multi-Protocol Label Switching (MPLS) network or, alternatively, any other form of network, such as an Internet-based network.

The various nodes/devices200may exchange data packets106(e.g., traffic/messages) via computer network100over links using predefined network communication protocols such as the Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Asynchronous Transfer Mode (ATM) protocol, Frame Relay protocol, or any other suitable protocol. Those skilled in the art will understand that any number of nodes, devices, links, etc. may be used in the computer network, and that the view shown herein is for simplicity. In various embodiments, nodes/devices200may employ a secure communication mechanism, to encrypt and decrypt data packets106. For example, nodes/devices200shown may use a Transport Layer Security (TLS) mechanism, such as the HTTPS protocol, to encrypt and decrypt data packets106.

FIG. 2is a schematic block diagram of an example node/device200that may be used with one or more embodiments described herein, e.g., as any of the routers of network100, or any other computing device that supports the operations of network100(e.g., switches, servers, etc.). Device200comprises a plurality of network interfaces210, one or more processors220, and a memory240interconnected by a system bus250. The network interfaces210contain the mechanical, electrical, and signaling circuitry for communicating data over physical links coupled to the network100. The network interfaces may be configured to transmit and/or receive data using a variety of different communication protocols.

SFC process/services244include computer executable instructions that, when executed by processor (s)220, implement an SFC architecture in the network. For example, details regarding the SFC architecture can be found in the Internet Engineering Task Force (IETF) request for comments (RFC) 7665 entitled, “Service Function Chaining (SFC) Architecture” by J. Halpern et al., which is hereby incorporated by reference. In general, SFC facilitates the use of network services and provides for network location techniques to locate the device(s) that support these services. Example services may include, but are not limited to, caching services, firewall services, anti-intrusion services such as intrusion detection services (IDS) and intrusion prevention services (IPS), malware detection services, deep packet inspection (DPI) services, acceleration services, load balancing services, lawful intercept (LI) services, optimization services, etc. In particular, a service function chain comprises an ordered set of services that may be provided to network traffic based on the classification of the traffic.

As part of the SFC architecture, a service function path (SFP) may denote to which service functions a certain packet must be sent (e.g., which services are to perform their respective functions on the packet). The SFC device that selects the SFP for the packet may indicate the selected SFP by encapsulating the packet using SFC-specific information. Of note is that SFC encapsulation is used solely to include data plane context information and is not used for purposes of network packet forwarding. In particular, an SFC device may add a Network service header (NSH) to a packet or frame, to convey metadata and service path information that can be used to create the service plane. For transport, the NSH and packet may be encapsulated in an outer header. Details regarding an NSH protocol header can be found in the IETF draft entitled, “Network Service Header,” by P. Quinn et al., the contents of which are hereby incorporated by reference.

For a given SFC, there can be a variable number of SFPs and a variable number of Rendered Service Paths (RSPs). Related to the concept of an SFP, an RSP refers to the actual points in the network to which a packet travels. In some cases, an SFP may be constrained to such a degree that the SFP also identifies the actual locations. However, in many cases, an SFP is less constrained, as a service chain can exist as a group of abstract functions/services. Each of the SFPs/RSPs may include a number of specific instances of service functions, service function forwarders (SFFs), and/or proxies. For example, an RSP may comprise the following chain: Firewall_A—NAT_C—Load_Balancer_G.

As noted above, the NSH architecture provides the mechanisms for the construction of service chains in a network and the forwarding of traffic through those service chains using network service headers carried within the data plane. The network service headers are imposed on to the original packet/frame through classification. An outer encapsulation used for transport between individual services of the service chain is then pushed onto the packet/frame. Forwarding of packets/frames is achieved at the service plane layer using the NSH headers. Specifically, a Service Path Identifier (SPI) and Service Index (SI) are used for this purpose. A unique SPI is used to identify a given service path instantiation of a service chain, and the SI is initialized to the total number of services within the service chain, and decremented at each service hop as packets/frames traverse through the service path.

An example of an SFC being configured is shown inFIGS. 3A-3B. As shown inFIG. 3A, assume that nodes A-E exist along a path that traverses network portion302. In particular, assume that node A is to send traffic to node E via the path shown. Further, assume that node B is an SFC classifier and that node C is an SFF that is configured to forward packets to a number of service functions, S1and S2. For example, S1may be a content filtering service and S2may be a NAT service. In some cases, S1and S2may be provided by separate network devices. However, as service functions in an SFC can be virtualized, service functions S1and S2can also be implemented locally on node C, in other implementations. As would be appreciated, the nodes shown are presented in a simplified manner and the path between nodes A and E may comprise any number of intermediary nodes and service functions.

An administrator operating an administrative device/node X (e.g., a device200) may define the service chains by sending instructions304to the devices/nodes associated with the chain. In some embodiments, the established service paths may be represented by their corresponding SPI and SI, to differentiate the different service paths. For example, one SFP may include service function S1, another SFP may include service function S2, a third SFP may include both service functions S1and S2, etc. In various embodiments, Open Daylight (ODL), or another similar mechanism, may be used to configure an SFP.

As shown inFIG. 3B, classifier node B may also be programmed with classification rules306that are used by classifier node B to make SFC decisions based on the different types of user traffic that may be sent via node B. For example, one classification rule may require only HTTP traffic to pass through content filtering service function S1, whereas other types of traffic may not require this service. Similar to the SFP configurations, the administrator operating administrative device X may define classification rules306that are then sent to classifier node B.

Referring now toFIGS. 4A-4D, examples of SFPs are shown. InFIG. 4A, assume that the SFPs have been established (e.g., as shown inFIGS. 3A-3B) and that node A sends user traffic402to node E via classifier node B. In such a case, any number of service functions (e.g., services functions S1, S2, etc.) may be performed on traffic402, prior to delivery to its destination node E.

As shown inFIG. 4B, classifier node B may classify traffic402according to its programmed classification rules (e.g., rules306). For example, classifier node B may classify traffic402by its type (e.g., the application associated with the traffic, etc.), its address information (e.g., the address and/or port of the source and/or destination device), or any other information that may be used to select a particular SFP for the traffic. Based on the classification, classifier node B may then construct a service chain header and encapsulate traffic402using the header. For example, classifier node B may select the SPI and SI associated with the classification and, in turn, may construct an NSH header for traffic402that indicates the selected values.

FIG. 4Cillustrates a first SFP404that may be selected by classifier B for traffic402. In particular, the NSH header added to traffic402may indicate that traffic402should be sent to both service functions S1and S2for processing. Notably, in response to receiving an NSH-encapsulated packet, SFF C may determine that traffic402should be sent first to service function S1for processing, then on to service function S2, before being forwarded towards its intended destination, node E.

As shown inFIG. 4D, traffic402may traverse an alternate SFP406, based on the NSH header inserted into traffic402. For example, while SFP404includes both service functions S1and S2, SFP406instead only includes service function S2. Thus, the classification of traffic402may affect which SFP, if any, the traffic will traverse before delivery to its destination.

As noted above, traditional TLS mechanisms present several potential security vulnerabilities that could be exploited during a certificate validation attack. First, the TLS proxy has no way of knowing which trust anchor should vouch for the domain associated with the server certificate. Additionally, since any domain can be vetted by any certificate authority, all domains will be vulnerable to a man-in-the middle attack if a certificate authority becomes compromised.

One approach to address the above security vulnerabilities of TLS proxies is the Domain Name Service (DNS)-Based Authentication of Named Entities (DANE). DANE is generally described in the IETF RFC 6698 entitled “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA,” by Hoffman et al. Generally, DANE operates by binding the server certificate to the domain name using DNS Security Extensions (DNSSEC).

Notably, DANE allows for the authentication of TLS clients and servers, without the reliance on a certificate authority, addressing both of the security vulnerabilities listed above. Instead, DANE proposes that the DNS server store the certificate/fingerprint as part of a TLSA record that is signed using DNSSEC (note that TLSA does not stand for anything). Thus, the certificate stored by the DNS server is controlled by the domain name holder, which may be self-signed or signed by a particular certificate authority.

A DANE-based TLSA record typically includes four fields:1. Certificate Usage Field—Generally, this field indicates how the certificate for the domain should be used. Certificate usage ‘0’ generally indicates the specific certificate authority that will provide certificates for the domain. This is also sometimes referred to as a “certificate authority constraint,” as only the specified certificate authority can issue certificates for the service/host. Certificate usage ‘1’ specifies the TLS certificate that should be used for the domain. Certificate usage ‘2’ indicates the trust anchor that is to be used to validate the TLS certificates for the domain. Finally, certificate usage ‘3’ indicates that the certificate is self-signed by the domain and does not need to be signed by a certificate authority.2. Selector Field—This field specifies which portion of the certificate should be matched against the association data. A selection of ‘0’ indicates that the full binary of the certificate is to be matched, whereas a selection of ‘1’ indicates that the subject public key information should be matched.3. Matching Type—This field specifies how the certificate association data indicated in the selector field should be presented. A matching type of ‘0’ indicates that an exact match is required for the selected content. A matching type of ‘1’ indicates that an SHA-256 hash of the selected content should be matched. A matching type of ‘2’ indicates that an SHA-512 hash of the selected content should be matched.4. Certificate Association Data Field—This field is used to store the full certificate or subject public key information selected in the selector field.

The DNS server may include the above certificate information as part of a DNS response. However, many applications and endpoint devices do not support DANE and, therefore, will not perform a DANE lookup. When this occurs, the intermediate TLS proxy will also not have visibility into the TLSA record that would otherwise be included in the DNS response. In particular, a DANE lookup involves multiple DNS requests and responses (e.g., to obtain a DNSKEY/RRSIG chain up from the root and to validate the chain of DNSSEC signatures).

In some embodiments, the TLS proxy may perform the DANE lookup after receiving the server certificate as part of the TLS handshake between the remote server and the client device. However, doing so will add significant latency to the TLS connection setup. Moreover, since the client device only sees the TLS proxy certificate and not the server certificate, it will not perform a DANE lookup.

Network Security System to Validate a Server Certificate

The techniques herein propose a security mechanism for TLS proxies and other security functions that inspect TLS handshakes. In some aspects, the security mechanism leverages DANE for purposes of certificate authorization, regardless of whether the local client device supports DANE. In particular, the security mechanism may use an SFC architecture to convey certificate information (e.g., DANE information, etc.) in NSH metadata between a TLS proxy and a DNS recursive server. In contrast to other mechanisms (e.g., public key pinning, etc.), the security mechanism can validate the certificate information on the first connection. In addition, the security mechanism herein is more secure that traditional TLS proxy mechanisms, as an attacker would also need to compromise the DNSSEC from the DNS root to perform an attack on the system.

Specifically, according to one or more embodiments of the disclosure as described in detail below, a Domain Name Service (DNS) server pre-fetches domain information regarding a domain that includes certificate information for the domain. The DNS server receives a DNS request that includes a security request for the domain in metadata of a Network Service Header (NSH) of the DNS request. The DNS server retrieves the certificate information for the domain from the pre-fetched information regarding the domain, in response to receiving the security request. The DNS server sends, to a Transport Layer Security (TLS) proxy, a DNS response for the domain that includes the certificate information in metadata of an NSH of the DNS response.

Operationally,FIG. 5illustrates an example network security system500using SFC to convey server certificate information, according to various embodiments. As shown, system500may generally include two separate services: 1.) a web security service502and 2.) a DNS Security Service510in communication with one another via a core network104, such as the Internet. In various embodiments, web security service502and/or DNS security service510may be implemented as a cloud-based service.

Generally, web security service502may include an SFC classifier504, an SFF506, and a TLS proxy508. In some embodiments, TLS proxy508may be established in the SFC as a service function that is configured to intercept traffic between client devices (not shown) and HTTPS servers518. TLS proxy508may be, for example, a server using Cloud Web Security from Cisco Systems, Inc. or any other TLS proxy server.

DNS security service510may include a second SFC classifier512, an SFF506, and a DNS recursive service516. Generally, DNS recursive service516may be hosted by a corresponding DNS server/device that is also in communication with HTTPS server518via the Internet/network104. For example, DNS recursive service516may be an OpenDNS service or similar service that provides DNS services for the domain of HTTPS server518.

In various embodiments, SFC classifier504may classify traffic from a client device based on the type of traffic. In particular, SFC classifier504may process and classify DNS traffic520differently than user traffic such as HTTPS traffic522. For example, SFC classifier504may inspect packets from the sending client/endpoint device, to determine whether the traffic is a DNS request (e.g., sent to DNS recursive service516) or an encrypted packet (e.g., sent to HTTPS server518). Based on the classification of the traffic from the client device, SFC classifier504may assign the traffic to a corresponding SFP.

As shown, if SFC classifier504determines that user traffic associated with the sender of DNS traffic520is to pass through TLS proxy508, it may add a corresponding security request to the associated DNS requests in DNS traffic520. For example, in some embodiments, SFC classifier504may apply an NSH header to the packets in DNS traffic520that includes the security request in NSH metadata. The applied NSH header may also identify an SFP that traverses through TLS proxy508, DNS recursive service516, and/or any other SFC services, as desired. Thus, on receipt of the encapsulated DNS packet in traffic520, SFF506may forward the packet on to TLS proxy508. In turn, the packet may be forwarded along the SFP on to the remote SFC classifier512and SSF514, which forwards the packet/DNS request on to DNS recursive service516. The NSH-based security request then signals to DNS recursive service516to return certificate information, such as DANE TLSA record information, in the DNS response.

On the return path, classifier512may perform a similar classification of any DNS responses from DNS recursive service516that causes the DNS response packet to be forwarded to TLS proxy508prior to forwarding the response on to the client device. Thus, TLS proxy508is able to intercept the certificate information included in the DNS response, which may include DANE information that would otherwise not be available to TLS proxy508if the client device does not support DANE.

HTTPS traffic between the client device and HTTPS server518may traverse a second SFP that includes, at a minimum, TLS proxy508. Since TLS proxy508has the needed encryption information from the DNS/DANE lookup, it may decrypt the packets for further processing by any number of other security devices/services. For example, TLS proxy508may provide the unencrypted packets to an IPS service or the like, to assess the decrypted packet. TLS proxy508may also re-encrypt the HTTPS traffic522using its certificate information and forward the packets on to, e.g., HTTPS server518. In other words, from the perspective of the client device, the client device may believe that it is communicating securely with HTTPS server518when, in reality, it is communicating with TLS proxy508. Similarly, from the perspective of HTTPS server518, it may believe that it is communicating securely with the client device when it is actually communicating directly with TLS proxy508.

FIG. 6illustrates an example sequence diagram600illustrating the operation of network security system500, in accordance with various embodiments. As shown, DNS recursive service516may pre-fetch information about the domain of HTTPS server518and store the fetched information in a local cache. In various embodiments, this pre-fetching may entail maintaining a reputation score for the domain, performing a DANE lookup for the domain, fetching DNSSEC records, performing any DNSSEC validation, storing TLSA records for the domain, or performing any other operation to obtain domain/certificate information regarding the domain of HTTPS server518. In turn, DNS recursive service516may use the pre-fetched information in its local cache to process any DNS request for the domain of HTTPS server518, thereby avoiding the overhead of having to perform a DANE lookup each time.

As shown, assume that endpoint device602generates and sends a DNS request604, to obtain domain information regarding the domain of HTTPS server518. For example, endpoint device602may execute a web browser or other local application that will communicate with HTTPS server518. In turn, endpoint device602may send DNS request604, to obtain the requisite information to communicate with HTTPS server518.

In response to receiving DNS request604, SFC classifier504may determine whether any encrypted traffic associated with endpoint device602will traverse through a service function that will perform server certificate validation. For example, SFC classifier504may determine whether traffic from endpoint device602will traverse TLS proxy508or another networking device configured to perform or inspect a TLS handshake.

In various embodiments, if SFC classifier504determines that an intermediate service/device is to insert itself into the HTTPS encryption process between endpoint device602and a remote server (e.g., HTTPS server518), classifier504may encapsulate DNS request604using an NSH header. For example, the appended NSH header may indicate that DNS request604is to traverse TLS proxy508and/or other SFP services. In some embodiments, classifier504may also include a security request in the metadata of the NSH header. Such a security request may request, for example, certificate information for the domain such as DANE-related information (e.g., certificate constraint, etc.), a certificate lifetime, or other information that TLS proxy508can use to perform a TLS handshake with endpoint device602as a proxy for HTTPS server518.

Once the encapsulated DNS request604reaches DNS recursive service516, the DNS service may perform a DNS lookup for the domain of HTTPS server518. In addition, in various embodiments, DNS recursive service516may retrieve the pre-fetched certificate information from its local cache, as requested in the NSH metadata of DNS request604.

After retrieving the DNS information requested by DNS request604, as well as any certificate information if applicable to the domain, DNS recursive service516may generate and send a DNS response606back towards endpoint device606. In various embodiments, DNS response606may also include any of the corresponding certificate information for the domain of HTTPS server518. For example, if the domain of HTTPS server518has deployed DANE, DNS recursive service516may include the certificate constraint, certificate lifetime, and/or other TLSA record information in NSH metadata of DNS response606.

As TLS proxy508is now on the return path of DNS response606and DNS response606includes the certificate/DANE information for the domain of HTTPS server518, TLS proxy508is able to capture the certificate/DANE information as part of the communication. Doing so addresses the situations whereby the application of endpoint device602does not support DANE. Without such a mechanism, TLS proxy508would be unable to capture the DANE information or otherwise use DANE, thus exposing TLS proxy508to the potential security holes of traditional TLS mechanisms. Once TLS proxy508captures the certificate information from the NSH metadata of DNS response604, TLS proxy508may cache the certificate information and forward DNS response606on towards endpoint device602. For example, TLS proxy508may cache the certificate constraint and lifetime of the server certificate for the domain of HTTPS server518. After expiration of the lifetime of the certificate, TLS proxy508may purge the certificate information, accordingly.

When DNS response606leaves the SFP, its NSH header will be stripped before DNS response606is forwarded to endpoint device602. Thus, from the perspective of endpoint device602, DNS response606is a traditional DNS response. In turn, using the information included in DNS response606, endpoint device602may attempt to initiate a TLS handshake608with HTTPS server518. Similar to the classification of DNS request604, classifier504may determine that TLS handshake608should be forwarded to TLS proxy508, encapsulate the packets using an NSH header that forwards the packets to TLS proxy508, and send the packets along the corresponding SFP.

Since TLS proxy508has all of the necessary certificate information for the domain of HTTPS server518, TLS proxy508may act as a proxy during TLS handshake608. In other words, endpoint device may602may believe that it is establishing an encrypted connection directly with HTTPS server518when, in reality, it is communicating with TLS proxy508. In various embodiments, when TLS proxy508receives the server certificate for HTTPS server518as part of TLS handshake608, it may use its cached certificate information to validate the certificate. In turn, TLS proxy508and HTTPS server518may exchange hello messages610and612, respectively, to complete the exchange and establish TLS proxy508between endpoint device602and HTTPS server518. This allows TLS proxy508to intercept and decrypt any packets between these devices and initiate further processing of the packets (e.g., by forwarding the packets to an IPS, for DPI inspection, etc.).

FIG. 7illustrates an example simplified procedure for including certificate information in a DNS response, in accordance with one or more embodiments described herein. For example, a non-generic, specifically configured device (e.g., device200) may perform procedure700by executing stored instructions (e.g., processes244,248). For example, a DNS server may perform procedure700by executing stored instructions. The procedure700may start at step705, and continues to step710, where, as described in greater detail above, the DNS server may pre-fetch domain information for a domain. In various embodiments, this pre-fetch may entail performing a DANE lookup of the domain and obtaining server certificate information such as a certificate constraint, a certificate lifetime, other TLSA record information, or the like. In further embodiments, the DNS server may also employ DNSSEC with the domain by retrieving DNSSEC record information for the domain as part of the pre-fetch and using the record information to validate the domain. In various embodiments, the DNS server may also cache any of the pre-fetched domain information, so that it does not have to perform a full lookup each time that it receives a DNS request for the domain. For example, the DNS server or other device in the network may store TLSA records for the domain as part of the pre-fetching.

At step715, the DNS server may receive a DNS request that includes a security request in NSH metadata of the request, as describe in greater detail above. For example, the DNS request may be encapsulated using an NSH header that includes a request for certificate information for the domain (e.g., DANE-related information).

At step720, as detailed above, the DNS server may retrieve the requested certificate information for the domain. If, for example, the DNS server cached the certificate information as part of the pre-fetching in step710, the DNS server may retrieve the corresponding information from its local memory. As noted, the certificate information may include the corresponding DANE information for the domain, such as the certificate constraint, certificate lifetime, and the like.

At step725, the DNS server may generate and send a DNS response that includes the information requested in the DNS request of step715, as described in greater detail above. In various embodiments, the DNS server may send the request back towards the requesting endpoint device and through a TLS proxy, allowing the TLS proxy to obtain the certificate information included in the DNS response. In some embodiments, the certificate information may be included in NSH metadata of the DNS response, thereby allowing the TLS proxy to store the certificate information before forwarding the DNS response on towards the endpoint device. Procedure700then ends at step730.

FIG. 8illustrates an example simplified procedure for using certificate information included in a DNS response to validate a server certificate, in accordance with one or more embodiments described herein. For example, a non-generic, specifically configured device (e.g., device200) may perform procedure800by executing stored instructions (e.g., processes244,248). For example, a TLS proxy or other networking device may perform procedure800by executing stored instructions. The procedure800may start at step805, and continues to step810, where, as described in greater detail above, the device may receive a DNS response that includes certificate information in NSH metadata for a domain. As noted, such certificate information may include DANE-related information such as a certificate constraint, other TLSA record information, a certificate lifetime, or any other certificate information that can be used to establish a secure connection with a server in the domain.

At step815, as detailed above, the device may store the certificate information. For example, the device may store the certificate information included in as NSH metadata in the DNS response within a local cache of the device.

At step820, the device may perform a TLS handshake with the endpoint device associated with the DNS response, as described in greater detail above. In particular, the device may perform a handshake with the endpoint device, acting as a proxy for the intended secure server. Doing so will allow the TLS proxy/device to intercept otherwise encrypted communications between the endpoint device and the server.

At step825, as detailed above, the device may use the stored certificate information to validate the server certificate for the domain. In particular, if the stored certificate information includes DANE-related information, this allows the device to leverage DANE during the TLS proxy process, without requiring the endpoint device to also support DANE. Procedure800then ends at step830.

It should be noted that while certain steps within procedures700-800may be optional as described above, the steps shown inFIGS. 7-8are merely examples for illustration, and certain other steps may be included or excluded as desired. Further, while a particular order of the steps is shown, this ordering is merely illustrative, and any suitable arrangement of the steps may be utilized without departing from the scope of the embodiments herein. Moreover, while procedures700-800are described separately, certain steps from each procedure may be incorporated into each other procedure, and the procedures are not meant to be mutually exclusive.

The techniques described herein, therefore, optimize TLS connection setup times on TLS security mechanisms/devices that perform DANE validation. In addition, the techniques herein allow these security mechanisms/devices to leverage DANE as an certificate authorization mechanism, thereby allowing the use of DANE in cases where the endpoint devices/applications do not support DANE.

While there have been shown and described illustrative embodiments that provide for network security, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, while certain protocols are shown, such as HTTPS, other suitable protocols may be used, accordingly.