[10:22:23] 07HTTPS, 10Traffic, 10Wikimedia-Site-requests: when serving Uzbek Wikipedia, make HTTPS canonical - https://phabricator.wikimedia.org/T45466#2337421 (10FriedhelmW) [13:00:14] bblack: perfect! [13:01:38] I tried splitting too, but it doesn't seem to like multiple ssl_stapling_file directives, and doesn't like them split -> concatenated in one file either [13:02:18] so I guess they do multi-issuer multi-cert stapling independently with the built-in stapler, but still only support a single staple-data per server stanza if using ssl_stapling_file (which implies only works for single-issuer multi-cert) [13:02:21] so basically the current setup works as long as both certs are issued by the same issue? [13:02:33] right [13:02:53] s/same issue/same issuer/ [13:03:18] either way, works for our case [13:04:28] nice that we can dump the patches too :) we'll still need a local build against our ossl1.0.2, and need that one local patch for debhelper issue [13:05:35] but the multicert and stapling ones can be dropped, nice [13:06:42] aside from the multi-cert work, 1.11 brings some nifty things. The HTTP/2 pre-read buffer, they've killed DHE cipher support without explicit ssl_dhparam (which is how we operate too, but nice that the default is more-secure now) [13:07:21] and the curves list thing. before it was just one fixed curve, now it's a list defauling to "auto", which with ossl1.0.2 is basically the NIST 256, 512, 384 curves [13:07:38] (before it was just the NIST 256) [13:08:00] great [13:08:00] in theory even though our ECDSA cert is NIST-256, the ephemeral part can be negotiated with one of the other two [13:08:07] if the client supports doing that [13:08:36] the changelog jumps straight from 1.9.15 to 1.11, wasn't there a 1.10 release in between too? http://nginx.org/en/CHANGES [13:08:54] and then building on that, when ossl1.1.0 gets released and we upgrade to it, X25519 gets added to the list as the first preference [13:09:23] (in theory at that point, if globalsign supported it, we could also add a third parallel cert with the cert as Ed25519 instead of NIST-256 too [13:10:02] along with the chacha20poly1305 coming in ossl1.1.0, it's possible to get completely free of crypto of questionable origins [13:10:14] (at least, for very modern browsers that track along with this stuff too) [13:11:21] ema: I think they fork a separate branch for 1.10 since it's their "stable" series, so master/ongoing-dev goes from 1.9.15 to 1.11 [13:11:34] but 1.9.15 == 1.10.0 exactly in code terms [13:12:13] oh I see [13:15:55] also I was reading the TLSv1.3 draft the other day, and something I hadn't realize before is they're replacing sessionids and rfc5077 tickets with PSK basically. [13:16:35] kinda puts a damper on us bothering with RFC5077 infrastructure for T86671 [13:16:35] T86671: HTTPS RFC5077 session tickets encryption key rollovers - https://phabricator.wikimedia.org/T86671 [13:17:20] basically on initial connection with a new client, instead of doing sessionid/ticket creation, a pre-shared secret key is negotiated that's based on the existing session's security [13:18:05] and then for the near-future reconnects, you actually switch algorithms from e.g. ECDHE-ECDSA-AES128-GCM-SHA256 to ECDHE-PSK-AES128-GCM-SHA256 [13:18:13] and use the shared secret from before [15:07:12] 10Traffic, 06Operations, 13Patch-For-Review: Raise cache frontend memory sizes significantly - https://phabricator.wikimedia.org/T135384#2337520 (10BBlack) At the new values testing on cp3048 we seem to stabilize around ~96G virt, with the usual RSS variation in the [78]xGB range. That's only 22% overhead,...