Also, it should be noted that this isn't new. Some folks appeared to spot this soon after it happened as it wasn't even remotely covert -- and also said that it appeared to be a "fat fingers" type of mistake based on the way it took place. Yet, to read the McAfee report, the assumption is that it must have been for nefarious reasons. Perhaps, but that wasn't what it appeared to be initially.

Of course, McAfee is pointing out that some of the traffic included US government and military traffic, but the US government said it was no big deal because its traffic was encrypted. However, McAfee is claiming that the US government is still at risk, and that it should be concerned. The explanation at "National Defense Magazine" based on what McAfee said seems slightly misleading:

"If China telecom intercepts that [encrypted message] and they are sitting on the middle of that, they can send you their public key with their public certificate and you will not know any better," he said. The holder of this certificate has the capability to decrypt encrypted communication links, whether it's web traffic, emails or instant messaging, Alperovitch said. "It is a flaw in the way the Internet operates," said Yoris Evers, director of worldwide public relations at McAfee.

It would be great if a security expert could chime in here, but this seems like a rather simplified version of how a man-in-the-middle attack on public key encryption would work. It's possible that it could work in some specific instances, but this report makes it out like China could automatically read any encrypted message.

Well that's somewhat not true... unless you use extremely weak security settings in your browser. The key would change, bells would go off and even if it's a legit key, any recent browser would complain.

Apparently it's only applicable for newly-introduced users, who don't already have the other user's PGP key. It's likely that the U.S. Government uses something more secure than PGP.

If people are worried about governments encroaching on their privacy, it seems a bigger threat is a "compelled certificate creation" attack, where government agencies force a certificate authority to issue bogus, but trusted, SSL certificates. They can then intercept anything the user sends via SSL.

is our government smarter than a college sophomore?

I would expect our government uses more advanced security than simple public keys ... so basically the threat described above is zero if the right precautions are taken.

however if lazy Field Agent A is pissed that his secure network is running too slow and decides to email sensitive files via gmail .... well all bets are off. or move files to his thumbstick and plug it in at an internet cafe...

It's FUD being hyped for political/economic gain

First, this looks far more like a fat-fingered mistake that resulted in a prefix hijack than anything else. It was FAR too obvious to be a serious attempt at doing anything nefarious; competent adversaries are not nearly so hamfisted, and as those working in this field know, there are many adversaries who are far more than merely "competent".

Second, it seems like that the real number was more like 1% to 2%; 15% is an enormous amount of traffic and it's not likely that the infrastructure could handle it even if such a hijack were (a) successful (b) undetected and (c) robust.

Third, when prefix hijacks happen, either deliberately or accidentally, consider what happens to traffic -- in particular, TCP connections. Any attempt to establish a new TCP connection will likely fail -- the initial SYN packets will be sent but never delivered, so the attempt will stall, time out, and likely be reported back to the application as an error. Any attempt to use an existing TCP connection will also fail, as ACKs won't be delivered, so there will be some retries and such before that (again) the attempt will stall, time out, and likely be reported back as an error. (Consider as well what happens with UDP: packets just hit the floor.)

This means that while some traffic analysis of existing connections, based on whatever few packets are transmitted before the connection dies, is possible -- it's not going to be much. It's certainly not going to be enough to perform good attacks against the crypto; there won't be enough data. It would be far more productive and far more subtle to go after end-user systems on the sites of interest; that would yield a much larger corpus for analysis or perhaps, thanks to a keystroke logger, some of the keys.

Fourth, one thing that conceivably could be extracted from this traffic is network flow data: that is, who's talking to who on which ports. But why? Does anyone seriously think that it's major news to any adversary that government unit A is talking to commercial site B? Or that users at nonprofit C are surfing porn site D?

Fifth, incidents similar to this have happened before and will likely happen again. This particular one is just being hyped because (a) it's good PR for McAfee (b) it serves political purposes because it involves the favorite boogeyman du jour (c) it's good budgetary justification for another few billion lobbed into the non-existent problem of cyberwar.

My take

A telco engineer (whose networks all of us have used in one way or another) I know and I had a chat about this and mentioned that it was probably a peering foul up and that this sort of thing happens more than we'll ever know.

Thinking evil, if you were after something specific and narrowly target it, it might be easy to figure out exactly what you were after. If you were after that same something specific, and targeted broadly, you may be able to get that something specific and nobody'd figure it out.

