Governmental https initiatives

Deutschland

https://https.jetzt/

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/BSI/BSI_Act_BSIG.pdf?__blob=publicationFile&v=1

Norway

https://nrkbeta.no/https-norge/

https://www.nrk.no/dokumentar/vil-kreve-sikrere-offentlige-nettsteder-1.12988202

https://fido.nrk.no/874a3eade140c78100d3e7f3c2ba28f5d1b85c08567e4db56d5213aaaadd55a6/Oppdrag%20NSM%20-%20sikker%20tilkobling%20-%20HTTPS.Pdf

https://fido.nrk.no/257200c7f6fd60ad9cf6f31bf860118d099a47cb677be4152af7492595d43fe7/NSM%20-%20sikker%20tilkobling%20HTTPS.pdf

Netherlands

https://pulse.openstate.eu/

United Kingdom

https://govuk.jamiemagee.co.uk/

US

https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-government

https://https.cio.gov

https://18f.gsa.gov/2015/02/09/the-first-gov-domains-hardcoded-into-your-browser-as-all-https/

Do you know any other governmental initivative?

If so, contact@tdelmas.eu

 

Protection des données personnelles : législations

Française

Article 34 de la loi n° 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés :

Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu’elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès.

Des décrets, pris après avis de la Commission nationale de l’informatique et des libertés, peuvent fixer les prescriptions techniques auxquelles doivent se conformer les traitements mentionnés au 2° et au 6° du II de l’article 8.

 

Article 226-17 du code pénal :

Le fait de procéder ou de faire procéder à un traitement de données à caractère personnel sans mettre en oeuvre les mesures prescrites à l’article 34 de la loi n° 78-17 du 6 janvier 1978 précitée est puni de cinq ans d’emprisonnement et de 300 000 euros d’amende.

Européenne

Directive 95/46/CE (jusqu’au du 25 mai 2018)

(Doit être transposé par les états membres pour être applicable)

SECTION VIII – CONFIDENTIALITÉ ET SÉCURITÉ DES TRAITEMENTS
Article 17 – Sécurité des traitements
1. Les États membres prévoient que le responsable du traitement doit mettre en oeuvre les mesures techniques et d’organisation appropriées pour protéger les données à caractère personnel contre la destruction accidentelle ou illicite, la perte accidentelle, l’altération, la diffusion ou l’accès non autorisés, notamment lorsque le traitement comporte des transmissions de données dans un réseau, ainsi que contre toute autre forme de traitement illicite.

Règlement (UE) 2016/679 (à partir du 25 mai 2018)

(D’application directe dans les états membres)

Règlement (UE) 2016/679 :

CHAPITRE II – Principes
Article 5 – Principes relatifs au traitement des données à caractère personnel
1.   Les données à caractère personnel doivent être:
f) traitées de façon à garantir une sécurité appropriée des données à caractère personnel, y compris la protection contre le traitement non autorisé ou illicite et contre la perte, la destruction ou les dégâts d’origine accidentelle, à l’aide de mesures techniques ou organisationnelles appropriées (intégrité et confidentialité);

Privacy shield (en remplacement du Safe harbor)

http://ec.europa.eu/justice/newsroom/data-protection/news/160229_en.htm

Annex 2, page 6, II.4.a:

Organizations creating, maintaining, using or disseminating personal information must take reasonable and appropriate measures to protect it from loss, misuse and unauthorized access, disclosure, alteration and destruction, taking into due account the risks involved in the processing and the nature of the personal data.

Autres législations

http://practicallaw.com – What security requirements are imposed in relation to personal data? All jurisdictions

Reply to « Should multilingual websites use HTTPS by default »

This post is a reply to Should multilingual websites use HTTPS by default

That post is well written and useful, but contains some mistakes that should be corrected.

In summary, my position about that question:

  • Yes they should, and it’s hard to do it:
    • If they handle personal data: fast (In Europe, you have an obligation of protection)
    • If they don’t: slowly

