On 2012-05-21 06:20, Phil Pennock wrote:
> I'll make it an Exim tunable option as a max clamp and default it to the
> NSS value of 2236.
Great! Good idea to make it tunable. Why repeat NSS's mistakes. I expect
to soon see some other software hitting a similar limit as well, so it
is a good idea th
On 2012-05-21 at 02:45 +0700, Janne Snabb wrote:
> On 2012-05-21 01:34, Janne Snabb wrote:
> > Maybe NSS is unable to create/use bigger keys than 2048 bits?
>
> I found the actual limit in NSS sources in
> mozilla/security/nss/lib/freebl/blapit.h:
You are awesome. Thank you.
> http://sourceforg
On 2012-05-21 01:34, Janne Snabb wrote:
> Maybe NSS is unable to create/use bigger keys than 2048 bits?
I found the actual limit in NSS sources in
mozilla/security/nss/lib/freebl/blapit.h:
#define DH_MAX_P_BITS 2236
Thus DHE keys up to 2236 bits do work, but longer keys cause the
observe
On 2012-05-20 17:35, Phil Pennock wrote:
> I don't see a better error code for peer EOF, but calling EOF a record
> overflow is still a little confusing to dumbasses like me.
I agree, EOF handling in GnuTLS does not look very convincing.
> Okay, is clearly NSS disliking the server_hello_done.
I
On 2012-05-20 at 17:11 +0700, Janne Snabb wrote:
> On 2012-05-20 16:24, Phil Pennock wrote:
> > I find it interesting that ssltap does show the length=4 packet but
> > *not* the length=9 packet which GnuTLS claims it was sent.
>
> Look at the log closer:
*sigh* I wish I hadn't run Thunderbird ;)
On 2012-05-20 at 12:14 +0700, Janne Snabb wrote:
> It appears that:
>
> - If I compile Exim 4.80 RC2 with GnuTLS (2.8.5-4.el6_2.2) on Scientific
> Linux 6.2 I do not have problems connecting to it with NSS based client
> (no matter if the client is shipped by SL or Ubuntu).
>
> - If I attempt to
