icecast ssl https cloudflare

Configurer Icecast avec un certificat SSL et Cloudflare

Voici comment configurer un serveur Icecast pour utiliser un certificat SSL pour proposer des flux radio servis en HTTPS, le tout derrière Cloudflare.

Depuis que Strict Transport Security (HSTS) a été activé par défaut pour tous les sites hébergés sur le serveur, la page de Thunderstruck Radio ne s’affiche plus correctement car le serveur Icecast est encore servi en simple HTTP, donc sans certificat SSL.

Nous allons donc changer tout cela et sécuriser Icecast avec le certificat SSL de notre domaine, de manière à ce que les flux radio ainsi que le flux JSON soient servis en HTTPS.

Étape 1 : créer un sous-domaine au niveau DNS

Il vaut mieux séparer la radio de votre site principal, c’est beaucoup plus simple à gérer et évite les épineux problèmes de configuration.

J’opte pour ajouter le sous-domaine thunderstruck.skyminds.net avec un enregistrement DNS de type A dans Cloudflare:

thunderstruck.skyminds.net.	1	IN	A	xxx.xxx.xxx.xxxCode language: CSS (css)

On garde le sous-domaine en DNS seulement, nul besoin d’activer le cache (puisque c’est un flux).

Étape 2 : ouvrir le port 8443 dans le pare-feu

J’utilise Cloudflare donc nous avons quelques ports HTTPS ouverts par défaut qui peuvent être utilisés sans blocages :

# Ports HTTPS ouverts par défaut chez Cloudflare, sans support cache :

    443
    2053
    2083
    2087
    2096
    8443Code language: PHP (php)

Nous utilisons ufw donc la commande est très simple pour ouvrir le port 8443 :

ufw allow 8443/tcp comment "Icecast SSL"Code language: JavaScript (javascript)

Le serveur accepte désormais les connexions sur le port 8443 pour Icecast.

Étape 3 : configurer le sous-domaine sous NginX

Nous allons maintenant configurer notre sous-domaine et éditer le bloc serveur de notre domaine sous NginX:

nano /etc/nginx/sites-available/skyminds.conf

Et nous y ajoutons ce bloc:

# Thunderstruck.skyminds.net
server {
    listen       8443 ssl http2;
    listen  [::]:8443 ssl http2;

    server_name thunderstruck.skyminds.net;

    # Let's Encrypt
    ssl_certificate         /etc/nginx/ssl/skyminds.net/fullchain.pem;
    ssl_certificate_key     /etc/nginx/ssl/skyminds.net/privkey.pem;

    location / {
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_pass              http://127.0.0.1:8443;
        proxy_read_timeout      90;
        proxy_redirect          off;
        proxy_buffering         off;
        tcp_nodelay             on;

	    # CSP headers
	    add_header Content-Security-Policy "media-src 'self' https://thunderstruck.skyminds.net:8443";
    }
}Code language: PHP (php)

Testez la configuration et rechargez nginx :

nginx -t

service nginx reload

Étape 4 : unifier le certificat SSL et sa clé privée

Icecast peut fonctionner avec un certificat SSL à partir de la version 2.4.4. Commencez donc par vérifier que cette version est à minima installée sur le serveur:

icecast2 -v

Ensuite, Icecast nécessite un fichier de certificat unique, qui est en fait une compilation du certificat et de sa clé privée.

Nous créons donc un fichier shell qui va contenir notre commande:

nano /home/scripts/icecast-ssl.sh

et dans lequel nous ajoutons notre commande cat :

#!/bin/bash
cat /etc/nginx/ssl/skyminds.net/fullchain.pem /etc/nginx/ssl/skyminds.net/privkey.pem > /etc/icecast2/bundle.pemCode language: JavaScript (javascript)

Vous pouvez exécuter le fichier de manière à générer le fichier bundle.pem:

bash /home/scripts/icecast-ssl.sh

On assigne maintenant les bons droits pour que le certificat soit lisible par icecast2:

chown icecast2:icecast /etc/icecast2/bundle.pem

Étape 5 : automatiser le renouvellement du certificat Icecast

J’utilise acme.sh pour la génération et le renouvellement automatique de tous les certificats du serveur donc il est très utile d’éditer la configuration du certificat pour que le script de génération du certificat pour SSL ait lieu automatiquement, juste après le renouvellement du certificat de notre domaine.

On édite donc la configuration acme.sh du domaine:

