1906590 - HTTPS-Only/First shouldn't try to downgrade pages on 3s timer that have HTTPS RR enabled

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Simon Friedberger [:simonf]]

We have the same for HSTS in bug 1903292 but HTTPS RR is more involved and the spec draft is not clear yet.

Comment 1

[Malte Jürgens [:maltejur]]

After the fix for Bug 1903292 lands, the only thing we would need to do to fix this it to move the HTTPS RR check before the one for HTTPS-Only (similar to what was done in Bug 1722489).

Also moving this to the Necko component, as they have worked on HTTPS RR so far.

Comment 2

[Simon Friedberger [:simonf]]

In case it's helpful, I created this trace last week: https://pernos.co/debug/5J3YSwQVXnayn8k6g0SNRw/index.html#f{m[B1Fs,VxQc_,t[AQ,kuc_,f{e[B1Fs,VxIZ_,s{ae5ONgAAA,bAZI,uBBvVLw,oBCjD/Q___/

Comment 3

[edgul]

Attachment: Bug 1906590: Stop HTTPS-First downgrade when HTTPS RR exists r=edgul,valentin

Comment 5

[edgul]

The path forward on this is not clear to me. Can someone please advise?

Comment 6

[Frederik Braun [:freddy]]

To recap, HTTPS-First is changing request protocols to HTTPS and if the request does not succeed (or takes longer than 3s), we fall back to HTTPS.
When the site uses HTTPS RR, then it is clearly signaling that the browser MUST use HTTPS and we should not fall back. Similar to how we respect HSTS and do not fall back to HTTP.

The bug is that we don't fully respect HTTPS RR by introducing the fallback to HTTP after 3 seconds. Bug 1903292 has more info about the HSTS-case.

Does that answer your question?

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/02bc8b92025d
Stop HTTPS-First downgrade when HTTPS RR exists r=valentin,necko-reviewers,edgul,kershaw

Comment 8

[Serban Stanca [:SerbanS]]

Backed out for causing mochitests failures in browser_https_rr_no_downgrade.js.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | dom/security/test/https-first/browser_https_rr_no_downgrade.js | Should upgrade - Got 8, expected 1

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1bf7d34d6bcd
Stop HTTPS-First downgrade when HTTPS RR exists r=valentin,necko-reviewers,edgul,kershaw

Comment 10

[Atila Butkovits]

Backed out for causing failures at browser_https_rr_no_downgrade.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/5891b5225371504454654e425f593a673427693e

Push where failures started: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=K9cDNB-7QeO_YweyowHi_w.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&fromchange=77b89b1fd8abb6c6e6fbce66f8edfda7dcbf8be7&searchStr=os%2Cx%2C10.15%2Cwebrender%2Copt%2Cmochitests%2Cwith%2Cnetworking%2Con%2Csocket%2Cprocess%2Cenabled%2Ctest-macosx1015-64-qr%2Fopt-mochitest-browser-chrome-spi-nw%2Cbc10

Failure log: https://firefoxci.taskcluster-artifacts.net/K9cDNB-7QeO_YweyowHi_w/0/public/logs/live_backing.log

Failure line: TEST-UNEXPECTED-FAIL | dom/security/test/https-first/browser_https_rr_no_downgrade.js | For example.org we pretend to have an HTTPS RR and don't downgrade. - false == true -

Comment 11

[Simon Friedberger [:simonf]]

I've disabled the test for MacOS 10.15. I assume the test failed there because it did not have support for HTTPS RR yet.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc187638a970
Stop HTTPS-First downgrade when HTTPS RR exists r=valentin,necko-reviewers,edgul,kershaw

Comment 13

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/cc187638a970