[Ach] Apache, Dovecot and other Cipherstrings aren't matching CipherString-B

[Aaron Zauner]

Hi,

L. Aaron Kaplan wrote:
> First of all, thank you very much for checking! This is really what keeps the project useful!
> People checking the assumptions and the document.
> Thanks!

+1. Thanks!

> 
> To answer your question:
> 
> IMHO we should stick with the original and make sure that it’s consistently the same everywhere.
> This was the idea when we created the guide.

I agree there. I remember there being some exceptions though - a few
daemons were restricted in how they parsed cipherstrings passed from
config files.

> 
> I remember I once wrote a simple sed script to search and replace the string “@@@CIPHERSTRINGB@@@“ in every .tex file with the actual value.
> I believe we should quickly move back to such a search & replace mechanism in order to keep the document consistent. That’s important.
> [1]

We since split the document into more parts (i.e. files) and have a
dedicated directory (`src/configuration`) that holds actual config files
instead of inlining those in the document itself. Tobias Pape has done a
tremendous effort there.

These config files are currently not auto generated and do *not* contain
the macro you mention above. So a simple `git grep '@@@CIPHERSTRINGB@@@'
*` in the config dir won't yield any results currently.

If we choose to autogenerate those, they really should be checked with
some form of continuous integration tooling (jenkins, travis-ci, etc.)
and some form of linting.

> On the other hand - you are right - there are differences in different OSes/libraries (openssl versions) and clients.
> For that we had discussed that the best option would be an automatic testing facility which tests compatibilities.
> There seems to be some previous work on this from azet as well as others.
> Once these test results are in, we *could* make a cipher string generator on the web page where users can select the OS version, libraries  , supported clients and click on “Variant A: a super secure cipher string, no compatibility” or “Variant B: compatible secure cipher string”.
> 

Somebody still needs to do this, nobody volunteered so far. It's a lot
of work if we're going to integrate testing.

> [1] (and if anyone wants to git blame… we can figure out how these inconsistencies slipped in, but I do not assume malicious intent. I’d rather assume this happens by accident when multiple people contribute).

Just checked the git log etc and there's no malicious activity, it's
just how the document evolved. We really need solid code review (gerrit
for example). But code review needs people reviewing, most of these
changes were reviewed on GitHub by one or two people, but not to the
extent that people might expect from a solid software engineering
project. So no inline comments, discussion et cetera. This can be
improved - and can even be done on GitHub, again - it needs people
willing to review that are also familiar with the services they're
reviewing in production.

HTH,
Aaron (azet)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20151107/75ee6656/attachment.sig>