Detlef Graef posted on Tue, 23 Feb 2016 21:08:17 +0100 as excerpted: > Am 23.02.2016 um 18:15 schrieb Detlef Graef: > >> Am 23.02.2016 um 04:43 schrieb walt: >> >>> I'm running the latest pan from git with gnutls support and I'm a bit >>> confused about how pan is saving the server certs. If you have a news >>> server that supports ssl/tls connections, could you look in your >>> ~/.pan2/ssl_certs directory for any files and check to make sure they >>> are stored correctly? >>> >>> They should be .pem files, which are plain text files containing lines >>> like -----BEGIN CERTIFICATE----- followed by a bunch of text garbage, >>> followed by -----END CERTIFICATE-----. >> >> I've configured three servers, two servers with TSL/SSL encryption. The >> directory ~/.pan2/ssl_certs was empty. >> >> The check-box "Always trust the servers certificate" was enabled. I've >> disabled the check-box and restarted pan. Then I was asked to confirm >> the certificate. A six byte file was saved at ~/.pan2/ssl_certs. >> >> The option "Always trust the servers certificate" is set if the >> certificate is confirmed. > > Just an update: > > The above behavior was on Fedora Linux. > > On MS Windows (Pan 0.140) the file with the certificate is ok. > > Maybe this bug is related to the C++11 ABI change in GCC5.
That crossed my mind as well, but the 6-byte cert files I have on at least one of my pan instances here are from long before I upgraded to gcc5, as I haven't used that pan instance in quite some time. But confirming that the cert files appear as expected on MS Windows, definitely does confirm a bug here on Linux, where they're only coming up as 6-bytes. Not being a coder, tho those 6-byte files didn't look right, I thought perhaps it was simply some sort of 6-byte binary digest of the cert, and that was considered "good enough". But if the certs are coming out as proper ascii files on MS, then obviously not -- the 6-byte-binary- file Linux behavior we're seeing _must_ be a bug. Which is definitely interesting and should give the MS Windows users somethign to feel good about, since 90+ percent of the time, if there's a bug on one platform and not the other, it's an MS-side bug, given that Linux is pan's primary platform and gets the most testing and use, as well as being the primary development platform. Meanwhile, the reason I didn't front-burner the problem and look into it in more depth myself, and I suppose probably the same for others, is because until /relatively/ recently, pan didn't support secure connections at all, and while the bug does mean MitM attacks are possible, the fact that the encrypted connections are made successfully at all, indicates pan is properly supporting the encryption, and even MitMable (semi-)secure connections are better than plain text, since an attacker then has to deliberately decrypt, do his logging or substitution or whatever, and recrypt, before passing on the packages, and while certainly doable for a determined attacker, it's well beyond the trivial "let's just sniff the stuff we can as it goes by" spying and connection interference that plain text allows. Additionally, some users encrypt primarily as a means of avoiding ISP interference with normal nntp connections, and don't really care about the actual security of the connection beyond that, and even the bugged pan version protects reasonably well against that, since that's pretty much exactly the "let's just sniff the stuff we can as it goes by" attack that even a "just accept whatever cert is handed to us" policy effectively defends against. But certainly, now that we know MS gets the actual ascii-format certificate file as expected, not only is it a confirmed Linux/*ix bug, but once it's tracked down and fixed, the fix should be a security fix, and we should consider filing it as such with the various distros that carry pan. Tho I don't know if we should file for a CVE number or not, since AFAIK, pan's secure connection handling has always had this bug on Linux, as I remember wondering about the 6-byte file thing when I first tried it out as the feature was being developed. Meanwhile, while it's definitely not a gcc5 thing, it remains quite possible that it's a 32-bit vs. 64-bit thing. My 6-byte certs are on amd64. Can anyone running a 32-bit x86 pan on Linux confirm whether you see 6-byte binary files, rather longer proper ascii files, or something else, on 32-bit? And for that matter, is your MS Windows pan 32-bit or 64-bit. If it's 32- bit, it could well be a 32-bit vs. 64-bit thing, not a Linux vs MS Windows thing. And of course if anyone is running pan on non-x86, either 32-bit or 64- bit, and using the secure connection functionality, reports on what your certificate files look like, 6-byte binary garbage, rather longer ascii, or something else entirely, would be greatly appreciated. =:^) -- 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
