Yves Rutschle's HomePage

sslh v2.3.0 release

Wed, 10 Sep 2025 00:00:00 +0200

I realised I haven’t advertised new releases of sslh on here for a very, very long time. sslh-v2.3.0 has just been released, with many new things, in particular support for Proxy-protocol and the ability to limit the number of connections.

sslh v2.0.0 release

Thu, 31 Aug 2023 00:00:00 +0200

After about a year as release candidate and one vulnerability discovered, here is sslh-v2.0.

sslh at PTS2022

Wed, 06 Jul 2022 00:00:00 +0200

I went to Pass the Salt, and presented sslh.

Here’s the talk. It was nice meeting users. In fact, it was nice realising there are real people using it :-)

Dataflow Tabular Charts at PTS2022

Tue, 05 Jul 2022 00:00:00 +0200

I went to Pass the Salt, and presented Dataflow Tabular Charts.

The talk was rather well received. I am looking forward to seeing those diagrams in third party documentations!

L'écho des temps passés

Wed, 13 Oct 2021 00:00:00 +0200

We published a new Web site for Eric’s new trio. It’s all shiny and also uses Jekyll and Markdown pages.

sslh v1.22

Tue, 17 Aug 2021 00:00:00 +0200

sslh v1.22 is now available. It supports UDP.

Think twice before implementing encryption

Thu, 08 Jul 2021 00:00:00 +0200

As we’ve seen before, encryption is a protection means rather than a security objective. Strong of that knowledge, we have clearly defined who should have access to our data, and who should not. Is encryption a good solution, then? Security attributes are often summed in three, sometimes four, basic properties that we may need to implement on our assets: Confidentiality, the loss of which, is disclosure, Integrity, the loss of which is corruption, Availability, the loss of which is denial of service. The fourth property is traceability, which is of no interest to us in this paper.

It is interesting that when talking about computer security, many people will think about confidentiality first. “What happens if my files get stolen?” “Google has all my e-mail!” Disclosure may or may not be bad. Typically, disclosure of technical secrets or business information can result in the loss of a competitive advantage. Disclosure of personal data can result in breach of regulations under the GDPR, and various side effects such as personal embarrassment, as in the case of France’s former minister Benjamin Griveaux, whose political career came to a stop after the leak of a sex tape. It can also have catastrophic effects in terms of branding and litigation from those whose data leaked, as in the case of the Ashley Madison hack. And most of the time, it has very little effect besides temporary bad publicity, as in the Facebook Cambridge Analytica affair, which seems to have produced little more than a Netflix documentary on the topic.

But confidentiality is really only one part of the equation. Losing integrity means your systems may start working against you. When Avast failed to protect CCleaner’s integrity, all of the application’s users became targets for the malware embedded in the corrupt file.

Losing integrity often means your systems also lose their availability: they become unable to perform their function: this happened to car manufacturers, aircraft part manufacturers, and probably others as well, resulting in weeks of downtime and sometimes disruption of the supply chain upwards and downwards. It turns out that availability is often the most important property of systems.

What few people seem to realise is that confidentiality is really the opposite of availability. The more confidential a file is, the less available it is, almost by definition. Open source projects that publish their source code to hundreds of Git repositories over the Internet gain the resistance of redundancy. When Linus Torvalds’ hard disk failed, he lost next to no work. Meanwhile, to keep data confidential will require having the fewest possible copies, which increases the risk of loss. Or it will require that we encrypt the data, but then how do we keep a copy of the key just in case? How do we ensure that the key remains available to those who will need it through time? What happens when the only guy who knows the passwords dies and leaves millions of users locked out of their account with no way to retrieve their money?

Using encryption also often means that the availability of your data becomes dependent on the availability of the encryption infrastructure. If the encryption is based on certificates and you validate the certificate, as you should, then access to the data is conditional to the availability of the revocation server. If you use smart cards, you will need to have them at hand. And probably, you will need to keep them physically secure, which again reduces the availability of your data: now instead of just double-clicking on a file, you need to retrieve a physical key, get up, walk to the safe, open it, retrieve the card, … by the time you come back from coffee, you no longer know what you wanted to open.

