Phalanx Close-in Ship Defense Guns getting Upgrades

The Mark 15 Phalanx ship defense weapon is capable of firing 3000 to 4000 20mm rounds-per-minute as a close-in anti-ship missile weapon. Defense Industry Daily reports that the upgraded version (1B) can also be used against gunboats, artillery, and helicopters.

Some of the customers for the Phalanx include:

• US Navy
• US Coast Guard
• Australia
• Israel
• New Zealand
• Japan
• United Kingdom
• Canada
• Taiwan
• Poland
• Bahrain
• Saudi Arabia

I don't think they're firing any of these at the Knob Creek Machine-Gun Shoot in Kentucky, though the crowds would be even bigger if they did.

The obstructionists were wrong (again)

I wonder if the obstructionists on Capitol Hill ever get sick of being wrong? W.C. Varones, writing at PoliPundit, remarks:

Are you thinking what I’m thinking? … that today’s missile tests by North Korea are an excellent illustration of the necessity of missile defense? And that all those Democrats who limited funding for and tried to block development of Ronald Reagan’s “Star Wars” program were dangerously, irresponsibly wrong? he argument was that missile defense would somehow upset the Mutual Assured Destruction balance and escalate the arms race with the Soviet Union. Well, now the Soviet Union is long gone. We now have rogue states with missiles, and a missile defense seems like a pretty good idea...

Yep™.

Photo Tour of North Korea

These photos of North Korea were taken by a Russian tourist. Many of the photos are "illicit", in that they depict the real conditions in the totalitarian state and not the utopian ideal (hat tip: Powerline).

MilitaryPhotos.net: Photo Tour of North Korea

Think your SSL traffic is secure?

If you use SSL at work in ways designed to elude acceptable-use filters (e.g., WebSense) or to secure applications like telephony and file-sharing, you may want to re-think that proposition.

A series of products, among them Blue Coat's SSL Proxy, provide SSL-cracking capabilities to organizations interested in shutting down SSL violations of policy.

In effect, Blue Coat's SSL Proxy breaks any SSL traffic its been configured to intercept. How can that be so? Isn't SSL/TLS secure from man-in-the-middle (MITM) attacks?

How Blue Coat cracks SSL/TLS

I've based the first part of this analysis on BlueCoat's SSL Proxy White Paper (PDF). Later details are based upon its Deployment Guide, which spells out some of the nuances of configuration.

When a connection request is made by the browser, it passes through the Blue Coat proxy on its way to the real SSL server. The response from the destination SSL server includes a certificate. This certificate is designed to (a) irrefutably identify the server; and (b) secure the communications between client and server. To do so, the cert wraps the server's public-key, which is tied to the domain name (or, less likely, IP address) of the server.

The real server's cert, though, is intercepted by the proxy on its way back to the browser.

