Unfortunately, that's incorrect. By hearing (reading) the joke, you have observed its state. This has destroyed the alternative quantum state of the joke.

What will really irritate quantum physicists in this instance is that, unfortunately, the joke is both funny and unfunny at the same time. The state of the joke relies upon the opinion of the observer, not any quantum juxtaposition.

Millions of ordinary people didn't know there was a vulnerability until now. Who knows how many bad guys knew already though?

Knowing of a potential vulnerability allows people to alter their behaviour if they deem that an appropriate response. Systems administrators can examine setups to see if they can use other methods to secure communications and it also allows all those who have written applications to examine their code.

I'd rather know of a vulnerability and respond, than not know while others are potentially exploiting it.

If somebody is sufficiently motivated, has lots of free time, and has the knowledge, you can be sure they'd learn about this exploit before slashdot or the mainstream media. You can be sure they'd probably learn about it the moment the first researchers learn about it and sell the information, or brag about what they discovered behind closed doors. Lets get real, most people can't keep a secret and that includes the people who discover the exploits, and while it might not be on slashdot, the sort of people

Millions of ordinary people didn't know there was a vulnerability until now.

Dear Ordinary Person,

As you may have heard in the media, there has been an exploit discovered in the security protocols used in the banking sector. As such, we require you to log on and reset your password. Please click on this link [notreallyyourbank.com] and enter your security details there. Please ignore any certificate warnings that you might see, they are unavoidable while we implement a more secure protocol.

I wouldn't be so sure on that, anyone can read a mail-listing Ill quote this from Marsh Ray on the ietf mail list:

I can confirm the severity of the TLS MITM bug. I've had a workingexploit going since the end of August.

Steve Dispensa and myself put together (with help of many of course) anindustry working group to address it. I think we were successful inproducing a preliminary fix, which vendors are in various stages oftesting and deployment.

We'd agreed to responsibly delay disclosure to give the industry time tocoordinate the fix.

But let me ask this : who would ever require SSL renegotiation in practice?

I mean seriously -- changing the cipher in the middle of an SSL session??
-- no mainstream scenario would ever do this.

A question comes to mind why renegotiation was ever supported in the first place.

The next question is what OTHER seldom-used "features" are supported bymost SSL implementations that are just supported so that the implementationcan claim full RFC compliance, but are never actually used by real web sites.

It's more than changing the cipher type, it's also negotiating up from anonymous client to verified client. The second situation occurs ALL THE TIME in web services that require different levels of trust for different content within the same site. So it's not a "seldom-used" feature in the least.

SSL renegotiation is useful in the following situations, once you have established an ordinary SSL session:

* When you require client authentication
* When you are using a different set of encryption and decryption keys
* When you are using a different set of encryption and hashing algorithms

The last two are kind of useless in practice. The first one is very useful to authenticate the client. Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.

Umm, you want to rotate your block ciphers on long-running connections. Saying this isn't useful in practice implies that you must reset connections and recover at the application level instead, or risk using the same block ciphers for too long.

Umm, you want to rotate your block ciphers on long-running connections. Saying this isn't useful in practice implies that you must reset connections and recover at the application level instead, or risk using the same block ciphers for too long.

Never attribute to malice that which may be adequately explained by incompetence. There is of course always the possibility that someone would do this on purpose. But I still trust people who let us see the code more than those who don't.

Individuals who base their worldview on the assumption that the world is not a corrupt place are always shocked by financial collapses, or corrupt politicians, or corrupt cops. When are you going to figure out that people are inherently selfish, inherently corrupt, and they aren't looking out for your best interest?

Yes some are incompetent, but if there is financial incentive to be corrupt then you should consider the possibility of corruption based on the amount of incentive and not on any assumption.

Maybe its time we stop using SSL and just use GNUPG Auth. Let the user generate their own key and be responsible for their own security, or lets just use smart card readers. We make impossible to secure our machines due to our institutional insecurity. This way we can use it as an excuse to blame terrorists and get the feds involved.

