Feature #8192

Have HTTPS on all the subdomains of tails.boum.org

Added by intrigeri 2014-10-31 18:28:41 . Updated 2016-11-03 09:56:41 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Tails_2.7
Start date:
2014-10-31
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:
270

Description

To be on Firefox’s HSTS preload list, one has to be on Chrome’s list. To be on Chrome’s HSTS preload list, one has to use the includeSubdomains option in the HSTS header. So, in order to have tails.b.o on these lists, we need valid certificates for all our subdomains of tails.b.o, otherwise various pieces of our infrastructure (e.g. Jenkins) will be unreachable (major browsers don’t let you validate a self-signed certificate by hand, if HSTS is enabled for this domain).

To do so, we can either:

a. Get a commercial wildcard certificate for *.tails.boum.org.
b. Get Let’s Encrypt certificates for each one of our subdomains.

Subtasks

Related issues

Related to Tails - Feature #8143: Use apt-transport-https to protect against security issues in APT? Rejected 2014-10-16
Blocks Tails - Feature #9102: Get tails.boum.org on the Chrome HSTS preload list Resolved 2015-03-24

History

#1 Updated by sajolida 2015-03-24 14:57:41

  • blocks Feature #9102: Get tails.boum.org on the Chrome HSTS preload list added

#2 Updated by intrigeri 2015-11-05 08:36:18

If we want to go with Let’s Encrypt, this may be useful: http://blog.mister-muffin.de/2015/11/04/let's-encrypt-with-pound-on-debian

#3 Updated by sajolida 2015-11-30 09:06:33

  • Assignee set to jvoisin

Just to make sure that I understood correctly, we need a wildcard for “*.tails.boum.org” which can exclude tails.boum.org, right? Because boum.org currently has a wildcard for “*.boum.org” which includes tails.boum.org but we don’t want to replace this.

I also understand that we can look for the cheapest option, and not necessarily Gandi, right? For the record, Gandi is 120.00 € excl. VAT/year (https://www.gandi.net/ssl).

Julien: are you knowledgeable or interested in investigating the cheapest option? Otherwise I’ll ask my favorite cryptographer…

#4 Updated by sajolida 2015-11-30 09:09:53

  • QA Check set to Info Needed

#5 Updated by intrigeri 2015-12-01 03:24:02

> Just to make sure that I understood correctly, we need a wildcard for “*.tails.boum.org” which can exclude tails.boum.org, right?

This, or a certificate for each $something.tails.boum.org that serves stuff over HTTPS.

> I also understand that we can look for the cheapest option, and not necessarily Gandi, right?

I think so.

Personally I was merely waiting for Let’s Encrypt to be out of beta, and for their toolkit to have matured a bit (e.g. python-letsencrypt is only in Debian experimental right now, I expect it’ll be in stable backports at some point). My main reason for waiting was that having automatic certificate updates is appealing, as opposed to adding to the sysadmin team’s plate yet another boring repetitive task (which would be the case if we bought commercial certificates).

#6 Updated by sajolida 2015-12-01 06:09:13

  • Subject changed from Get a certificate for *.tails.boum.org from the CA cartel to Have HTTPS on all our subdomains of tails.boum.org
  • Description updated
  • Assignee changed from jvoisin to sajolida
  • Target version set to 2016
  • Type of work changed from Communicate to Wait

I thought about Let’s Encrypt before writing my previous note but as they don’t issue wildcard certificats, I was not sure it would work (seeing the title of the ticket). So I’m updating the ticket ticket to:

  • Mention Let’s Encrypt explicitely.
  • Marking it as Wait as they are still in beta.
  • Marking it for 2016 as according to our roadmap.
  • Assigning it to me for the time being as I’m subscribed to the Let’s Encrypt blog and am following this already. I’ll ping you once they’re out of beta.

#7 Updated by jvoisin 2015-12-01 07:20:56

Else, it’s $40 per year ;)

#8 Updated by intrigeri 2015-12-05 12:31:25

intrigeri wrote:
> If we want to go with Let’s Encrypt, this may be useful: http://blog.mister-muffin.de/2015/11/04/let's-encrypt-with-pound-on-debian

This one too: http://blog.steve.org.uk/i_jumped_on_the_ssl_bandwagon.html

