search

mozilla / tls-interop

9 stars 7 forks source link

Investigate failure of CHACHA20-POLY1305-SHA256 with bssl_shim #11

Open jallmann opened 6 years ago

jallmann commented 6 years ago

I have already tried to figure out why testing this suite fails. The reason seems to be bssl_shim not activating this suite when asked to do so, but I couldn't figure out the exact reason and why it behaves differently than with other suites. It might be an issue with the exact name of the suite passed to the shim, since internally it seems to be named AEAD-CHACHA20-POLY1305-SHA256, but I reached certain limits of my understanding while investigating this. I'm pretty sure though that it's not an issue of NSS but of the boring shim.

jallmann commented 6 years ago

The three TLS1.3 ciphers seem to be excluded from the standard process of enabling/disabling cipher suites in boringSSL, and they seem to be enabled by default. I haven't fully understood why, but when passing another valid cipher-name (or none) to bssl_shim instead of CHACHA20-POLY1305-SHA256, the test case succeeds. The other two TLS1.3 suites only worked because "AES128-GCM-SHA256" and "AES256-GCM-SHA384" are valid TLS1.2 suite names in boringSSL and therefore don't crash the bssl_shim, like "CHACHA20-POLY1305-SHA256" and "AEAD-CHACHA20-POLY1305-SHA256" do.

martinthomson commented 6 years ago

Could you open an issue on boringSSL for this then?

jallmann commented 6 years ago

Where exactly do I file such an issue for boringSSL? This line in the source code suggests that TLS1.3-Suites are consciously excluded from the activation/deactivation mechanism all other suites are run through: https://boringssl.googlesource.com/boringssl/+/master/ssl/ssl_cipher.cc#716

Should I still file an issue to find out why this is the case?