Note that using a smartcard in this case would not help you. Smartcards provide a protected place to put your keys and do "private" stuff (like signing) but all the same protocols are usually used on top of that (including SSL/TLS).

I doubt GNUPG Auth is without fault itself. It's really hard to do security and crypto stuff correctly. Really, really hard as even the best mathematicians, theorists and developers in the world get caught out all the time.

You are clearly confused. This is about a flaw in the SSL protocol, not a flaw in X.509/PKI. The only real difference between PGP and X.509/PKI is in key management. Using PGP's extremely expensive, time-consuming, and error-prone key distribution method is the reason PGP is going extinct. Your grandma will never go to a key-signing party.

Another thing you are confused about: smart cards? What? What do they have to do with anything? Smart cards typically use X.509, not PGP. And in this case, smart cards wou

The problem is SSL. Did you do your research as to what GNUPG auth is? Sure it does not replace all the functions of SSL, but SSL if it's this broken isnt really much better. I think there should be an alternative to SSL so that SSL actually has reason to improve. If you only offer one crypto protocol and one set of options then what do you expect?

What password of random characters can you actually store in your mind and how many? If anyone actually has access to your machine then all your passwords are useless. Assuming your passwords cannot be cracked is silly. The smartcard removes the need to enter a password into a machine, this prevents remote users from using a software keylogger.

Passwords are why everyone is so easy to hack today. Nobody picks a secure password because those passwords cannot be remembered, and the passwords which can be remem

While the SSL crypto part is pretty neat, I always felt the commercial CAthing is one of the biggest money-making rip-off's in the entire IT field.Nor do I believe it to be secure or "trust" it. We always assume MITM's to besomeone without access to the CA's themselves. Frankly, the people I worrymore about are those, that DO have a

Indeed. GPG and SSH have workable trust models. Not perfect, but workable. The model in TLS is just wrong. Anything which requires me to trust the (hopefully merely incompetent) people working for Verisign is a loss.