Following citations are from the post, underline and […] are from me.

Google is encouraging webmasters to use HTTPS and has made it as a part of ranking signals. However I recommend eCommerce business owners to wait until this is settled.

eCommerce are business who should migrate faster than others because they manipulate personal data.

Encrypting all pages on your website will only slow them down

Using http2 (or spdy) to encrypt data will not be slower but faster than pages without encryption.

Encrypting all pages on your website […] will not improve security on pages where you are not entering any sensitive information.

Encrypting webpage is useful even if they don’t manipulate sensitive date. Without encryption, malicious actors can:

you cannot use virtual hosting – it’s 1 server, 1 domain due to the way certs work

That’s not true. On your virtual host you can host www.example.com and www.example.co.uk and have one certificate that covert both. (But some content provider may limit your abilities to  set-up certificate)

There are also cost issues such as buying: SSL certificate and dedicated IP address.

https://letsencrypt.org give SSL certificate for free, that are as secure as paid ones. (but dedicated IP are indeed a problem)

Your websites’ visitors use all kinds of browsers and apps on mobiles and smart phones. They are not ready for HTTPS

Yes they are. If you want, you can allow IE6 and really old android 2.3 to connect to your htttps website: https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=216.58.195.238

In the online world, it’s all about testing

100% true!

If sites used HTTPS by default and users were trained to avoid sites that use only the HTTP protocol, phishing would be almost useless

Phishing doesn’t use your domain name, so they don’t care if you use https or not. Phishing website can use https too, and they can look more secure that yours if you don’t use https! Users need to be trained to look for https, yes, but also be sure they are on the correct domain to defeat phishing.

Multilingual website owners should make their move when all applications and browsers are compatible with HTTPS.

That mean today, right?

In conclusion,

yes, the migration to https for multilingual website is expensive (because it require skill and time), complex, and yes, there is a lot of technical debt, and hosting manager aren’t always helpful. But the migration is inevitable, the only question is the timeline.

Don’t make that mistake with new websites and avoid the painful migration: start directly with https.

Plan de migration vers HTTPS/HSTS

1 – Activer https sur l’intégralité des pages du domaine et des sous-domaines

2 – Rediriger tous les visiteurs vers le https

Via une redirection permanante (301)

3 – Forcer le https pour en utilisant HSTS

HSTS permets d’indiquer au navivateur de contacter directement le site en https  même si c’est la version http qui a été demandée. Ses effets par rapport  la simple redirection 301 sont :

  • S’applique à tous le domaine (et pas seulement à l’URI demandé)
  • S’applique pendant un temps déterminé précisément
  • Peut s’appliquer aux sous-domaines si demandé
  • Empêche l’utilisateur de passer outre les messages d’erreurs de sécurité

    1. Activer HSTS avec une durée faible (1 heure par exemple) et vérifier que tout fonctionne sur le domaine

    Strict-Transport-Security « max-age=3600 »

2. Ajouter l’option includeSubdomains et vérifier que l’intégralité des sous domaines fonctionnent (y comprit les domaines réservé a un usage interne utilisant des certificats auto-signés par exemple)

Strict-Transport-Security « max-age=3600; includeSubDomains »

3. Augmenter progressivement la durée d’HSTS à une journée (max-age=86400) puis une semaine (max-age=604800)

4. Si les tests sont concluants, fixer la durée d’HSTS à sa valeur définitive : un an (max-age=31536000)

Strict-Transport-Security « max-age=31536000; includeSubDomains »

5. include dans les pages principales (d’arrivés des visiteurs) des sous-domaines une requête vers le domaine principal (via une image invisible par exemple)

6. Ajouter l’option preload et valider le domain principal sur https://hstspreload.appspot.com/

Strict-Transport-Security « max-age=31536000; includeSubDomains; preload »

