Summary: | [Cocoa] Stop performing caching of intermediate TLS certificates and/or automatic certificate downloading | ||
---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | kaie, mcatanzaro, wilander, youennf |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 10 | ||
Hardware: | Mac | ||
OS: | macOS 10.12 | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=181679 |
Description
Michael Catanzaro
2017-05-03 11:16:52 PDT
Hi Michael! For clarity, when you say "Igalia could certainly implement this functionality for our ports, and we will if we have to", do you mean you could implement intermediary caching to be able to accept incomplete chain connections in many cases? (In reply to John Wilander from comment #2) > Hi Michael! > > For clarity, when you say "Igalia could certainly implement this > functionality for our ports, and we will if we have to", do you mean you > could implement intermediary caching to be able to accept incomplete chain > connections in many cases? Yeah... if we can't get any traction on having this feature removed from some major browser, as would be ideal, then we'll eventually give up and implement it. (It would actually need to be done in one of our dependencies, glib-networking.) (In reply to Michael Catanzaro from comment #3) > (In reply to John Wilander from comment #2) > > Hi Michael! > > > > For clarity, when you say "Igalia could certainly implement this > > functionality for our ports, and we will if we have to", do you mean you > > could implement intermediary caching to be able to accept incomplete chain > > connections in many cases? > > Yeah... if we can't get any traction on having this feature removed from > some major browser, as would be ideal, then we'll eventually give up and > implement it. (It would actually need to be done in one of our dependencies, > glib-networking.) Thanks! I have now passed on your request to the engineering team behind Safari's TLS stack. If there's anything we can share from that conversation, I'll do it here. OK, I totally forgot when I filed this earlier today, but there is another possibility for how Safari might be verifying this incomplete chain. It could be using the authority information access extension of the server certificate [1] to download the intermediate. If so, then the result is predictable, this bug report is invalid, and we should change nothing on Mac. Instead, other WebKit ports should implement the same functionality in their networking backends for compatibility. (Igalia would handle the libsoup backend.) But if it's caching intermediates, then everything I said earlier is valid and Safari should stop doing that. It would be good to get confirmation from the relevant Apple developers as to what is happening here: is it caching intermediate certificates, or is it using authority information access? [1] https://tools.ietf.org/html/rfc5280#section-4.2.2.1 And five minutes later, I have confirmation from Google that AIA is in fact what Chrome is doing here, with no intermediate certificate caching. Since Chrome uses authority information access, we pretty much have to implement that now. But my Google contact is telling me they think you do *both* intermediate certificate caching *and* authority information access lookup. It would be great if you could confirm this, since if Safari is indeed caching intermediate certificates, that is independently a bad thing. (In reply to Michael Catanzaro from comment #6) > But my Google contact is telling me they think you do *both* intermediate > certificate caching *and* authority information access lookup. It would be > great if you could confirm this, since if Safari is indeed caching > intermediate certificates, that is independently a bad thing. Actually I misunderstood his mail, he's saying he thinks you are doing only AIA. If your TLS people can verify that, then this bug report should be closed as invalid (and sorry for the false alarm). I have learned a lot about this today.... We're going to implement authority information access lookup for soup-based WebKit ports, despite the privacy concerns, because it seems to be the only option for web compatibility right now. (In reply to Michael Catanzaro from comment #8) > We're going to implement authority information access lookup for soup-based > WebKit ports, despite the privacy concerns, because it seems to be the only > option for web compatibility right now. (the only option that does not result in nondeterministic certificate verification) |