Slashdot Mirror

I'd written a blog post speculating about a worst-case scenario involving attackers using the leaked firmware signing keys to push a malicious firmware update from Sony's compromised backend servers.

Personally, I've disconnected my PS3 from the network until the all-clear sounds from Sony.

That's pretty trusting of you. Myself, I've permanently disconnected by PS3 from their network, and sold all my games already. When I get some time I'll go hack my system open and toss Linux on it, but its days as a gaming machine are now past.

I'd written a blog post speculating about a worst-case scenario involving attackers using the leaked firmware signing keys to push a malicious firmware update from Sony's compromised backend servers.

Personally, I've disconnected my PS3 from the network until the all-clear sounds from Sony.

Yeah, that's much worse... as long as you've got under $250 in your bank account and you consider any personal time dealing with banks to be worthless.

I'd written a blog post speculating about a worst-case scenario involving attackers using the leaked firmware signing keys to push a malicious firmware update from Sony's compromised backend servers. Personally, I've disconnected my PS3 from the network until the all-clear sounds from Sony.

No, only one party needs a certificate (call them party S for server). The other party (C for client) picks a random symmetric key and encrypts it to the public key of S. S decrypts it and the two ends can exchange data.

This is a (greatly oversimplified) overview of how SSL usually works, without client certificates. The CA is necessary because the client doesn't know the server's cert in advance. It does have the limitation that S cannot prove the absence of a man-in-the-middle, but C can. In practice, S relies on C to do a good job of this. If C trusts a corrupt CA, then all bets are off.

SSL was originally designed to make people feel comfortable typing their credit card numbers into web forms on the internet. So it didn't originally provide any way for the server to prove the security of the connection (hey as long as the card goes through, right?)

Apparently Mozilla doesn't accept Tunisia as a trusted CA at this time. I blogged about this issue regarding CNNIC.

I use http://213.251.145.96/cablegate.html

and

http://wikileaks.extendedsubset.com/cablegate.html

I hinted about this in a blog post last night http://extendedsubset.com/?p=40

I've been around a few years now and seen a few political battles play out. My gut feeling is that Lieberman's aides are madly trying to figure out how they're going to explain him out of this screwup. We might even see politicians calling for an investigating Amazon for conspiring with him. Tomorrow's talk shows are going to be interesting.

See for yourself. Check out Twitter #imwikileaks and #wikileaks tags right now.

The take-away here is that when I buy an Intel processor, I'm not getting the best performance, I'm not getting the best price, and I'm not getting the the best value. At best, I'll get crippleware. Crippleware sucked and I'm glad it died out of the marketplace back in the late 90s.

Some Intel products open security holes on your system with their defective DRM: http://extendedsubset.com/?p=30 . I just figured they couldn't get competent C programmers after what they did to Randal Schwartz http://www.lightlink.com/spacenka/fors/ . The HDCP leak was yet another example of fail. But now they want to bring this level of quality engineering directly into the CPU? Haha, no thanks guys.

Imagine the APT malware that would be possible if the CPU microcode update protections get busted wide-open like HDCP just did.

Now was it really such a good idea to hand the Elbonian Business Network a way to sell cracks for who-knows-how-many millions of CPUs for $50 each? Congratulations Intel, the black market value of a crack on your microcode just went from $100k to $M++. Did you stop to consider the fact that some of the top supercomputers on the planet are botnets? That's right: the adversary has the computational resources of a state actor and he doesn't even pay his own power bill.

I'm sitting right now within arm's reach of 14 Intel cores I've bought within the last year or two (from Atoms to i7's), never mind the stuff I have a voice in professionally. My next general purpose CPU is coming from AMD.

That was pretty hard to follow, what with the unrelated chatter about ARP and the origin of CRLF in HTTP headers.

Here's a better document: http://extendedsubset.com/Renegotiating_TLS.pdf with helpful diagram: http://extendedsubset.com/Renegotiating_TLS_pd.pdf

That was pretty hard to follow, what with the unrelated chatter about ARP and the origin of CRLF in HTTP headers.

Here's a better document: http://extendedsubset.com/Renegotiating_TLS.pdf with helpful diagram: http://extendedsubset.com/Renegotiating_TLS_pd.pdf

The linked articles only discuss authentication via client certificates

Not true. From http://extendedsubset.com/Renegotiating_TLS.pdf :

Cases not involving client certificates have been demonstrated as well.

It is a complex issue that has no simple/obvious solutions. The current protocols and almost all client/server software is vulnerable, and at least some of the attack scenarios are not uncommon.

It is a complex issue that has no simple/obvious solutions. That's why the usual blah is not occurring.

It is a huge thing because we used to design web services ala 'Slap SSL onto it, and traffic can not be modified and wiretapped' (assuming the server cert is right).
That beauty of SSL, just to add a layer that will take care of it all, is gone ... as the pdf states, even if no client certs are involved, the current protocols and all client/server software is vulnerable, and at least some of the attack scenarios are not uncommon.

all in all -> :-(

I had no certainty. I was simply taking the 3.0+ in the summary at face value.
However:
http://extendedsubset.com/Renegotiating_TLS.pdf
Says:
"including SSL v3 and previous"
So, I suppose that was simply inaccurate and I should have read thoroughly.

Now on to second part of your comment. If any part of the banking website supports client certificates, for any reason, it seems a renegotiation can be trivially triggered by the attacker.

Anyway, the portion:
"Not that the picture is all rosy even when client certificates are not involved. Consider the attacker sending an HTTP request of his choosing, ending with the unterminated line "X-Swallow-This: ". That header will then swallow the real request sent by the real user, and will cause any headers from the real user (including, say, authentication cookies) to be appended to the evil request."

Is a pretty severe attack as well and I don't see any safety from that one.