1353705 - security.ssl.treat_unsafe_negotiation_as_broken is not indicated for subresources on a secure page

Status: NEW

(Firefox :: Site Identity, defect, P3)

Description

[Darkspirit]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170404100210

Steps to reproduce:

you set securiy.ssl.treat_unsafe_negotiation_as_broken to true.
https://steamcdn-a.akamaihd.net/steamcommunity/public/images/avatars/70/70767680939ecfe0b2bf9e9c63ef2091b50e4370_full.jpg (has a green padlock with yellow triangle as it should)
but if you go to the parent site, this error of a subrequest is not shown: https://steamcommunity.com/groups/fast-aim-community (green padlock without yellow triangle)



Expected results:

1. A website should have a green padblock with a yellow triangle if a subrequest would have one.

2.  I want to suggest to enable this pref by default, but only in Nightly for now. The "enable for all" bug would be bug 665859. It would be nice if bug 1310447 could get enabled by default in Nightly together with this on the long way to bug 1351684.

Comment 1

[Darkspirit]

1.) If I understand it correctly: As long Akamai doesn't try a server-initiated renegotiation, everything should be safe, but the client can't be sure about this. That's why security.ssl.treat_unsafe_negotiation_as_broken warns about this.

https://www.ssllabs.com/ssltest/analyze.html?d=steamcdn%2da.akamaihd.net
Secure Renegotiation: Not supported, ACTION NEEDED (more info)

--> https://blog.qualys.com/ssllabs/2010/10/06/disabling-ssl-renegotiation-is-a-crutch-not-a-fix-2
=
https://blog.ivanristic.com/2009/11/ssl-and-tls-authentication-gap-vulnerability-discovered.html
+
https://blog.ivanristic.com/2010/05/secure-renegotiation-test-added-to-ssl-labs.html


2.) We will be safe with TLS 1.3
https://www.cloudflare.com/learning-resources/tls-1-3/
Features Removed from TLS 1.3: [...] Renegotiation

Conclusion:
Akamai sponsors OpenSSL's TLS 1.3 implementation, which doesn't have renegotiation.
It would be interesting to see some statistics about this topic. TLS 1.0-1.2 will live further years and it would be curious if Akamai was the only one. But if done wrong this is more serious than RC4.

Comment 2

[Darkspirit]

https://www.trustworthyinternet.org/ssl-pulse/
> March 03, 2017
> Secure renegotiation: 134,505 (96.8%)
> Insecure renegotiation: 1,412 (1.0%)
> Both: 417 (0.3%)
> No support: 2,625 (1.9%) 
> "In 2009, the renegotiation feature of SSL was found to be insecure. A successful exploitation of this issue may allow the attacker to impersonate his victims and extract confidential data. Most vendors have issued patches by now or, at the very least, provided workarounds for the problem."

As you can see, the "Secure renegotiation" rate went up 4% within 1.5 years, from 92.8% (bug 665859 comment 8) to 96.8%.
So we potentially have a small yellow triangle on 3.2% of the sites then. If Akamai fixes this, it could be far less:

My Email to Akamai quoted this bug, the stats and ends with this: 
> Expectations on you:
> a) You fix this.
> b) You currently have a secure workaround, but you adjust it to have a common behavior.
> Please. <3

Comment 3

[Johann Hofmann [:johannh]]

Enabling by default is covered in bug 665859. There's no real point in enabling it in Nightly only IMO, but you're free to make a new bug in Firefox:Security. Let's track subresources not being indicated as broken in this bug.