[17:55:19] 10Traffic, 10Operations, 10Research: Set up git-driven static microsite for wikiworkshop.org - https://phabricator.wikimedia.org/T242374 (10bmansurov) Status update: I've [[ https://www.mediawiki.org/w/index.php?title=Gerrit/New_repositories/Requests/Entries&diff=prev&oldid=3609873&diffmode=source | requeste... [21:12:54] Have we had many reports of modern browsers getting sent to https://en.wikipedia.org/sec-warning [21:13:20] iOS 13.3, ssl labs does say they support 1.2 etc [21:13:48] oh, I didn't know we were doing that [21:14:01] had thought of opening a phab task about what are we planning to do? [21:14:20] I looked at the requests at WMES [21:14:32] and there were lots of mobile devices using TLS 1.0 :( [21:15:03] Reedy, we've had a few through info-en [21:15:15] HakanIST: Nice timing ;P [21:15:42] So hopefully it's maybe just devices not negotiating to the "best" they can support [21:15:47] don't think I've heard any complaints about iOS [21:16:06] I have heard of one case of a Windows 10 + Edge user getting the page despite having TLS 1.2 enabled [21:17:18] It seems to be working now [21:19:38] not negotiating to the "best" they can support -> this doesn't make sense [21:19:51] it could be that they are misconfigured not to use TLS 1.2 [21:20:01] or that they needed certain patches [21:20:18] Platonides: In HakanIST's case, sslabs confirms it is configured to use TLS 1.2 [21:20:39] I'm not even sure you can change it on ios safari [21:20:54] so, it negotiates 1.2 against ssllbs but not against wikimedia? O_O [21:21:09] Seemingly [21:21:22] Or there's some sort of caching/weirdness from the wikimedia side [21:21:48] so this is a modern browser getting sec-warning? [21:21:55] it'd be a stretch but maybe it has something to do with turkish govt block of wikipedia [21:21:57] when it theoretically should support TLS 1.2? [21:21:58] HakanIST: could you visit https://servidor.wikimedia.es/tls-test-HakanIST ? [21:22:28] just did [21:22:28] Not theoretically, it does according to https://www.ssllabs.com/ssltest/viewMyClient.html [21:23:30] you used TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 [21:23:51] https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=11268064 [21:23:57] I use 1.1.1.1 dns at home to access wikipedia at home, elsewhere (other isps) changing dns doesn't work [21:23:59] and the Romanian guy TLSv1.2/DHE-RSA-AES256-SHA [21:26:28] so that makes this the second unexplainable cases of a client that should support TLS 1.2 somehow getting sent to /sec-warning [21:26:32] maybe we should mention it at https://phabricator.wikimedia.org/T238038 [21:32:00] the message mentions a cut-off date of 1 January [21:32:33] so if you were connecting using TLS 1.0, now supposedly you wouldn't be able to connect [21:32:45] so couldn't see the message either :/ [21:34:13] yeah I don't think anything happened on that day? [21:34:36] there is https://gerrit.wikimedia.org/r/c/operations/puppet/+/562779 but it is not merged [21:36:10] maybe it hasn't been actually disabled yet [21:38:53] I'm wondoering, regarding the browsers not negotiating TLS 1.2 [21:39:09] if perhaps they got a transient connection error [21:39:19] and the UA automatically tried downgrading the TLS version [21:40:12] there would be the tls_fallback_scsv [21:40:28] but maybe the sec-warning takes precedence? [21:45:02] one interesting thing we found for the edge user was that it only showed up on english, the portal and other languages were fine [21:49:03] that's weird [21:49:57] perhaps some cached setting [21:50:06] who knows since when [21:50:44] definitely feels to me like some weird cached thing somewhere yeah [23:53:16] 10Traffic, 10Operations: servers freeze across the caching cluster - https://phabricator.wikimedia.org/T238305 (10Krenair) `Jan 12 22:51:15 PROBLEM - Host cp3065 is DOWN: PING CRITICAL - Packet loss = 100% Jan 12 22:53:51 PROBLEM - Host cp3061 is DOWN: PING CRITICAL - Packet loss = 100%...