>> In short, I don't see what problem is being solved.

>The issue is one of user expectations.  Naive users expect that when they
>connect with SSL to a service, that connection has (at least) two 
>properties:

>1) They have a reasonable assurance that the identity of the other party
>   is what they believe it to be.

Which is flawed unless they verify the cert offered by the server.
[I know you know that ;-)]

>2) The connection is secure from prying eyes, even if those eyes choose
>   to run active attacks against the SSL session, e.g. MITM.

Also flawed unless at least one party verifies the cert of the peer.

>The problem is that much open-source software that uses SSL does not
>provide these properties because it does *no certificate validation at
>all*.  Obviously, without some trusted CA to validate against, you can't
>do any -- which, I'm contending, is an even worse situation to leave the
>naive user in than the one in which he trusts whoever you decided it
>might be reasonable for him to trust by default (IOW, uses the browser/OS
>default certificate bundle).

Yep.  When I implemented the BSD r* commands over SSL, I took the approach
of maying the client (ssl_rcmd) play the SSL server role.  This is the
entity for whom a cert is mandatory and since the server (SSLrshd) is the
one that cares about authenticating and authorizing the connection, we
ensure that the connection is verified by at least one party.
Naturally, if authentication fails or the cert is not authorized, the
connection is dropped.

The above is a much more suitable arrangement for SSL based authenticted 
services since it lends itself well to private CAs and such.
Obviously the HTTPS model is far common, but as you note, without browsers
verifying servers HTTPS has little value.

>Sophisticated users can look out for themselves -- they already had to,
>with no bundle provided and no validation going on, after all -- but it's
>Joe User who blithely tries to use pkgsrc lynx to do his online banking
>I'm worried about, here; the current state of the system leaves him all too
>open to attack.

If that's your target audience, then yes, including the veri$ign and other
common browser CA certs makes sense.

--sjg