One or more governments will probably keep us from ever knowing the truth about why this happened.

Re: My take

You're right that broad (overt) targeting might be used to misdirect attention from narrow (covert) targeting. We see this used quite often in attacks against specific resources, e.g., web sites: attackers unleash a large, broad-spectrum bombardment in order to make it more difficult to spot the pinpoint attack buried in there somewhere.

The upside of this approach is that it can overwhelm defending analysts. The downside is that it draws lots of attention. (And depending on how it's done, it requires significant and clever resources -- like trying to drink a drop from the firehose.)

yeah i just read this on msnbc and people dont een know t=what they are talking about and panic about big brither and privacy, when we never ahd protection from governments. thanks tech dirt for claering thing up :)

Interesting spin

... if unsuprising.

When this happened the story I heard at the time was it was to do with controlling internet traffic into/out of their own country and they totally snarked it up - entirely plausible given the way routing algorithms work and the complexity of the internet. Kind of the way things would have to work for the vaunted "Internet Kill Switch" to be possible. (I can hear the argumants already "Well we can be trusted with such a "weapon" but not those dastardy Chinese....")

Personally I'd go with the "never attribute to malice what can adequately be explained by stupidity" reason over the spin of a vested interest.

It would be great if a security expert could chime in here, but this seems like a rather simplified version of how a man-in-the-middle attack on public key encryption would work.

I'm not an expert but I do have a little experience with things like this. As I understand it, it's feasible as far as it goes. There are some proxy appliances that operate as this seems to suggest - you request an HTTPS session, the proxy intercepts and sends out its' own session request, obtaining a cert from the endpoint service requested. It then responds to the user session with its' own certificate to establish the encyrpted tunnel allowing on-box de-cryption and re-encryption for monitoring of the session.

That being said, in that scenario you already trust the proxy box and are deliberately sending traffic there and besides the certificate would look different to the endpoint services' even if it was Verisigned or similar so was considered "safe".

Could you do a simlar thing but spoofing the endpoint certificate? Possibly, but as someone already pointed out this only works with a PGP key exchange rather than private-key encryption - I don't think a VPN would be susceptible to this kind of attack for example without it being noticable even obvious.

All communication is vulnerable to some extent on the internet - it's public and that's what encryption is for after all - I don't think this kind of re-routing necessarily makes it more so. Id say the bigger risk was the cut-off and the info not getting to where it's supposed to at all.

darryl (the first commenter) is absolutely correct. The US gov't is not dependent on public Internet for information flow of sigint, critical information, military communications, etc. These things are done through dedicated satellite links.
However, what this might (and I stress the word "might") do is slow down/cut dissemination of public information. I do not see how that interruption would last for any extended period of time unless the gov't's technological ability was somehow compromised (basically, if they can do it to us, we can do it to them). So by itself, the redirect isn't an effective weapon unless used as part of an overall strategy to confuse population in case of a bigger attack, say an EM pulse caused by a multiple nuclear explosions. (Boy, I miss Jessica Alba and "Dark Angel"...) However, at that point the ability of gov't bureaucracies to communicate would be the least of everyone's problems. The military and emergency responders would still be able to communicate through normal secure means unless that ability was compromised as well. Which means we're on the wrong end of WW3 and the fact that the Chinese gov't may or may not read be able to read the congressional e-mails really doesn't matter any more.

So if I set up an HTTPS server (Public Key, Public Cert) I can automatically decrypt Military documents just by re-routing them through my server? WHAT!!!! Who the frak wrote that? You still need the private key. That's exactly why we don't use McAfee any more, I am a network tech and we had thousands of LAN users on McAfee and moved them all to AVG.
2 reasons we made the change to AVG.
1. Try before you buy
2. Better Product

So if I set up an HTTPS server (Public Key, Public Cert) I can automatically decrypt Military documents just by re-routing them through my server? WHAT!!!! Who the frak wrote that? You still need the private key. That's exactly why we don't use McAfee any more, I am a network tech and we had thousands of LAN users on McAfee and moved them all to AVG.
2 reasons we made the change to AVG.
1. Try before you buy
2. Better Product

So if I set up an HTTPS server (Public Key, Public Cert) I can automatically decrypt Military documents just by re-routing them through my server? WHAT!!!! Who the frak wrote that? You still need the private key. That's exactly why we don't use McAfee any more, I am a network tech and we had thousands of LAN users on McAfee and moved them all to AVG.
2 reasons we made the change to AVG.
1. Try before you buy
2. Better Product