Attention : cette dernière étape est irreversible. (Alors que les précédentes peuvent se désactiver au bout de la durée max-age spécifiée)

https://ssllabs.com/ssltest permets de vérifier l’activation de HSTS et l’inclusion dans les listes préchargés des navigateurs.

Les adresses des différentes listes sont disponibles là : https://github.com/ssllabs/research/wiki/Preload-Lists

HTTPS Trust levels

In answer to @selecadm :

As a visitor, can you trust that website ?

  1. Websites publicly known ( google.com , amazon.com , …) : You are sure you visit the right website.
  2. Extended validation (The « green bar »): A Certificate Authority claimed that it verified that the owner of the website is the brand. If you know the brand, it’s very highly probable that you visit the official website.
  3. The brand give you the address of their website (when you was in their shop for example) : you can be sure (almost) you are on their website.
  4. You know the address through word of mouth or the Certificate type is Organization validation : it’s probably the website you are looking for, but still, be careful.
  5. If you don’t know the brand nor the website : be carefull, HTTPS only mean that the owner of the website decide what do you see and who can access the informations you provide.

What about Certificate Transparency, OCSP Stapling and other TLS stuffs ?

They can’t be put it the same level as the classification before : they are orthogonal to it. You can only draw a matrix of trust like that :

A+ A A- B C D F T HTTP
1.
2.
3.
4.
4.
5.

Where the number correspond to the previous enumeration, and the letter the « quality » of the HTTPS connexion (ssllabs.com or tls.imirhil.fr for example)

What about TLS validation ? It was the question in the begining !

Let’s take again the classification of @selecadm :

  1. Extended validation
    1. with SCTs via OCSP stapling or TLS extension
    2. with SCTs embedded as X.509 extension
    3. non-transparent
  2. Organization validation
  3. Domain Validation (Commercial CAs)
  4. Let’s Encrypt
  5. CloudFare Universal SSL
  6. Self-signed
  7. (EC)DH_anon (anonymous Diffie-Hellman)

Let’s rewrite it correctly :

  1. Extended validation
  2. Organization validation (but useless because no-one see it)
  3. Domain Validation (Some Commercial CAs)
  4. Let’s Encrypt
  5. Domain Validation (Most Commercial CAs)
  6. CloudFare Universal SSL (if back-end http or self-signed, else, somewhere upper…)
  7. Self-signed

What, what about (EC)DH_anon? It’s not about validation, but about the connexion.

And about (non-)CTs for EV? Now, EV imply CT, and CT can be used outside EV (Like with Let’s Encrypt and as a punishment for some CA with major failure…)

Why Let’s encrypt in the middle of commercials CA? To be honest I should put if over, because their algorithm to check ownership are public and the ownership must be proven every 3 months (and a certificate is only valid 3 month), so the last ownership check is at least 6 month old, where some CA give certificates valid for more than 3 years. And, as said before, Let’s Encrypt do use CT.

But Let’s Encrypt do not collect contact informations contrary to Commercials CAs ! Yes, some CAs do collect more informations, but they do not verify it.

But with commercials CAs ask for bank informations !  Yes, the CA will possess some informations, but let’s not forget the objective of SSL/TLS certificates : authentify the connection between the visitor and the website (and the Organization behind the website for EV/DV). For DV, the fact that the CA possess more or less informations doesn’t change the quality of the authentication of the connection : when you visits the website, the CA only tells you « The person sending you informations has the same private key than the person who asked me a certificate some time ago, and I (the CA) checked that he owns the domain (or at least that he has some administrations rights on it) ». So for the visitor, it’s help in nothing to know that the CA possess nothing or a lots of informations about the owner of the private key, because the visitor can’t know how much information the CA possess nor how much checked information. But I agree, the fact that the CA possess a little information can help in two case :

  1. The certificate was obtained by someone who is not the owner of the website
  2. The certificate was obtained by someone who is the owner of the website and something goes wrong after the visitor visits the website and the visitor did kept a copy of the certificate and the registrar of the domain did not have enough informations about the owner and it was not possible to obtain more informations from the owner of the server

