MyLAD
takes you back to before the Internet
How It Works | Download LAD | Support | LAD Security | Features & Uses | Resources | Members | User Guide
Decrypting TLSEncrypted "Secure DNS"In recent years TLS-encryption has been applied to DNS messaging, which in effect hides the DNS messages from network admins and and prevents them from restricting network traffic by domain name. This allows anyone from students wanting to access improper material to malware purveyors wanting to command and spread the reach of their malicious programs to skirt domain access controls, hiding the domains with which they are corresponding from the networks domain access controls. LAD returns control over domain access to the network by baring the contents of DNS requests and other DNS messages and thereby rendering them detectable, trackable and blockable. It simply appears to the malware, adware and spyware that their requests have merely timed out, likely due to temporary network connectivity issues, but they have, in fact, timed out permanently. LAD now integrates TLS decryption into its robust suite of features for network management, security and communications. Demand for greater security and privacy has broadened the application of TLS (formerly SSL) encryption to Internet communications, yet it hamstrung many secrurity and monitoring devices and applications, that relied on being able to examine the contents of packets in order to detect and block threats, examine network traffic for signatures and monitor activity. Malware and other 'ware developers were quick to notice and take advantage of the camouflage that the ubiquity of TLS-encryption afforded them, adopting it for their malicious communications in order to thwart the efforts of network admins to keep them out. LAD's ability to decrypt TLS encrypted traffic on the network exposes the commingling of nefarious traffic among legitimate, returning network access control once again to the network owners and administrators. A Short Primer on TLS EncryptionTLS encryption relies on certificates, public keys and private keys. When starting a TLS-encrypted session, the client and the server first negotiate which key to use to encrypt the session. This starts when the client (typically a browser) uses the public key (available from the server's certificate) to encrypt and send a session encryption key of its choice to the server. The server then decrypts the transmission from the client using the private key to obtain the session encryption key to use to encrypt the TLS session's communications. It is worth pointing out that the session encryption key utilized for TLS is typically rather short, in the range of 40 bytes. This encryption scheme is also opaque to the user, as it is the browser that selects the session encryption key and the user can only hope that it uses a good one, and that it would not store the key beyond the current TLS session or transmit to any other destination than the counterparty server. The user actually has no control or oversight over the session encryption key, its composition or whether it persists beyond the current session. Certificates and Private KeysEvery TLS session requires a server to provide a certificate. A certificate is simply a file generated by a so-called certificate authority (CA) that contains information about the server, such as domain name, address and other auxiliary information and also includes two necessary components, a public key and a signature. Your browser has a certain number of certificate authority's certificates preinstalled. When the browser sees a new certificate coming from a server, it checks its signature. A signature is a set of bytes. Also within the certificate is a set of bytes referred to as "public key." A public key is, in essence, a very long number. Multiplying this very long number in a special way by the number represented by the signature yields a product that is compared to what is expected. If it matches, the browser deems the certificate valid. If deemed valid, the browser proceeds to obtain the public key of the server from its certificate. It take this public key and multiplies it by a set of bytes that the browser generates, which it would use as a session encryption key. The browser sends the result of this multiplication to the server, which in turn multiplies it by its private key. The result is the exact set of bytes as originally generated by the browser to use as a session encryption key. The public key and private key are selected and paired in such a way, that any number multiplied by the public key can be returned its original state by multiplying it by the private key. TLS Decryption with LADDecrypting TLS enhances LAD's packet capture and reporting capabilities. LAD further makes it possible to examine packets — TLS or no TLS — in popular third party applications like Wireshark for forensic examination, analysis, content retrieval, monitoring and debugging, by providing both the packet capture data and the respective keys needed for these third party applications to decrypt them. LAD's ability to decrypt TLS, however, does not interfere with the integrity or security of the TLS-encrypted communications either within the network or going out of it. Communications remain encrypted coming into LAD, and remain encrypted coming out of LAD, maintaining both privacy and security. Read more about how LAD decrypts TLS while maintaining privacy and security with its MITM. |