So if I set up an HTTPS server (Public Key, Public Cert) I can automatically decrypt Military documents just by re-routing them through my server? WHAT!!!! Who the frak wrote that? You still need the private key. That's exactly why we don't use McAfee any more, I am a network tech and we had thousands of LAN users on McAfee and moved them all to AVG.
2 reasons we made the change to AVG.
1. Try before you buy
2. Better Product

So if I set up an HTTPS server (Public Key, Public Cert) I can automatically decrypt Military documents just by re-routing them through my server? WHAT!!!! Who the frak wrote that? You still need the private key. That's exactly why we don't use McAfee any more, I am a network tech and we had thousands of LAN users on McAfee and moved them all to AVG.
2 reasons we made the change to AVG.
1. Try before you buy
2. Better Product

SSL and the chain of trust

This has been alluded to above but not explained simply: The legitimate security concern relates to SSL endpoints and any other system that uses a PKI with multiple CAs. SSL doesn't distinguish which CA signed a server cert, as long as the CA is considered trusted, and given the political situation in China, it would be trivial for the government to obtain a bogus cert for "www.google.com" (or what have you) signed by a trusted Chinese CA.

As for the comments about the use of PKE above: The military absolutely does use PKE, since being "the military" doesn't solve the key-distribution problem. What's very likely, however, is that the US military is using ECC instead of RSA for its asymmetric crypto primitive.

We're from McAfee and we're here to help..!

Stories such as this will become more common in a Republican-led House of Representatives as companies such as Intel attempt to justify mergers and acquisition activity by selling new, shiny, and expensive corporate-generated solutions to fix Government's failed policies and Corporate America's addiction to cheap offshore labor.

if somebody tricked you into using their public key, instead of the public key of the computer you are trying to send an encypted message too, then they will be able to decrypt your message with their correspinding private key.

this is why you get the puplic key from a certificate authority. to successfully decrypt the message they would need to simultaneously intercept your communication with the recipient of the encrypyed message and the certificate authoriy where the public key came from.

I don't know about the US goverment, but commercial use of public/private key encryption only used to send a different key for the rest of the communication session. if both intended computers were not in possession of this other key, which they would not be if the correct pupblic key was not used, then the communication would breakdown pretty quickly.

Re: And the winner is...

Re: Re: And the winner is...

As a mathematician/computer scientist, I have to chime in here to explain to the layman:

A 256 bit encryption is standard these days for confidential info. When I was doing work for an enigneering corp, they constantly used 512 and 1024 bit encryption, (explanation I got: "The sysadmin was bored").
Nevertheless, the number of combinations of 256 bits is enormous. 2^256 = 1.1 * 10^77.
To put that in perspective, the number of milliseconds that have passed since the beginning of the universe is about 4.4*10^16, and the estimated observable universe is about 47 lightyears long , or something like 4.7*10^19 millimeters long. The volume, then, is around 10^60.

So, if we multiply the age of the universe, in milliseconds, by the size of the observable universe, in millimetres cubed, we get a number on the scale of 10^76 . . . which is still 10x smaller than the complexity of a single 256 bit encryption.

If we had a computer the size of the observable universe, running since time began, with each transistor a single nanometer, it could only be guaranteed to break 100,000 256 bit encryptions. To guarantee breaking one 256 bit encryption or this massive, insanely powerful computer, would take 10^11 years . . . that's 100 billion years.
For a computer the size of the universe.

In short, brute force is never an option, because no one has the juice or the time.

The source of the story is McAfee, who certainly has some incentives to play up such "threats," so perhaps take it with a grain of salt.

Logic Sounds Good! About how I take techdirt's stories. After all, every story leans precariously towards promoting products or services that the masnick supports, endorses, or sells. Doesn't make them any more accurate given the obvious bias present.

Re:

I think it is a safe bet that many of the large companies I have seen advertize here want access to the eyeballs but do not agree with much of the contents of this website.

You are correct that everyone has biases, and perhaps the majority of the income by this article's author is in areas he champions.

On the other hand, Mike doesn't generally (or at all) sell his blog pieces as authoritative. And it does make sense to mention the salt when statements are by someone (eg, McAfee) that can reasonably be considered to be an authority of some sort on security.

