Bug 181679 – [GTK] Styles not loaded from https://us.ivoox.com/es/

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Andres Gomez Garcia]

MiniBrowser with WebKitGTK+ 2.18.5-1 from Debian buster

If you go to:
https://us.ivoox.com/es/

The page doesn't show the styles (unlike with other browsers).

I don't think this is a new bug, just decided to report it now.

[Michael Catanzaro]

Unacceptable TLS certificate for static-1.ivooxcdn.com. There is no chain of trust at all. Until we support using authority information access to complete certificate chains, blocking it is the right thing to do. I'm hoping to work on that soon.

[Andres Gomez Garcia]

(In reply to Michael Catanzaro from comment #1)
> Unacceptable TLS certificate for static-1.ivooxcdn.com. There is no chain of
> trust at all. Until we support using authority information access to
> complete certificate chains, blocking it is the right thing to do. I'm
> hoping to work on that soon.

Not sure about the resolution status and your explanation.

If you have to work on this for WKGTK+, is it, then, a bug or missing feature in WKGTK+ or an actual bug from ivoox?

If it is the latter, I would like to know and how to explain the case so I can report to them ...

[Michael Catanzaro]

(CCing Brent because the privacy implications of (b) below are similar-ish to those of HSTS, and John because this relates to bug #171609.)

(In reply to Andres Gomez Garcia from comment #2)
> If you have to work on this for WKGTK+, is it, then, a bug or missing
> feature in WKGTK+ or an actual bug from ivoox?

It's actually both. The website is IMO broken because it's sending a single certificate with no chain of trust, that's why WebKit refuses to load the stylesheet, and why I picked INVALID as the bug resolution. Other browsers are doing questionable things to verify the chain:

 (a) Firefox caches intermediate certs that it has seen in the past, then uses them to complete broken chains in the future. This leads to nondeterministic certificate verification behavior since whether a particular website works depends on what websites you have visited in the past.
 (b) Other major browsers look in a certificate extension field of the server cert to get a URI to use to download the certificate from out of band. This is a privacy issue as it allows CAs to very easily track which websites you are visiting by using a different URL in each server certificate. Firefox refuses to implement it for this reason.

I'm planning to implement (b), because unless we convince some major browser to change what it's doing, we have to implement one or the other. (b) is what I believe Safari does, and I really don't want to make our certificate verification nondeterministic. See bug #171609, but in particular comment 5 there. My head comment in that bug is wrong because it assumes that Safari implements method (a), but I believe it has actually implemented method (b). Or maybe it does both... I don't know for sure.

[Andres Gomez Garcia]

(In reply to Michael Catanzaro from comment #3)
...
> (In reply to Andres Gomez Garcia from comment #2)
> > If you have to work on this for WKGTK+, is it, then, a bug or missing
> > feature in WKGTK+ or an actual bug from ivoox?
> 
> It's actually both. The website is IMO broken because it's sending a single
> certificate with no chain of trust, that's why WebKit refuses to load the
> stylesheet, and why I picked INVALID as the bug resolution.

Thanks for the thorough explanation, Michael.