#9 Updated by intrigeri 2015-12-19 01:17:24

https://github.com/kuba/simp_le is reportedly better suited to automation than the default client.

#10 Updated by sajolida 2016-06-20 08:24:22

  • Assignee changed from sajolida to intrigeri

Let’s Encrypt is out of beta and very popular. The recommended client, which works fine for automation, is in Debian backports: https://tracker.debian.org/pkg/python-certbot. So we can do that.

Now, I think that volenta told me that having HTTPS on all the subdomains is not really a prerequisite to be in HSTS preload list.

So deassigning this from me. As next step, maybe intrigeri can confirm the relationship between this ticket and Feature #8191 and decide whether tails-sysadmin wants to have Let’s Encrypt on their todo list anyway and for when.

#11 Updated by sajolida 2016-06-20 08:24:32

  • Type of work changed from Wait to Sysadmin

#12 Updated by intrigeri 2016-07-13 10:10:50

  • QA Check deleted (Info Needed)

Yes, I’d like to tackle this in 2016 (because it should be easy enough, and I want to do it; and if we sysadmins don’t do this, then the team you assembled for Feature #8191 can’t do its job in 2016).

bertagaz, do you agree?

> confirm the relationship between this ticket and Feature #8191

Given we can relatively easily get HTTPS everywhere, I won’t spend any time researching a temporary workaround myself. So, until I see a clear report of how one can cheat the system and do differently than what Google documents, I’ll stick to following the doc. But if volenta or someone else feels differently and wants to speed Feature #8191 up thanks to workarounds, I certainly will welcome their work :)

#13 Updated by bertagaz 2016-07-14 02:44:19

intrigeri wrote:
> Yes, I’d like to tackle this in 2016 (because it should be easy enough, and I want to do it; and if we sysadmins don’t do this, then the team you assembled for Feature #8191 can’t do its job in 2016).
>
> bertagaz, do you agree?

Yes. There are puppet modules out there already, we just need to spend some time auditing them.

#14 Updated by intrigeri 2016-07-15 10:55:07

bertagaz wrote:
> There are puppet modules out there already, we just need to spend some time auditing them.

I did a survey today, and it seems that https://forge.puppet.com/danzilio/letsencrypt/readme is the closest to our needs. I’ll test it locally.

#15 Updated by intrigeri 2016-08-27 10:06:32

  • Target version changed from 2016 to 2018

#16 Updated by intrigeri 2016-08-27 10:08:25

  • Status changed from Confirmed to In Progress
  • Target version changed from 2018 to Tails_2.9.1
  • % Done changed from 0 to 10

#17 Updated by intrigeri 2016-09-23 12:30:10

I have something that works for my personal website, using the aforementioned Puppet module.

Now, our setup is a bit more complex: most of our vhosts are served by a reverse proxy, that terminates the TLS connection, so we need to run certbot on the reverse proxy, and to have each of our vhosts 1. listen also on port 80; 2. include a few location rules to avoid proxying requests that need to point to local files so that the ACME protocol can work with the webroot authentication (e.g. https://community.letsencrypt.org/t/how-to-nginx-configuration-to-enable-acme-challenge-support-on-all-http-virtual-hosts/5622); 3. point their ssl_certificate* statements to the per-domain location under /etc/letsencrypt/live.

But a nicer way would be to redirect all requests to HTTPS, except the ones needed by the ACME protocol; and then we can centralize the Let’s Encrypt -specific config in the default vhost, that would be the only one that needs to listen on port 80: https://gist.github.com/renchap/c093702f06df69ba5cac#file-readme-md using server_name *. And then vhosts would only have to enable SSL, listen on port 443, stop listening on port 80, and point their ssl_certificate* statements to per-domain locations under /etc/letsencrypt/live; no Let’s Encrypt -specific configuration would need to be added to our vhosts’ config. The only downside I can see with this approach is that it requires all clients to support HTTPS: e.g. we would need to install apt-transport-https in Tails (and use HTTPS APT sources while we’re at it, to avoid useless redirections)… but this would likely break our apt-cacher-ng usage; thankfully we can make an exception, and have the {*.snapshots.,}deb.tails.boum.org vhosts keep listening on port 80, and not use Let’s Encrypt for them.

#18 Updated by intrigeri 2016-10-14 14:48:14

  • % Done changed from 10 to 20

Done for nightly.t.b.o (redirecting all requests to HTTPS except the ACME protocol’s ones).

#19 Updated by intrigeri 2016-10-14 14:55:15

Done for jenkins.t.b.o.

#20 Updated by intrigeri 2016-10-14 15:00:33

Done for iso-history.t.b.o.

#22 Updated by intrigeri 2016-10-14 15:24:17

  • % Done changed from 20 to 30

Left to do: deb.tails.boum.org, tagged.snapshots.deb.tails.boum.org and time-based.snapshots.deb.tails.boum.org. Note that we need to keep supporting HTTP as well for those, otherwise it would break acng caching e.g. for our build systems.

#23 Updated by intrigeri 2016-10-14 19:15:46

  • Assignee changed from intrigeri to bertagaz
  • Target version changed from Tails_2.9.1 to Tails_2.7
  • % Done changed from 30 to 50
  • QA Check set to Ready for QA
  • Deliverable for set to 270

I think I’ve covered everything, so adding to SponsorS_M6 so that we report about it. All our vhosts except those we use with apt-cacher-ng now redirect non-ACME requests to HTTPS. Please review!

#24 Updated by intrigeri 2016-10-15 15:15:51

  • related to Feature #8143: Use apt-transport-https to protect against security issues in APT? added

#25 Updated by bertagaz 2016-10-18 12:08:35

  • Assignee changed from bertagaz to intrigeri
  • QA Check changed from Ready for QA to Dev Needed

intrigeri wrote:
> I think I’ve covered everything, so adding to SponsorS_M6 so that we report about it. All our vhosts except those we use with apt-cacher-ng now redirect non-ACME requests to HTTPS. Please review!

Awesome ! I very much like it. Code wise it’s nice, I don’t even think it needs documentation, it’s quite clear by itself. Two remarks though:

  • Some of our Git repo may need update (I’m thinking about our internal one mainly, which now contains old fingerprints)
  • We receive a lot of not so useful emails on the sysadmins mailing list from certbot. Its crontab may need some adjustement to notify us only on failures maybe?

#26 Updated by intrigeri 2016-10-18 18:16:59

  • Assignee changed from intrigeri to bertagaz
  • QA Check changed from Dev Needed to Info Needed

> * Some of our Git repo may need update (I’m thinking about our
> internal one mainly, which now contains old fingerprints)

I thought I had fixed that. Which ones are still wrong?

> * We receive a lot of not so useful emails on the sysadmins mailing list from certbot. Its crontab may need some adjustement to notify us only on failures maybe?

Yes, I’ll fix that.

#27 Updated by bertagaz 2016-10-19 11:17:45

  • Assignee changed from bertagaz to intrigeri
  • QA Check changed from Info Needed to Dev Needed

intrigeri wrote:
> > * Some of our Git repo may need update (I’m thinking about our
> > internal one mainly, which now contains old fingerprints)
>
> I thought I had fixed that. Which ones are still wrong?

Maybe you didn’t push your changes? In the internal repo, the systems/{ecours,lizard} files still contain the old snakeoil certificates fingerprint.

#28 Updated by intrigeri 2016-10-19 12:29:20

>> I thought I had fixed that. Which ones are still wrong?

> Maybe you didn’t push your changes? In the internal repo, the systems/{ecours,lizard} files still contain the old snakeoil certificates fingerprint.

I had pushed them, but apparently sajolida rewrote history by mistake. Pushing again.

Now I’ll look into the other problem you mentioned (hopefully next week or the week after).

#29 Updated by intrigeri 2016-10-26 16:19:26

  • % Done changed from 50 to 60

commit 78737d7 in puppet-tails.git should make the certbot cronjob quiet unless there are errors. Let’s see how it goes.

#30 Updated by intrigeri 2016-10-27 09:31:45

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 60 to 100
  • QA Check changed from Dev Needed to Pass

Some of the cronjobs have run and we did not get email.

#31 Updated by intrigeri 2016-11-03 09:56:41

  • Subject changed from Have HTTPS on all our subdomains of tails.boum.org to Have HTTPS on all the subdomains of tails.boum.org