Security / Sécurité

Entries feed - Comments feed

Last entries

Sun 01 Jan 2017

  • David Mentré

A new PGP key

I started this new 2017 year by creating a new PGP key (with fingerprint 3EA1 53E8 9472 8519 CDD1 1B9D 45DD 2720 B15E CA67). My old key was made twelve years ago and was too weak. The new one should be stronger (RSA 4096 bits). You can find my new public key on key servers or on my contact page.

To make it, I followed this "Email Self-Defense" tutorial from FSF (which was a bit out-dated on the version of Enigmail I used). Thanks Gilles! (nearly one year ago: sic!)

Thu 28 Aug 2014

  • David Mentré
  • 1

DNSSEC Validator supporte DANE !

Après une mise à jour récente de Firefox, j'ai découvert avec plaisir que le plug-in DNSEC Validator (qui s'appelle maintenant DNSSEC/TLSA Validator) supporte le protocole DANE. Avec ce plug-in, vous pouvez voir que mon domaine www.bentobako.org est correctement vérifié par DNSSEC (et pas par DANE). Ce plug-in est disponible pour les principaux navigateurs du marchés (Internet Explorer, Mozilla Firefox, Google Chrome, Opera et Apple Safari)

DANE (DNS-based Authentication of Named Entities), reposant sur DNSSEC, permet de valider un certificat SSL/TLS d'un serveur web (pour HTTPS), email ou autre sans besoin d'utiliser des « autorités » de certification qui font payer très cher et à la confiance douteuse. En d'autres termes, on n'utilise pas de PKI (Public Key Infrastructure, Infrastructure de clés publiques) mais directement des signatures des certificats dans les champs du DNS, champs eux-mêmes vérifiés pas DNSSEC (on peut aussi combiner PKI et DANE si on veut).

Chacun est maître de son infrastructure et permet à ses « clients » de vérifier qu'ils accèdent bien au bon serveur web, en toute sécurité. C'est à mon avis une petite révolution dans les moyens permettant de chiffrer et authentifier les communications sur Internet : la sécurité gérée de manière décentralisée et à coût zéro. Bien évidemment, le protocole n'est pas encore largement déployé, d'où mon intérêt pour le plug-in DNSSEC/TLSA Validator.

Pour plus de détails sur DANE, lire les excellents comptes-rendus des RFC 6394 et RFC 6698 de Stéphane Brotzmeyer.

Il ne me reste « plus » qu'à configurer tout ça sur mon serveur web. Quelqu'un connaît-il une documentation simple pour faire sa propre autorité de certification avec en plus la configuration de DANE ?

Wed 20 Aug 2014

  • David Mentré

HTTPS pris en compte pour la qualité d'un site web par Google

Le 6 août dernier, Google a annoncé qu'il favoriserait (faiblement) un site web en HTTPS dans son algorithme de recherche, par rapport à un site web standard sans HTTPS. Le but clairement affiché est d'inciter les site web à passer en HTTPS.

Deux remarques :

  • Je pense que c'est une bonne chose, tous les sites web devraient être en HTTPS. Cela gênerai (sans empêcher) les espionnages par la NSA et autres agences de renseignement ;
  • Un seul gros acteur du web peut influencer le comportement de nombreux autres sites. C'est glaçant (sans être d'une grande nouveauté).

Quelques remarques pertinentes aussi dans les commentaires du billet.

Au passage ce blog est aussi disponible en HTTPS, malheureusement avec un certificat auto-signé et une configuration faite avec les pieds.

Sun 01 Dec 2013

  • David Mentré

The day I left GMail

On Saturday 2013-11-30 at 16:06 I left GMail. Now all (or at least most of them) of my emails are sent to my own email server based on Postfix, Dovecot and a Debian server.

It is increased burden to have to manage such a server. It was much easier for me to let Google administrators handle all the issues. But now at least I know where my emails are stored (in France) and how they are handled. I will less fear to see my Google GMail emails read by American spy agencies through PRISM program. Or at least, it will be a little more difficult for those agencies to access them. Hopefully, I won't have too many administration issues with this server.

Wed 13 Nov 2013

  • David Mentré
  • 1

Mozilla published a guide to help configure TLS on web servers

In a blog post called "Navigating the TLS landscape", Mozilla announced its Security/Server Side TLS guide.

