SSL crypto broken in Daisy?

SSL crypto broken in Daisy?

[Boszormenyi Zoltan]

Hi,

I have built systemd-gnome-image from Daisy-based Angström using instructions from

http://wp.angstrom-distribution.org/?page_id=53

The set of layers include "meta-intel" and I use the "genericx86" CPU.

The image I have has curl installed and whenever I want to use an https:// URL from
the internal LAN it fails with:

========================================
curl: (35) gnutls_handshake() failed: Handshake failed
========================================

The same happens with and without option "-k" (or "--insecure") to curl.

The webserver's cert is not actually right, as I get this when I use curl from Fedora 19,
20 or 21Alpha:

========================================
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
========================================

But using "curl -k" with the same URL from the *Fedora client* fetches the data properly.

Is this problem already known in Daisy or Daisy-based Angström?

Thanks in advance,
Zoltán Böszörményi

Re: SSL crypto broken in Daisy?

[Paul Eggleton]

Hi Zoltán,

On Thursday 18 September 2014 14:36:16 Boszormenyi Zoltan wrote:
> I have built systemd-gnome-image from Daisy-based Angström using
> instructions from
> 
> http://wp.angstrom-distribution.org/?page_id=53
> 
> The set of layers include "meta-intel" and I use the "genericx86" CPU.
> 
> The image I have has curl installed and whenever I want to use an https://
> URL from the internal LAN it fails with:
> 
> ========================================
> curl: (35) gnutls_handshake() failed: Handshake failed
> ========================================
> 
> The same happens with and without option "-k" (or "--insecure") to curl.
> 
> The webserver's cert is not actually right, as I get this when I use curl
> from Fedora 19, 20 or 21Alpha:
> 
> ========================================
> curl: (60) Peer's Certificate issuer is not recognized.
> More details here: http://curl.haxx.se/docs/sslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default
>  bundle file isn't adequate, you can specify an alternate file
>  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in
>  the bundle, the certificate verification probably failed due to a
>  problem with the certificate (it might be expired, or the name might
>  not match the domain name in the URL).
> If you'd like to turn off curl's verification of the certificate, use
>  the -k (or --insecure) option.
> ========================================
> 
> But using "curl -k" with the same URL from the *Fedora client* fetches the
> data properly.
> 
> Is this problem already known in Daisy or Daisy-based Angström?

Hmm, this sounds like it might be related to the following bug:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6708

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SSL crypto broken in Daisy?

[Boszormenyi Zoltan]

Hi,

2014-09-18 14:41 keltezéssel, Paul Eggleton írta:
> Hi Zoltán,
>
> On Thursday 18 September 2014 14:36:16 Boszormenyi Zoltan wrote:
>> I have built systemd-gnome-image from Daisy-based Angström using
>> instructions from
>>
>> http://wp.angstrom-distribution.org/?page_id=53
>>
>> The set of layers include "meta-intel" and I use the "genericx86" CPU.
>>
>> The image I have has curl installed and whenever I want to use an https://
>> URL from the internal LAN it fails with:
>>
>> ========================================
>> curl: (35) gnutls_handshake() failed: Handshake failed
>> ========================================
>>
>> The same happens with and without option "-k" (or "--insecure") to curl.
>>
>> The webserver's cert is not actually right, as I get this when I use curl
>> from Fedora 19, 20 or 21Alpha:
>>
>> ========================================
>> curl: (60) Peer's Certificate issuer is not recognized.
>> More details here: http://curl.haxx.se/docs/sslcerts.html
>>
>> curl performs SSL certificate verification by default, using a "bundle"
>>  of Certificate Authority (CA) public keys (CA certs). If the default
>>  bundle file isn't adequate, you can specify an alternate file
>>  using the --cacert option.
>> If this HTTPS server uses a certificate signed by a CA represented in
>>  the bundle, the certificate verification probably failed due to a
>>  problem with the certificate (it might be expired, or the name might
>>  not match the domain name in the URL).
>> If you'd like to turn off curl's verification of the certificate, use
>>  the -k (or --insecure) option.
>> ========================================
>>
>> But using "curl -k" with the same URL from the *Fedora client* fetches the
>> data properly.
>>
>> Is this problem already known in Daisy or Daisy-based Angström?
> Hmm, this sounds like it might be related to the following bug:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6708

