Daneil,
        just some 'thinking out loud' comments on your proposed changes:

On Tue, 27 Aug 2002 00:16, Daniel Stenberg wrote:
> On Sat, 24 Aug 2002, Cris Bailiff wrote:

...

> I'm slowly being convinced that you guys are preaching the right religion,
> and due to this fact I'm currently working on this:
>
> $ curl https:[URL hidden to save the innocent]
> curl: (58) Insecure SSL connect attempted without explicit permission
> granted Since SSL doesn't offer any true security if you don't use a CA
> certificate to verify the peer certificate with, you must either provide
> one to make sure that the server really is the server you think it is, or
> you must explicitly tell curl that insecure SSL connects are fine.
> Allow insecure SSL operations with -k/--insecure

Did you plan to add a ca-bundle file into the curl distribution? I know it's
a bit large (although it zips well), and it re-enforces the "global CA
monopoly", but I think it's probably worthwhile:

* With a default set of CA's, users wouldn't need to use '-k' when going to
sites that other SSL software (mozilla, ie, konqueror, opera etc.) normally
'trusts'.

* Finding and adding CA certs for many sites could be a bit tricky for many
users - they'll just use -k instead of finding their own ca-bundle, so
they'll basically turn off security when they didn't really need to.

> ... which in turn is controlled by the CURLOPT_SSL_INSECURE option to
> libcurl. If that isn't set TRUE, this kind of insecure connections will
> immediately return CURLE_SSL_INSECURE. Using -k will of course make curl
> work as before (like 7.9.8 and all previous versions).

* You wouldn't necessarily need a new libcurl option - just set the defaults
for CURLOPT_VERIFY_PEER=1 and CURLOPT_VERIFY_HOST=2 in the library, and let
the library user provide a CA file/path. If they don't provide one, and don't
change the verify options, they can't make secure connections.

* The command line tool can set CURLOPT_SSL_CACERT to the bundled one, and
'-k' could then just set CURLOPT_VERIFY_PEER=0 and CURLOPT_VERIFY_HOST=0.

* You could even have the library itself install the default CACERT file,
which would reduce the impact on existing library-using code. This would
remove any forced code changes for existing library using clients.

> The particular verbose error message above is this verbose to help users
> around the problems that this might introduce. I of course as always
> appreciate your help on putting the words in a better order or entirely
> different way to make end-users understand this better and faster.

Certainly a verbose error message is important - like the numerous popups in
a good browser - users should find it more convenient to use the security,
rather than to ignore it. The error could just be displayed, though, when SSL
verification fails with the included certs.

> I'm quite sure that the next release of curl and libcurl will be 7.10 if
> these changes go in, as I think this is a significant change to motivate
> this bump.

This seems reasonable, though with an included CA set, the impact of the
changes should be greatly reduced.

If you think it ugly that curl would need to reference a movable external
file, you can actually embedd default certs in the code, though this makes
changing certs prety inflexible. I have code for this somewhere if it's of
interest.

Cheers,
Cris

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
Received on 2002-08-27