There is a class of products that consist of a hardware box that you ram your network traffic moving between different business locations in a company through that tries to accelerate this traffic. F5 is one manufacturer of them. One technique these use is to have private key material such that they can pretend to be the server at the other end of a TLS connection — that’s most of the “encrypted” traffic that you see on the Internet. If you go to an “https” URL in your Web browser, you’re talking TLS, using an encrypted connection. They can then decode the traffic and use various caching and other modification techniques on the decoded information to reduce the amount of traffic moving across the link and to reduce effective latency, avoid transferring duplicate information, etc. Once upon a time, when there was a lot less encrypted traffic in the world, you could just do this by working on cleartext data, but over time, network traffic have increasingly become encrypted. Many such techniques become impossible with encrypted traffic. So they have to be able to break the encryption on the traffic, to get at the cleartext material.
The problem is that to let this box impersonate such a server so that it can get at the unencrypted traffic, they have to have a private key that permits them to impersonate the real server. Having access to this key is also interesting to an attacker, because it would similarly let them impersonate the real server, which would let them view or modify network traffic in transit. If one could push new, malicious software up to control these boxes, one could steal these keys, which would be of interest to attackers in attacking other systems.
It sounds, to my brief skim, like attackers got control of the portion of F5’s internal network that is involved with building and distributing software updates to these boxes.
The problem is that if you’re a sysadmin at, say, General Dynamics (an American defense contractor which, from a quick search, apparently uses these products from F5), you may have properly secured your servers internal to the company in all ways…but then the network admin basically let another box, which wasn’t properly secured, into the encrypted communications between your inter-office servers on the network. It could extract information from your encrypted communication streams, or modify it. God only knows what important data you’ve been shoveling across those connections, or what you’ve done with information that you trusted to remain unmodified while crossing such a connection. It’s be a useful tool for an attacker to stick all sorts of new holes into customer networks that are harder to root out.
Me: Uh-huh. Uh-huh. Uh-huh
Those certainly are some words that I understand seperately, but not together.
There is a class of products that consist of a hardware box that you ram your network traffic moving between different business locations in a company through that tries to accelerate this traffic. F5 is one manufacturer of them. One technique these use is to have private key material such that they can pretend to be the server at the other end of a TLS connection — that’s most of the “encrypted” traffic that you see on the Internet. If you go to an “https” URL in your Web browser, you’re talking TLS, using an encrypted connection. They can then decode the traffic and use various caching and other modification techniques on the decoded information to reduce the amount of traffic moving across the link and to reduce effective latency, avoid transferring duplicate information, etc. Once upon a time, when there was a lot less encrypted traffic in the world, you could just do this by working on cleartext data, but over time, network traffic have increasingly become encrypted. Many such techniques become impossible with encrypted traffic. So they have to be able to break the encryption on the traffic, to get at the cleartext material.
The problem is that to let this box impersonate such a server so that it can get at the unencrypted traffic, they have to have a private key that permits them to impersonate the real server. Having access to this key is also interesting to an attacker, because it would similarly let them impersonate the real server, which would let them view or modify network traffic in transit. If one could push new, malicious software up to control these boxes, one could steal these keys, which would be of interest to attackers in attacking other systems.
It sounds, to my brief skim, like attackers got control of the portion of F5’s internal network that is involved with building and distributing software updates to these boxes.
The problem is that if you’re a sysadmin at, say, General Dynamics (an American defense contractor which, from a quick search, apparently uses these products from F5), you may have properly secured your servers internal to the company in all ways…but then the network admin basically let another box, which wasn’t properly secured, into the encrypted communications between your inter-office servers on the network. It could extract information from your encrypted communication streams, or modify it. God only knows what important data you’ve been shoveling across those connections, or what you’ve done with information that you trusted to remain unmodified while crossing such a connection. It’s be a useful tool for an attacker to stick all sorts of new holes into customer networks that are harder to root out.
Sounds like an inbuilt self inflicted back door on encryption to me!
Back doors are always bad!
The attackers can access the keys needed to decrypt traffic going through the appliances.