Encryption overview

I saw a lot of misleading information in these comments, so I thought I would try to clear things up a bit.

The short version is, the original post (from the source, not Techdirts) is wrong. Simply sitting in the middle of a secure connection is not sufficient to eavesdrop, unless the users are doing something wrong (the US government probably isn't).

Public key encryption are systems that allow 2 parties to share a key (think of it very much like a key for a lock) over an unsecured medium (such as the internet) in a secure way. Think of public key as a safe with 2 doors, and each user has a key to only one door, and only one door may be open at a time (not entirely technically correct, but good enough for this discussion).

An example of public key is RSA. There are others. I don't know what the US government uses, and I won't venture to guess.

Public key systems are mathematically proven to be secure against all but brute force attacks (guessing and checking). All systems are breakable by brute force, you simply choose how long you want to be secure. It is cheap (fast) enough for the user to choose a value of years.

Public key is relatively slow (expensive) compared to private key encryption, so the typical usage is to use public key to encrypt a private key so it is safe to send over the unsecure medium (again internet). The private key is then used on a short term basis (such as a single message, or an hour on a longer term connection).

Private key is a system where the same key is used to encrypt (lock) and decrypt (unlock) the data (the "safe", this time with only one door).

The man in the middle attack (MITM) works like this: M (the middle) does the public key algoritm with A (the first person) while pretending to be B (the second person), which ends with M and A having a secure connection to each other. Similarly M pretend to be A and sets up a connection with B.

The connection now looks like A-M-B, but A and B think it looks like A-B.

Fortunately the public key encryption system fixes this. By doing the public key algorithm backwards (oversimplification), you can verify that you are talking to who they say they are.

The only way MITM works is if the 2 users have never spoken to each other before, has no trusted 3rd party who can vouche for them, or has no secure medium (something other than the internet) to do an inital introduction. I'm fairly certain the US government has both of those systems in place.

The "flaw" the original source spoke of is this needed 3rd party, but this FUD (fear, uncertainty and doubt). For the commercial sector there are companies that handle the introductions. For the US government, I suspect it is handled in house.

Re: Encryption overview

The only way MITM works is if the 2 users have never spoken to each other before, has no trusted 3rd party who can vouche for them, or has no secure medium (something other than the internet) to do an inital introduction.

Pretty nice response. For general Internet activity (https/ssl), those first time connections are definitely the most vulnerable to MITM since without the authentic key, the rogue can present its own key, with the proper name, and bogus/dirty cert authority. This would appear OK to the browser if the user clicked accept for the bogus CA or if it were somehow already on the trusted list.

Still chances are pretty low, if this situation were intentional, that this is what the Chinese intended to do.

Re: Encryption overview

Re: Encryption overview

The "flaw" the original source spoke of is this needed 3rd party, but this FUD (fear, uncertainty and doubt). For the commercial sector there are companies that handle the introductions. For the US government, I suspect it is handled in house.

Yes, there are companies that handle the introductions. In China, this is handled by CNNIC, which is... part of the Ministry for Information Industry. The CNNIC CA certificate (serial #49:33:00:01) ships in most SSL implementations. Draw your own obvious conclusions.

Re: Encryption overview

The NSA handles the 3rd party duties of authentication. All .mil addresses do not accept or issue RSA certificates. Many times, if you go to a .mil your browser will warn you that it cannot authenticate the website is who it says it is because DOD refuses to participate in the entire public key system.

Re: Encryption overview

What you're saying is mostly accurate and true, however some systems do not bother to check if the owner of the certificate they recieve is legitimate (one would really hope no military system has this deficiency obviously). Some one also suggested that China can get fake certificates from a Chinese Trusted CA it can control which might also be possible however I would imagine Military systems have their own CAs and they trust them exclusively Public CA is not something I would use in a military environment.

Bottomline whats being suggested is possible but only if the implementation itself was flawed after all the whole idea of Certificates was to protect against a Man in the Middle attack.

On the military side its hubris to think they're safe cause all traffic is encrypted however. Encryption can be compromised in a number of ways... Brute force were encryption is meant to make it unfeasable to guess the correct key in a time window where the content you're decrypting still matters (while this will be good protection against individuals I would worry when big governments like china are involved I would think they have the resources to actually make successful bruteforce attacks). Weakness in the algorithm or actually managed to covertly acquire the private key itself. Encryption is just one security layer... the path it travels is another having one compromised is never good news.

some guesses

Yes, it's possible they might have run a mini wargame. They might have tried to record much of this data to mine later. Within there you would find many interesting things. And yes the attempt could certainly be to focus on a few communication streams, especially if brute force was going to be attempted over time or it happened that there was some other weakness they knew would exist at that point in time. Yes, this can make for a great movie and book and actually be realistic. They may have simply been fishing to see who of interest might have had their pants down during that moment. Lot's of people would be using versions of software with known vulnerabilities. They may have also found or known of an undisclosed weakness in a major technology used. For example, I don't trust closed source software at all (and Microsoft, eg, a firm without a spectacular security record in their software has also shared source voluntarily with Beijing I believe.. nevermind having IP assets in China or elsewhere hacked), and they might have found access to such code and found undiscovered vulnerabilities. But even for open source, problems have existed from time to time (and people might be using weak versions of things). Red Hat even reported some vulnerability with OpenSSL recently (I haven't looked at the details). A major source of information would be from companies using less sophistication than the government. Trade secrets are a valuable commodity and they may have already had inside access (eg, to private keys or to some likely flaw in protocols). Finally, if you authenticate properly, man-in-the-middle does not work, but I would assume there might be flaws in the browser acknowledging the other side of typical Cert procedures were used. Two parties that have a private robust mechanism for authentication after https connection are likely safe, but if the man in the middle had access to all traffic to include the checks on the certificates, then I think the browser mechanism could be made to fail if you acted fast enough in real-time. For traffic with China firms or where the browser trusts any particular CA that the man in the middle could get to issue them a bogus license (someone above suggested this for a Chinese CA beholden to their government) then of course you could easily spoof the end point authentication that would rely on such certs (like typical e-commerce).

[These are opinions only (based on some experience and what I recall from memory).]

Re: some guesses

>> Finally, if you authenticate properly, man-in-the-middle does not work, but I would assume there might be flaws in the browser acknowledging the other side of typical Cert procedures were used. ... if the man in the middle had access to all traffic to include the checks on the certificates, then I think the browser mechanism could be made to fail if you acted fast enough in real-time.

OK, this is wrong. Let's say you want to communicate securely with www.buysomegoods.com. Even if you use a single ISP and they are the man in the middle, they can only succeed with SSL (https) if they use their public key (ie, one for which they know the private key, assuming they haven't hacked www.buysomegoods.com), and the CA (unless themselves hacked, bribed, etc) will not certify that that public key by this ISP company corresponds to that website domain (www.buysomegoods.com) that the ISP is trying to hijack.

