Change Details

Given recent progress on production puppetization of LetsEncrypt.org (LE), and LE itself improving in general in recent months (moved from beta to production status, has proved itself a bit, ratelimits are reasonable, etc), I think we can now really contemplate the idea of doing a secure redirector service to cover large counts of junk domains. We talked this out a bit on IRC, and AFAICS there's now no real technical blockers to making this happen; we'll probably be able to handle hundreds of one-off domainnames for this through LE mechanisms. One noteable tradeoff is it will have to be an SNI-dependent service for the bulk of the names. That means many of these secure redirects will not work for certain older browsers (notably IE8/XP, and some old feature phones like Symbian). Given the alternative is to dead-park (no browser functionality or at least no true redirect) the bulk of these domains, the SNI limitation is probably acceptable, and we can certainly arrange the certificate sets such that the highest-value ones are on the default SNI server for greater compatibility than the rest. What it basically boils down to now is: [x] Decide on a reasonable SAN list length limit per cert: 100 [ ] Prioritize which "junk" domains should be in the primary (works for non-SNI) SAN list [ ] Puppetize a service role built around modules/nginx + modules/letsencrypt that can redirect a configured large set of domainnames securely. [ ] Assign a new public IP for this in eqiad + codfw LVS ranges. [ ] Deploy this service in eqiad + codfw (possibly on virtual hosts as the load should be fairly light). Probably manual gdnsd inter-DC failover at least initially until we sort out x-dc LE-cert issues.

Given recent progress on production puppetization of LetsEncrypt.org (LE), and LE itself improving in general in recent months (moved from beta to production status, has proved itself a bit, ratelimits are reasonable, etc), I think we can now really contemplate the idea of doing a secure redirector service to cover large counts of junk domains. We talked this out a bit on IRC, and AFAICS there's now no real technical blockers to making this happen; we'll probably be able to handle hundreds of one-off domainnames for this through LE mechanisms. One noteable tradeoff is it will have to be an SNI-dependent service for the bulk of the names. That means many of these secure redirects will not work for certain older browsers (notably IE[78]-on-XP, Android 2.x, and some very old feature phones like Symbian and Blackberry). Given the alternative is to dead-park (no browser functionality or at least no true redirect) the bulk of these domains, the SNI limitation is probably acceptable, and we can certainly arrange the certificate sets such that the highest-value ones are on the default SNI server for greater compatibility than the rest. What it basically boils down to now is: [x] Decide on a reasonable SAN list length limit per cert: 100 [ ] Prioritize which "junk" domains should be in the primary (works for non-SNI) SAN list [ ] Puppetize a service role built around modules/nginx + modules/letsencrypt that can redirect a configured large set of domainnames securely. [ ] Assign a new public IP for this in eqiad + codfw LVS ranges. [ ] Deploy this service in eqiad + codfw (possibly on virtual hosts as the load should be fairly light). Probably manual gdnsd inter-DC failover at least initially until we sort out x-dc LE-cert issues.

Given recent progress on production puppetization of LetsEncrypt.org (LE), and LE itself improving in general in recent months (moved from beta to production status, has proved itself a bit, ratelimits are reasonable, etc), I think we can now really contemplate the idea of doing a secure redirector service to cover large counts of junk domains. We talked this out a bit on IRC, and AFAICS there's now no real technical blockers to making this happen; we'll probably be able to handle hundreds of one-off domainnames for this through LE mechanisms. One noteable tradeoff is it will have to be an SNI-dependent service for the bulk of the names. That means many of these secure redirects will not work for certain older browsers (notably IE8/XPIE[78]-on-XP, Android 2.x, and some very old feature phones like Symbian and Blackberry). Given the alternative is to dead-park (no browser functionality or at least no true redirect) the bulk of these domains, the SNI limitation is probably acceptable, and we can certainly arrange the certificate sets such that the highest-value ones are on the default SNI server for greater compatibility than the rest. What it basically boils down to now is: [x] Decide on a reasonable SAN list length limit per cert: 100 [ ] Prioritize which "junk" domains should be in the primary (works for non-SNI) SAN list [ ] Puppetize a service role built around modules/nginx + modules/letsencrypt that can redirect a configured large set of domainnames securely. [ ] Assign a new public IP for this in eqiad + codfw LVS ranges. [ ] Deploy this service in eqiad + codfw (possibly on virtual hosts as the load should be fairly light). Probably manual gdnsd inter-DC failover at least initially until we sort out x-dc LE-cert issues.