On Mon, 30 Sep 2013, Phil Pennock wrote:
> On 2013-09-30 at 22:34 +0100, Jeremy Harris wrote:
>> On 30/09/13 21:45, Jeremy Harris wrote:
>>> The testsuite threw me an error for testcase 2025:
>>>
>>> tls_require_ciphers invalid:
>>> gnutls_priority_init(!RSA_AES_256:DES-CBC3-SHA) failed at offset 0,
>>> "!RSA_AES.." failed: The request is invalid.
>>
>> It's possible that something's changed on my test system;
>> this particular testcase is failing for all the build
>> versions I've tried so far...
>
> That string doesn't pass gnutls_priority_init() testing for me.
>
> This is the only 20?? test using tls_require_ciphers; the others are all
> "encrypted = ..." checks, which are Exim doing list matching of the
> string from the middle colon-separated section of tls_in.cipher.
>
> It seems strange that this test is unmodified from 2006; I know we ran
> the GnuTLS tests for the 4.80 release, so any changes caused by
> switching to GnuTLS priority strings should have been exposed then.
>
> Aha, I see that this was a known-broken test at the time:
>
> ----------------------------8< cut here >8------------------------------
> 2025 is known broken, I thought I'd commented upon it in a previous
> mail. I saw this when testing before the RC cut and after a little
> prodding decided to skip it.
>
> Previously I thought that it was that we were expanding the available
> cipher suites, so the previous assumptions within the more restricted
> set didn't hold.
>
> Instead, the new start-up check is revealing that the string used for
> the test just is not accepted by GnuTLS as a priority string. This is
> the big backwards-compatibility break.
>
> Fortunately, I suspect that very few people ever actually set
> tls_require_ciphers, so the fallout won't be too bad. But we do need to
> figure out the idea behind this test so that we can properly test it in
> the new world order.
> ----------------------------8< cut here >8------------------------------
I for one *do* set tls_require_ciphers (though I currently use OpenSSL
not GnuTLS) - I dropped RC4 a couple of weeks ago after using
it for a couple of months to protect against the BEAST.
> Looks like the point of the test was just to confirm that
> tls_require_ciphers is honoured, so I've no idea what the point behind
> the conditional expansion of the string is, based upon the source
> address.
At least I have a fixed value in my config.
> For the only _stated_ purpose of the test, you should just be able to
> pick a new priority string, to reflect the as-of-4.80 state of option
> parsing, to confirm no regressions beyond the stated compatibility break
> in 4.80.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison@??? http://www.dpmms.cam.ac.uk/~werdna
