Hello Allie, Saturday, October 23, 2004, 17:36:00, you wrote:
AM> On Saturday, October 23, 2004 at 1:34:00 PM [GMT -0500], Army Redleg AM> wrote: >> Recommendation- >> The "Unknown CA Certificate" dialog box must give the User the ability >> to always select "View" allowing for a verification of server cert >> presented. Agree. See below. >> When viewing certificates in this manner a "hash" or digital fingerprint >> should be made of the certificate that TB! will check against in all >> future sessions to protect against sudden changes, tampering, MitM >> issues, etc... Disagree. Se below. >> The "Unknown CA Certificate" dialog box should give the User the ability >> to "Add to Trusted" any server certificate, chain complete or not, if >> they have viewed/verified and have determined this is from a server the >> User trusts (again, regardless if the server negotiates with a complete >> chain or not). >> ==== Agree. See below. AM> Interesting. Seems reasonable, though one wonders about the security of AM> it. I guess you're more interested in transmission encryption more than AM> strict authentication of the certificates? An user should *always* be allowed to "View" a certificate, mostly when there is an issue regarding it's validity (like an incomplete root chain). If this does not happen nowadays, then it is a bug on TB!. No questions about it. One might even go ahead and allow the user to add a certificate with an incomplete root chain to the base. No big deal here. But, here, we must draw the line. If the user succeeds in finding out the missing intermediate roots, and adds them to the base, then everything is OK, and life goes on. Otherwise -- i.e. there are still missing intermediate roots --, then TB! *HAS* to refuse using the certificate. If this is not an option for the user, then I humbly suggest the user to stop using SSL (or other schema in the same line). When you receive a certificate (on SSL negotiation) you do NOT trust this certificate. What you "trust", want it or not, is that it's signature can be verified by a "known" authority -- known to you, and accepted as such by you. This "known" authority is represented by the root certificates you accepted to use. Your trust on the certificate you received is transitive: you trust it because a know root confirms it. And *THIS* root is trusted by you not to mess up. As such, if there are missing intermediate root certificates, then there is no trust transitivity, and the certificate you received is, by default, tainted. This is not paranoia (although, I have to say, I *am* paranoid). This is simply the rules of the game. Allie, you are absolutely correct when you wonder about the security of this. There is none. Another option here is that this server is using a self-signed certificate. If this is the case, all that is needed to do is add the certificate itself to the trsuted root. 0bviously, there is then the problem of trust, back to haunt: you *can* trust a self-signed certificate, as long as you can positively confirm it. Since you cannot use a trusted root anymore, the only way to confirm it is by direct contact with the other party. Only after such confirmation should you add the certificate to the trusted root. -- ..hggdh.. Using The Bat! v3.0.1.33 and BayesIt! 0.7.3 on Windows 2000 5.0 Build 2195 Service Pack 4
pgpfiUhEmR5oV.pgp
Description: PGP signature
________________________________________________________ Current beta is 3.0.2.1 Beta/1 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