About the first case, I means that someone succeeded to trick the CA. I’ve the feeling that a Let’s Encrypt certificate is a better guaranty in that case for two reason : the 3 month period and the CT : If you know that last year the website has a problem with it’s DNS, then with a normal DV, you can’t be sure. With a Let’s Encrypt one, you can be. And if you, as a website owner, someone did hijack your DNS, then after the attack you can check CT logs…

To conclude

There is two thing to take into count :

  1. If you want to visit the website of the brand, how can you be sure of the domain name ?
    • You get it directly from the brand
    • Someone else give it to you
    • Someone assert it for you (Extended validation, or Organization validation)
  2. When you know the domain name, how sure are you about the security of the connexion ?

In other words :

If you know the website, a certificate issued by Let’s Encrypt with a robust configuration (CT, HSTS preload, HPKP, OCSP Stapling, DNSSEC,DANE/TLSA, 4096+ RSA keys and 256+ EC keys, Forward Secrecy cyphers, …) is really more sure than a website with Extended Validation you don’t know from a company you don’t know with an horrible configuration.

Proposer le choix entre http et https ne permet pas de protéger les données personnelles

De nombreux sites manipulant des données personnelles ne forcent pas l’utilisation du https, préférant laisser le choix entre http et https.

Cela signifie que les données personnelles des visiteurs arrivant sur la version http ne sont pas protégés, malgré l’obligation légale :

Loi n° 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés – Article 34 :

Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu’elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès.

De plus, les visiteurs qui souhaiteraient utiliser la version https voient leurs données personnelles moins protégés, car une personne malveillante pourrait utiliser une attaque de type sslstrip pour déchiffrer la connexion.

Pour protéger correctement les données personnelles, la seule solution actuellement efficace est l’utilisation du protocole https accompagné de :

  • Une redirection permanente des pages http vers les pages https pour éviter les attaques passives
  • L’utilisation du HSTS afin de protéger les visiteurs contre les attaques actives de type sslstrip

 

 

Les Cast Codeurs 125 et 127 : Le https

Retrouvez les épisodes 125 et 127 des Cast Codeurs sur le https :

https://lescastcodeurs.com/2015/05/25/lcc-125-interview-sur-https-avec-tom-delmas-partie-1/

https://lescastcodeurs.com/2015/06/24/lcc-127-interview-sur-https-avec-tom-delmas-partie-2/

Liens directs ( sous licence CC BY-SA 4.0 ) :

Partie 1 : LesCastCodeurs-Episode-125.mp3

Partie 2 : LesCastCodeurs-Episode-127.mp3

 

Recommandations de sécurité pour les nouveaux projets informatiques

Lorsque l’on débute un nouveau projet, il peut être tentant de ne pas se préoccuper des questions de sécurité, soit parce que le but est de développer une simple démonstration, soit parce que c’est uniquement un projet statique.

Mais tous les projets évoluent, et appliquer certains principes de sécurité à un projet existant est souvent beaucoup plus coûteux que s’ils avaient étés pris en compte depuis le début.

Voici donc une liste de bonnes pratiques à appliquer selon moi à tout nouveau projet.

Continuer la lecture de Recommandations de sécurité pour les nouveaux projets informatiques

Protection contre le man-in-the-middle

Actuellement la meilleure protection est l’utilisation du https

  • Cela suffit ?

Non, pour réellement être protégé, il faut activer HSTS

Vous pouvez utiliser HPKP  (mais attention, ne l’utiliser que si vous êtes absolument sur de vous)

  • Et maintenant, c’est complètement sécurisé ?

Oui, autant que possible. La prochaine étape étant DNSSEC et DANE, quand les navigateurs l’auront implémenté