TLS interception

TLS interception involves capturing obtaining the plain text of an encrypted transport (usually "HTTPS" using TLS (Transport Layer Security) previously/commonly known as SSL (Secure Sockets Layer) ) either by collecting the encrypted stream and decoding it at a later stage, or more conventionally by posing as the sender (to the reciever) and receiver (to the sender). Security researchers refer to this as a man-in-the-middle attack (MITM) when applied without user knowledge. Vendors that supply equipment for this purpose often refer to the capacity as SSL inspection.

Unencrypted communications data

Despite being an encrypted connection, there are points of communication data that can be gathered or inferred from a TLS stream. Including:

• Client IP address
• Server IP address
• Quirks in the behaviour of the TLS implementations may narrow identification of software used on either side.
• Modern browsers support SNI which means that the browser will specify, in the clear, the host name they need the certificate for
• For https connections the name of the site will usually be encoded into the certificate
• For https: the path or document, being requested from the server will not be known. The user credentials will not be known. The contents will not be known but, absent deliberate obfuscation, the size of data transferred can be inferred.

SNI based site blocking

(see wikipedia: Server Name Indication)

Website blocking for plaintext http sites can be implemented using systems capable of Deep packet inspection to inspect and act on the contents of the http "Host:" request header. These headers are not retrievable within an https session, but most browsers (since 2006-2014) will now send the host in plaintext as part of the SNI certificate request, which can be used to make hostname-based policy decisions.

This capability has been reported to be in use in South Korea in 2019.

An extension to TLS1.3 to allow for encrypted SNI is currently in draft form.

Retrospective decryption

