Eddy Nigg (StartCom Ltd.) wrote:
Boris Zbarsky:
Could maybe try to brute-force the old key until they come up with a
forged
certificate that an SSL library accepts?
No, not really. It requires the possession of the certificate with the
weak key signed by a CA.
I really don't think that
Eddy Nigg (StartCom Ltd.) wrote:
Yes, in case the attacker managed to get a copy of the previously used
and signed key. Not, in case the subscriber managed to change his cert
before.
Right. But I'm not going to bet against the possibility that there a bad
guys even now downloading the public
Boris Zbarsky:
Could maybe try to brute-force the old key until they come up with a forged
certificate that an SSL library accepts?
No, not really. It requires the possession of the certificate with the
weak key signed by a CA.
The whole point is that all the weak
keys come from a
Eddy Nigg (StartCom Ltd.) wrote:
Oh, that would technically not be possible I guess. Searching for such
keys dynamically could take hours per key, hence previously created
keys are used. They would need to be hosted somewhere and compared to.
That's why Mozilla would know about which public
Gervase Markham wrote:
- Do nothing
Once Firefox 3 is released, many people will upgrade. This means they
will be using soft-fail OCSP, and so will detect attempts to use revoked
keys.
As far as I can see, there is no way around having at least an optional
extension that allows to check
Gervase Markham:
Eddy Nigg (StartCom Ltd.) wrote:
Oh, that would technically not be possible I guess. Searching for such
keys dynamically could take hours per key, hence previously created
keys are used. They would need to be hosted somewhere and compared to.
That's why Mozilla would
Eddy Nigg (StartCom Ltd.) schrieb:
Do you have an idea how big such a list
which would cover just the most commonly used key sizes would be?
The current lists of chksslkey that cover the vast majority of the weak
keys take 13 MByte -- no problem for most PCs.
bye, ju
Eddy Nigg (StartCom Ltd.) wrote:
Locally stored where exactly? Do you have an idea how big such a list
which would cover just the most commonly used key sizes would be?
Doesn't sound feasible to me, hence I thought you were talking about
some kind of lookup service.
Read, the bug, Eddy! :-)
Gervase Markham:
Eddy Nigg (StartCom Ltd.) wrote:
Locally stored where exactly? Do you have an idea how big such a list
which would cover just the most commonly used key sizes would be?
Doesn't sound feasible to me, hence I thought you were talking about
some kind of lookup service.
Hi Gerv,
[Off-topic] For one I must notice the incredible inconvenience in
working with Bugzilla and this mailing list. It happens many times that
the same issue is discussed and tracked at different bugs in parallel.
I'm a CC bug 434128 and just got aware of bug 435082. Can you tell me
the
Eddy Nigg (StartCom Ltd.) wrote:
This is a known shortcoming of FF2 and inherits higher risks then weak
keys. That's because if a certificate is revoked because of a weak key
it was most likely requested by the subscriber himself and he wouldn't
continue use of the weak key anyway.
But the
Eddy Nigg (StartCom Ltd.) wrote:
[Off-topic] For one I must notice the incredible inconvenience in
working with Bugzilla and this mailing list. It happens many times that
the same issue is discussed and tracked at different bugs in parallel.
I'm a CC bug 434128 and just got aware of bug
Boris Zbarsky:
But the MITM attacker could use it to impersonate the site, which is the whole
point.
Yes, in case the attacker managed to get a copy of the previously used
and signed key. Not, in case the subscriber managed to change his cert
before.
- Modify NSS/Firefox to detect
Eddy Nigg (StartCom Ltd.) wrote:
Yes, in case the attacker managed to get a copy of the previously used
and signed key. Not, in case the subscriber managed to change his cert
before.
Could maybe try to brute-force the old key until they come up with a forged
certificate that an SSL library
14 matches
Mail list logo
