NSA Director Says the US Must Secure the Internet

Trailrunner7 writes "The United States has a responsibility to take a leadership role in securing the Internet against both internal and external attackers, a duty that the federal government takes very seriously, the country's top military cybersecurity official said Tuesday. However, Gen. Keith Alexander, director of the National Security Agency and commander of the US Cyber Command, provided virtually nothing in the way of details of how the government intends to accomplish this rather daunting task. 'We made the Internet and it seems to me that we ought to be the first folks to get out there and protect it,' Alexander said. 'The challenge before us is large and daunting. But we have an obligation to meet it head-on.' It's unlikely that any of Alexander's comments Tuesday will do much to quiet the criticisms of the Obama administration's security efforts thus far. Speaking mostly in generalities, Alexander emphasized the administration's commitment to the Comprehensive National Cybersecurity Initiative, a plan developed by the Bush administration and recently partially de-classified by Obama administration officials."

Re:Already secure

[betterunixthanunix]

You are assuming that SSH is secure; I know of at least one attack on SSHv1, and it is likely that there are other attacks on SSHv2 (and yet-undiscovered attacks).

done

[Venik]

NSA Director Says the US Must Secure the Internet

As of 10am EST this morning I have completely secured the Internet. The NSA director and my immediate management have been notified. I closed the ticket.

Re:Are they joking?

[arth1]

One of the suggestions I've read around here is to support public keys in DNS records. If the DNS records are signed, then you can verify the public key did, in fact, come from the domain owner.

That feature has been in DNS and SSH for several years [ietf.org] now. The optional SSHFP record contains a fingerprint of the public key, and if the ssh client has VerifyHostKeyDNS set to "yes", you don't have to manually verify the host key.
The question then is whether the DNS can be trusted.

Anyhow, to generate a couple of DNS entries for a host to insert into the zone file, do something like:

#!/bin/sh
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key | cut -d\ -f2 \
  | sed 's/://'g | xargs echo -e `hostname` "\t\tSSHFP 1 1"
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key | cut -d\ -f2 \
  | sed 's/://'g | xargs echo -e "\t\t\tSSHFP 2 1"

If your DNS server doesn't support the SSHFP RR identifier, you may have to use the numeric code, 44, instead.

Here It Comes...

[BlueStrat]

They've been working themselves up to this for a while now, and it appears that the lead-in propaganda campaign has heated up. I can't believe that I haven't seen another post discussing this yet. It fits perfectly with TFA/TFS. Two words.

Trusted Computing. [trustedcom...ggroup.org]

Here [cam.ac.uk] is a paper by Ross Anderson on some of what implementing Trusted Computing will mean.

This had better be nipped before implementation or there won't be another chance. The internet is a tool with more than one use, just as with nearly any tool. While the internet has tremendous power to empower, inform, and enrich, it also has tremendous power to monitor, control, and suppress if Trusted Computing is allowed to be implemented.

Strat

We did make the Internet

[falconwolf]

CERN disagrees.

CERN does not disagree. CERN was the birthplace of the World Wide Web" [wikipedia.org] and the internet is much more than just the web. Here's A Short History of Internet Protocols at CERN [web.cern.ch] from the horse's mouth.

Falcon

Re:Already secure

[arth1]

One of the endpoints being compromised is the issue. Either the server, or the ssh client, or the person operating the ssh client has been compromised into believing that the end point doesn't extend into his own gullible brain.

SSH is vulnerable to man-in-the-middle attacks if someone obtains a copy of the private host key, or if the client side accepts a changed host key despite warnings that it has changed. In fact, it being vulnerable is the sole reason for the warning!

Scenario 1:
Between client A and server B, insert malicious host X.
Client A tries to connect to server B, but reaches host X instead. Host X, having previously obtained server B's host key, answers like if it was server B, including giving client A the correct public key. Host X then completes the key exchange with server B on behalf of client A, keeping two connections open.
All traffic that A sends is decrypted and saved to disk, and also forwarded to B. Similar for traffic from B to A. Neither A nor B notices anything different, except increased latency.

Scenario 2:
Between client A and server B, insert malicious host X.
Client A tries to connect to server B, but reaches host X instead. Host X replies with a different key than the verified host key for B, but the user at client A has seen so many "the host key has changed" messages that he automatically accepts it (or runs ssh-keygen -R hostname to get rid of the cached key). Host X then completes the key exchange with server B on behalf of client A.
All traffic that A sends is decrypted and saved to disk, and also forwarded to B. Similar for traffic from B to A. Neither A nor B notices anything different, except increased latency.

Scenario 1 can happen if a server has been compromised earlier, with or without the knowledge of the admins. Or if an inside tech sets up a listening man-in-the-middle host before quitting. Or someone gets ahold of a failing and discarded disk. Or the government subpoenaing a backup tape from your bunker storage provider. Or when someone has tricked another service at the host into reading the private key. Or...
The reason why it's doable is that dual-key SSH depends on the host key never falling into the hands of others.
To protect against this, host key pairs should be changed whenever someone with root access to the machine leaves, or there is reason to believe that the key may have been copied outside your full control. And the keys should be excluded from backups.

Scenario 2 can be done by someone at your ISP (including a government tap). If it's the first time the user connects to the site, and he doesn't call a sysadmin to read the fingerprint, he won't even have to disregard a warning that the key has changed -- when he accepts it, he accepts the middleman's key.
The reason why it's doable is that dual-key SSH depends on the initial key exchange being verified, and it almost never is.
To protect against this, you have to always verify the public host key fingerprint when asked, and NEVER blindly accept it.

And, of course, there is the third possibility of your ssh client having been compromised and replaced with one that gives away all your traffic. Or simpler yet, your cached host key file has been modded. How sure can you be that your endpoint isn't compromised?

Man-in-the-middle exploits are also possible with SSL. A typical scenario is an internet cafe, where the CA certificates have been replaced with generated certificates, and there's a transparent proxy intercepting, decoding and saving a copy of all internet traffic.
Or a government tap at the ISP that intercepts your SSL traffic to a certain site, with a bogus certificate created by a signing authority that is under your government's control.

In short, for the chain of trust to work, every single link has to hold. Including the endpoints, which are much bigger than most people think -- they include not only the client keys, but the cached host key, the client software, th