On 2/7/08, Robert Relyea <[EMAIL PROTECTED]> wrote: > > D3|\||\|!$ wrote: > > The issue isn't with certificates; it is with private keys. > > > I disagree with you...What if somebody deleted the private key fromkey3.db > and its associated certificate entry in cert8.db??? Then added > his own thing and went around playing with it...??? > > > The keys in the key3.db will not match the certs in the cert8.db. > > Certs that have 'mojo' are the certs that have related private keys. They > show up as 'user certs' to NSS users. > If you delete key3.db, those certs will no longer show up as user certs, > and in effect are no different that the peer certs the user has collected > from S/MIME (for instance) to communicate with other S/MIME users. >
*I am not talking about deleting....I'm talking about modifying both the cert8.db & the key3.db!! Injecting fake(but valid) stuff into both the DBs...Then the attacker hijacks(blocks) the victim's connection, directing the traffic to himself... After this he can do a thorough man-in-the-middle job... :-) * You are right that private keys stored in files and protected > by passwords can be attacked with dictionary attacks, rainbow > tables, guessing, etc. The traditional counter-measure is to > store the private-key in a FIPS 140-2 Level 2/3 certified > hardware token that will not give up the private-key, and can > lock up after some configurable number of incorrect password > attempts. > > > This arrangement will work fine on the server side; but necessitating > the same thing for every client running the application... will be > cumbersome!! > > I would rather be tempted to use the mechanism being used by browsers > like Firefox and AOL communicator etc... > If somebody could shed some light on that, I'd be very glad... > > > The best bet is to allow the OS to secure the key3.db. NSS is certificate > for FIPS 140-2 Level 2, but it assumes the OS is protecting the > key3.db(requires an OS with manditory access control). > * Kindly refer to the other parts of the discussion: I have provided a solution that works for atleast the close source people... Creating a "wrapper file system" around the certdb & whose source code is not as readily available as that of the certutil.exe...* Warm Regards, > D3|\||\|!$ > > _______________________________________________ > dev-tech-crypto mailing [EMAIL > PROTECTED]://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
