Bugtraq mailing list archives
Certificate Validation Error in Netscape Browsers...
From: mattison () WEBOVISION COM (Dennis W. Mattison (Little Wolf))
Date: Wed, 15 Mar 2000 17:43:32 -0800
This may not be a normal "BugTraq" issue, since it is more a flaw in trust in a security design then it is an actual bug in software...but none-the-less I think it is something that should be discussed. I haven't checked this with Microsoft IE, I just noticed it as being a flaw in Netscape (submitted a bug report to them earlier but they are either really busy or have chosen to ignore the report.) Tested in browsers from 4.07 - 4.72, all which operated in the same fashion. What is the issue? The scenerio is that a user accesses a website for which they do not currently have trust for the signer of the certificate. They are asked whether they would like to trust the server certificate (until it expires,) which if they respond yes, the web site signer certificate will be stored in the certificate database. You can check on these certificates by clicking on the Security Icon on the browser, then select the Website item from the menu. Once stored in the database, any future access to this site is permitted without warning. The error occurs when the web site certificate is expired and the new site certificate is valid, Netscape never checks to see if the certificate is expired and replaced with a new certificate, and thus the user can continue to access the site without a warning stating that the certificate is expired and that a new certificate exists for the site (it apparently only checks to see if the new certificate isn't expired.) Manually verifying the old certificate in the database will prove that the certificate is invalid. When the site is properly reissued a certificate, Netscape automatically trusts the new certificate based on the previous certificate...if the previous certificate is removed from the database and the website is re-accessed, the standard warning appears asking the user if they wish to trust the certificate. Since the new certificate is cryptographically different from the old certificate, no trust relationship should exist (only the signer is the same.) Netscape does not replace the old expired certificate with the new certificate, and does not add the new certificate to the database. Nor does it tell the user that the new certificate a site is sending does not match a previous certificate. Why is this a problem? The problem is that there is an inherited trust between an expired certificate and an active certificate, where there really shouldn't be. If any trust should be there, it certainly shouldn't be with an expired certificate. The idea here is that Netscape should complain about a site which has a certificate different than what Netscape has in its database. When you accept a certificate from a website which you do not already hold a trust with the signer of the certificate, you should be warned if that certificate is no longer valid or when the server has been issued a new one. You are trusting that certificate and its signer, not that site. If the site's certificate changes, you should be warned about the change and asked if you still want to trust the site. If a hacker manages to gain access to the key and the certificate, and changes the key and the certificate, a warning may be the only thing to protect you from that hacker becoming a man in the middle to the attack. What should be the solution? An option, in the browser, to allow the user to be warned the first time a certificate changes on a webserver. If the previous certificate is expired, and the current certificate on a site is different, the user should be warned of the change, and asked whether they wish the new certificate to replace the previous one. That way, paranoid users like myself can be warned when a certificate changes, so that we can decide whether the new certificate should be trusted. Of course, if I already trust the certificate signer, then I shouldn't be prompted about the certificate. <HR NOSHADE> <UL> <LI>application/x-pkcs7-signature attachment: smime.p7s </UL>
Current thread:
- Exploit for Mandrake 6.1 (PAM/userhelper bug), (continued)
- Exploit for Mandrake 6.1 (PAM/userhelper bug) Paulo Ribeiro (Mar 14)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Darron Froese (Mar 17)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Matt Davis (Mar 17)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Jeremy Gault (Mar 21)
- Oracle Web Listener 4.0.x Cerberus Security Team (Mar 14)
- Re: Advisory Update: ServerIron TCP/IP predictability fixed H D Moore (Mar 14)
- Re: Advisory Update: ServerIron TCP/IP predictability fixed Max Vision (Mar 16)
- FreeBSD Security Advisory: FreeBSD-SA-00:07.mh [REVISED] FreeBSD Security Officer (Mar 19)
- Bypassing IP filters in Bordermanager 3.5 Roy Sigurd Karlsbakk (Mar 15)
- Local / Remote DoS Attack in MERCUR WebView WebMail-Client 1.0 for Windows 98/NT Vulnerability Ussr Labs (Mar 15)
- Certificate Validation Error in Netscape Browsers... Dennis W. Mattison (Little Wolf) (Mar 15)
- TESO & C-Skills development advisory -- kreatecd Sebastian (Mar 16)
- Trend Micro release patch for "OfficeScan DoS & Message Replay" V ulnerabilies Richard Sheng (Mar 16)
- Exploit for Mandrake 6.1 (PAM/userhelper bug) Paulo Ribeiro (Mar 14)
- Re: TESO advisory -- wmcdplay Wichert Akkerman (Mar 13)