System and method of use of WIREGUARD tunneling protocol
A system that improves upon the existing Tor protocol by (1) simplifying the network creation with a reduction in the number of different components, (2) reducing the time for a network to become operational, (3) allowing for a microservices architecture that supports dynamic scalability, and (4) reducing the latency and increasing the throughput of the resulting network. A simplified nested wireguard tunnelling network creation and reduced operational deployment time reduces the cost to deploy and maintain the network. The use in a microservices architecture further allows dynamic scalability of the network, permitting more cost-effective deployments in environments that have dynamic use patterns, for example, traditional educational and business environments with primary “nine to five” hours of operation).
Latest TELOS CORPORATION Patents:
This application claims priority to U.S. Provisional Patent Application Ser. No. 63/526,171, filed on Jul. 11, 2023, the disclosure of which is incorporated herein by reference in its entirety.
TECHNICAL FIELDThe presently disclosed subject matter relates to online location protection, and, more particularly, to provide efficient and rapid deployment of a system and method for location obfuscation of network traffic.
BACKGROUNDThe original Onion Routing (Tor) protocol causes data from a client device 104 to be transported across a circuit 110 within the Tor network 100 to a target or recipient, here a server 105, as seen in
When the circuit 110 has been obtained, the guardian or access node 101 uses the information associated with each node in the circuit 110 to successively encrypt the original data or message 120 (which can be either unencrypted or “end-to-end” encrypted with a destination's public encryption key, for example) with the public key of each node K1, K2, K3 along with the Internet Protocol (IP) address of the following node. As shown in diagram 200 in
More specifically, not only is the data multiply encrypted, but the IP addresses of the ensuing nodes are as well, as shown in
As illustrated in
The TELOS GHOST® secure network access system, provided by Telos Corporation of Ashburn, Virginia, currently employs the original onion routing, Tor, protocol to provide a cloud-based virtual location obfuscation network as-a-service for network traffic. TELOS GHOST is a registered trademark of Telos Corporation. Three areas in which the existing architecture suffers are: 1) the static monolithic nature of the private virtual network due to the automated nature of the deployment in the cloud service provider; 2) the time necessary for the transit nodes to become available through the announcement (the traditional probationary period is waived because all nodes are under Telos' control, but announcement of availability still occurs); and 3) consensus voting protocol and the latencies incurred due to the data exchange operating at the application layer (layer 7) of the network. The TELOS GHOST network is a private network to which only authorized users are permitted access on which all nodes are private. The TELOS GHOST network can exit to the public internet, a private cloud, and an on-premises enclave. In addition, the TELOS GHOST network can hide mobile communications: voice, video, chat and data. Details of the TELOS GHOST secure network access system are provided in U.S. Pat. Nos. 8,832,311, 8,904,036, and 9,130,911, all of which are hereby incorporated herein in their entireties.
The diagram in
The time to coalesce a private Tor network must be considered when network maintenance is performed as it adds to the time required for the network to become available after being shut off for any maintenance effort. Further, the latency added to the data transfer across the network limits the applications that can use the network in an effective manner. For example, real-time operation is often not possible and interactive applications, such as voice and video can suffer in usability because of the lag in the delivery of the underlying content. Therefore, what is needed is a system and method to provide fast and secure online location protection, and, more particularly, to provide fast and secure location obfuscation for network traffic.
SUMMARYEmbodiments of the presently disclosed subject matter replace the existing Tor tunnel system requirement for transit node announcement and consensus voting by a predictable creation and configuration of network nodes and reduces latency times by operating at a lower layer in the 7-layer Open Systems Interconnection (OSI) model of network communications from the International Organization for Standardization (ISO), specifically, with a nested WIREGUARD© secure virtual private network (VPN) tunnel network 400 (which is interchangeably referred to herein as a WIREGUARD tunnel network and a WIREGUARD implementation) at a network layer (OSI Model layer 3) 425, as seen in
Whereas, as seen in
Within the WIREGUARD protocol, secure onion routing is accomplished through the nested WIREGUARD tunnels wg0, wg1, wg2 as shown in
In an embodiment of the presently disclosed subject matter, as shown in
The TELOS GHOST network currently utilizes the Tor protocol for data transport between the access node and the exit node to create a circuit over which an open source Virtual Private Network (OpenVPN©) traffic passes between the source and destination nodes. OpenVPN is a registered trademark of OPENVPN, INC. of Pleasanton, California. However, as seen in
Feature Comparison.
Onion Routing. Both the Tor and the WIREGUARD approaches provide onion routing, but in very different ways. The Tor approach encapsulates and encrypts the routing information and the data in a reverse recursive approach, that is, starting with the last node in the circuit first at the access node and the onion is peeled at each successive node in the circuit as the data transits the circuit, as seen in
All circuit information is known at the access node within the Tor approach when the access node requests a circuit from the directory authorities and uses that information to create the encrypted data onion in
Encryption.
While the Tor approach uses AES-256 encryption, the WIREGUARD approach uses multiple encryption algorithms, which provides a comparable level of security to the Tor approach. Specifically, the encryption algorithms used in the WIREGUARD approach include:
-
- ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539's AEAD construction;
- Curve25519 for ECDH;
- BLAKE2s for hashing and keyed hashing, described in RFC7693;
- SipHash24 for hashtable keys; and
- HKDF for key derivation, as described in RFC5869.
Anonymity at Intermediate Nodes.
In the original Tor network, intermediate nodes can be located anywhere around the world, and are owned by any number of individuals, so the Tor onion routing approach limits the routing information at any individual node to the preceding and subsequent nodes because the nodes are untrusted. In other words, the nodes in the Tor network have public IP addresses that can be seen by anyone on the network.
In the TELOS GHOST network, as currently operated, all nodes are obtained within AWS under control of a single AWS account and can use both public and private IP addresses. The WIREGUARD protocol can also utilize public IP addresses, which can be restricted with AWS security groups to preclude external snooping. In addition to using public IP addresses, the WIREGUARD protocol has been configured as well as to use private IP addresses in an on-premises network for transport. In the private IP addresses embodiment, a load balancer is used in front of the access nodes and a network address translation (NAT) gateway is used to cloak the exit nodes, so, as a result, all of the internal nodes can be private IP addresses, which are completely hidden from outside view. These configurations are described in more detail below in relation to
Embodiments of the presently disclosed subject matter improve upon the existing Tor protocol by simplifying the network creation with a reduction in the number of different components further reducing the time for a network to become operational, allowing for a microservices architecture that supports dynamic scalability, and reducing the latency and increasing the throughput of the resulting network. The simplified network creation and reduced operational deployment time also reduces the cost to deploy and maintain the network.
The use in a microservices architecture further allows dynamic scalability of the network, permitting more cost-effective deployments in environments that have dynamic use patterns, for example, but not limited to, traditional educational and business environments with some sort of set primary “nine to five” hours of operation.
The presently disclosed subject matter supports a “drop-in” replacement for the existing TELOS GHOST network from a functional perspective, so all existing applications of the current Telos Ghost network seen in
Where the definition of terms departs from the commonly used meaning of the term, applicant intends to utilize the definitions provided below, unless specifically indicated.
For the purposes of the disclosed subject matter, directional terms such as “lower,” “above,” “below,” “inside,” “outside,” etc., are merely used for convenience in describing the various embodiments of the presently disclosed subject matter.
For the purposes of the presently disclosed subject matter, the term “access node” or “ingress node” refers to a node that reroutes traffic from a client node to a tunnel circuit and encrypts the traffic prior to sending the traffic to the tunnel circuit. An access node may be part of a separate device or may be part of a client device including the client node.
For the purposes of the presently disclosed subject matter, the term “client device” refers to electronic devices that may be used to access a data network or a communication network. Examples of client devices include, but are not limited to, personal computers, wearable computers, personal data assistants, cell phones, landline telephones, laptops, tablet computers, handheld gaming devices, and video game players. When an access node is part of a separate device that is not part of a client device, the terms “client device” and “client node” may be used interchangeably.
For the purposes of the presently disclosed subject matter, the term “exit node” or “egress node” refers to a node that reroutes encrypted traffic from a tunnel circuit to a server node and decrypts the encrypted traffic prior to sending the traffic to the server node. An exit node or an egress node may be part of a separate device or may be part of a server including the server node.
For the purposes of the presently disclosed subject matter, the term “logically adjacent node” refers to the node from which a given node receives private traffic and the node to which a given node sends private traffic.
For purposes of the presently disclosed subject matter, the term “mode of communication” and the term “communication link” refer to any suitable technology or device known and available in the art for communicating between two or more devices. A mode of communication may be achieved or carried out through any suitable medium, such as any wired or wireless connections as well as any protocols, including, but not limited to: the Internet; GMR (Geo-Mobile Radio); TCP/IP; MOD BUS RTU, MODBUS ASCII, and MODBUS TCP; XML; Ethernet; file transfer protocol (FTP); Bluetooth®; ZigBee®; e-mail, such as SMTP; cellular modems; cellular phone networks, such as CDMA and TDMA; radio signals or remote terminal units (RTU) coupled to radio frequency transmitters; satellite transmission; SDI-12; existing telephone or communication networks or wiring; a standard public switched telephone network (PSTN); dial-up using landline or telephone; a wireless network such as Wi-Fi; a wide area network (WAN); a wireless local area network (WLAN); a local area network (LAN) or a metropolitan area network (MAN); a cable Internet connection; short message system (SMS); dial-modem; a point-to-point link; global system for mobile communications (GSM, 3GSM), general packet radio services (GPRS), evolution-data optimized (EV-DO), enhanced data rates for GSM evolution (EDGE), digital enhanced cordless telecommunications (DECT), integrated digital enhanced network (iDEN), universal mobile telecommunications systems (UMTS) or advanced mobile phone systems (AMPS); or any other means for communicating between two or more devices known to those skilled in the art.
For the purposes of the presently disclosed subject matter, the term “nested WIREGUARD tunnels” refers to a logical nesting of two or more virtual tunnel circuits where a first WIREGUARD tunnel is created from an access node to a first transit node. A second WIREGUARD tunnel is created from the access node to a second transit node routing the traffic through the first WIREGUARD tunnel. A third WIREGUARD tunnel is created from the access node to the exit node through the second WIREGUARD tunnel and the first WIREGUARD tunnel. Each of these tunnels are established using the WIREGUARD keys of the corresponding endpoints and the routing is established such that the traffic is transparently forwarded across each intermediary node to ensure that a node only communicates with the predecessor and successor nodes in the circuit.
For the purposes of the presently disclosed subject matter, the term “tunnel circuit” is an ordered series of logically adjacent nodes.
For the purposes of the presently disclosed subject matter, the term “network” refers to a telecommunications system used to send and receive data.
For the purposes of the presently disclosed subject matter, the term “onion router” refers to a device that employs multiple layers of encryption in order to provide confidentiality and anonymity.
For the purposes of the presently disclosed subject matter, the term “private access node” or “private ingress node” refers to an access node or an ingress node that is connected to other nodes only by private connections.
For the purposes of the presently disclosed subject matter the term “destination” or “server” or “target” or “target device” refers to the final termination point of the communication circuit initiated by a client application (e.g., web browser, cell phone call, text message). When an exit node or an egress node is part of a separate device that is not part of a server, the terms “server” and “server node” may be used interchangeably.
For the purposes of the presently disclosed subject matter, the term “transit node” refers to a transit node or router whose sole purpose is to route traffic through it to another transit node or an exit or an egress node using a secure communications channel, within the secure communications channel.
The presently disclosed subject matter will now be described with reference to the drawing figures, in which like reference numerals refer to like parts throughout. Embodiments of the presently disclosed subject matter advantageously provide systems and computer-based methods for planning missions, as described in more detail below.
Previously, the system operated using onion routing through the Tor software, where multiple layers of encryption are wrapped around the data being transported through the network and these layers are “peeled” back through each hop in the network to determine the next recipient. Within the prior system this is implemented at the application layer as a “circuit” with individual hops as circuits are created and broken down to achieve a dynamic nature to the transit cloud to generate an ever-changing configuration to limit any static attack surface.
In contrast, the WIREGUARD VPN tunnel is an Open Systems Interconnection (OSI) layer 3 (that is, network layer) peer-to-peer network communication protocol that can be implemented directly in a Linux kernel to create virtual network interfaces that can be used to route traffic and currently employs Onion Routing to provide location obfuscation for network traffic. Two areas in which the existing Tor protocol suffers are: 1) the time necessary for the transit nodes to become available through the announcement and consensus voting protocol for a new instance of a private Tor network; and 2) the latencies incurred due to the data exchange operating at the application layer (that is, layer 7) of the network.
The WIREGUARD Protocol and the TELOS GHOST Network Deployment Environment.
The WIREGUARD Protocol.
The WIREGUARD VPN utilizes state-of-the-art cryptography to be faster, simpler, leaner, and more useful than IPsec, while avoiding the known issues with IPsec's complexity and the administrative burden it requires. The WIREGUARD VPN is designed to be better performing than OpenVPN. The WIREGUARD system is designed as a general-purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances, such as smart phones and fully loaded backbone routers. The WIREGUARD configuration is performed on a peer-to-peer basis and operates within the Linux kernel. The peer-to-peer basis allows configuration between peers through a public key mechanism like the “ssh” keypair exchange.
The TELOS GHOST Network Deployment Environment.
In the WIREGUARD protocol deployment, a simple onion routing circuit was configured with AWS EC2 virtual machines consisting of a single access node, two transit nodes and an exit node within a single AWS region. Additional administrative components, for example, but not limited to, a Domain Controller and a Managed Active Directory were also created for authentication purposes. Nested WIREGUARD tunnels were deployed between the various nodes for data transport. The data routing for the nested tunnels for a traditional exit node is shown in
Embodiments of the presently disclosed subject matter replace the requirement for transit node announcement and consensus voting by using a predictable creation and configuration of the network nodes and reduces the latency by operating at a lower OSI layer, the network layer (that is, layer 3) of the network. This improves upon the existing Tor protocol by simplifying the network creation with a reduction in the number of different components further reducing the time for a network to become operational, allows for a microservices architecture that supports dynamic scalability and reduces the latency and increases the throughput of the resulting network. The simplified network creation and reduced operational deployment time reduces the cost to deploy and maintain the network.
-
- in addition, the use in a microservices architecture further allows dynamic scalability of the network, permitting more cost-effective deployments in environments that have dynamic use patterns, for example, but not limited to, traditional educational and business environments with some sort of primary “nine to five” hours of operation.
Similar to the Tor network, a WIREGUARD network transmits data from the origin to the destination through a series of nodes. However, instead of encrypting the data into an object that is passed at the application layer as in Tor and as shown in
This virtual nesting is performed as shown in
In contrast, as seen in
It is the separation of the encrypting material, that is, the peer keys in the WIREGUARD implementation 500, from the IP addresses of the actual endpoints through the use of the port forwarding on the internal nodes that allows the WIREGUARD transport protocol to mimic the node anonymity in the Tor implementation. Each node only knows the source and destination of the next hop in the network with which it exchanges packets and not about any nodes beyond that.
The exemplar embodiment of the WIREGUARD implementation 500, as seen in
Overlaying this on
As a result, traffic flowing from Host 1 to Host 4 goes over wg2, which goes over wg1, which goes over wg0, effectively creating a similar sort of layering as onion routing, but without the need to include the IP addresses, so, while not an exact 1-1 match, the similarity can be seen.
For all hosts, the sys.net.ipv4.ip_forward value was set to 1 and the iptables were flushed. Individual configuration details, testing and other comments follow. All ssh commands were executed from Host 1. Also note that each successive tunnel operated over a different port. The first hop was the default 51820, the second 52821, and the third 51822.
For Host 1 the virtual network interface wg0 was created using:
-
- # wg show wg0
- interface: wg0
- public key: 0N8dqLe9Pj0k8cgua7R9Gv2yXd6H+Sq+olhXK6vpKjQ=
- private key: (hidden)
- listening port: 51820
- peer: dabeyd3hRa5qylVCoWyYahFMKLOFnkTfls5uiEUz10Y=
- endpoint: 192.168.182.114:51820
- allowed ips: 10.0.0.2/32, 0.0.0.0/0
- latest handshake: 11 minutes, 10 seconds ago
- transfer: 129.92 KiB received, 133.28 KiB sent
For the first hop, an ssh to the virtual IP address of the peer interface shows the traffic coming from Host 1's virtual interface.
-
- # ssh [email protected]
- [email protected]'s password:
- Last login: Mon Jan 17 15:33:29 2022
- % who am i
- karl pts/2 2022-01-20 17:12 (10.0.0.1)
For traffic to be routed over wg0, a static route was added to take the traffic off the local network and routed through wg0 for the next hop (192.168.182.115) in the nested configuration:
-
- # route add-host 192.168.182.115 wg0
- # wg show wg1
- interface: wg1
- public key: 0N8dqLe9PjOk8cgua7R9Gv2yXd6H+Sq+olhXK6vpKjQ=
- private key: (hidden)
- listening port: 51821
- fwmark: 0xca6c
- peer: FnyyOlpm49pM3I/NGPPvd/3q+OfEiZGeSbAtHDsK62c=
- endpoint: 192.168.182.115:51821
- allowed ips: 172.23.0.4/32, 0.0.0.0/0
- latest handshake: 22 minutes, 8 seconds ago
- transfer: 88.88 KiB received, 93.52 KiB sent
For the second hop an ssh to the virtual interface of Host 3 shows the traffic coming from Host 1's virtual interface, but ssh to the IP address of Host 3 shows the traffic coming from Host 2's regular ethernet, i.e., making it appear that the traffic is originating from Host 2, when in fact it originated at Host 1.
-
- # ssh [email protected]
- [email protected]'s password:
- Last login: Thu Jan 20 17:22:43 2022 from 172.23.0.3
- [karl@WG3~]$ who am i
- karl pts/1 2022-01-20 17:23 (172.23.0.3)
- # ssh [email protected]
- [email protected]'s password:
- Last login: Thu Jan 20 17:23:43 2022 from 172.23.0.3
- [karl@WG3~]$ who am i
- karl pts/1 2022-01-20 17:23 (192.168.182.114)
For traffic to be routed over wg1, a static route was added to take the traffic off the local network and routed through wg1 for the next hop (192.168.182.116) in the nested configuration:
-
- # route add-host 192.168.182.116 wg1
- # wg show wg2
- interface: wg2
- public key: 0N8dqLe9PjOk8cgua7R9Gv2yXd6H+Sq+olhXK6vpKjQ=
- private key: (hidden)
- listening port: 51822
- fwmark: 0xca6e
- peer: eP2akRLPYyQcXR6CIpkjWJqKoJtE3FjvolDK5IOq1Ss=
- endpoint: 192.168.182.116:51822
- allowed ips: 10.10.10.6/32, 0.0.0.0/0
- latest handshake: 1 minute, 12 seconds ago
- transfer: 124 B received, 828 B sent
For the third hop an ssh to the virtual interface of Host 4 shows the traffic coming from Host 1's virtual interface again, but ssh to the IP address of Host 4 shows the traffic coming from Host 3's regular ethernet, i.e., making it appear that the traffic is originating from Host 3, when in fact it again originated at Host 1.
-
- [root@localhost wireguard]# ssh [email protected]
- [email protected]'s password:
- Last login: Thu Jan 20 16:16:02 2022 from 10.10.10.5
- [karl@wg4~]$ who am i
- karl pts/1 2022-01-20 17:55 (10.10.10.5)
- # ssh [email protected]
- [email protected]'s password:
- Last login: Thu Jan 20 17:55:11 2022 from 10.10.10.5
- [karl@wg4~]$ who am i
- karl pts/1 2022-01-20 17:55 (192.168.182.115)
For the virtual interface of Host 2 the virtual network interface wg0 was created using:
-
- # wg
- interface: wg0
- public key: dabeyd3hRa5qylVCoWyYahFMKLOFnkTfls5uiEUz10Y=
- private key: (hidden)
- listening port: 51820
- fwmark: 0xca6c
- peer: 0N8dqLe9PjOk8cgua7R9Gv2yXd6H+Sq+olhXK6vpKjQ=
- endpoint: 192.168.182.113:51820
- allowed ips: 10.0.0.1/32, 0.0.0.0/0
- latest handshake: 1 minute, 48 seconds ago
- transfer: 170.83 KiB received, 176.95 KiB sent
For the virtual interface of Host 3 the virtual network interface wg1 was created using:
-
- # wg
- interface: wg1
- public key: FnyyOlpm49pM3I/NGPPvd/3q+OfEiZGeSbAtHDsK62c=
- private key: (hidden)
- listening port: 51821
- fwmark: 0xca6c
- peer: 0N8dqLe9Pj0k8cgua7R9Gv2yXd6H+Sq+olhXK6vpKjQ=
- endpoint: 192.168.182.114:48725
- allowed ips: 172.23.0.3/32, 0.0.0.0/0
- latest handshake: 1 minute, 53 seconds ago
- transfer: 125.57 KiB received, 186.98 KiB sent
For the virtual interface of Host 3 the virtual network interface wg1 was created using:
-
- # wg
- interface: wg2
- public key: eP2akRLPYyQcXR6CIpkjWJqKoJtE3FjvolDK5IOq1Ss=
- private key: (hidden)
- listening port: 51822
- fwmark: 0xca6c
- peer: 0N8dqLe9Pj0k8cgua7R9Gv2yXd6H+Sq+olhXK6vpKjQ=
- endpoint: 192.168.182.115:51822
- allowed ips: 10.10.10.5/32, 0.0.0.0/0
- latest handshake: 1 minute, 56 seconds ago
- transfer: 11.00 KiB received, 24.34 KiB sent
Because WIREGUARD VPN uses configuration files, the private and public keys for each host are maintained in the configuration files. This is equivalent to the public and private keys being used to identify the various transit nodes in the Tor implementation in which there is a lot more routing information visible on the starting host, specifically, the IP addresses of each node. However, when the current Tor implementation gets a circuit created, the IP addresses of the transit nodes are only available with the use of a command-line application, for example, but not limited to, Nyx, which looks up the information that is used to create the onions on the access node and displays it to an operator. Nyx is provided as open source software. In the public Tor network, for example, but not limited to, this would be the guardian or access node that would be on an originating client using the Tor browser. For the TELOS GHOST network it would be the access node.
In the nested tunneling approach in
In the embodiment in
Network Layout.
The WIREGUARD protocol network layout of the present embodiment mimics the traditional TELOS GHOST network layout shown, for example, in
Virtual Private Clouds.
The virtual private clouds are essentially unchanged from the exemplary traditional TELOS GHOST network deployment. Specifically, in the original Tor TELOS GHOST network, Virtual Private Clouds (VPCs) were created to contain the Elastic Compute Cloud (EC2) instances over which the Tor protocol transferred data. The access nodes 386 and transit nodes 387′ were generally located together in a common region (for example, us-east-1) to reduce latency and the exit nodes 389 were placed in the desired exit region. No change was required for the WIREGUARD protocol. For the purposes of the WIREGUARD protocol, all nodes were still contained within us-east-1 but are dynamically created/destroyed during scaling events.
Security Groups were modified for the WIREGUARD implementation.
Updated Security Groups.
The security group necessary to allow the WIREGUARD nodes to communicate over UDP are added to the VPCs in which they are located.
Nodes.
The nodes used for the WIREGUARD onion routing are the access, transit, and exit nodes.
Access Nodes.
The access node 555 is connected to the OpenVPN tunnel 557 with an authentication interface (including, but not limited to RADIUS, Lightweight Directory Access Protocol (LDAP) and local authentication), and the three tunnels added to its specification. OpenVPN utilizes “plugins” for authentication and the authentication mechanisms that have been implemented include: 1) LOCAL (i.e., username/password on the access node, which is good for testing, but is not scalable); 2) RADIUS—through a RADIUS server to a back end (e.g., Windows Active Directory); and 3) LDAP—either through an LDAP interface (e.g., Windows Active Directory) or any other LDAP server.
The last digit of the tunnel's number corresponds to the last digit of the third value in the CIDR block (the X in 10.0.10X.0/24) as well as the last digit of the UDP listening port (the X in 5182X).
-
- ovpn_radius_conf_path: “/etc/openvpn/pam_radius_auth.conf”
- # The expected spot on a Configurator access node
- #ovpn_radius_conf_path: “/etc/raddb/server/pam_radius_auth.conf”
- tunnels:
- wg0:
- tun_cidr_block: “10.0.100.0/24”
- tun_peer: “{{ghost_inventory_group}}tr01”
- listen_port: 51820
- wg1:
- tun_cidr_block: “10.0.101.0/24”
- tun_peer: “{{ghost_inventory_group}}tr02”
- listen_port: 51821
- wg2:
- listen_port: 51822
- tun_cidr_block: “10.0.102.0/24”
- tun_peer: “{{ghost_inventory_group}}ex01”
Transit Nodes.
The transit nodes 560, 565 have their corresponding peers referring to the access node 555. As seen in
-
- guardtr01:
- ec2_name_tag: “guardtr01”
- aws_region: “us-east-1”
- ghost_node_type: “transit”
- node index: 1
- tunnels:
- wg0:
- tun_peer: “{{ghost_inventory_group}}ac01”
- guardtr02:
- ec2_name_tag: “guardtr02”
- aws_region: “us-east-1”
- ghost_node_type: “transit”
- node index: 2
- tunnels:
- wg1:
- tun_peer: “{{ghost_inventory_group}}ac01”
Exit Node.
Like the transit nodes 560, 565, the exit node 570 has its corresponding peer referring to the access node.
-
- guardex01:
- #Northern Virginia
- ec2_name_tag: “guard_guardex01”
- aws_region: “us-east-1”
- ghost_node_type: “exit”
- node index: 1
- tunnels:
- wg2:
- tun_peer: “{{ghost_inventory_group}}ac01”
Authentication Infrastructure.
The authentication infrastructure for the WIREGUARD protocol is the same as the traditional TELOS GHOST network deployment—options include a Windows Domain Controller (DC) and AWS Managed Active Directory (MAD) or an LDAP server.
Implementation.
There are two main differences in the WIREGUARD protocol from the traditional TELOS GHOST network deployment: 1) removal of all Tor software related activities, and 2) installation of the nested WIREGUARD tunnels.
Nested WIREGUARD Tunnels.
The installation and configuration of the WIREGUARD VPN is as shown above. In the scaling implementation, when a triplet of nodes is created, the creator (the scaling infrastructure) also computes peer keys and distributes these along with the port assignments for both the WIREGUARD tunnels and the iptables forwarding rules.
Installation.
The installation consists of the installation of required packages, anti-spoofing changes to AWS for the exits, to allow for source/destination address IP rewriting through the iptables rules enabling IP forwarding, adding loopback to the exit node for DNSMASQ requirements and configuring DNSMASQ for the exit node.
Configuration.
The configuration consists of setting up the peer keys on all the nodes, using the public keys from the peers along with instantiating template files to create the corresponding/etc/wireguard/wgX.conf files. The WIREGUARD services are started and enabled to automatically restart when the nodes reboot.
It should be noted that the wgX.conf files contain the necessary iptables filtering rules. Additionally, while the example shows the tunnel relationships between directly non-communicating nodes (for example, the access node 555 and the second transit node 565 and the exit node 570), the generation of the wgX.conf files uses only the corresponding public and private keys and iptables UDP forwarding ports to ensure node anonymity, which is possible because each node only knows the previous and subsequent nodes in the circuit.
Access Node OpenVPN Server.
The access node OpenVPN server is installed and configured on the access node 555 with the required packages, the necessary SSL certificates, private key, etc. and templating out the required files for the ovpn_server.conf and rule-tunX files and creating the /etc/pam.d/openvpn and/etc/openvpn/ucn.pl files. The corresponding OpenVPN tunnel 557 is then enabled and started as a service as well.
Network Deployment.
In the following embodiment description, the deployment is described as following a traditional TELOS GHOST network deployment process with respect to AWS or GCP network configuration.
Inventory.
Using an Infrastructure As Code (IaC) approach with tools such as Terraform or Ansible, a network inventory is created that contains the VPS, a management proxy/bastion host, authentication infrastructure (Windows AD/Managed Active Directory or an LDAP server), incoming region load balancer(s), access region VPCs, transit region VPCs, exit region VPCs and outgoing region Name Address Translation (NAT) gateways. Additional infrastructure components to handle the Circuit Provisioning Platform (CPP) and Application Auto-Scaling Engine (AASE) are created utilizing the individual CSPs capabilities.
Generate Node Certificates.
OpenVPN SSL Certificates are used for the OpenVPN tunnel 557 on the access node 555. No other certificates are used.
Install and Configure WIREGUARD VPN.
The WIREGUARD transport circuit is created during the scaling activity by generating code (that is, the lambda operations) that dynamically configure the nodes within the circuits for scalable operation and push the configurations to the EC2 instances as they are created during scaling events:
Operational Considerations.
User Authentication.
Within the WIREGUARD implementation authentication is performed via RADIUS protocol at the client OpenVPN connection on the access node with a Windows Domain Controller (DC) and AWS Managed Active Directory (MAD) or through an LDAP lookup to an LDAP server.
In fact, for this embodiment, a small virtual machine, for example, but not limited to, a Centos Linux 7 was used, but any other version of Linux that supports WireGuard within the kernel can be used. In additional embodiments, for example, large scale systems with many users and high bandwidth requirements, performance testing will be performed to determine the sweet spot of CPU/memory/disk/ethernet interface bandwidth to support any specific number of users.
In
The auto-scaling system 655 is communicatively connected to a serverless, NoSQL database 660, for example, but not limited to, an Amazon DynamoDB, and the application auto-scaling engine 655 is also communicatively connected to a circuit provisioning engine 665, for example, but not limited to, a TELOS GHOST circuit provisioning engine, which is also communicatively connected to the serverless, NoSQL database 660 and an elastic compute cloud web service 670, for example, but not limited to, an Amazon Elastic Compute Cloud (EC2), which is communicatively connected to a dynamic firmware resource 675, for example, but not limited to an AMI dynamic firmware resource. The elastic compute cloud web service 670 is communicatively connected to the first virtual circuit 620 and the second virtual circuit 630.
In the network 600 of
In these implementations, the network load balancer 615 provides an interface for clients, i.e., users, 610 to access the network 600 and the virtual circuits 620, 630, which are also called channels, can be deployed between available regions in the CSPs. A client 610 can connect using a VPN-based software, for example, but not limited to, OpenVPN, IP/Sec, or WIREGUARD to one of the access nodes attached to the load balancer and is authenticated using various methods (for example, SSL certificates, username/password, Pre-Shared Keys, etc.). Circuits can be destroyed on a configurable time-based setting and clients reauthenticate to another access node as needed when a circuit being used is destroyed, allowing for dynamic circuit configuration. All configuration information for the nodes is pushed when they are created. Capacity can be increased or decreased based upon usage metrics. Utilizing the CSP infrastructure allows only the network load balancer and the exit node to require public IP addresses. For an enterprise deployment, all exit nodes in a given location can be placed behind an exit gateway (described below in relation to
Exit Region NAT Gateways vs. IP Addresses For Static IP.
A traditional TELOS GHOST deployment utilizes static IP addresses for the exit locations of the TELOS GHOST networks. This, along with an “exit node IP swap,” which can occur one or more times a day, has allowed the exiting IP address to fluctuate and reduce exposure. Depending on the quantity of users and containerized processes, a NAT Gateway may be preferable to provide a common static IP address for all activity associated with a deployment exiting in a single location. Scaling can be accomplished by running multiple circuits to the VPC to which the NAT Gateway is attached for egress. Multiple user-selectable scaling options are provided and are based on the specific user's needs.
In
In the network 700 of
In these implementations, the network load balancer 715 provides an interface for clients, i.e., users, 710 to access the network 700 and the virtual circuits 720, 730, which are also called channels, can be deployed between available regions in the CSPs. A client 710 can connect using a VPN-based software, for example, but not limited to, OpenVPN, IP/Sec, or WIREGUARD to one of the access nodes attached to the load balancer and is authenticated using various methods (for example, SSL certificates, username/password, Pre-Shared Keys, etc.). Circuits can be destroyed on a configurable time-based setting and clients reauthenticate to another access node as needed when a circuit being used is destroyed, allowing for dynamic circuit configuration. All configuration information for the nodes is pushed when they are created. Capacity can be increased or decreased based upon usage metrics. Utilizing the CSP infrastructure allows only the network load balancer and the exit node to require public IP addresses. In the network 700, all exit nodes in a given location can be placed behind the NAT gateway 785, resulting in only the NAT gateway 785 requiring a public IP address for all traffic.
The use of WIREGUARD is significantly simpler than Tor in its implementation, configuration, and operation. Its installation can be as straightforward as a kernel module in the Linux kernel without any need for compilation of software (for example, the Tor clients and directory authority components). Its configuration requires what amounts to generation and distribution of paired ssh-style keys with port forwarding information. Its operation is inherent with the startup of the nodes. It operates at the network layer (that is, layer 3 of the OSI network model), thus reducing the amount of local network stack traversal required as the data passes through each node.
The interface establishes IP addresses of the virtual tunnel interfaces using: “ciscoasa(config-if)#ip address 192.168.1.10 255.255.255.254”. In addition, the existing “tunnel destination” configuration option is: “ciscoasa(config-if)#tunnel destination 10.1.1.1”, which can possibly be extended to take a port number using: “ciscoasa(config-if)#tunnel destination 10.1.1.1 51821”.
While this implements a static, enterprise-level sort of nested WIREGUARD tunnel configuration, since the virtual tunnel interface configurations are manual, an automated system for management of these devices is also contemplated.
In another embodiment of the presently disclosed subject matter, a public WIREGUARD onion routing (WOR) Network mimics the existing public Tor network architecture with corresponding replacement of circuit configuration information and components to use the WIREGUARD equivalent. Specifically, there would be: 1) directory authority nodes; 2) guard (or access) nodes; 3) relay (or transit) nodes; 4) exit nodes; and beyond the traditional obfuscated (primarily web) traffic of the actual network: 5) hidden (or cloaked) services. In this embodiment, all nodes can appear anywhere on the public internet, with the only requirement being a static public IP address (not a dynamic or ephemeral IP address) and ability to route traffic for the desired range of port numbers. The architecture described below is for a distributed dynamic network, but it can also be implemented in a static configuration as well. Except for the directory authority nodes, for which a mechanism for publication of the IP addresses is needed, all other nodes can be added/removed dynamically from the network.
Nodes, other than the directory authority nodes, can operate in any of the roles (access, transit, or exit), including simultaneously as multiple roles, but are described below with the characteristics specific to the individual types of nodes for each function.
In this embodiment, the directory authority nodes provide the same functionality as in Tor and have been described as “dedicated servers which tell Tor clients which relays make up the Tor network. Information about these directory authorities, located around the world and maintained by super trusted we-know-you-and-have-had-many-beers-with-you TOR volunteers, are hard-coded into Tor.” (source: https://blog.torproject.org/introducing-bastet-our-new-directory-authority/.)
The differences being that the information exchanged between the nodes and the directory authority nodes use WIREGUARD connections (e.g., peer public key(s), IP addresses and ranges of port numbers for iptables forwarding rules, etc.) in addition to any similar bandwidth or probationary period information used to determine when a node is sufficiently “trusted” to be allowed to pass “production” traffic, as with current Tor protocol.
The directory authority nodes use consensus voting (again as similarly performed in the Tor network) to determine available nodes for circuit creation, respond to circuit requests (from guard, or access nodes) transmitting the circuit configuration information to the individual nodes in the resulting circuit. Similar capabilities and alarms for managing the quantity of nodes in the network using reported metrics mentioned above (user count, bandwidth, etc.) can be implemented to allow for dynamic capacity configuration.
Within the public Tor network, nodes can identify what roles they are willing to perform. A guard, or access node, can provide the interface for a client to connect to the network. A list of available access nodes can be requested from the directory authority nodes.
In Tor, this functionality is performed by client software running in a Tor browser on the client device; in TELOS GHOST it is accomplished by client VPN software (e.g., OpenVPN, StrongSwan, WIREGUARD) running on the client device and connecting to a corresponding server running on the access node. Both OpenVPN and StrongSwan (IP/sec) allow for dynamic IP address allocation (using DHCP) and anonymous connectivity and can be used for this capability. The servers on the access node can be configured to send a circuit request to the directory access nodes upon connection and establish the corresponding circuit by configuring the resulting WIREGUARD tunnel endpoints with the returned configuration information.
DNS routing can be used to ensure that the DNS requests are routed to the exit node or any required internal DNS servers that might respond to identify the internal location of hidden or cloaked services. The client VPN software has a capability for receiving pushed DNS lookup information from the server upon connection.
Relay nodes can publish availability and capabilities to directory authority nodes and receive circuit configuration and destruction information in return. Rules for iptables are also provided based upon their location within a specific circuit.
Exit nodes also publish availability and capabilities to directory authority nodes and receive circuit configuration and destruction information in return. Additionally, the exit nodes operate a forwarding DNS server to respond to requests from the access nodes to prevent DNS request leaks at the access nodes.
Hidden (or cloaked) services are servers that are configured to only be available within the WIREGUARD onion routing network when users are connected to an access node. An internal DNS, routing information, and any necessary firewalls/security groups, can be configured to allow connectivity to these servers from within the defined network only.
In an embodiment of the disclosed subject matter, a system including: a network layer peer-to-peer protocol implemented directly in an operating system kernel in a processor and configured to create a virtual circuit to anonymously route network traffic through the virtual circuit. The virtual circuit includes: an access node communicatively connected and configured to receive and send requests to create the virtual circuit; a plurality of transit nodes including: a first transit node communicatively connected to the access node via a first secure virtual private network (VPN) tunnel; a second transit node communicatively connected to the access node via a second secure VPN tunnel where the second secure VPN tunnel is configured to route the network traffic through the first VPN tunnel, and an exit node communicatively connected to the access node via a third secure VPN tunnel where the third secure VPN tunnel is configured to route the network traffic through the second VPN tunnel and the first VPN tunnel, where the access node, each of the plurality of transit nodes, and the exit node each know only a previous node and a following node in the virtual circuit using port forwarding rules at the network layer.
In an embodiment of the disclosed subject matter, an obfuscated persona management system including: a network load balancer communicatively connected to a network and the network load balancer being configured to automatically connect to at least one virtual circuit on the network in response to a request to connect and each at least one virtual circuit with a plurality of nodes including an access node, a first transit node communicatively connected to the access node, a second transit node communicatively connected to the first transit node, and an exit node communicatively connected to the second transit node. The obfuscated persona management system further including: an auto-scaling component communicatively connected to the at least one virtual circuit and configured to monitor a level of network usage and request a change in a number of virtual circuits in the at least one virtual circuit; a provisioning engine communicatively connected to the auto-scaling component and the load balancer and configured to effect the change in the number of virtual circuits in the at least one virtual circuit; at least one computing unit including a bus communicatively connected to each of a processor, a random-access memory, a long-term memory, and a communication unit communicatively connect to the network; and a network layer peer-to-peer protocol implemented as executable software code directly in an operating system kernel in the at least one computing unit, where, when executed by the processor, creates the at least one virtual circuit to anonymously route network traffic across the at least one virtual circuit using a plurality of nested virtual private network tunnels at the network layer.
In an embodiment of the disclosed subject matter, a computer-implemented method of enabling a location obfuscation of network traffic system, the method including: receiving, by a computing device, a request for a virtual secure communication circuit; and determining, by the computing device, availability of the virtual secure communication circuit. If the virtual secure communication circuit is not available, setting up, by the computing device, the virtual secure communication circuit as a private wireguard virtual secure communication circuit including an access node communicatively connected to a first transit node via a first virtual tunnel, the first transit node communicatively connected to a second transit node via a second virtual tunnel through the first virtual tunnel, the second transit node communicatively connected to an exit node via a third virtual tunnel through the first virtual tunnel, and the exit node communicatively connected to a public communications network; and if the virtual secure communication circuit is available, establishing a communication connection over the virtual secure communication circuit between a user device and a target device connected to the public communications network.
While the disclosed subject matter has been described in conjunction with a number of embodiments, it is evident that many alternatives, modifications and variations would be or are apparent to those of ordinary skill in the applicable arts. Accordingly, Applicant intends to embrace all such alternatives, modifications, equivalents, and variations that are within the spirit and scope of the disclosed subject matter described herein.
Claims
1. A system comprising:
- at least one computing unit including a bus communicatively connected to each of a processor, a random-access memory, a long-term memory, and a communication unit communicatively connect a network
- a network layer peer-to-peer protocol implemented as executable software code directly in an operating system kernel in the random-access memory in the processor and configured, when executed by the processor, to create a virtual circuit to anonymously route network traffic through the virtual circuit at a network layer of the operating system kernel, the virtual circuit comprising:
- an access node communicatively connected and configured to receive and send requests to create the virtual circuit via the processor at the network layer of the operating system kernel; and
- a plurality of transit nodes including: a first transit node communicatively connected to the access node at the network layer of the operating system kernel via a first secure virtual private network (VPN) tunnel; a second transit node communicatively connected to the access node at the network layer of the operating system kernel via a second secure VPN tunnel where the second secure VPN tunnel is configured to route the network traffic through the first VPN tunnel, and an exit node communicatively connected to the access node at the network layer of the operating system kernel via a third secure VPN tunnel where the third secure VPN tunnel is configured to route the network traffic through the second VPN tunnel and the first VPN tunnel, where the access node, each of the plurality of transit nodes, and the exit node each know only a previous node and a following node in the virtual circuit using port forwarding rules at the network layer of the operating system kernel.
2. The system of claim 1, wherein the operating system kernel is a Linux kernel.
3. The system of claim 1, wherein each of the first secure VPN tunnel, the second secure VPN tunnel, and the third secure VPN tunnel operate at the operating system kernel level configured in a nested configuration.
4. The system of claim 3, wherein each node in the virtual circuit knows only the previous and following nodes in the virtual circuit using port forwarding rules at the network layer.
5. The system of claim 1, wherein a client device is communicatively connected to the access node and a target device is communicatively connected to the exit node and both are located outside of the virtual circuit, and each have a unique IP address.
6. The system of claim 5, wherein the exit node is further configured to receive and send messages over the virtual circuit between the client device and the target device.
7. The system of claim 6, wherein the virtual circuit comprises a VPN between the client device and the access node.
8. The system of claim 1, wherein the first transit node is communicatively connected to the access node at the network layer of the operating system kernel via a first secure virtual private network (VPN) tunnel further comprises:
- the first transit node is communicatively connected to the access node via the first secure VPN tunnel over a public IP address of the first transit node.
9. The system of claim 8, wherein the second transit node is communicatively connected to the access node at the network laver of the operating system kernel via a second secure VPN tunnel where the second secure VPN tunnel is configured to route traffic through the first VPN tunnel further comprises:
- the second transit node is communicatively connected to the access node via the second secure VPN tunnel through the first VPN tunnel to the public IP address of the second transit node.
10. The system of claim 9, wherein the exit node is communicatively connected to the access node at the network layer of the operating system kernel via a third secure VPN tunnel where the third secure VPN tunnel is configured to route traffic through the second VPN tunnel and the first VPN tunnel further comprises:
- the exit node is communicatively connected to the access node at the network laver of the operating system kernel via the second secure VPN tunnel through the second VPN tunnel and the first VPN tunnel to the public IP address of the exit node.
11. The system of claim 1, wherein each of the first secure VPN tunnel, the second secure VPN tunnel, and the third secure VPN tunnel comprises:
- a secure wireguard VPN tunnel.
12. The system of claim 1, further comprising an obfuscated persona management system comprising:
- a network load balancer communicatively connected to the network and the network load balancer being configured to automatically connect to an at least one virtual circuit on the network in response to a request to connect and the at least one virtual circuit with a plurality of nodes including the access node, the first transit node communicatively connected to the access node, the second transit node communicatively connected to the first transit node, and the exit node communicatively connected to the second transit node;
- an auto-scaling component communicatively connected to the at least one virtual circuit and configured to monitor a level of network usage and request a change in a number of virtual circuits in the at least one virtual circuit;
- a provisioning engine communicatively connected to the auto-scaling component and the load balancer and configured to effect the change in the number of virtual circuits in the at least one virtual circuit;
- at least one computing unit including a bus communicatively connected to each of a processor, a random-access memory, a long-term memory, and a communication unit communicatively connect to the network; and
- the network layer peer-to-peer protocol implemented as executable software code directly in an operating system kernel in the at least one computing unit, where, when executed by the processor, creates the at least one virtual circuit to anonymously route network traffic across the at least one virtual circuit using a plurality of nested virtual private network tunnels at a network layer.
13. The obfuscated persona management system of claim 12 wherein the access node is communicatively connected to a client node.
14. The obfuscated persona management system of claim 13 wherein the exit node is communicatively connected to a target node.
15. The obfuscated persona management system of claim 14 further comprises:
- a network address translation (NAT) gateway communicatively connected between the exit node and the target node.
16. The obfuscated persona management system of claim 12 wherein the plurality of nested virtual private network tunnels comprises:
- a first secure virtual private network (VPN) tunnel communicatively connected between the access node and the first transit node,
- a second secure VPN tunnel communicatively connected between the access node and the second transit node, where the second secure VPN tunnel is configured to route the network traffic through the first secure VPN tunnel, and
- a third secure VPN tunnel communicatively connected between the access node and the exit node, where the third secure VPN tunnel is configured to route the network traffic through the second secure VPN tunnel and the first VPN tunnel, where the access node, the first transit node, the second transit node, and the exit node each know only a previous node and a following node in the at least one virtual circuit using port forwarding rules at the network layer.
17. The obfuscated persona management system of claim 16 further comprises:
- a network address translation (NAT) gateway communicatively connected between the exit node and a target node.
18. The obfuscated persona management system of claim 17, wherein the NAT gateway has a public IP address and is located outside of the plurality of nested virtual private network tunnels communicatively.
19. The system of claim 1 wherein the network layer peer-to-peer protocol comprises:
- a computer-implemented method of enabling a location obfuscation of network traffic system, the method comprising:
- receiving, by the processor, a request for a virtual secure communication circuit;
- determining, by the processor, availability of the virtual secure communication circuit;
- if the virtual secure communication circuit is not available, setting up, by the processor, the virtual secure communication circuit as a private wireguard virtual secure communication circuit including the access node communicatively connected to the first transit node via a first virtual tunnel, the first transit node communicatively connected to the second transit node via a second virtual tunnel through the first virtual tunnel, the second transit node communicatively connected to the exit node via a third virtual tunnel through the first virtual tunnel, and the exit node communicatively connected to a public communications network; and if the virtual secure communication circuit is available, establishing a communication connection over the virtual secure communication circuit between a user device and a target device connected to the public communications network.
20. The system of claim 19 further comprising:
- determining, by the processor, whether the virtual secure communication circuit is still needed; and
- if it is determined that the virtual secure communication circuit is not needed tearing down, by the processor, the virtual secure communication circuit.
21. The system of claim 11, wherein each of the first secure VPN tunnel, the second secure VPN tunnel, and the third secure VPN tunnel comprises:
- a third secure wireguard VPN tunnel being nested within a second secure wireguard VPN tunnel, the second secure wireguard VPN tunnel and the third secure wireguard VPN tunnel being nested within a first secure wireguard VPN tunnel.
| 6266704 | July 24, 2001 | Reed et al. |
| 7590245 | September 15, 2009 | Levitan |
| 8832311 | September 9, 2014 | Reynolds et al. |
| 8904036 | December 2, 2014 | Reynolds et al. |
| 9130911 | September 8, 2015 | Reynolds et al. |
| 10225289 | March 5, 2019 | Tucker, IV |
| 20230370425 | November 16, 2023 | Vandenbussche |
| 20240364515 | October 31, 2024 | Haddad |
- David M. Goldschlag et al., “Hiding Routing Information”, Workshop on Information Hiding, Cambridge, UK, May 1996, pp. 1-14.
- Roger Dingledine et al., “Tor: The Second-Generation Onion Router”, USENIX Association, Proceedings of the 13th USENIX Security Symposium, San Diego, CA, USA, Aug. 9-13, 2004, 18 pages.
- Wikipedia, “Onion Routing”, https://en.wikipedia.org/wiki/Onion_routing, last downloaded Oct. 7, 2024, 5 pages.
- Jason A. Donenfeld, “WireGuard: Next Generation Kernel Network Tunnel”, https://www.wireguard.com/papers/wireguard.pdf, Jun. 1, 2020, pp. 1-20.
- Jason A. Donenfeld, “WireGuard: fast, modern, secure VPN tunnel”, https://www.wireguard.com, last downloaded Oct. 9, 2024.
- SSH Academy, “What is SSH Public Key Authentication”, https://www.ssh.com/academy/ssh/public-key-authentication, last downloaded Oct. 9, 2024.
- Jason A. Donenfeld, “Protocol & Cryptography—WireGuard”, https://www.wireguard.com/protocol/, 9 pages, last downloaded Oct. 9, 2024.
- Bobcares, “Iptables udp port forwarding—Easy way to do it!”, https://bobcares.com/blog/iptables-udp-port-forwarding/, 9 pages, last downloaded Oct. 9, 2024.
- Albert L. Donaldson et al., “Covert Channels in Trusted LANs”, The 11th NBS / NCSC National Computer Security Conference, pp. 226-232. Oct. 17-20, 1988, Baltimore, MD.
- Roger Dingledine, “Adaptive throttling of Tor clients by entry guards”, Tor Tech Report 2010-09-001, The Tor Project, Sep. 19, 2010, pp. 1-5.
- Roger Dingledine, “Better guard rotation parameters”, Tor Tech Report 2011-08-001, The Tor Project, Aug. 20, 2011, pp. 1-3.
- Roger Dingledine et al., “Design of a blocking-resistant anonymity system”, Tor Tech Report 2006-11-001, The Tor Project, Nov. 2006, pp. 1-25.
- Karsten Loesing, “Case study: Learning whether a Tor bridge is blocked by looking at its aggregate usage statistics, Part One”, Tor Tech Report 2011-09-002, The Tor Project, Sep. 15, 2011, pp. 1-6.
- Nicholas Hopper, “Protecting Tor from botnet abuse in the long term”, Tor Tech Report 2013-11-001, The Tor Project, Nov. 20, 2013, pp. 1-14.
- Karsten Loesing, “What fraction of our bridges are not reporting usage statistics?”, Tor Tech Report 2012-04-001, The Tor Project, Apr. 30, 2012, pp. 1-6.
- Karsten Loesing, “What if the Tor network had 50,000 bridges?”, Tor Tech Report 2012-03-001, The Tor Project, Mar. 9, 2012, pp. 1-3.
- Karsten Loesing, “An Analysis of Tor Bridge Stability—Making BridgeDB give out at least one stable bridge per user”, Tor Tech Report 2011-10-001, The Tor Project, Oct. 31, 2011, pp. 1-9.
- Karsten Loesing, “Analysis of Circuit Queues in Tor”, Tor Tech Report 2009-08-001, The Tor Project, Aug. 25, 2009, pp. 1-6.
- Philipp Winter, “Design Requirements for a Tor Censorship Analysis Tool”, Tor Tech Report 2013-02-001, The Tor Project, Feb. 6, 2013, pp. 1-5.
- Roger Dingledine et al., “Challenges in deploying low-latency anonymity”, Tor Tech Report 2005-02-001, The Tor Project, Feb. 2005, pp. 1-22.
- Karsten Loesing, “Reducing the Circuit Window Size in Tor”, Tor Tech Report 2009-09-002, The Tor Project, Sep. 20, 2009, pp. 1-5.
- Karsten Loesing, “Counting daily bridge users”, Tor Tech Report 2012-10-001, The Tor Project, Oct. 24, 2012, pp. 1-13.
- Sebastian Hahn et al., “Privacy-preserving Ways to Estimate the Number of Tor Users”, Tor Tech Report 2010-11-001, The Tor Project, Nov. 30, 2010, pp. 1-15.
- Karsten Loesing, “Overview of Statistical Data in the Tor Network”, Tor Tech Report 2011-03-001, The Tor Project, Mar. 14, 2011, pp. 1-13.
- Steven J. Murdoch, “Comparison of Tor Datagram Designs”, Tor Tech Report 2011-11-001, The Tor Project, Nov. 7, 2011, pp. 1-15.
- Steven J. Murdoch, “Datagram Testing Plan”, Tor Tech Report 2012-03-002, The Tor Project, Mar. 16, 2012, pp. 1-3.
- George Danezis, “An anomaly-based censorship-detection system for Tor”, Tor Tech Report 2011-09-001, The Tor Project, Sep. 9, 2011, pp. 1-3.
- Sebastian Hahn, “Different Ways to Use a Bridge”, Tor Tech Report 2011-11-002, The Tor Project, Nov. 29, 2011, pp. 1-4.
- Karsten Loesing, “Measuring the Tor Network, Evaluation of Relays from Public Directory Data”, Tor Tech Report 2009-06-001, The Tor Project, Jun. 22, 2009, pp. 1-8.
- Karsten Loesing, “Measuring the Tor network, Evaluation of Client Requests to the Directories”, Tor Tech Report 2009-06-002, The Tor Project, Jun. 25, 2009, pp. 1-11.
- Antonela Debiasi et al., “Addressing Denial of Service Attacks on Free and Open Communication on the Internet: Interim Report 1”, Tor Tech Report 2018-11-001, The Tor Project, Nov. 19, 2018, pp. 1-55.
- Cecylia Bocovich et al., “Addressing Denial of Service Attacks on Free and Open Communication on the Internet: Final report”, Tor Tech Report 2019-05-001, The Tor Project, May 31, 2019, pp. 1-33.
- Nick Mathewson, “Denial-of-service attacks in Tor: Taxonomy and defenses”, Tor Tech Report 2015-10-001, The Tor Project, Oct. 29, 2015, pp. 1-9.
- George Kadianakis et al., “Extrapolating network totals from hidden-service statistics”, Tor Tech Report 2015-01-001, The Tor Project, Jan. 31, 2015, pp. 1-10.
- Roger Dingledine, “Five ways to test bridge reachability”, Tor Tech Report 2011-12-001, The Tor Project, Dec. 1, 2011, pp. 1-6.
- Karsten Loesing, “Comparison of GeoIP Databases for Tor”, Tor Tech Report 2009-10-001, The Tor Project, Oct. 23, 2009, pp. 1-6.
- David Goulet et al., “Hidden-service statistics reported by relays”, Tor Tech Report 2015-04-001, The Tor Project, Apr. 28, 2015, pp. 1-13.
- Babatunde Okunoye, “Censored Continent: Understanding the use of tools during Internet censorship in Africa: Cameroon, Nigeria, Uganda and Zimbabwe as case studies.” Technical Report 2020-07-001, OTF, The Tor Project, Jul. 31, 2020, 31 pages.
- Karsten Loesing et al., “Evaluation of a libutp-based Tor Datagram Implementation”, Tor Tech Report 2013-10-001, The Tor Project, Oct. 30, 2013, pp. 1-11.
- Roger Dingledine, “Measuring the safety of the Tor network”, Tor Tech Report 2011-02-001, The Tor Project, Feb. 6, 2011, pp. 1-5.
- Karsten Loesing, “Measuring the Tor Network from Public Directory Information”, Tor Tech Report 2009-08-002, The Tor Project, Aug. 7, 2009, pp. 1-12.
- Iain R. Learmonth et al., “Tor Metrics Data Collection, Aggregation, and Presentation”, Tor Tech Report 2019-03-001, The Tor Project, Mar. 25, 2019, pp. 1-25.
- Iain R. Learmonth et al., “Towards Modernising Data Collection and Archive for the Tor Network”, Tor Tech Report 2018-12-001, The Tor Project, Dec. 19, 2018, pp. 1-26.
- George Kadianakis, Packet Size Pluggable Transport and Traffic Morphing, Tor Tech Report 2012-03-004, The Tor Project, Mar. 13, 2012, pp. 1-7.
- Roger Dingledine, “Overhead from directory info: past, present, future”, Tor Tech Report 2009-02-001, The Tor Project, Feb. 16, 2009, pp. 1-3.
- Roger Dingledine et al., “Performance Improvements on Tor or, Why Tor is slow and what we're going to do about it”, Tor Tech Report 2009-11-001, The Tor Project, Nov. 9, 2009, pp. 1-29.
- Steven J. Murdoch et al., “Pluggable Transports Roadmap”, Tor Tech Report 2012-03-003, The Tor Project, Mar. 17, 2012, pp. 1-6.
- Karin Herm, “Privacy analysis of Tor's in-memory statistics”, Tor Tech Report 2017-04-001, The Tor Project, Apr. 2017, pp. 1-26.
- Karsten Loesing, “An analysis of Tor Relay Stability”, Tor Tech Report 2011-06-001, The Tor Project, Jun. 30, 2011, pp. 1-12.
- Nick Mathewson et al., “Towards Side Channel Analysis of Datagram Tor vs Current Tor”, Tor Tech Report 2018-11-002, The Tor Project, Nov. 27, 2018, pp. 1-9.
- Roger Dingledine, “Strategies for getting more bridge addresses”, Tor Tech Report 2011-05-001, The Tor Project, May 13, 2011, pp. 1-3.
- Runa A. Sandvik, “Forensic Analysis of the Tor Browser Bundle on OS X, Linux, and Windows”, Tor Tech Report 2013-06-001, The Tor Project, Jun. 28, 2013, pp. 1-13.
- Roger Dingledine, “Ten ways to discover Tor bridges”, Tor Tech Report 2011-10-002, The Tor Project, Oct. 31, 2011, pp. 1-7.
- Mike Perry, “TorFlow: Tor Network Analysis”, Tor Tech Report 2009-08-003, The Tor Project, Aug. 7, 2009, pp. 1-18.
- Virgil Griffith, “Tor growth rates and improving Torperf throughput”, Tor Tech Report 2014-10-001, The Tor Project, Oct. 4, 2014, pp. 1-11.
- Jacob Appelbaum, “Tor and NAT devices: increasing bridge & relay reachability or, enabling the use of NAT-PMP and UPnP by default”, Tor Tech Report 2012-08-001, The Tor Project, Aug. 22, 2012, pp. 1-5.
- Karsten Loesing et al., “Requirements and Software Design for a Better Tor Performance Measurement Tool”, Tor Tech Report 2013-10-002, The Tor Project, Oct. 30, 2013, pp. 1-11.
- Karsten Loesing. “Performance of Requests over the Tor Network”, Tor Tech Report 2009-09-001, The Tor Project, Sep. 22, 2009, pp. 1-7.
- Karsten Loesing et al., “Virtual Private Services”, Tor Tech Report 2008-07-001, The Tor Project, Jul. 25, 2008, pp. 1-13.
- Karsten Loesing, “Measuring the Tor Network—Evaluation of Bridges and Their Usage in Tor”, Tor Tech Report 2009-06-003, The Tor Project, Jun. 22, 2009, pp. 1-3.
- Sebastian Hahn et al., “Measuring the Tor Network—Alternative Requirements for Relay Flags”, Tor Tech Report 2009-04-001, The Tor Project, Apr. 11, 2009, pp. 1-6.
Type: Grant
Filed: Jul 11, 2024
Date of Patent: Sep 29, 2026
Assignee: TELOS CORPORATION (Ashburn, VA)
Inventors: Karl A. Nyberg (Ashburn, VA), David R. Ryan (Reston, VA), Thomas Badders (Ashburn, VA)
Primary Examiner: Mohamed A. Wasel
Application Number: 18/770,117
International Classification: H04L 9/40 (20220101); H04L 12/46 (20060101);
