[cryptography] current limits of proving MITM (Re: Gmail and SSL)

ITechGeek itg at itechgeek.com
Mon Dec 17 19:55:06 EST 2012

I think the browser makers should watch how many intermediates start issuing bogus certs and if a root has "high number" of intermediates issuing bad certs or has any intermediates that keep issuing bad certs, then the root should be held accountable (maybe not legally, but at least by the browser makers).

Might be hard to file a lawsuit against someone like diginotor unless damages can be proved (might be hard to prove an Iranian was thrown in jail for something posted online or emailed while Iran was doing a MITM of Google).

Apple, Google, Microsoft, Mozilla, and any other interested parties should come together and try to set a somewhat uniform policy for approving/revoking root CAs.

Maybe pull a Google and each hardcode some of their certs into their browsers to try and find MITM attacks with bogus certs.

Note high number should be defined as part of that uniform policy idea.

Sent from my iPad

On Dec 17, 2012, at 18:18, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:

> [A bit OT. Sorry]
> On Sun, Dec 16, 2012 at 5:51 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>> On Sun, Dec 16, 2012 at 4:48 AM, ianG <iang at iang.org> wrote:
>>> On 16/12/12 11:47 AM, Adam Back wrote:
> [snip]
>>>> On Sun, Dec 16, 2012 at 10:52:37AM +0300, ianG wrote:
>>>>> [...] we want to prove that a certificate found in an MITM was in the
>>>>> chain
>>>>> or not.
>>>>> But (4) we already have that, in a non-cryptographic way.  If we find
>>>>> a certificate that is apparently signed by say VeriSign root and was
>>>>> found in an MITM, we can simply publish it with the facts.  Verisign
>>>>> are then encouraged to disclose (a) it was ours, (b) it wasn't ours,
>>>>> or (c) mmmmummm...
>>>> Verisign cant claim it wasnt theirs because the signing CA it will be
>>>> signed
>>>> by one of their roots, or a sub-CA thereof.
>>> Just to nitpick on this point, a CA certainly can claim that they or an
>>> agent did not sign a certificate.  And, they can provide the evidence, and
>>> should have the ability to do this:  CAs internally have logs as to what
>>> they did or did not sign, and this is part of their internal process.
>> That brings up a good point: the CA should be responsible for their
>> reseller's or agent's actions. The CA entered into the relationship,
>> and no one forced them into the partnering.
>> I also envision a scenario where a CA sets up a subsidiary (that is, a
>> distinct corporate entity) and then uses the new corporate entity to
>> subvert the spirit and intentions of the system. Later, the CA claims
>> "it was them, not us."
>> Lack of responsibility and accountability are part of the problem. It
>> needs to be addressed.
> IANAL (thank God! ;), but I really don't see how this could work, at
> least unless there were laws specific and restricted to only cases like
> this narrow focus and I don't see that as likely. I think that this will
> continue to be enforced by legal binding contractual agreements
> rather than regulatory issues. There would be great resistance from
> most businesses to have it otherwise.
> What you propose all sounds good on the surface, specifically if
> the intent of the CA is to create such a subsidiary for potentially nefarious
> purposes, but intent is something is difficult to regulate as well as being
> difficult to prove.
> I'm sure if the scenario that you outline were to happen and a breach
> resulted because of it, both the CA and their subsidiary could be sued
> even without any specific existing laws governing this.  In many (most?)
> states in the USA (well, at least in Ohio), one cannot completely waive
> tort despite what the contract that sign says. (Or so my attorney informs
> me.) If it can be shown that there is an intent to defraud or negligence
> is involved (especially if it is intentional), the contract is thrown out the
> window. (Of course, showing enough evidence in court is another
> matter entirely.) In some such cases, even criminal charges are
> possible.
> But there is also an inherent risk in doing business and no business in their
> right minds would ever sign an agreement where they are liable for some
> other service provider's screw-ups. Usually, businesses want contractual
> agreements with their service providers where the service providers agree to
> liability in cases where service provider screws-up. (E.g., where their buggy
> software causes an unexpected service outage.) In my experience, most service
> providers--at least those with deep pockets--are reluctant to agree to
> even that much. So it is highly unlikely of businesses are going to support
> any type of legislation that makes them liable for what their service providers
> do. They naturally want to shed liability, not take it on.
> In the specific case that you mention, even if there were such specific laws
> it would likely mean an end CAs creating such CA subsidiaries which
> probably means higher prices for certificates all of us.
> If you think about what you are asking for in the *general* sense, I think you
> might reconsider. For example, consider a case where a merchant wants to
> do a credit check so they send a credit bureau an SSN and DOB and get back
> a credit rating. Let's suppose the merchant does all this securely and
> doesn't even
> permanently store the SSN / DOB, but only holds it long enough to get a credit
> rating back from some credit bureau.  Surely, you would not hold that merchant
> responsible for the credit bureau's lack of security, would you? Would you want
> that merchant to be able to be (successfully) sued even though a security breach
> of the credit bureau resulted in the identity fraud of all the
> merchant's customers?
> And of course a similar scenario could be possible with credit cards. Why should
> the merchant be responsible in such cases when that merchant has pretty much
> lost control of how someone downstream is handling sensitive data?
> I realize that we are somewhat comparing apples and oranges here, but law
> often tends to become become more encompassing than originally intended
> because it gets used a precedent in similar cases that are brought to
> trial. There
> is enough similarity here between what I think you are suggesting and the
> example that I've outlined and I'm fairly certain you would not approve of a
> merchant being held liable for another service provider's lack of security.
> So just be careful of what you wish for as there are likely to be unintended
> consequences.
> Regards,
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We *cause* accidents."        -- Nathaniel Borenstein
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

More information about the cryptography mailing list