This is why PGP is more risky, you don't have that automated (and third party involved) mechanism to authenticate. You have to figure out your own way (out of band) such as by calling up the person, meeting with them to exchange the key, or taking a chance with trusting your email or other Internet communication that you think the same man in the middle will not have hacked.

Re: Just no.

First, nobody has actually established that it was 15% of the Internet's traffic. Personally, I think that number is hyperbole. It might have been something like "15% of the routes", but that is NOT in any way shape or form equivalent to "15% of the traffic".

Second, nobody "shut down" anything. Everything out there still had power and was still burning CPU cycles.

Third, if you're not familiar with concepts like routing, ASNs, BGP, etc., and/or if you don't read lists like NANOG on a regular basis, then it's probably not going to be clear to you that not only could China do this, so could techs in a lot of other places, if they made sufficiently egregious mistakes. Which they have. Please see, for one example of many discussing these kinds of problems: http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

Fourth, this is a well-known issue which has been discussed ad infinitum among people who actually run networks. It's not new. All that's new here is the fear-mongering.

DOD uses 2 different networks for sensitive info. NIPRNET for sensative stuff and SIPRNET for SECRET. SIPRNET is a parallel internet that can only be accessed from the internet be taking over a computer that is simultaneously connected to both at the same time. This has been done but it ain't easy.

Also, to access any DOD network each uses must have their smartcard (CAC Card) inserted into a computer. This is far more secure than trying to hijack a bunch of quasi classified info and break the encryption.

This is not how you spy on the US government. Instead, you drop off a bunch memory sticks with virus' in the Pentagon parking lot. (how China actually penetrated)

For the truly secret stuff (my mom used to work at DTRA) the comps are not even allowed to connect to the internet. Her HD was locked in a safe in the basement at the end of the day with 24hr security.