Before the proxy passes the certificate through, it unwraps the public key and then re-wraps it in an "emulated certificate" (I'll go ahead and call it a spoofed cert, which I think is more accurate). This spoofed cert is then returned to the client browser. The client thinks everything is on the up-and-up and -- after it verifies the spoofed cert -- it establishes the encrypted tunnel.

The tunnel, though, is now terminated at the proxy server. The proxy itself has established a second tunnel to the real destination SSL server.

The proxy can now inspect the cleartext traffic, block the traffic, or pass it on to other devices for their use (more about this later), and otherwise fiddle with it prior to sending it down the second encrypted tunnel to the real SSL server.

Modifications are required on the client

This approach, though, does require a slight modification on the client side. Namely, the server has to be "trusted" within the client's certificate chain. If a corporation runs its own CA (certificate authority), odds are that the browsers in the organization will already be configured to use an extended CA chain.

Even if the organization doesn't have its own CA, a new signing-key -- in the form of a new cert in the client-side chain -- can be added to the browser's list as "trusted." Once added, all proxying of the SSL traffic can take place without popped-up warnings or errors: the browser's SSL configuration is ostensibly "correct". The server brokering the SSL session is correct and "trusted."

The Blue Coat Systems Deployment Guide explains how this client-side operation works (PDF):

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store. The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

Concerns with Cracking SSL

To be sure, one wonders about the privacy issues raised by this class of device. A commenter on the SANS list expressed just this concern a few weeks back:

...I understand the reasoning behind doing SSL interception just for content filtering, but even in a corporate, .gov, or .mil situation where the user may have explicitly or implicitly signed away all of their privacy rights, there is some expectation that SSL traffic is not going to be visible to a third party, much less cached...

In fact, the Blue Coat Deployment Guide spells out a recommended best practice that alludes to this facet of operation:

[You should] Implement HTML notification for intercepted sites... to inform end-users that their HTTPS traffic will be monitored and that they can opt-out if they do not want their traffic to be intercepted. HTML notification is also helpful if a site is accidentally intercepted.(Ed: emphasis mine )

Interestingly, of all the operations described in the manual, the Windows Update process is arguably the most secure! Presumably, this is because Microsoft doesn't allow alteration of the certificate authority chain. The FAQ in the Deployment Guide notes:

Problem: Windows Update Description: The Windows update does not work when the SSL Proxy intercepts windows updates connections. This is because the Windows update client does not trust the emulated certificate presented by the SSL Proxy. Solution: SSL connections for Windows updates should always be tunneled.

Exposure of SSL cleartext to third-parties

As far as privacy concerns, another aspect of SSL Proxy operation is interesting to contemplate. Namely, certain companies have established partnerships with SSL Proxy vendors in order to add to the suite of capabilities offered by the base proxy products. For instance, BlueCoat struck a deal with PortAuthority, presumably to permit sharing of cracked SSL/TLS traffic between the companies' devices.

I haven't investigated all the permutations of these arrangements, but one wonders the following:

• How secure is the communication channel between the products?


• How secure are the products themselves (i.e., how many vulnerabilities do the various proxies have -- and their partner products)?


• How do organizations validate the configurations to ensure that banking and other sensitive traffic remains protected on an ongoing basis?

It's not that these issues can't be addressed. But they should be food for thought for anyone implementing or operating under the constraints of these types of devices.

In any event, be aware that these products exist... and they can do what they claim if properly configured. Webmail, peer-to-peer file sharing, telephoney, etc. can all be monitored and blocked, even if tunneled through SSL/TLS.

The New York Times' Eric Lichtblau: Bonfire of his Vanity

Excerpt, courtesy Powerline:

Eric Lichtblau’s story in the New York Times, June 22: Bank Data Secretly Reviewed by U.S. to Fight Terror By ERIC LICHTBLAU and JAMES RISEN Eric Lichtblau today, on CNN’s Reliable Sources: “USA Today”, the biggest circulation in the country, the lead story on their front page four days before our story ran was the terrorists know their money is being traced, and they are moving it into—outside of the banking system into unconventional means. It is by no means a secret.

The Times' Disclosures: Lileks' Beatdown

Executing a snark tour de force  is no easy task. But James Lileks makes it look routine, with a brutal smackdown of the New York Times. The Times' proclivity for leaking national security secrets like candy from a Pez dispenser is an egregious, well-nigh-treasonous practice. One would, then, not be surprised to read the following stories someday soon:

September 10, 2006: The New York Times runs a story about a CIA agent named Mohammed Al-Ghouri, 1034 Summit Park, Evanston Illinois, who is attempting to penetrate a radical sleeper cell suspected of having 19 liters of homemade mustard gas. The series concludes with the agent’s obituary, and a moving quote from a CIA historian who notes that the “al-Ghouri was one of rare, brave breed whose names and deeds are rarely known. Except in this case, of course.” ... Feb. 14, 2007: Times Editor Keller approves the publication of the Pentagon’s plans for a Feb 15th strike on Iran, asserting that “there has been far too little debate about whether the sustained assault by cruise missiles and stealth bombers will provide a cover for the infiltration of several SpecOps teams from the Iraqi and Afghan bases, or whether these groups, code named ‘Red Six’ and ‘Blue Fourteen’ respectively, might suffer friendly fire. One error in timing, such as the barrage scheduled for the 3 AM on night of the 24th, could expose our troops to great harm. If this leads to a debate about whether the Tomahawk missile can be sent slightly off course by a concentrated microwave burst, as classified documents seem to suggest, it’s a debate we need to have.”

Picking up the beat(down) is David Reinhard of the Portland Oregonian ("Who died and left you president of the United States?" - hat tip: Powerline):

The founders didn't give the media or unnamed sources a license to expose secret national security operations in wartime. They set up a Congress to pass laws against disclosing state secrets and an executive branch to conduct secret operations so the new nation could actually defend itself from enemies, foreign and domestic... Not to worry, you tell us, terrorists already know we track their funding, and disclosure won't undercut the program. (Contradictory claims, but what the heck.) You at the Times know better. You know better than government officials who said disclosing the program's methods and means would jeopardize a successful enterprise. You know better than the 9/11 Commission chairmen who urged you not to run the story. Better than Republican and Democratic lawmakers who were briefed on the program. Better than the Supreme Court, which has held since 1976 that bank records are not constitutionally protected. Better than Congress, which established the administrative subpoenas used in this program. Maybe you do. But whether you do or not, there's no accountability. If you're wrong and we fail to stop a terror plot and people die because of your story, who's going to know, much less hold you accountable? No, the government will be blamed -- oh, happy day, maybe Bush's White House! -- for not connecting dots or crippling terror networks.

Stand with John Kerry on Net Neutrality

As a strong GOP backer who raised funds, wrote op-eds and appeared on talk radio in support of George W. Bush in 2004, I stand with John Kerry on the issue of net neutrality:

On Wednesday in the Senate Commerce Committee I warned that those of us who believe in net neutrality will block legislation that doesn’t get the job done. It looks like that’s the fight we’re going to have. The Commerce Committee voted on net neutrality and it failed on an 11-11 tie. This vote was a gift to cable and telephone companies, and a slap in the face of every Internet user and consumer. It will not stand.

If you've never made a call to your Senator before, this is your day. If you've never emailed him or her, the time is now. Muster the energy and do it.

The future of the incredible value-creation machine we know as the Internet is at stake. Put simply, the carriers wish to pick and choose the winners and losers among content providers: they, not you, will decide the next Google. They, not you, will decide which telephony service, which file-sharing software, which instant-messenger you will use.

How do we know this? Because the carriers have repeatedly told us of their intentions:

...William L. Smith, chief technology officer for Atlanta-based BellSouth Corp., told reporters and analysts that an Internet service provider such as his firm should be able, for example, to charge Yahoo Inc. for the opportunity to have its search site load faster than that of Google Inc. Or, Smith said, his company should be allowed to charge a rival voice-over-Internet firm so that its service can operate with the same quality as BellSouth's offering...

I can find no simpler way to put it: the carriers seek to turn the Internet into cable television. In doing so, they put America's technological leadership position at risk, they endanger the immense and fragile Internet ecosphere, and -- by extension -- they threaten the Internet itself.

Take action today. And tomorrow. And the next day... until the Senate gets the message -- loud and clear -- over the ringing of the lobbyists' cash registers.

Related: John Kerry on the Factor