[yocto-security] Default dropbear cipers should disallow SHA1

[KAINDL Bernhard]

Hi Richard, I'm also glad for having this discussion.

Agreed, uses of SHA1 should be disabled when possible, as only long 
obsolete ssh/ssh-servers with tons of security bugs (and should be 
banned therefore) need it.

I think you should submit a new patch (with the answers for Richards 
requests in the commit message to have that information recorded in in 
the git commit itself).

Just for more clarity or correction of your statements, I have a few 
remarks, in case you add them to the commit message. You wrote:
> According to https://www.openssh.com/releasenotes.html, SHA1 KEX is 
> disabled by default in the "OpenSSH 7.0/7.0p1 (2015-08-11)" release.  
> As far as I can tell, SHA1 MAC is still allowed.
> According to https://matt.ucc.asn.au/dropbear/CHANGES, SHA1 KEX is 
> disabled in the "2018.76 - 27 February 2018" release.  But SHA1 is 
> still allowed for MACs.  As far as I know, SHA1 MACs are still allowed.
These upstream releases didn't target SHA1, they targeted LogJam:
They only disabled diffie-hellman-group1-sha1 in response to the DH 
Group 1 weakness (LogJam for key lenghs <= 1024 bits)
> So I think SHA1 MACs are still allowed by OpenSSH and dropbear.  (As 
> mentioned in this email chain, these uses are considered weak but not 
> broken.)

Yes, and both upstream projects still support DH Group14 (2048 bits) 
which use SHA1 internally, by default.

For example, even Ubuntu 18.04 supports DH Group14, e.g. you can use ssh 
-oKexAlgorithms=diffie-hellman-group14-sha1-oMACs=hmac-sha1 to connect 
to it.

And not even OpenSSH 8.0 changed that, the reason is likely this:

The upstream projects and mass-market mainstream Linux distributions 
have a HUGE interest to avoid backwards-incompatible changes whenever 
possible.

> The OpenBMC patch disables all uses of SHA1 in OpenBMC's ssh server, 
> including SHA1 MACs.
Agreed, when the directive is security, breaking connectivity with 
ancient SSH clients like RHEL 5. Such old software should even be banned 
from such space.

I propose to implement this such more paranoid configuration as a 
PACKAGECONFIG:

This way, the pure implementation of the PACKAGECONFIG (without enabling 
it) should be merged into OpenEmbedded upstream, not Yocto.

In OE, OpenSSH should then also have a similar PACKAGECONFIG which 
allows to control if diffie-hellman-group14-sha1 and hmac-sha1 should be 
enabled in the programs by default, and both may be controlled by a 
DISTRO_FEATURE setting to have consistency when migrating between 
dropbear and OpenSSH.

The first step of just adding PACKAGECONFIG for dropbear should have 
little resistance as it does not make the software more restrictive, but 
it makes it easy for all security-aware OpenEmbedded layers and 
OpenEmbedded distros to just enable it.

In a second step, that can be extended to openssh and a DISTRO_FEATURE, 
which also helps OpenBMC for consistency too, should OpenBMC or its 
users switch to OpenSSH later.

Best regards,
Bernhard

On 08.05.19 20:18, Joseph Reynolds wrote:
> On 2019-05-08 09:34, KAINDL Bernhard wrote:
>> Hi Joseph,
>>
>> I am just an outside information source, but I researched SHA1 in SSH
>> recently.
>>
>> Summary:
>>
>> While it appears SHA1 in SSH is secure for now,
>> in the end,
>>
>> I agree in general to be as restrictive as possible with algorithms
>> for a embedded OS which might be hard to update (like a board
>> management controller etc).
>
> Richard and Bernhard,
>
> Thanks for your response.  I am glad we are having this discussion.
>
>
> To be clear about my purpose:
> The OpenBMC project has decided to remove all uses of DH group1 and 
> SHA1 in KEX and MAC and encryption ciphers because we have security 
> conscious users.  My question is if (a) OpenBMC carries that patch, or 
> (b) Yocto/poky or dropbear carries the patch (which means OpenBMC gets 
> that change from its upstream projects).  I just want that answer so I 
> know where to target this patch (and I understand it's a complicated 
> question).
>
>
> To expand on the details:
> It is important to distinguish uses of the SHA1 cipher in Key Exchange 
> (KEX), Message Authentication (MAC), and encryption algorithms.  They 
> are different uses.  OpenBMC has decided to remove all use of SHA1 in 
> MAC algorithms, not just KEX algorithms.  And that's what the patch 
> referenced in this email chain does.
>
> According to https://www.openssh.com/releasenotes.html, SHA1 KEX is 
> disabled by default in the "OpenSSH 7.0/7.0p1 (2015-08-11)" release.  
> As far as I can tell, SHA1 MAC is still allowed.
>
> According to https://matt.ucc.asn.au/dropbear/CHANGES, SHA1 KEX is 
> disabled in the "2018.76 - 27 February 2018" release.  But SHA1 is 
> still allowed for MACs.  As far as I know, SHA1 MACs are still allowed.
>
> So I think SHA1 MACs are still allowed by OpenSSH and dropbear. (As 
> mentioned in this email chain, these uses are considered weak but not 
> broken.)  The OpenBMC patch disables all uses of SHA1 in OpenBMC's ssh 
> server, including SHA1 MACs.
>
>
> To conclude: OpenBMC is tightening this security item.  I would urge 
> Yocto/poky and dropbear to do the same, considering the widespread 
> support for newer algorithms, but it is your decision.
>
> - Joseph
>
>
> P.S. Yes, I did fumble my previous OE-Core patch attempt.  This is a 
> different set of changes.