Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

'Black boxes' will be installed by internet services providers to filter & decode encrypted materials – including social media and email messages, something which critics say will have an impact on personal privacy.

share|improve this question
Encryption gives you a false sense of security. It's not any big difference using todays spying systems, if your information is encrypted or not. You propagate everywhere so many information that it doesnt matter if they can intercept the http headers and content or not. Also, many security products do have crypto weakened big time, like checkpoints. –  Andrew Smith Jul 9 '12 at 11:05
@AndrewSmith Can you back up your claims with hard facts? –  curiousguy Jul 16 '12 at 4:53
Also compare these two answers to the SO question Can a proxy server cache SSL GETs?: Mentioning Charles Proxy and Bluecoat. –  FriendFX Sep 10 '14 at 3:40

2 Answers 2

up vote 9 down vote accepted

Rather than "bypass" encryption, they can spoof the identity of the server, so as to perform a MITM attack (effectively).

Encryption itself is only one part of the configuration when setting up an SSL/TLS connection: this ensures the confidentiality of the communication between the client and the server. Before that, the client needs to verify the identity of the server, to make sure it's exchanging data confidentially with the party it expects: this is what certificates are used for.

An X.509 certificate is issued by a CA for a given server name. If the browser trusts this CA (there are a number of trust anchors provided by default with most browsers), it can trust its content: the binding between its public key and the name it contains. The browser also has to check that the server name it was looking for is one of the names in the certificate.

What the government can do is to ask you to trust its CA certificate (and/or have the big CAs give them an intermediate CA certificate) so that they can issue certificates for their surveillance device, thereby spoofing the real server certificate. This device would be a server and decipher the connection and then act as a client itself to the real server: you would then have 2 encrypted sections: one between the client and the surveillance device, and one between that device and the real server.

There exist appliances that do this (sometimes referred to as "MITM proxy servers"), typically used on a enterprise network.

Besides the fact that anyone in control of that CA's private key could see and alter any traffic the client makes to an HTTPS site (there are a number of non-technical problems here), there are a number of technical problems when doing this at the scale of a country:

  • These proxy servers may need to be explicitly configured in the browser (as an HTTP proxy).

    Indeed, it's quite difficult to implement a MITM proxy transparently, because it can't always get the name it should put in the certificate it generates dynamically by just looking at the initial TCP packets. If Server Name Indication is not used (SNI is quite common nowadays, but not supported by all clients), all it can get is the IP address of the server, which may not necessarily resolve back to the expected name. For example, if you get the address for and do a reverse DNS lookup, you'll get something like It could work with a wildcard here, but that pattern can't be expected in general.

  • This will make any service that uses client-certificate authentication break. Since during the SSL/TLS handshake, when a client certificate is used, the client signs the concatenation of all the handshake messages (including the server certificate) at the end, and the server compares it to what it has sent and received (including the real certificate). If there's something in the middle that inserts it own certificate, this is going to make this verification fail.

  • There will certainly be a delay in the establishment of the handshake, since the certificates may have to be generated dynamically. (Some could be cached.)

  • This expects users to "play nice" and use the ports that they are meant to do. Alternative ports might not be monitored or would have to be completely firewalled.

  • To track down Facebook/Google+/Gmail exchanges in a usable form, these devices will also need to be able to look through the structure of the pages (or JSON payload for AJAX) and be able to extract the relevant data (or to store everything it can't understand somewhere). Any slight change in the internal API of those services would require some costly adaptation.

Doing all this for all HTTPS communications will certainly require a large amount of computing power and yield a substantial electricity bill.

(It's possible that the reports that led the Home Office to make such plans were drafted before Facebook switched to HTTPS for everything, by the way.)

share|improve this answer
"it's quite difficult to implement a MITM proxy transparently, because it can't always get the name it should put in the certificate it generates dynamically by just looking at the initial TCP packets" not true "all it can get is the IP address of the server" with just this, you can connect to the legitimate TLS server and get the certificate, and copy everything from it except cryptographic data. –  curiousguy Jul 16 '12 at 4:40
@curiousguy, fair point, although this will certainly increase latency. –  Bruno Jul 16 '12 at 7:55
"this will certainly increase latency" it isn't supposed to lower latency either! The latency should be approx. the same as for a normal TLS connexion, and I think it will. –  curiousguy Jul 17 '12 at 4:15
@curiousguy - You think? What a wonderful way to express your viewpoint. –  Ramhound Jul 23 '12 at 11:59
@curiousguy, I was just thinking that it would have to make a its own query first to get the original cert, before proceeding with a secondary, proxied request (for the actual request it's relaying), which would cause some overhead upon connection (two handshakes with the real server instead of one + having to wait for the first one to get the cert and name). Some of this can be cached, of course. –  Bruno Jul 23 '12 at 12:08

They will get a CA that is in the CA root zone for all browsers to issue them valid certificates. This CA will probably be a UK based company. Spying will be completely transparent to the users. Browsers will show no warnings. This will work for a few days, until it is detected by the public at which point browser vendors will revoke the root certificate of the CA in question, like they did in the past due to security issues at a few CAs. There is no other practical way to decrypt encrypted connections, unless if someone is using very week protocols, but that is unlikely. They could also just install this boxes and then use them selectively, only target people they wish to spy on, not everyone. In this case it probably won't be detected and CA certificate will not be rejected. But you cannot monitor and decrypt all secure internet traffic and not be noticed.

share|improve this answer
Bit like Diginotar:… –  jippie Jul 8 '12 at 18:35
Keep in mind that this only applies to "traditional" web traffic. Privacy network systems such as Tor remain relatively resilient to snooping. –  Polynomial Jul 10 '12 at 10:35
Tor provides IP address anonymity, not confidentiality. Run a Tor endpoint, which are in very short supply, and you will see all the unencrypted traffic going through your node. You can even set up your policy to only provide access to Facebook and then all traffic passing through you will be Facebook related. Just sniff. –  Matrix Jul 10 '12 at 17:57
"This will work for a few days" at most. Maybe a few hours. –  curiousguy Jul 16 '12 at 4:44
@Matrix "Tor provides IP address anonymity, not confidentiality." Tor provides confidentially inside Tor. User in the UK can use Tor with a Tor exit outside the UK, which cancels any potential benefits of this inane government attempt. –  curiousguy Jul 16 '12 at 4:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.