Re: [Pan-users] Need help debugging pan + gnutls-3.x.x

[Duncan]

walt posted on Thu, 13 Dec 2012 16:11:11 -0800 as excerpted:

> Duncan: I posted this reply on 12-11 but AFAICT it never reached the
> mailing list, so this is my second try--with fingers crossed:
> 
> On 12/11/2012 02:45 AM, Duncan wrote:
>>> The broken/working/broken bit MAY be the NSP's server, serving
>>> different
>>> >certs depending on what front-end you connect to.
> 
>> I still think that may be it...
> 
> Aha!  Good guess :)  I'm not yet certain how many different keys I may
> be getting from the same IP address (it's always the same address) but
> there are at least two -- the broken one is RSA512 (weak) and the
> working one is RSA1024.
> 
> Mind you, gnutls-2.x.x accepts both of those keys without problem, so
> gnutls-3 must be doing something different with the 512-bit key.

Cross-check more than that -- the key hashing algorithms (md5 is long 
deprecated, sha-1, sha-256, etc), etc.  I seem to remember reading 
something about some of the weaker ones being disabled in default builds 
now, but I don't remember what library (or app) I was reading that about, 
or the details of what was actually disabled.  However, I believe there's 
still a configure option to build the weak stuff, if you want it, it's 
just no longer enabled by default, because while still not real-time 
brute-forceable, off-the-shelf break-time is down to a week or less with 
some of them, and that was judged to be simply too weak to enable by 
default any longer, when people's lives could be on the line (think 
Iran's intelligence network, which is known to have been behind at least 
one certificate authority pwnage and subsequent shutdown).

If it does end up being gnutls lacking default weak-stuff support, you'll 
have to decide whether you're satisfied with what amounts to obfuscation 
instead of encryption (prevents real-time, but not much more) for 
everything you use gnutls for, not just pan.  Tho of course you could 
probably do a custom build for pan and do a library pre-load for pan 
only, pointing at it, if it came to that.  This of course assumes that 
you're mainly using snews to prevent ISP or the like snooping, since your 
NSP likely has your payment data anyway, and must be assumed to cooperate 
with law enforcement, possibly even without requiring a warrant, so what 
amounts to obfuscation enough to prevent real-time snooping is all you're 
really after.  Of course if you have reason to want real encryption with 
pan as well, you'd need to contact your NSP and see what they can do to 
drop the weak stuff entirely.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman