Obviously such attacks are possible because of the application security, renegotiation just makes it easier. BTW, here is a tool to check if your server is vulnerable to renegotiation attacks: https://www.ssllabs.com/ssldb/

BTW, clients (e.g. browsers) are pretty save - there is NO need to panic!!

Well, in our solar system at least one planet is spinning the other way around: http://wiki.answers.com/Q/Why_does_venus_spin_the_other_way It's not quite the same like orbiting into the opposite direction, but the Venus apparently received a nudge or two as well in order to spin the other way around. Such accidents appear to happen.

...Firefox to view this web site.

Correction, no single-point-of-failure problem. Retracting this statement.

Correct, specific plans exist for various scenarios. Concerning the web-of-trust, there are some inherent problems without a unifying institutional body. See, security has some clear rules which are easier to enforce in a corporate environment. Specially if you work at StartCom ;-)

And yes, I heard about "Perspectives", so it might have currently a single-point-of-failure problem. Personally I don't believe that it should provide a means for self-signed certificates. It might however provide a good additional layer to existing efforts.

I'm quite pleased to receive a A- :-)

The reason for not disclosing anything before is perhaps quite easy to understand. Minor events are logged in the ongoing events logs and no further actions are required. Events in the magnitude of issuing a certificate wrongfully due to a bug and which requires modifications to the systems, require detailed reporting (as seen in the "critical event report"). Those reports were reviewed in time by relevant parties and will be presented to the auditors during auditing. A major event like a CA key compromise (we don't sign directly from the root) would have to be made public and handled according to the "disaster recovery guidelines". In such an event, all software vendors, subscribers and the general public must be informed immediately.

The event which happened recently wasn't a major event, but obviously important enough to act accordingly and issue the critical event report. Important to note that no third party could have relied on and have taken damage. Therefore the resolution was appropriate. The disclosure was done in order to prevent any rumors and false accusations about what did and what not happened (once it was published by Mike).

There was huge difference between the recent events and how they were handled. Full Disclosure.

That's because your company distributed their root or server certificate with the active directory or domain controller. Chrome currently relies on the windows cert store so does IE obviously. Not so Mozilla Firefox and hence the error.

Some CAs proved that verification can be done correctly for the right price. The others must go if greed compromises our security.

According to the work done over at Mozilla, this shouldn't happen. The Mozilla CA Policy clearly requires domain control validation. Being myself part of the team which reviews CAs, I must say that there is a failure. It's unfortunate, because domain validated certificates do have a value and are excellent for protecting low-value sites like blogs, portals, webmail etc. But the practice disclosed in the article is certainly not going to work!

Except you use a CA which doesn't use user names and passwords ;-)