This is also a problem when documenting large industrial projects. Typically over decades, everyone who worked on it will have left the company. Yet access to the data is still required. Every so often, you will run into a ZIP file that was dutifully protected with a password, with no-one on the project able to tell you what it is.

A good way to envisage the trade-off is to wonder what is worse: having all your files published for all to see, or losing them forever?

This article originally appeared on my employer’s Web site.

Do not require encryption

Thu, 25 Mar 2021 00:00:00 +0100

In these days of mass storage of data on clouds, muddied RGPD waters and regular massive data theft, it has become – morally and legally – mandatory for companies to take steps to protect some or all of their data from unwanted access. This often turns into company directives or technical specifications that require that “data shall be encrypted”.

The problem with that requirement is that it mixes up protection and security. Security is a state in which your assets are protected from threats from attackers. Protection is a means to ensure security. For those who have dabbled in systems engineering, this is the security equivalent of needs versus solution. Specifying the protection without specifying the security is unconstructive because it often does not help the solution designer to come up with an effective protection scheme. “There, data shall be encrypted,” says the specifier before going home with the feeling of a job well done. Then comes the security architect with questions. “Encrypt? That’s easy. Who needs to have access to the key?”

By specifying the solution, the actual expression of needs has been left aside. In the end, encryption is nothing more than an access control mechanism, which allows the architect to work on the protection of small amounts of data – the keys – instead of protecting the data itself. The actual security questions are: what data do I need to protect? Who from? Who needs to have access to it? How long does the data need to be protected for? Specifying the solution lets us feel satisfied that the data will be secure, but we have answered none of the hard questions, and we cannot design an appropriate system without an answer to these questions.

We see this all the time. “The data shall be encrypted”. The data is stored on an AWS cloud, which we know is encrypted by Amazon. That means Amazon can (possibly) access our data. Is that OK? The data is stored in a Software-as-a-service platform hosted on AWS, so now it’s Amazon and the SaaS admins that can access the data. Is that OK? I’m using full disk encryption on my laptop, which really only protects against disk theft: is that OK, or did you want your data to be protected in case I open a malicious e-mail attachment?

Requiring encryption is akin to requiring that your house doors “shall have locks.” Is that your actual requirement? Sure, you need to be able to lock and unlock the front door, from inside and outside. Maybe you also want the bedroom doors to have a lock, but probably it doesn’t need to be as strong. Maybe you do not want a lock on your child’s bedroom at all. You may want your toilet door to have a simple keyless lock that only operates from inside, but indicates when it’s engaged outside, and with an override from outside in case your child locks himself inside. And what about the cat flap?

Unfortunately, there is no simple way out. What needs to be specified is the result of a standard risk analysis: who interacts with the system? Who needs access to the data? Which attackers might want my data? How bad is it if my data leaks?

And maybe your architect will even find a solution that is cheaper than encryption.

This article originally appeared on my employer’s Web site.

24h clock for kids

Wed, 06 Jan 2021 00:00:00 +0100

My son is growing up quickly. Finding landmarks in the day (“breakfast”, “naptime”, “dinner time” and so on) is not as trivial as one might think, and obviously small children are too small to read the time and turn an abstract “5 o’clock” to “teatime”.

Of course, the Internet has solutions for everything. You can buy 24-hour clock mechanisms, for which the hour hand will do only one turn per day (as opposed to standard, 12-hour clocks, where the hour hand turns twice).

Then I found Steve Pomeroy’s 24-hours clockface, which was both pretty enough and easily editable.

Then I added colours and icons randomly collected on the Internet, more or less based on my kid’s current habits and activities (I have to admit I did not keep track of the icons I used). And a fox, as his favourite plush toy is a fox.

And here’s the result, as an SVG file, which can be easily further edited with most vector editors, such as Inkscape:

Loquat disappointment

Sat, 28 Nov 2020 00:00:00 +0100

A couple of months ago I brewed a loquat beer. It turned out completely disappointing, as I explained at the end of that post.