-
Notifications
You must be signed in to change notification settings - Fork 12
Introduction to Secure DNS based Service Discovery (DNS SSD)
Network Web Sockets allow web pages and applications to create ad-hoc, full-duplex broadcast channels, based on Web Sockets, across the local network by requesting the same channel name.
A Named Web Socket Proxy, which is called a Service Proxy in this document, thus performs three functions:
- to broadcast its own channel peers for a given channel name across the network,
- to discover other channel peers that match its own known channel names in the network, and;
- to establish communication channels between its own channel peers and other channel peers with the same channel name so they can communicate directly with each other.
The result of running these functions is the creation of a web of communication channels between matching channel peers on the local network.
The Network Web Sockets Proxy performs the functions defined above and creates broadcast communication channels by matching channel peers that are requesting the same channel name with each other.
You can read more generally about the Network Web Sockets project on the project home page.
This page discusses the challenges faced in communicating over an untrusted local network and the solution we came up with to secure each function described above against a number of common network attack scenarios.
While it is relatively easy to both discover and establish connections between different service peers in a local network using existing service discovery protocols, the established mechanisms do not provide any security for either the discovery process or the peer connection process. With no transport-level security or encryption of communication channels any peer can connect to any advertised network service simply by listening for any open service advertisements within the network.
Without robust security challenges or encryption it is possible for any third-party in the network to launch a Man-in-the-Middle attack (MITM) against any network service operating within the local network. A third-party node needs to simply listen for any service advertisement broadcasts on the network and they can join any channel they wish as an uninvited, and possibly malicious, third-party peer.
We thus wanted to find a way to enable channel peers to both advertise themselves and discover each other securely, preventing third-party peers from eavesdropping or joining channels they are not invited to. In addition to this we wanted to find a mechanism to establish mutual identity establishment between channel peers to ensure they are not a potentially malicious third-party trying to opportunistically connect to an advertised network service's communications channel.
The requirements for 'Secure Local Network Service Discovery' can be split between the different functions of a Service Proxy (e.g. a 'Network Web Sockets Proxy') as defined in the 'Introduction' section above.
When advertising a channel peer the requirements for a Service Proxy are that:
- The channel name of the channel peer must not be shared in cleartext at any time over the network during the service advertisement process.
- Channel peers should be advertised in such a way that does not let uninvited third-party peers discover the identity of a channel (the channel name) if they are not actively searching the network for the same channel name themselves.
- Channel peers should be advertised in such a way that does not let an uninvited third-party peer connect to an advertised services URL endpoint without first establishing that the remote peer is authorized to connect.
- Any information sent in a service advertisement must be resistant to rainbow-table attack, brute-force attack and replay attack to prevent unauthorized third-parties from gaming the system.
When discovering a channel peer the requirements for the Service Proxy are that:
- It must be possible for the Service Proxy to collect all service advertisements sent from other peers in the network.
- Matching channel names provided in services advertisements to locally known channel names must require the Service Proxy to solve a cryptographic challenge.
- It must not be possible for a Service Proxy to derive the specific channel name of the service advertisement unless it also knows the channel name (presumably because it is also advertising peers with that name on the network).
And finally, when establishing a communication channel between peers the requirements for the Service Proxy are that:
- It must mutually authenticate with the other channel peer, ensuring that both peers know the original channel name and are therefore authorised to connect with each other.
- It must encrypt all communications channels between matching channel peers for the lifetime of the communications (using e.g. public-key cryptography).
We built our solution to this problem statement and the list of requirements on top of Apple's multicast DNS/DNS-SD mechanism (also commonly known as 'mDNS+DNS-SD' or 'Bonjour').
We have called this solution 'Secure DNS-based Service Discovery' (DNS-SSD) and the remainder of this document is intended to introduce in detail how it works and how it fulfills the requirements included above.
When a new channel peer is to be advertised in the network, we generate a unique peer id and use its associated channel name to generate a channel hash using bcrypt.
There are a number of reasons we use bcrypt to generate this channel hash. Firstly, we can use any 'salt' we like when creating the bcrypt hash therefore making the resulting channel hash resistant to rainbow-table attacks. Secondly, the Blowfish algorithm - which underlies the bcrypt hashing process - is computationally expensive which makes bcrypt much more resistant than other hashing algorithms against brute-force attacks.
For an example channel name called myservice and with a randomly generated unique peer id (e.g. 8206439217616170221) and a base64-encoded version of a bcrypt-generated channel hash for myservice (e.g. JDJhJDEyJE0zdWYyMW54MVlrek5KSzlvQnAuemUva0xGblZJTHl2L3RuZ2YubGJMeUVDRjU0UVBpbC5P) we create a standard DNS-SD service advertisement (in this example with a DNS-SD service type of _nws._tcp.local.). We then advertise this DNS-SD data toward the standard network multicast address and port as follows:
_nws._tcp.local. 10 IN PTR 8206439217616170221._nws._tcp.local.
8206439217616170221._nws._tcp.local. 10 IN SRV 10 1 62246 MacBook.local.
MacBook.local. 10 IN A 10.32.1.94
MacBook.local. 10 IN AAAA fe80::c62c:3ff:fe3d:609
8206439217616170221._nws._tcp.local. 10 IN TXT "hash=JDJhJDEyJE0zdWYyMW54MVlrek5KSzlvQnAuemUva0xGblZJTHl2L3RuZ2YubGJMeUVDRjU0UVBpbC5P"Other Service Proxies in the network are then able to discover this service by searching for DNS-SD records with the target service type _nws._tcp.local. according to the standard procedure defined for DNS-SD.
Another peer now wishes to connect with this first peer. The requirement for these peers to connect is for them to use the same channel name (i.e. myservice). The second peer's Service Proxy will then generate its own random unique peer id (e.g. 2942498593785408789) and its own base64-encoded version of a bcrypt-generated channel hash for myservice (e.g. JDJhJDEyJFhWSkxPbXFTN01MRjZPUFBjamR3Ti5ua2R3aXgxVTA3bHpOTGJyVFp2eno0eWViRUpSWnFP). Then this Service Proxy advertises this channel peer with the DNS-SD service advertisement toward the standard multicast DNS address and port as follows:
_nws._tcp.local. 10 IN PTR 2942498593785408789._nws._tcp.local.
2942498593785408789._nws._tcp.local. 10 IN SRV 10 1 62451 OtherPC.local.
OtherPC.local. 10 IN A 10.32.2.28
OtherPC.local. 10 IN AAAA fe80::7aca:39ff:feb4:42c1
2942498593785408789._nws._tcp.local. 10 IN TXT "hash=JDJhJDEyJFhWSkxPbXFTN01MRjZPUFBjamR3Ti5ua2R3aXgxVTA3bHpOTGJyVFp2eno0eWViRUpSWnFP"With two peers now advertising themselves via mDNS/DNS-SD within the local network we can now discover these peers from each Service Proxy host. The next section describes how we resolve these secure DNS-SD advertisements back to channel names which is required before they can then establish communication channels between themselves (described in the subsequent section).
To discover matching peers a Service Proxy must listen for secure DNS-SD service advertisements on the standard multicast DNS address and port.
In the case of Network Web Sockets, we are interested only in discovering services with a DNS-SD service type of _nws._tcp.local.. When we discover one of these DNS-SD advertisements (collectively known as the DNS-SD records) we will then attempt to resolve it against one of our own known channel names. The Service Proxy has a set of known channel names because it is advertising channel peers with certain channel names to the network itself.
A first Service Proxy discovers a matching DNS-SD record and then parses the data in its associated DNS TXT record to obtain the value of the hash parameter contained therein. The Service Proxy then base64-decodes this value to obtain the original bcrypt hash value provided by the advertised channel peer.
The Service Proxy then attempts to match this base64-decoded hash against its own known channel names using the standard bcrypt matching process. Assuming that this Service Proxy has a peer that it is advertising on myservice then comparing the bcrypt-hash value to this string will result in a positive bcrypt key/hash match being made.
At this stage we are thus calculating the answer to the following question (written in pseudo-code):
does service_name('myservice') match bcrypt_hash(base64_decode('JDJhJDEyJFhWSkxPbXFTN01MRjZPUFBjamR3Ti5ua2R3aXgxVTA3bHpOTGJyVFp2eno0eWViRUpSWnFP'))?which will, in this example, resolve as true according to the standard bcrypt key/hash matching process.
This DNS-SD record, having now been matched against a known channel name by the Service Proxy, can now be used to establish a communications channel between the matching local and remote channel peers (described in the next section).
If the result of the question above had been false then the Service Proxy must move on to its next known channel name and continue to try to resolve the DNS record's bcrypt-hash value against all of its known channel names. If no match is found for any of its known channel names then the Service Proxy must ignore this DNS-SD record.
Securing only the advertisement and discovery parts of our system would mean that an attacker could simply bypass the need to resolve DNS-SD records to channel names it knows and proceed directly to establishing a connection with the advertised service using addressing information available within the DNS-SD record.
Therefore we must also implement a connection authentication system at each service's URL endpoint (as advertised in the DNS-SD record) to ensure that only authorized peers (i.e. peers that can prove they know the channel name) can establish connections with each other.
For this purpose we use a password-authenticated key agreement protocol called TLS-SRP.
TLS-SRP has a number of benefits that make it ideal for use in our solution:
- It does not rely on Certification Authorities to be able to establish TLS sessions between peers - something which is highly valuable in a dynamic environment such as a local network and avoids users needing to generate and maintain TLS keys themselves.
- It requires mutual authentication of both parties to ensure they both know the 'password' (i.e. the channel name). If either party does not know the channel name of the discovered service then a TLS session can not be established between the peers. This makes the security at the communication channel equal to the security used in the service discovery process described in the previous section with both channel peer connections being 'keyed' on the same known, shared channel name.
- A by-product of the SRP Authentication process is the exchange of public-key information between peers. Thus we can generate and use per-session unique public keys to establish authenticated and encrypted TLS sessions for each peer connection as a result of the SRP authentication process.
- A third-party can not intercept the 'password' (i.e. the channel name) or the TLS key data during the TLS-SRP setup process making it robust against common network phishing attacks.
To establish a TLS-SRP based session between channel peers, a Service Proxy will request the a DNS-SSD service's URL endpoint as derived from the originally advertised DNS-SD record (e.g. wss://OtherPC.local.:62451). This Service Proxy must then provide the base64-encoded version of the bcrypthash originally provided in that DNS-SD TXT record as the SRP 'username'. It must then use the known channel name (as confirmed during the discovery step described in the previous section) as the SRP 'password'.
If both parties usernames and passwords are identical during the SRP authentication handshake then they will establish a TLS session between themselves based on information derived during this handshake. These two peers can now communicate freely with each other over an encrypted TLS channel that is known to be secure against any kind of network attack.
Our solution makes it possible to advertise, discover and connect service peers in a network without third-parties being able to join the channel or intercept any communication between authorized peers within a channel on the network unless they know or can guess the channel name that is shared between the peers.
The solution described on this page is only as secure as the channel name used by both peers. Thus it is recommended that peers choose and share a suitably pseudo-random channel name to use to establish communications (e.g. a 64 character random series of numbers, letters and symbols).
DNS-SSD, as described on this page, is currently implemented and has been shown to work in the Network Web Sockets Proxy project. The process described above could also theoretically be applied to any other mDNS/DNS-SD service in the future.
If you have any questions on anything discussed on this page please file an issue against the main project and we can discuss further!