I read the first article (second won't load...probably hosed by the/. effect) and it's still not clear to me why this is a big deal. Can someone explain how injecting prefixes compromises my secure datastream?

From what I understand, the MITM could "swallow" the original HTTP request from the client, inject their own URL (with parameters in the query string) into the request all while continuing to forward the client authentication cookies. Imagine prefixing an HTTP GET request for a poorly written webapp: GET bad.webapp.com/payment/send.php?account=12345&amount=1000000000.00 HTTP/1.1

Basically, the only thing the attacker gets is the ability to make the client's browser request whatever the attacker wants.

Oh, is that all? So for example, you can serve something that looks like my bank's home page but originates on your server.

Then when I enter my user name and password your server collects them, and if you're feeling particularly clever redirects me back to my bank's real site. Now you have access to my account, and I'm none the wiser.

Erm, no, you're getting it wrong. What this attack means is that the attacker gets the ability to make arbitrary requests for resources on behalf of the user.

So no, it doesn't mean that the attacker can now serve you malicious web pages that will appear to be coming from your bank's web site. What it does mean is that once you go to a secure page on your bank site, the attacker can instruct the bank to transfer money from your account to his, without you ever knowing. This is kind of similar to the IMG tag

You're right, this isn't a big deal. What they're describing is essentially a very complicated CSRF. The upshot is that you can get the user's browser to visit a URL of your choosing, but you can't see the results from that page. Sound familiar? That's because all you'd have to do is embed an IMG tag in some HTTP that the user is getting back in order to accomplish the exact same thing -- no fragile renegotiation attack required.

The key difference is that with IMG tag the attacker can only get the user's browser to make GET requests, whereas this attack enables POST requests as well. Any reasonably well-designed online banking application should not be exploitable via GET requests.

Also, the attack vector here is different compared to a "regular" CSRF through XSS. Which one is more practical is open to debate.

Let's say you have a web service exposed to your clients that processes orders. The error allows an arbitrary amount of data to be injected into the beginning of the client request - so the "bad guy" takes your request:
POST/OrderTheFrogs HTTP/1.0
content-length: 20

So it's really not that big of a deal for HTTPS. Attacks exactly like that already exist, they are called cross site request forgery. However this is a significant attack against other SSL wrapped protocols.

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 [extendedsubset.com] 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 scen

The linked articles only discuss authentication via client certificates, which seems pretty rare currently. How does this vulnerability actually impact the "usual" web commerce usages of SSL, which involves a server certificate? Also it does not appear that there is any way to force a re-negotiation from outside. And while re-negotiation appears common for client certs, I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS.
How important is this for the common-use cases of e-commerce and banking?

The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.

When routing, you have a default gateway IP... no, that's wrong. You configure such a thing; but what you have is an ARP request finding the MAC of the default gateway (say 10.0.0.1 -> 00:11:22:AA:BB:CC). Not sending to the local network? Slap that MAC as the target packet; the router interface gets the packet, reads the IP, says "Hmm that's not my IP address," checks routing table, s

ALL SSL attacks are MitM attacks. An eaves drop attack is a lazy MitM that could become an active MitM if he cared.Somewhat true.

One big downside of being an active MITM is it makes it much easier to get caught. If some peice of software doesn't behave in the way you expect or maybe someone manually verifies a certificate then the tampering may be reveled. Depending on how much influence they have they may then start looking for you.

Routers are often physically point-to-point, connected either to a network segment with exactly 1 router on it or directly to another router. Physically eaves dropping across these links is impossible.

In any other layout, you've got a router plugged into a switch. ARP spoofing can break the switch, in no greatly useful way. Still, the routers are configured (I've done this) in the same way as hosts: the next hop is a network address, which they ARP for the IP address of (unless you add a static ARP tab

The systemic problems in SSLv2 seem less-bad than this flaw in SSLv3.I will take the truncation of encrypted messages or attempt to downgrade the protocol (which as noted Firefox restricts anyway so it won't have much effect) any day over a replay attack.

The removal of the renegotiation and fixing of the protocol are excellent in medium-to-long-term.But as a user, right now, I'm using banks that *will* have that feature.

Reverting to SSLv2 is the only viable option apart from doing all my finances in person.

And your certainty that SSLv2 is not vulnerable to this same problem comes from?

And have you tried watching a session with your bank? Set up an ssl-dumping proxy and see if there are any renegotiations. I'm guessing not. This only occurs where the server needs a client certificate (not your bank) or the cipher suites are going to change (not going to happen on a "normal" TLS connection.

My non-terrible advice? It's not going to affect 99% of anything anyone does unless someone figures out a way to force the

I had no certainty. I was simply taking the 3.0+ in the summary at face value.However:http://extendedsubset.com/Renegotiating_TLS.pdf [extendedsubset.com] 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 certifi

If he is in the middle, he just has to force you to access a client certificate portion of the bank's website.He can do this by inserting a fetch for that data into some other request that you perform.And you don't even necessarily have to be doing any unencrypted browsing at the same time, due to the 2nd portion of the attack, seems he can insert unencrypted headers which could do a redirect.

And of course if you *did* do any unencrypted browsing in another window, a JS payload could be

I am not a developer or security expert, but I know quite a bit about Internet services (run my own LAMP server locked as tight as I can afford on a hobbyist's budget) and I do what I can.

Firefox disabled by default ssl2. In 2006, wrote a post telling users how to reenable ssl2 in Firefox [mistersquid.com]. One of my main users (and my fiance) gets lots of Firefox was running into errors. So, I disabled ssl2 in/etc/apache2/httpd.conf.

====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.====

Not unencrypted, just unauthenticated. The attacker will do the initial connection in which the client is not yet authenticated. Any data send at that time should not be trusted to come from the client, including any GET requests. This is a problem when the page is in a protected domain *and* the first page is accepting information from e.g. a GET request to fill in forms and such. Then the response will be encrypted for the authenticated user only, but the attacker still could inject information to the ser