thanks for the quick answer! given the text in rfc 4346 then,
the conclusion is that curl simply doesn't allow anonymous
key exhange, _OR_ for that matter pre-shared key tls (as
described in rfc 4279. i fully understand the risk of a mitm
in the former case, but i still don't see why curl should care
if i don't. in the latter case, however, i cannot even think of
a good excuse...

--para

On Nov 27, 2007 7:22 PM, Johnny Luong <johnny_at_trustcommerce.com> wrote:
> you can find a more definitive answer in rfc 4346 section 7.4.2.
> basically in most cases, your going to see a server certificate unless
> the key exchange is anonymous (and i don't know of anybody that does the
> setup the anonymous way)
>
> -johnny
>
> paranoid paranoia wrote:
> > The following snippet in Curl_ossl_connect_step3 causes
> > aborted connection attempts even when curl is rather clearly
> > instructed to not bother checking the peer's certificate:
> >
> > ssluse.c: (lines 1638-1641 in 7.6.14, 1624-1628 in today's snapshot)
> > //-----------------------------------------------------
> > connssl->server_cert = SSL_get_peer_certificate(connssl->handle);
> > if(!connssl->server_cert) {
> > failf(data, "SSL: couldn't get peer certificate!");
> > return CURLE_SSL_PEER_CERTIFICATE;
> > }
> > //-----------------------------------------------------
> >
> > This code is executed _no_matter_what_ even when
> > CURLOPT_SSL_VERIFYPEER, CURLOPT_SSL_VERIFYHOST,
> > and CURLOPT_CAINFO are *all* set to 0.
> >
> > WHY?!??
> >
> >
>
>
>
Received on 2007-11-27