Folks,

On Wed, 4 Jun 2003 08:25 am, Daniel Stenberg wrote:
> On Tue, 3 Jun 2003, Torsten Foertsch wrote:
> > the patch below adds a "--peer-CN-regex <regular expression>" to the
> > command line tool and a new "CURLOPT_SSLPEERREGEX" to libcurl.

> I would guess that a much simpler approach would suffice for most people,
> using good old and much simpler DOS-style wildcards. Don't you agree?

I certainly agree with Daniel here - wildcard support is very simple, codewise
(I thought libcurl already gained this recently?) and completely adequate for
SSL security needs. (I personally think even wildcard certs are a bit
'dangerous', but they are widely accepted)

If you allow curl to make SSL connections to a CN which doesn't match the URL
hostname, then you almost might as well just use '--insecure' - the main
security benefit (of knowing exactly who you are connecting to) is removed.
Although the connection may be "encrypted", it's still vulnerable to
man-in-the-middle attacks (OK, maybe not so much on localhost), and
therefore the encryption also offers little protection. The result is a
completely false sense that the connection is 'secure' in some way.

I guess as long as the option is off by default, I don't care if curl has
something like this (code bloat and 3rd party libraries aside), but it still
looks like a powerful tool for users to shoot themselves in the foot where
ssl is concerned. I'd suggest it's better just sticking with the obvious
'--insecure' option....

Cris

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
Received on 2003-06-04