Project

General

Profile

Bug #12836

Feature #9796: HTTPS mirrors

Adjust our Puppet code to only support HTTPS mirrors

Added by u over 1 year ago. Updated 13 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
06/21/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

History

#1 Updated by intrigeri over 1 year ago

  • Target version set to 2017

(Like the parent ticket.)

#2 Updated by BitingBird about 1 year ago

  • Target version changed from 2017 to 2018

#3 Updated by intrigeri about 1 month ago

Hey espiv, since you wrote the tails::mirror class (#7125), maybe you would be interested in taking care of this evolution?

I think what needs to change is:

  • The $server_name class param probably needs to become required.
  • The vhost templates (templates/mirror/*/*.erb) need to be updated for HTTPS-only.
  • The path to the X.509 cert & key must be added as class params.

And somehow we need to require a X.509 cert and key. The good news is that all our mirrors now serve our stuff over HTTPS so this requirement is already satisfied by any active mirror. I wonder if it's a good idea to make the certbot paths (/etc/letsencrypt/live/<%= @public_hostname %>/...) be the default value for the new parameters. I guess it's easy to check how many of our mirrors use Let's Encrypt certs, and if that's 75% or more, go for it?

Initially I thought "oh, let's set up Let's Encrypt in the class" but then I figured that most of our mirror operators who could be interested in this class probably use their web server for other stuff too, probably have a Let's Encrypt client set up already, and I'd rather avoid fiddling with their config. But it would be nice to at least give a hint in the class doc, such as a pointer to the voxpopuli module, for new mirror operators :)

What do you think?

#4 Updated by espiv about 1 month ago

Hello there,

we'll look into it and get back asap.

#5 Updated by intrigeri about 1 month ago

  • Assignee changed from intrigeri to espiv

we'll look into it and get back asap.

Amazing, thanks :)

#6 Updated by espiv 15 days ago

So,

it seems the majority of current mirrors do use Let's Encrypt:

user@mimi:~$ for i in $(curl -s https://tails.boum.org/mirrors.json | jq -r ".mirrors[].url_prefix" | awk -F 'https://' '{print $2}' | awk -F '/' '{print $1}') ; do echo "mirror: $i" ; echo | openssl s_client -connect ${i}:443 2>/dev/null |openssl x509 -noout -text | grep "Issuer:" ; echo; done > /tmp/tails_mirrors_certificate_authorities
user@mimi:~$ grep "mirror" /tmp/tails_mirrors_certificate_authorities | wc -l
44
user@mimi:~$ grep "Let's Encrypt" /tmp/tails_mirrors_certificate_authorities | wc -l
31

I think it should be simple enough to tweak the class so as:

- if administrator has already deployed TLS cert&key, pass the file paths as parameters
- if no TLS cert&key is specified, class will go ahead to use the existing letsencrypt module

We'll work on such a patch.
Be back soon.

#7 Updated by intrigeri 13 days ago

I think it should be simple enough to tweak the class so as:

- if administrator has already deployed TLS cert&key, pass the file paths as parameters
- if no TLS cert&key is specified, class will go ahead to use the existing letsencrypt module

Makes sense to me!

Also available in: Atom PDF