nano /root/.acme.sh/skyminds.net_ecc/skyminds.net.conf

Et nous éditons la directive Le_RenewHook avec le chemin de notre nouveau script shell :

Le_RenewHook='bash /home/scripts/icecast-ssl.sh && service icecast2 restart'Code language: JavaScript (javascript)

Sauvegardez les changements.

Lire la suite

WordPress : afficher des média oEmbed avec HTTPS photo

WordPress : forcer le chargement des média oEmbed en HTTPS

Lorsque le site est servi via HTTPS, toutes les ressources – même les ressources oEmbed automatiquement générée par WordPress – qui composent une page doivent également être servies via une connexion chiffrée aussi.

Il se trouve que je mets des vidéos Youtube et consorts de temps en temps : elles ne s’affichaient plus en https, étant servies par défaut en http.

Le changement vers HTTPS est en marche mais tous les services oEmbed n’ont pas encore adopté le chiffrement des connexions.

Servir les vidéos Youtube en HTTPS

Au lieu d’utiliser Youtube.com, nous allons utiliser la version cookie-less de Youtube, à savoir youtube-nocookie.com : cela permet d’éviter les cookies pisteurs de Google et donc offre plus de sécurité et de respect de la vie privée.

J’utilise ce système depuis des années sur SkyMinds donc je me suis dit qu’il était bien temps de le partager dans ces colonnes.

Le code permet donc de remplacer youtube.com par youtube-nocookie.com dans le code généré par l’oEmbed WordPress.

Ce code est à ajouter dans votre utility plugin (ou à défaut le fichier functions.php de votre thème WordPress).

Le premier code remplace toutes les occurences des médias HTTP pour HTTPS :

<?php
/* Force HTTPS rewrite for oEmbeds
* Source : https://wordpress.stackexchange.com/questions/40747/how-do-i-embed-youtube-videos-with-https-instead-of-http-in-the-url
*/
add_filter( 'embed_oembed_html', 'sky_embed_oembed_html' );
function sky_embed_oembed_html( $html ) { 
  return preg_replace( '@src="https?:@', 'src="', $html );
}Code language: HTML, XML (xml)

Le second code modifie tous les appels à youtube.com et les remplace par youtube-nocookie.com, ce qui empêche la création de cookies pisteurs :

<?php
//BEGIN Embed Video Fix - HTTPS and privacy mode
//https://wordpress.org/support/topic/forcing-ssl-return-for-youtube-oembed

add_filter('the_content', 'sky_add_secure_video_options', 10);
function sky_add_secure_video_options($html) {
   if (strpos($html, "<iframe" ) !== false) {
    	$search = array('src="http://www.youtube.com','src="http://youtube.com');
	$replace = array('src="https://www.youtube-nocookie.com','src="https://www.youtube-nocookie.com');
	$html = str_replace($search, $replace, $html);
   	return $html;
   } else {
        return $html;
   }
}Code language: HTML, XML (xml)

Cela a l’air tout bête mais cela permet de faire respecter un peu plus notre droit au refus de se faire pister à tout bout de champs sur le net.

Le petit plus : on charge également moins de cookies, qui ne sont pas des ressources cachables par essence donc on améliore un peu aussi le temps de chargement de la page.

Serveur dédié : ajouter le domaine à la liste HSTS preload photo 1

Serveur dédié : ajouter le domaine à la liste HSTS preload

Maintenant que votre site est servi en HTTPS à l’aide d’un certificat SSL/TLS et sécurisé par DNSSEC et DANE, il est maintenant temps de l’ajouter à la liste HSTS preload.

HSTS (HTTP Strict Transport Security) est un entête de réponse qui demande au navigateur de toujours utiliser SSL/TLS pour communiquer avec votre site.

Qu’importe si l’utilisateur ou le lien qu’il clique spécifie HTTP, HSTS forcera l’usage d’HTTPS.

Toutefois, cela laisse l’utilisateur vulnérable lors de sa toute première connexion à un site. L’HSTS preloading corrige donc cela.

Serveur dédié : ajouter le domaine à la liste HSTS preload photo 1

L’HSTS preloading

Il existe une liste qui permet d’inclure un domaine dans la liste HTTP Strict Transport Security preload de Chrome.

Il s’agit d’une liste de sites qui sont codés en dur dans Chrome comme étant uniquement servis en HTTPS.

