Certificate authorities seem to be a real weakness in SSL
My main reaction to recent events is that they show how certificate authorities are one of the real practical weaknesses in SSL. All of the theoretical security in the world can be trivially thrown away by shoddy practices on the part of a single trusted certificate authority, and we've recently seen not one but two such CAs exposed.
The case of the improperly issued mozilla.com certificate is a clear-cut procedural failure, either failing to vet your resellers or failing to properly vet a signing request or, for that matter, both flaws at once, depending on your perspective. My view is that it is both at once, since Comodo appears to have been happy to take money from what could generously be called an extremely dodgy reseller and to delegate customer verification to resellers, which I am not convinced is at all consistent with a CA's responsibilities.
While the RapidSSL CA exploit is primarily an attack based on the weaknesses of MD5, note that it was only made possible by the sloppy security habits of RapidSSL, namely sequential serial numbers and fast, predictable signing speeds. The latter is especially significant as a CA security issue, because it means that the ability to sign certificates with RapidSSL's CA certificate is very 'close' to the public-facing website and is fully accessible by automated means. Even if an attacker who can compromise the website does not get the CA private key, they have probably gained the ability to get a valid certificate for any host.
(I am going to generously assume that RapidSSL's internal software won't auto-sign CA delegation certificates or wildcarded certificates, and that RapidSSL's private key is held in a hardened dedicated crypto processor, not in something that an attacker could compromise.)
It would be nice if we could believe that these were isolated incidents. But I can't; I think that they are the inevitable end product of the kind of economic incentives that CAs operate under. There is simply no money to be made from security and from vetting people; security costs money, and vetting your resellers and customers not only costs money, it also loses you money as you have to turn down more resellers and customers instead of taking their money. In the absence of actual costs to this behavior (as opposed to occasional bad press), we should expect that there are far more weak CAs out there that just haven't been exposed yet.
One of Python 3's fundamental problems on Unix
Here is a thesis that I have been mulling over lately:
One of Python 3's fundamental problems is that it is trying very hard
to pretend that Unix is fundamentally a Unicode operating system, so
that Python itself can be Unicode-based while still working on Unix. The
problem with this is that it is demonstrably false, as seen in the
os.listdir() problem; Unix is fundamentally a
'bytecode strings' environment, and attempts to pretend otherwise can
run into problems any time that this pretense runs up against actual
os.listdir() problem is actually the smallest one.)
I am not sure why Python 3 has decided to hide this messy reality from programmers (it certainly knows that it exists; the release notes are full of commentary). It seems very atypical for Python, which has always struck me as quite honest about this sort of thing. My only theory is that the Python 3 people felt that programmers would revolt if they were forced to work in Unicode and to still deal explicitly with such conversion issues, so they felt that a flawed pretense that usually worked was absolutely required.
(Possibly this issue has been discussed to death on the Python 3 development lists, but I don't follow Python news in much depth any more; I ran out of time.)
Sidebar: why I care
It is tempting to brush this under the carpet with various excuses, especially because most people will never see this; most people work on Unix systems where everything is correctly encoded in a single encoding. But this is an unstable situation and results in software that merely usually works, if everything goes well. As a system administrator, I am unhappy about software that can be broken by someone doing something peculiar; I want my software to be as resilient as possible.