Yes, it sounds like it, but wget (in my tree currently built against gnutls) works when
the cert is ignored.
I'll try building curl against OpenSSL in my tree.

Thanks,
Zoltán Böszörményi

>
> Cheers,
> Paul
>

Re: SSL crypto broken in Daisy?

[Boszormenyi Zoltan]

2014-09-18 15:17 keltezéssel, Boszormenyi Zoltan írta:
> Hi,
>
> 2014-09-18 14:41 keltezéssel, Paul Eggleton írta:
>> Hi Zoltán,
>>
>> On Thursday 18 September 2014 14:36:16 Boszormenyi Zoltan wrote:
>>> I have built systemd-gnome-image from Daisy-based Angström using
>>> instructions from
>>>
>>> http://wp.angstrom-distribution.org/?page_id=53
>>>
>>> The set of layers include "meta-intel" and I use the "genericx86" CPU.
>>>
>>> The image I have has curl installed and whenever I want to use an https://
>>> URL from the internal LAN it fails with:
>>>
>>> ========================================
>>> curl: (35) gnutls_handshake() failed: Handshake failed
>>> ========================================
>>>
>>> The same happens with and without option "-k" (or "--insecure") to curl.
>>>
>>> The webserver's cert is not actually right, as I get this when I use curl
>>> from Fedora 19, 20 or 21Alpha:
>>>
>>> ========================================
>>> curl: (60) Peer's Certificate issuer is not recognized.
>>> More details here: http://curl.haxx.se/docs/sslcerts.html
>>>
>>> curl performs SSL certificate verification by default, using a "bundle"
>>>  of Certificate Authority (CA) public keys (CA certs). If the default
>>>  bundle file isn't adequate, you can specify an alternate file
>>>  using the --cacert option.
>>> If this HTTPS server uses a certificate signed by a CA represented in
>>>  the bundle, the certificate verification probably failed due to a
>>>  problem with the certificate (it might be expired, or the name might
>>>  not match the domain name in the URL).
>>> If you'd like to turn off curl's verification of the certificate, use
>>>  the -k (or --insecure) option.
>>> ========================================
>>>
>>> But using "curl -k" with the same URL from the *Fedora client* fetches the
>>> data properly.
>>>
>>> Is this problem already known in Daisy or Daisy-based Angström?
>> Hmm, this sounds like it might be related to the following bug:
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6708
> Yes, it sounds like it, but wget (in my tree currently built against gnutls) works when
> the cert is ignored.
> I'll try building curl against OpenSSL in my tree.

It seems the problem is not totally identical to bug #6708.

Neither buiding GnuTLS from master (3.3.5) nor porting the GnuTLS RPM spec
file from Fedora 21 Alpha (GnuTLS 3.3.7) to an OE recipe fixed it.

However, changing CURL's configuration to use SSL did fix it, this is what
Fedora uses. So, the other half of the bug report works for me, i.e. moving
away from GnuTLS. The bug report used OpenSSL, which

I have verified that wget does indeed use GnuTLS, as forcibly removing
libgnutls28 breaks wget and opkg, too, since it uses wget to dl the packages,
so don't try this at home.

Another thing I noticed while working on this problem is that Fedora cuts out
patented crypto algorithms out of the sources of GnuTLS and OpenSSL, in order
to avoid paying royalties. Despite this fact, these packages in OE don't need the
"commercial" flag and use the upstream pristine sources.

I have the set of package recipes that removes the non-free parts from both,
basically I used the "hobble-gnutls" and "hobble-openssl" from Fedora.

Also, I split up the NSS package per the Fedora style, so I have nss-util, nss-softokn
and nss recipes now. In my extra layer, ca-certificates is now at 20140201, i.e.
2014.2.1 from Fedora.

Is anyone interested in upstreaming these recipes? Or the patent protection parts?

Best regards,
Zoltán Böszörményi

>
> Thanks,
> Zoltán Böszörményi
>
>> Cheers,
>> Paul
>>