[Owasp-leaders] Cert Stealer Released
abbas.naderi at owasp.org
Sun Dec 29 17:46:44 UTC 2013
I’m talking about DNS rebinding and all similar attacks.
For example, what about certificate revokation? Can’t someone just revoke the pinned certificate and then pin their MITM certificate in place? Can’t someone force unpinning (there are always scenarios in implementations, not in specifications)? Doesn’t it just introduce another complexity in the browsers, which is bad for security? Do you think that stopping 99% of attacks is a good idea? because it only gives the user a sense of security. After all, valid cert MITMs are advanced attacks to begin with, and its easy to bypass these semi-protections when the heart is set on it.
My proposed solution would be to involve the user. Show him all the certs for the website, and ask for approval when the cert changes, by showing a list of certs and the dates they were encountered (similar to asking for cookies). Certs are not typical to change, and there is no need to ask for approval on the first cert the browser sees on a website (similar to pinning), but it should ask when a new cert is faced (typically in a year or two, on attacks more recently, there is a pattern to check as well).
That is my proposed short-term solution. The long term solution would definitely be to have a one-to-one relation between certs and domains, i.e instead of just asking CA for the validity of domain and cert, asking domain for the validity of its CA as well. It can involve a new protocl, or it can be just as easy as DKIM, having the domain vouch for its CA through a simple DNS lookup.
On Dec 29, 2013, at 12:39 PM, Tobias <tobias.gondrom at owasp.org> wrote:
> Hi Abbas,
> well, am not sure to which DNS pinning attacks you are referring, but it is correct key pinning is not the perfect solution and has some weaknesses, but it significantly reduces the attack surface.
> And hopefully it will be out and in all the browsers soon.
> (we are in the last review iteration in WG last call at this moment.)
> Cheers, Tobias
> On 29/12/13 17:26, Abbas Naderi wrote:
>> Well then it just introduces the new pinning attacks that existed on DNS. Thats not a solution.
>> On Dec 29, 2013, at 4:30 AM, Tobias <tobias.gondrom at owasp.org> wrote:
>>> just fyi: the browser vendors are in the IETF currently working on cert pinning, which should be released very soon and will pin the cert to a domain. (With that the browser will only accept your pinned domain cert for your domain, instead of any one from any of the 640s CAs worldwide.) This was developed as a response out of the Diginotar/Comodo incidents in 2011.
>>> Best regards, Tobias
>>> On 26/12/13 21:05, Abbas Naderi wrote:
>>>> They all are, the problem is, they are all trusted the same by the browser, regardless of whether you pay $5 a year for your certificate to be signed, or a thousand times that amount.
>>>> On Dec 26, 2013, at 3:57 PM, Gregory Disney <gregory.disney at owasp.org> wrote:
>>>>> Isn't that the whole point of certificate authority to be considered a trustworthy signer?
>>>>> On 12/26/13, 12:49 PM, Abbas Naderi wrote:
>>>>>> There is no such thing as the legitimacy of the signer. As long as someone trusted has signed a certificate, that one is deemed trusted too.
>>>>>> On Dec 26, 2013, at 3:36 PM, Gregory Disney <gregory.disney at owasp.org> wrote:
>>>>>>> Problem is browser should by default check the legitimacy of the signer, if it loaded into the CA-certs bundle in mozilla, majority besides akamia will show no difference. Well this trick isn't for governments anymore, it's for everybody. :)
>>>>>>> On 12/26/13, 12:26 PM, Abbas Naderi wrote:
>>>>>>>> Well this is changing the signer, e.g google is signed by a Level one and you’re using a Level 3.
>>>>>>>> This is an old trick though, many countries already used this to sniff on their people. The simplest way to stop it is to store fingerprints and check them later.
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4893 bytes
Desc: not available
More information about the OWASP-Leaders