Re: [Pan-users] ssl/tls certificate handling?

[Duncan]

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