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
[email protected] http://www.dpmms.cam.ac.uk/~werdna
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
