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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
