BoringSSL: error in verifying ECDSA signature?

[mori...@gmail.com]

I really do not know it this is the right place for such a question... anyway...

For an embedded device, I've just compiled Chromium 56 (part of Qt 5.9.5 framework), but I've got some *strange* behavior about BoringSSL linked by Chromium...

Whatever HTTPS website I try to navigate to, I get the generic error page "This site can't provide a secude connection": ERR_SSL_PROTOCOL_ERROR"... Everything works like a charm for non secure HTTP sites.

Digging down into source code I found that the problem arises in BoringSSL's function ECDSA_do_verify(), in file ecdsa.c: the last call to BN_cmp() returns a value different than zero, and actually variables u1 and sig->r have different values:

Using wget or cURL on the same device (both of the relying on OpenSSL original libraries instead of BoringSSL) works fine, so the problem appears strictly related to BoringSSL and/or Chromium...

Any ideas of the reason of SSL failure? And/or can you provide me a way for further debugging this kind of stuff?

Thanks.

[Adam Langley]

On Mon, May 21, 2018 at 1:11 AM <mori...@gmail.com> wrote:

For an embedded device, I've just compiled Chromium 56 (part of Qt 5.9.5 framework), but I've got some *strange* behavior about BoringSSL linked by Chromium...

(M56 is 10 releases out of date and contains numerous, public security issues.)

 

Whatever HTTPS website I try to navigate to, I get the generic error page "This site can't provide a secude connection": ERR_SSL_PROTOCOL_ERROR"... Everything works like a charm for non secure HTTP sites.

Digging down into source code I found that the problem arises in BoringSSL's function ECDSA_do_verify(), in file ecdsa.c: the last call to BN_cmp() returns a value different than zero, and actually variables u1 and sig->r have different values:

A site like https://rsa2048.badssl.com/ should still work, right? That shouldn't trigger any ECDSA verify.

 

Using wget or cURL on the same device (both of the relying on OpenSSL original libraries instead of BoringSSL) works fine, so the problem appears strictly related to BoringSSL and/or Chromium...

Any ideas of the reason of SSL failure? And/or can you provide me a way for further debugging this kind of stuff?

Chrome 56 obviously didn't fail to verify ECDSA signatures because that would have broken the world. But lots of possibilities still remain.

I'm not sure how much we can help here, but I'd start like this:

It may be easier to iterate just with BoringSSL if you can get CMake to build on the device: https://boringssl.googlesource.com/boringssl. If you build in build/, then `build/tool/bssl client -connect play.google.com:443` will hopefully reproduce the issue as a test. The DEPS file at the top-level of the Chromium tree should include the exact revision of BoringSSL that it's building at.

One you have that setup (or maybe just with a Chromium build), I'd build BoringSSL on a desktop machine at the same revision and step them concurrently in a debugger. You can do things like printing the value of BN_bn2hex(foo) to show the values of the bigints. Try to manually binary-search with breakpoints for the point at which the computations diverge.

For that you'll want the inputs to be the same, which is why using just a BoringSSL build is nice: you can build crypto_tests and run with --gtest_filter="ECDSATest.VerifyTestVectors" to debug on the test vectors. Alternatively, you can craft a small, custom program based on that test to drive ECDSA_verify.

Good luck.

Cheers

AGL 

[Morix Dev]

Navigating to https://rsa2048.badssl.com does not result in a SSL error, but unluckily gives me a segmentation fault! ☹

 

I think that getting things work should take me a long long time… :cry:

 

/Morix

 

 

Da: Adam Langley
Inviato: lunedì 21 maggio 2018 17:30
A: mori...@gmail.com
Cc: security-dev
Oggetto: Re: BoringSSL: error in verifying ECDSA signature?