The main objective of this guide is to help SysAdmin configure their web server in order to improve security for web server clients. The guide gives the preferred configuration as well as justification for choices made, which is a very good thing. There is a strong emphasis on forward secrecy. Configuration parameters for several web servers are provided (Nginx, Apache, Haproxy, Stud, ...). It also provide some tips to check the configuration.

Next step: apply it on my own server!

Thu 05 Feb 2009

  • David Mentré

Google's Browser Security Handbook

Some people at Google have made an interesting Browser Security Handbook available under a free license (CC-3.0-BY). A quite interesting read that shows the brittle security features used in modern web browsers. Certain features like content handling mechanisms are really frightening!

In short, it is quite difficult to make secure web sites accepting and displaying content from external users. The main issue comes from the legacy of old HTML and related technologies. Even if modern versions of HTML, HTTP, ... have attempted to improve the situation, it failed in a number of ways (for example for HTTP 1.1 by not specifying behaviour when talking to 0.9/1.0 HTTP proxies). Of course, certain initial choices like using a textual encoding are a horrible legacy that we are going to carry until another technology takes over the web. If only the binary encoding of extprot had existed in 1992!

One could also notice that the rapid adoption of Web technologies is directly linked to its fragility: ability to constantly add new features also means lack of long term thinking to harmonize those features. Are the tags of Open Street Map going to follow the same mess?

Mon 02 Feb 2009

  • David Mentré

A visual way to represent and check fingerprints

One way to avoid the mess around Certification Authorities (who do you trust to check that a certificate is indeed correct for a given website?) would be to let the end user systematically check the fingerprint of the certificate himself. This is at least the model used by PGP/GPG when you verify the fingerprint of a public key before signing it with your own key. One could imagine a simple way so that anybody can easily check such a fingerprint.

Of course, the most obvious (and currently only) way is to check letter by letter the fingerprint. But if the fingerprint is a bit long, it becomes quickly boring and error-prone.

Another approach would be to show the fingerprint in a representation which is visually explicit and strongly tied to the value of the fingerprint. In other words, represent the fingerprint as a picture so that it is easy to compare two fingerprints.

For displayed characters, one could play on:

  • their sizes;
  • their colours;
  • their shapes.

For example, suppose we want to represent the fingerprint D3:10:0F:7A:F6:C5:94:0B:15:D5:65:8B:78:6D:0A:7C:EE:45:EB:6B.

We could:

  • Group each octet in a group of three and associate to them a web colour. For example, D3:10:0F is associated to the web colour #D3100F;
  • Take each letter and represent them with a size proportional to the value of the letter: 0 is 100%, 1 is 110%, ..., F is 250%.

For the above fingerprint, we would have following result (the fingerprint is patted with zeros to have a multiple of three octets):

D 3 1 1 0 F
7 A F 6 C 5
9 4 0 B 1 5
D 5 6 5 8 B
7 8 6 D 0 A
7 C E E 4 5
E B 6 B 0 0

I seems to me that with such a visual representation, it is easier to check that two fingerprints are identical. This visual clue could be displayed next to an HTTPS URL, for example in a pop-up. The user would have to compare this visual fingerprint with the original one given to him, for example on a business card or in an email.

One left point is how secure is such a visual representation? In other words, is it possible to make too fingerprints that are visually similar but have a different value?

The lower bits of a group of three octets might be the easier to change. For example, the colour of D3:10:0E is very close to D3:10:0F, the shape of E is close to F and the size is nearly identical. One approach to solve that issue would be, for one dimension of the visual representation, e.g. the size of characters, to inverse the 4 bits. For example, F would stay F but E would become 7, thus the size of the last character would not be 240% but 170%. Graphically, we would have (notice that the colours appear visually the same even if their values are different):

D 3 1 1 0 F
D 3 1 1 0 E

The result is not entirely convincing. A more elaborate scheme might be necessary, so that colours and shapes change a lot if a single character is modified in the fingerprint. That's said, as the visual representation is directly tied to the value of the fingerprint, which is itself computed with a cryptographic hash or similarly suited method, it might be quite difficult to produce a wrong certificate with a visual fingerprint close to representation of the correct certificate.

Another issue is that some people are visually impaired, for example might not distinguish certain colours. But in that case, the textual value of the fingerprint might be more useful for such people.

I have not made a detailed analysis of the proposed scheme and more attacks might be possible. This post is just made to give the general idea. ;-) What do you think of it?

PS: As usual, it appears that other people had the same idea before me. :-) Like using fractal images to represent a fingerprint or the visual ASCII representation of an SSH fingerprint that is used in recent SSH 5.1.