On 10/29/2012 7:05 PM, Jeffrey Walton wrote:
On Mon, Oct 29, 2012 at 11:04 AM, Jakob Bohm <jb-open...@wisemo.com> wrote:
On 10/27/2012 10:58 PM, Jeffrey Walton wrote:

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. <blan...@gmail.com> wrote:

Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:

http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.


] Supporting wildcard certificates requires manually parsing
] the name to find the wildcard character, ensuring that it is
] in a valid location within the domain, and then trying to
] match the pattern with the server's expected hostname.
Don''t do it because it violates the Principal of Least Privilege. Why
should users be asked to trust the receptionist's machine in the lobby
or a developer's machine with nearly anything installed?

If you are in a multi-domain environment (such as Apache with virtual
hosts), use multiple certificates or Server Name Indication (SNI).


You obviously don't understand the proper uses and necessity of
wildcard certificates:
Actually, I do. Its not a risk I am willing to accept. As a security
architect, I am more than happy to kick software that follows the
practice.


If you truly understand the part of my post that you removed
(especially item 3), then your beliefs about its insecurity and your
insistence on blocking it on behalf of others not so deluded are pure
security theater.

I will repeat my item 3 here for reference:

> 3. Being covered by a wildcard certificates name match does not give
> a computer access to the private key needed to actually use that
> certificate.  The security model is that the wildcard cert identifies
> the organization, and the organization only installs the private key
> on trusted servers

Put another way, a wildcard certificate identifies a person or organization, not a particular computer. The person/org decides
which computers are trusted to represent them at the relevant level
of assurance.  It is the closest available approximation of giving
the person/org a path-constrained intermediary CA, with the path
constraint enforced for the DNS path, not the X.400 path.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to