Change Details

This is one of our two last remaining non-forward-secret ciphers, which we'd like to eliminate as soon as reasonably possible. It's also the subject of the [[ https://sweet32.info/ | SWEET32 ]] birthday attack due to being a 64-bit (block size) cipher, which we've mostly-mitigated in other ways for now (shortened session key lifetimes). The only statistically-significant browser which relies on this cipher to communicate with us is IE8-on-XP, which is long-unsupported (over 2 years now) and horribly insecure, so any motivation we can give users to get off of this browser is a net win for everyone involved. Currently this cipher amounts to ~0.17% of all requests to our sites (and has been slowly declining for some time), and we've been running a very limited campaign for a while now which redirects a very small percentage of those requests (filtered down to just /wiki/ pageviews on the desktop sites, and only 1% odds) to the information at https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations . Because of technical limitations, we can't scale up that redirect much without having a better mechanism in place. IE8-on-XP is too old for CentralNotice JS to function correctly, so CN isn't really an option for campaigning here. Users which cannot move off of the underlying Windows XP operating system can install the latest Firefox easily and use that to connect to us with much more secure cipher choices, so there is a fairly painless path forward for these users. The plan of action here is this: [ ] - Coordinate with the Community team to ensure they're aware of everything here ahead of any user complaints. This probably isn't the kind of situation where pre-announcements on community talk pages and/or mailing lists help much, as the target users aren't likely to be readers there, but it's still better to be prepared with answers. [ ] - Prepare a couple of pages on meta.wikimedia.org based on something like https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations . The first should be our user redirect target, and should be very simple and direct about the 3DES issue in particular, specifies the future cutoff date on which support will be disabled, and provides advice for users to avoid loss of connectivity to us (such as installing Firefox on XP, or upgrading to Win7+, etc). The second can be a more-detailed explanation of broader things like the existing wikitech page. [ ] - Code to show this to a random X% of pageviews from affected clients (keeping in mind avoiding redirects for these pages themselves). [ ] - Once the above is ready, we'll set the final timeline in place: a 2 month period over which we'll ramp the percentage up from a small value (say, 5% of affected pageviews) to 100% of affected pageviews, and a further month during which we'll still allow connections from affected clients, but 100% of their pageviews will go to the information page. [ ] - After the 3 month window is complete, remove support for this cipher entirely.

This is one of our two last remaining non-forward-secret ciphers, which we'd like to eliminate as soon as reasonably possible. It's also the subject of the [[ https://sweet32.info/ | SWEET32 ]] birthday attack due to being a 64-bit (block size) cipher, which we've mostly-mitigated in other ways for now (shortened session key lifetimes). The only statistically-significant browser which relies on this cipher to communicate with us is IE8-on-XP, which is long-unsupported (over 2 years now) and horribly insecure, so any motivation we can give users to get off of this browser is a net win for everyone involved. Currently this cipher amounts to ~0.17% of all requests to our sites (and has been slowly declining for some time), and we've been running a very limited campaign for a while now which redirects a very small percentage of those requests (filtered down to just /wiki/ pageviews on the desktop sites, and only 1% odds) to the information at https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations . Because of technical limitations, we can't scale up that redirect much without having a better mechanism in place. IE8-on-XP is too old for CentralNotice JS to function correctly, so CN isn't really an option for campaigning here. Users which cannot move off of the underlying Windows XP operating system can install the latest Firefox easily and use that to connect to us with much more secure cipher choices, so there is a fairly painless path forward for these users. The plan of action here is this: [ ] - Coordinate with the Community team to ensure they're aware of everything here ahead of any user complaints. This probably isn't the kind of situation where pre-announcements on community talk pages and/or mailing lists help much, as the target users aren't likely to be readers there, but it's still better to be prepared with answers. [x] - Prepare a Varnish synthetic page output based on our standard error page templates, which gives a very quick note about connection security and offers a link to the explanatory https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations . [ ] - Code to show this to a random X% of pageviews from affected clients (already implemented for redirect, needs switch to synthetic output above). [ ] - Once the above is ready, we'll set the final timeline in place: a 2 month period over which we'll ramp the percentage up from a small value (say, 5% of affected pageviews) to 100% of affected pageviews, and a further month during which we'll still allow connections from affected clients, but 100% of their pageviews will go to the information page. [ ] - After the 3 month window is complete, remove support for this cipher entirely.

This is one of our two last remaining non-forward-secret ciphers, which we'd like to eliminate as soon as reasonably possible. It's also the subject of the [[ https://sweet32.info/ | SWEET32 ]] birthday attack due to being a 64-bit (block size) cipher, which we've mostly-mitigated in other ways for now (shortened session key lifetimes). The only statistically-significant browser which relies on this cipher to communicate with us is IE8-on-XP, which is long-unsupported (over 2 years now) and horribly insecure, so any motivation we can give users to get off of this browser is a net win for everyone involved. Currently this cipher amounts to ~0.17% of all requests to our sites (and has been slowly declining for some time), and we've been running a very limited campaign for a while now which redirects a very small percentage of those requests (filtered down to just /wiki/ pageviews on the desktop sites, and only 1% odds) to the information at https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations . Because of technical limitations, we can't scale up that redirect much without having a better mechanism in place. IE8-on-XP is too old for CentralNotice JS to function correctly, so CN isn't really an option for campaigning here. Users which cannot move off of the underlying Windows XP operating system can install the latest Firefox easily and use that to connect to us with much more secure cipher choices, so there is a fairly painless path forward for these users. The plan of action here is this: [ ] - Coordinate with the Community team to ensure they're aware of everything here ahead of any user complaints. This probably isn't the kind of situation where pre-announcements on community talk pages and/or mailing lists help much, as the target users aren't likely to be readers there, but it's still better to be prepared with answers. [ ] - Prepare a couple of pages on meta.wikimedia.org based on something like https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations . The first should be our user redirect target, and should be very simple and direct about the 3DES issue in particular, specifies the future cutoff date on which support will be disabledx] - Prepare a Varnish synthetic page output based on our standard error page templates, and provides advice for users to avoid loss of connectivity to us (such as installing Firefox on XP, or upgrading to Win7+,which gives a very quick note about connection security and offers a link to the explanatory https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations etc). The second can be a more-detailed explanation of broader things like the existing wikitech page. [ ] - Code to show this to a random X% of pageviews from affected clients (keeping in mind avoidingalready implemented for redirects for these pages themselves, needs switch to synthetic output above). [ ] - Once the above is ready, we'll set the final timeline in place: a 2 month period over which we'll ramp the percentage up from a small value (say, 5% of affected pageviews) to 100% of affected pageviews, and a further month during which we'll still allow connections from affected clients, but 100% of their pageviews will go to the information page. [ ] - After the 3 month window is complete, remove support for this cipher entirely.