Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 16:18:39, Antoine Beaupré wrote:
> On 2018-08-31 21:30:14, Ola Lundqvist wrote:
>> Hi Antoine
>>
>> Thank you for the input this is valuable. I have some comments below.
>>
>> On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré <anarcat@orangeseeds.org> wrote:
>>>
>>> On 2018-08-31 13:29:29, Ola Lundqvist wrote:
>>> > Hi all LTS contributors
>>> >
>>> > My question is whether removing default ciphers and introducing new
>>> > options is acceptable so late in the release cyckle. My assumption is
>>> > no, but let me know if you have another opinion. More details below.
>>>
>>> A priori, I think it is if it fixes serious security vulnerabilities and
>>> there is no easier way to do so.
>>
>> I'm not so sure this is a serious issue as it is only exploitable in a
>> rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is
>> unsupported by the peer.
>> Most software do have that support as I understand it.
>
> That's the crucial part, I guess. :) I am not sure.
The paper actually makes that claim which seems important:
> The “Encrypt-then-MAC” countermeasure from RFC 7366 is supported in
> mbed TLS and GnuTLS, but requires client-side support and has seen
> little uptake elsewhere (e.g. neither Firefox nor Chrome supports the
> EtM extension).
In other words, EtM is not well supported in clients at all, and just
forcing that mode does not seem to be a good strategy for mitigation.
The paper does refer to a good source for TLS adoption numbers.
https://notary.icsi.berkeley.edu/
With that as a source, it says that 10% of TLS traffic is still in CBC
mode. The site does not load here so I cannot make further research,
unfortunately.
[...]
> If you are unsure about updates, upload a test package somewhere and ask
> people for feedback. I do it all the time and it actually works, if you
> give people time (sometimes a week or more). For an update as critical,
> it would certainly be warranted.
Also, I would be happy to review patches and packages you propose,
unless that wasn't clear already. :)
>>> It seems that upstream did the right thing here and backported a bunch
>>> of stuff for us already - it'd be too bad to waste that effort and skip
>>> those CVEs. ;)
>>
>> :-D on the other hand maybe we break backwards compatibility. If it
>> wasn't for the backwards compatibility I would not have asked. :-)
>
> Yeah, I guess I don't know what's in those updates exactly, that's a
> good point.
Another important point I found while (finally) reading the whole
paper is that:
> However, we believe that the GnuTLS code is still vulnerable to
> variants of the attacks presented in our paper due to its
> padding-dependent memory accesses. We notified the GnuTLS team of our
> concerns about this on June 13th 2018. Our understanding is that the
> GnuTLS team does not plan to address the issues, but prefers to
> promote the use of Encrypt-then-MAC (as specified in RFC 7366) when
> legacy cipher suites are required.
Considering this and the lack of EtM support in the wild, I'm starting
to seriously question the claims of the GnuTLS upstream. It does not
seem like they really have fixed this at all, again, I should add.
I'm sorry I am not bringing a more positive note here, but it does seem
like things are a mess on GnuTLS' side. Maybe we should consider asking
upstream for more information about their stance on the paper author's
claims to get a clearer picture.
Finally, the paper mentions that the Red Hat security team issued those
CVEs, so they might have something up their sleeve as well, although a
look at their Bugzilla does not yield anything conclusive.
Good luck!
A.
--
If it's important for you, you'll find a way.
If it's not, you'll find an excuse.
- Unknown
Reply to: