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

[L. Aaron Kaplan]

> On 07 Nov 2015, at 14:32, Gunnar Haslinger <gh.bettercrypto at hitco.at> wrote:
> 
> 
>> On 2015-11-03 00:38, Aaron Zauner wrote:
>> Nevertheless I feel the same way, AES128 should be preferred;
>> and that exactly what we're doing with the latest version of
>> our bettercrypto cipherstring recommendation:
>> https://git.bettercrypto.org/ach-master.git/blob/HEAD:/src/common/cipherStringB.tex
> 
> On 2015-11-03 07:57 Gunnar Haslinger wrote:
>> CipherString-B in Theory-Section 3.2.3 is different to
> Apache-Recommendation in Section 2.1.1.
> 
> On 2015-11-03 08:04 L. Aaron Kaplan wrote:
>> This sounds like a mistake then. They should be the same.
> 
> 
> I just checked the current Dovecot Cipherstring - and it differs to
> CipherString-B too (equal to Apache).
> 
> nginx differs too (equal to Apache)
> 
> lighttpd differs too (similar to Apache) - additionally there is a ":"
> missing between "!aNULL!eNULL".
> 
> Cherokee seems to be copied from lighttpd, so same missing ":" between
> "!aNULL!eNULL".
> 
> cyrus - like dovecot / apache
> 
> postfix - like dovecot / apache
> 
> IronPort: similar to dovecot / apache but additional: "!SRP"
> 
> 
> Finding a single Cipherstring being suitable for a variety of
> OpenSSL-Versions is very hard. At least on current Debian 8.2 we
> realized that CipherString-B is not sorted as it was thought to be when
> current recommendation in the guide was merged. The discussion lead to:
> maybe there should be separated recommendations for different
> Versions/OS-Distributions.
> 
> 
> But how should we deal with this differences in the guide in the meantime?

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!

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 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]


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”.


> 
> Should Apache, Dovecot, nginx, lighttp, etc... CipherStrings be changed
> to match CipherString-B?
> 
Yes. See above.

> Should CipherString-B get an Update?
> 
To be discussed! There might be some good reasons over the course of two years time.
But I’d rather keep that a separate focussed discussion and now focus on having a consistent picture (again).

Thanks again for checking!
Aaron (Kaplan).



[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).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20151107/2b8a5c2d/attachment.sig>