Firefox, Safari, IE 11 and Edge ont également des listes HSTS preload qui incluent la liste de Chrome.

Pré-requis

Il y a quelques pré-requis avant de pouvoir être inclus dans la liste HSTS preload. Votre site doit:

  • avoir un certificat valide,
  • rediriger tout le trafic HTTP vers HTTPS, c’est-à-dire n’être servi qu’en HTTPS uniquement,
  • servir tous les sous-domaines en HTTPS, même le sous-domaine www si un enregistrement DNS existe pour ce sous-domaine,
  • servir un entête HSTS pour les requêtes HTTPS avec une date d’expiration supérieure à 18 semaines (10886400 seconds), les tokens includeSubdomains et preload doivent impérativement être spécifiés. Si vous servez une redirection depuis votre site HTTPS, cette redirection doit obligatoirement contenir l’entête HSTS.
  • L’entête HSTS doit être présent dans le VirtualHost HTTP aussi, juste avant la redirection vers le VirtualHost HTTPS.

Lire la suite

Serveur dédié : mettre à jour Apache et configurer le mod_h2 pour HTTP/2 photo

Serveur dédié : mettre à jour Apache pour HTTP/2

C’est sur toutes les lèvres : 2015 aura vu l’arrivée de PHP7 et de la révision du protocole HTTP qui passe à la version 2, en remplacement du mod_spdy de Google.

Tout cela promet pas mal de gains de performance donc il est très tentant de le vérifier par nous-mêmes.

HTTP/2 : une évolution du protocole HTTP

Avec HTTP/1.1, la vie des développeurs n’était pas simple. L’optimisation d’un site revenait à plusieurs techniques qui tournaient toutes autour de l’idée de minimiser le nombre de requêtes HTTP vers un serveur d’origine.

Un navigateur ne peut ouvrir qu’un nombre limité de connexions TCP simultanées vers une origine et le chargement des ces ressources via chacune de ces connexions est un processus en série : la réponse de chaque ressource doit être retournée avant que la réponse de la ressource suivante ne soit envoyée. C’est ce qu’on appelle le head-of-line blocking.

HTTP/2 promet donc des gains de performance d’environ 30%, sans avoir à gérer ni minification ni concaténation dans le processus de création et déploiement des pages.

Plus besoin (normalement!) d’optimiser les connexions TCP ou les requêtes HTTP avec la création de sprites, le chargement des ressources directement dans le corps des pages, la concaténation ou la création de sous-domaines pour charger les ressources en parallèle (domain sharding) pour contourner les limitations d’HTTP 1.1.

Lire la suite

Serveur dédié : retirer Varnish, devenu inutile avec HTTPS photo

Serveur dédié : retirer Varnish, devenu inutile avec HTTPS

J’ai vraiment aimé jouer avec Varnish.

Le problème, c’est qu’en passant l’intégralité du site en HTTPS, il m’est devenu inutile.

Varnish est incompatible avec HTTPS et ne le sera probablement jamais puisque les connexions chiffrées ne doivent, par définition, jamais être mises en cache.

Par conséquent, j’ai décidé de le retirer temporairement du serveur : cela me fera un service de moins à gérer.

Notez que je ne le désinstalle pas, je m’assure juste qu’on ne fait pas appel à lui. Cela me permettra de le remettre en route si jamais j’héberge un jour un site en HTTP simple.

Ce tutoriel part du principe que vous avez suivi les tutoriels précédents et que votre serveur tourne avec Apache et Varnish comme reverse-proxy.

Configuration d’Apache

On doit éditer plusieurs fichiers :

1. le fichier /etc/apache2/ports.conf :

 nano /etc/apache2/ports.conf 

On remet les valeurs par défaut et on écoute sur le port 80 :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

# SkyMinds.Net
# Quand Varnish est actif
# NameVirtualHost *:8080
# Listen 8080

# Apache only
NameVirtualHost *:80
Listen 80


    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to 
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.

   NameVirtualHost *:443
   Listen 443



    Listen 443
Code language: PHP (php)

2. les fichiers de chacun de nos VirtualHosts :

nano /etc/apache2/sites-available/www.skyminds.net
nano /etc/apache2/sites-available/static.skyminds.netCode language: JavaScript (javascript)

On écoutait sur le port 8080, on se remet sur le port 80 :

#<virtualhost *:8080="">
<virtualhost *:80="">
Code language: HTML, XML (xml)

Lire la suite