Whither bug reports for false brokens in TLS 1.3?

Asked by B. C. Schmerker

In testing Mozilla Firefox 50-up on guest services at Cloudflare, I noticed that, due to major amendment of the TLS protocol at the Internet Engineering Task Force, the Page Info reports false positives for broken connections, viz., insecure content(s) and/or bad certificate(s), on actually secure Web pages in TLS 1.3 only. For example, a TLS_ECDHE_ECC_WITH_AES_128_GCM_SHA256 (in TLS 1.2 terms) reports as TLS_AES_128_GCM_SHA256 pursuant to the IETF draft specification for 1.3; the key exchange and certificate algorithm do not report in the cipher suite, unlike TLS 1.2. (CipherFox correctly reads the certificate algorithm for TLS_ECDHE_ECC_WITH_AES_128_GCM_SHA256 as ECC_256_SHA256; SSleuth, in TLS 1.2 terms as ECDSA_256_SHA256.) I consider this issue as applicable upstream at Mozilla Development but could not identify a bug consistent with the above misbehavior at BugZilla.Mozilla.org. (Possible that a tracking Bug is open for developing new code for correct behavior under TLS 1.3.) I see the false-broken issue as a sure Confirmed on account of multiple users affected and probably Triaged due to need for new code at Mozilla to address this misbehavior, but of no greater than high and in greater likelihood medium priority due to the protocol-specific condition. How does one go about filing a bug, if not already done, for a TLS 1.3-specific misbehavior?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu firefox Edit question
Assignee:
No assignee Edit question
Solved by:
B. C. Schmerker
Solved:
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said :
#1

I suggest you report a bug

Revision history for this message
B. C. Schmerker (bcschmerker) said :
#2

Done, Bug #1661400 filed. Apport tagged system data to the information for @mozillateam to forward upstream to BugZilla.