Ian, I'd rather not spell this out, because it's a blueprint that any
malicious coder could follow. Unfortunately, you seem to insist on
documentation -- and refuse to accept the word of those who actually
do know. So.
The "clear and present danger" exists.
It requires:
A router (say, a WRT54G) running a custom distribution of Linux,
listening on all 10.0.0.0/8 addresses.
A DHCP configuration that provides a local DNS server configuration.
A custom DNS server ('custom' in that it answers all name lookups with
10.0.0.0/8 addresses, allocating them dynamically)
A webserver that's tightly integrated with the DNS server (so it knows
the names that have been looked up and the IPs that they have been
given).
All the compromised keys.
Logic in the webserver to automatically download the certificate of
any site, and to recognize the compromised keys.
If it's not a weak key, transparently proxy the connection.
If it is a weak key, the webserver loads up the key for it along with
the certificate, then acts as the TLS endpoint in MITM mode,
decrypting the connection and talking to the real server as a TLS
client.
Since the name matches the certificate, even if it's not the True
World-Accessible IP for the server, Firefox won't complain.
-Kyle H
On Thu, Jan 22, 2009 at 4:26 AM, Ian G <i...@iang.org> wrote:
> On 22/1/09 12:26, Eddy Nigg wrote:
>>
>> On 01/22/2009 01:13 PM, Ian G:
>>>
>>> Although it is good that people rose to the challenge of the debian PRNG
>>> failure, I do not understand the position that all certs had to be
>>> revoked. Isn't it a situation between the Subscribers, Relying Parties
>>> and the CA concerned? That is, notification is as far as you can go?
>>
>> Indeed! Mozilla is a relying party.
>
>
> good point. So this means that Mozilla has agreed to the RPA?
>
> ;-) The problem with acting "as if" is that you get all the
> responsibilities and none of the powers.
>
>
>> A weak key is compromised from the outset and upon detection (which can
>> be actively pursued) requires revocation of the key by the CA. This is
>> what most CAs have in their policies. This was what drove some CAs to
>> actually revoke them. Gerv and others were very helpful in pointing out
>> the arguments in favor of such an action.
>
>
> Arguments in favour ... are nice. What about arguments against?
>
> The system could be further protected by other means. It could be used for
> client-cert work. It could be in use for a low-security usage, such as
> would be acceptable for SSCs. It could be an old or deprecated site. It
> could be a no-liability cert (that's an oxymoron, all certs are
> no-liability, but oh well)... It could be an expiry in a month. It could
> be a free cert, in which case no support is offered? It could be an S/MIME
> cert for internal email, in which case who cares? There could be penalties
> for revocation. The subscriber agreement could have covered this already.
>
> Unless you can demonstrate a clear and present danger to the end-user of
> Mozilla's products, it may be hard to to establish a line here. Theoretical
> weaknesses in crypto mean little, it's a business discussion, and the threat
> has to be related to the business risks, liabilities and obligations.
>
>
>
> iang
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
