I certainly don’t mean them to be straw men, but I do find your argument fairly generic as well, so maybe I am taking liberties. Here are some clarifications:

- It is up to the damaged party to assert liability and to sue somebody. That means someone who feels damaged should attempt it. To suggest somebody is liable also assumes that the injured party will sue for damages. I think it would be interesting (and fruitless) for someone to try to sue the CA.

- The action above does not preclude RapidSSL from seeking damages from the researchers for reasons originally described. I don’t know if this would work or not. Clearly, the researchers increased the risk by a huge amount (though I don’t believe increased risk is enough to assert damages).

- These two theoretical civil suits are not mutually exclusive nor are they synchronized in any way, so I don’t understand why you think someone should be sued “before” or “prior” to anyone else.

- My point with 3 and 4 relate to the assumption that people always want to assign liability based on individual vulnerabilities (how many times as the Internet died again?) yet there is no objective litmus test to determine this with software (actually, there is, but nobody uses it). Affect and availability heuristics prevail in cases like these, which is probably the reason you don’t want to “touch this”.

- If you are suggesting that every website that can set up an SSL tunnel should be trusted, I think you are crazy. No, the point of the generic CA is definitely not trust. It simply satisfies a process to set up an encrypted channel between two untrusted points. (This is different from true CAs in meaningful PKIs).

I agree that it might not be fraud, I just think that this kind of situation is grayer than ‘standard’ vuln discovery/disclosure as discussed in my original post.

Responsible disclosure incorporates notification of the affected vendor with some grace period prior to public discussion. They didn’t do that. The reason they used is a reason that anyone could use in this arena and therefore means that nobody needs to follow responsible disclosure (which they don’t anyway).

My argument related to your argument was that the CA should be liable to the end user and/or Internet community prior towards any litigation going towards the authors. A better argument against your position (IANAL either) would be my hope that since the CA did not take actions against a 2 year old paper that, their lawsuit would not hold up. But my cynicism for technical reasoning affecting legal proceedings is very deep.

#1: I don’t recall anything about the CA being sued, so I see this as a non sequitur to my comment. I see the CA being penalized by the community it supposedly is offering trust.

#2, #3, #4 I’m lost as to how these relate to my comments. No offense, but they seem like straw man arguments. For #2, step back and then ask yourself what is the purpose of a CA. #3, I don’t think I included or excluded any adversary in the discussion. #4, um, yeah, not even touching this.

Btw, I have disabled the RapidSSL CA [1] in my settings. The whole point of a CA is trust.

[1] C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1

They never issued certificates to anyone. I still don’t see how they acted in a fraudulent way and disregarded responsible disclosure to the vendor.

Does this count? If there are factual inaccuracies in my post, please point them out. If you disagree with my opinion, I’d enjoy hearing the counterargument. Thanks.

1) It certainly would be interesting for the researchers or customers or anyone you suggest has suffered damages to take RapidSSL to court. The damages are not as clear to me, though that would change if you know of a case or cases when this weakness was exploited in the wild.

2) I think you are assigning a level of trust to CAs that most Internet users do not. It is pretty easy to get a certificate signed (remember the Microsoft one?), and this isn’t even the easiest. In any case, nobody cares about authenticity, they just want the encrypted comm.

3) Don’t forget about the intelligent adversary. It is remarkable how easily the real ‘bad guy’ gets left out of the equation.

4) All non-trivial software has vulnerabilities. The world lives with it the same way the world lives with things like glass and plywood and easily picked locks on houses without suggesting the builders or the manufacturers are liable if someone breaks in.

@Security4all -

The reason researchers could get sued is that they have compromised the business process and (potentially) acted in a fraudulent manner. This is an exercise anyway, as Verisign appears generally supportive of their efforts.

Thanks for the thoughtful comments!

They did contact some vendors like Mozilla and Microsoft about the issue weeks (or even months) prior to the presentation.

I saw their presentation live from the first row in Berlin. They did make a certificate and posted it online as proof of concept but they had it expire in 2004 to avoid issues and had it put on the certificate revocation list. I think they acted ‘quite’ responsibly.

Set you PC clock back and test it on
https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/ (signed by MD5 collisions inc.)

Shouldn’t the CA also be liable to the customers (and non-customers because of the intrinsic risk) because they knowingly withheld a security update to their service that was exposed is academia almost two years prior? [1]. Doesn’t a CA have a higher level of responsibility again because one weak CA weakens all CAs, including the responsible ones that at a minimum stopped using MD5 for signing? Or, to make your argument more logically consistent, wouldn’t the authors of [1] be more liable than the group that showed the flaw, since the cat was out of the bag in the paper? (Although, there’s overlap between the authors and members of the two groups.) Or, do you differentiate between theoretical risk and empirical risk, and if so, why? Or, heck, go back to 2004 and sue the authors of the first MD5 paper on collisions [2]. They showed that MD5 was weak to begin with.

Before any researchers even are considered in litigation, I would like to see the CA be penalized. At a minimum, their CA cert should have been (or can still be) revoked from all browsers. We, as in the Internet community, have no way to trust them when they say their CA was not compromised from any prior attacks, even though the information was in the public court since 2007 and weaknesses were known since 2004. This demonstration should have not even been able to occur, in my opinion, if the CA acted more responsibly and heeded the warnings in the 2007 paper: “Therefore we repeat, with more urgency, our recommendation that MD5 is no longer used in new X.509 certificates.” Or, the CA could have even implemented a work-around: “Obviously, the attack becomes effectively impossible if the CA adds a sufficient amount of fresh randomness to the certificate fields before the public key, such as in the serial number (as some already do, though probably for different reasons).”

When do vendors become responsible for not responding to publicly-known flaws that can impact any Internet user and not just the vendor’s customer base?

[1] “Chosen-prefix Collisions for MD5 and Colliding X.509 Certificates for Different Identities”, Feb. 2007
[2] “Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD”, August 2004

No, I am not kidding. What kind of favor was done and who is the community you are talking about?

Thanks,

Pete