Captured TLS traffic streams, assuming initial handshake is captured, can be retrospectively decrypted if full access to the private keys is available (usually just the server's private key). However, this only works where the session key is derived from the key. In the case of sessions where Diffie-Hellman key exchange is used, the session-key is not derived from the private key and cannot be recreated.

See: wikipedia: Diffie–Hellman key exchange, wikipedia: Perfect forward secrecy

Backdoored algorithms

It has been suggested that the random-number generators included in encryption standards may have been compromised by intelligence agencies during the standardisation process. This would, in theory, allow retrospective decryption of sessions secured using these algorithms. (See wikipedia: Dual EC DRBG as an example.)

Key disclosure

In July 2013 the US Government obtained a search warrant demanding that email provider Lavabit hand over its SSL keys. This would allow a government agency to use a man-in-the-middle attack against a user of the site, or (unless forward security was used) perform retrospective decryption of captured traffic. This order was unsealed in October 2013 as part of an appeal. It is unlikely that this is the first time a private key was secretly demanded by a government.

Private networks

The use of TLS interception is believed to be widespread on private corporate networks - especially those that consist of centrally managed Windows PCs. It is commonly used in network malware detection, adult-content filtering, and network policy enforcement (e.g. monitoring social network use by employees).

• wikipedia: Microsoft Forefront Threat Management Gateway (Technet:Planning for HTTPS inspection)

• https://www.techdirt.com/articles/20120208/03043317695/trustwave-admits-it-issued-certificate-to-allow-company-to-run-man-in-the-middle-attacks.shtml
• wikipedia: M86 Security
  • http://www.m86security.com/products/web_security/secure-web-gateway.asp
• http://www.bluecoat.com/security/security-archive/2012-06-18/growing-need-ssl-inspection

Interception by service providers

In 2013, Nokia was found to be running a MITM attack against its handset owners and decrypting their https traffic by taking advantage of having installed their own certificate as pre-trusted and effectively impersonating secure sites.

Police and security services

TLS interception targeted against specific websites has been observed from countries in the Middle East. However, MITM attacks that involve compelled certificate creation are expected to be rare as the expected consequence on detection would be for the CA in question to have its root certificate revoked. Therefore surreptitious use might only be expected from "compromised" CAs (e.g. Diginotar) or where a rogue CA has been added to an access device (e.g. via malware).

Use of MITM attacks in lawful interception may be currently already used in the UK, where "dynamic triggering" can be used to isolate the network traffic of specific targets.

If country-wide TLS interception was introduced in the UK, without resistance from root certificate distributers, there is a clear moral hazard that it would give a green light for use in countries currently facing challenges in democratic development.

• Use of malware-assisted TLS interception planned by German police against criminal suspects ("Bundestrojaner").
  • https://www.theregister.co.uk/2011/10/12/bundestrojaner/ "Bundestrojaner"
  • https://wikileaks.org/wiki/Skype_and_the_Bavarian_trojan_in_the_middle

• https://www.wired.com/2010/03/packet-forensics/
• http://files.cloudprivacy.net/ssl-mitm.pdf
• https://wikileaks.org/wiki/Skype_and_the_Bavarian_trojan_in_the_middle
• Encrypted connections banned in Pakistan
• Syria uses MITM attack against Facebook
• Iran MITM attack against Google
• Cyberoam use in Jordan
• (are there solid examples of reported use in Saudi Arabia or China?)

Issues for UK nationwide deployment

Statements from the Home Office have been ambiguous regarding whether TLS interception would be implemented by 'black boxes' mandated by the Communications Data Bill. (When asked if the proposed system handled https, Director of the Office for Security and Counter-Terrorism Charles Farr responded "It will.") Therefore inclusion of TLS interception capabilities in the 'black boxes' is still only speculation at this time.

It's also unclear if the intention is for TLS interception would be intended universally, or just in cases where the service is unwilling to be covered by the requirements of UK law. For example, there may be no need to decrypt TLS sessions for Facebook or Google since those companies will be expected to comply with police requests. Only sites outside the reach of the UK would need to be routed via a device for TLS interception.

If the Home Office indeed intends to implement wide-scale TLS interception there are various issues this raises (in addition to the clear civil liberties problems):

• MITM implies active rather than passive interception. This means that the Home Office equipment would essentially become the bottleneck of UK internet access. Broadband Internet connections would not be faster than available capacity of the interception boxes. Which, unless ridiculously over-provisioned, would require investment in interception equipment to match projected capacity need... at a public cost (e.g. 4x over the next 4 years).
  • And, given MITM involves (at least) two TLS connections, a potentially significant amount of latency will be introduced into any real-time applications.
  • Additional DoS risk
• Clearly identifies a CA (certificate authority) issuing fraudulent certificates (end user certificates, or "intermediate roots" - signing certificates)
  • The implication of universal black-box MITM is that the black boxes would either have intermediate certificates onboard with the ability to create new ones on fly, or a the ability to request new TLS credentials over the network.
  • The ability to create false TLS credentials on the fly would be of great interest to criminal groups and extra-national entities.
• Primary distributers of CA certificated (Mozilla, Google, Apple, Microsoft, etc) may chose not to distribute CA certificates known to be issuing fraudulent certificates. Indeed there may be significant pressure not to distribute these certificates in countries outside of the UK.
  • Would likely require additional legislation to compel communications device providers to support compromised certificate creators.
• It's not clear how such a system should work where the certificate of the intercepted site has expired or has been revoked. i.e. it may expose users to a greater risk of criminal fraud.
• Not only will this expose communications data, but will also potentially expose many shared-secret authentication methods (e.g. login passwords).
• Will likely render "Extended Validation" certification moot in the UK.

Intercept-specific Certificate Authority

Assuming a CA is not compelled to risk removal from the distribution list by assigning a signing key to UK law enforcement, another possibility is for the creation of a specific CA that does not appear in international browsers. This certificate could be added to access devices sold in the UK, installed as part of an ISP set-up routine, or manually added.

This is the method by which corporate SSL inspection usually works: by automatically inserting a new root certificate on all devices that are centrally managed.

Future challenges

Possible future changes to TLS, that would be problematic. e.g. wikipedia: Convergence (SSL). However, most work focuses on surreptitious interception of communications, whereas a legally-mandated general interception has less need to conceal its intent.

Moral hazard

It's likely that deployment of state-based TLS-interception (or even serious discussion) would be seen as a green light to regimes with a weaker commitment to democracy to adopt similar plans. UK companies have been involved in exporting this class of equipment to repressive nations in the past. However, Foreign Secretary William Hague MP has openly supported the Bill in the Commons.

See also

• wikipedia: Transport Layer Security
• wikipedia: Man-in-the-middle