bugtraq - Re: Self-signed certs unrestricted in Windows XP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 16 Dec 2003 14:08:26 -0700
From: "Kurt Seifried" <bt@...fried.org>
To: "Andrew Daviel" <advax@...umf.ca>, <bugtraq@...urityfocus.com>
Subject: Re: Self-signed certs unrestricted in Windows XP

> It appears that if a self-signed (test) certificate is installed under
> Windows XP, that it acquires all (or an unreasonable number of) privileges
> by default.

This is no surprise. When you created the self signed certificate you did
not place any restrictions on it (i.e. can only be used for web sites and
email, not code signing, 3 deep, whatever). You then installed the
certificate as a trusted certificate. It has no restrictions and as such can
be used to sign other certificate, other signing certificates, etc. This is
why there is support for "basic constraints".

> I was testing a webserver and Java applet which I had signed with
> a self-signed cert (https://andrew.triumf.ca/mterm/)
>
> I notice that under Windows XP, if I elect to accept the certificate
> permanently, and then go to the Content tab in "Internet Options" in IE,
> that I see my cert is installed under "Trusted Root CAs", and if I click
> Advanced, that it is by default trusted for a large number of purposes
> such as driver verification and time stamping; I can change this (and did)
> under "View->Details->Edit Properties".
>
> I would have assumed that it would only be trusted for "Server
> Verification" (and for the Java certificate, "Code Signing")

It has no restrictions and as such can be used to sign other certificate,
other signing certificates, etc. This is why there is support for "basic
constraints". Had you created a self signed certificate restricted to these
operations then you would have gotten what you expected.

> (In Netscape 4 or Mozilla on Linux, the server cert is installed only as
> an "SSL Server Site", while the Java cert, although installed as a CA,
> does not by default certify network sites, and is not used for local
> functions such as filesystem encryption, software package verification
> etc.)

This is because the certificate is installed in the web browser (since the
browser is stand alone), not as part of the general certificate store that
is an OS component (isn't integration neat!).

> Since by default self-signed certs are not trusted, and generate a lot
> of alerts if used, I don't see this a big problem. But on occasion
> someone may use such a cert to provide protection against eavesdropping at
> zero cost, and tell users "if you install the cert you won't get the
> popups every time you connect", without taking the same precautions to
> safeguard the private key as they might otherwise have done.

Yup. Shrug.

> (It might be nice to have a mechanism to trust a certificate for
> only one object, but I guess things don't work like that)

Nope. That's because X.509 certificate implementaitons are NOT about
providing security for the end user. They are about creating a sense of
trust (i.e. walmart.com really is walmart.com) so that users would feel
confortable using the Internet for online shopping, banking, executable
content delivery, etc.).

> -- 
> Andrew Daviel, TRIUMF, Canada
> Tel. +1 (604) 222-7376
> security@...umf.ca

Kurt Seifried, kurt@...fried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/