Re: [Pan-users] [feature-request] Implement newer TLS Version in neawsreader pan?

[Duncan]

Detlef Graef posted on Wed, 05 Jul 2017 18:52:21 +0200 as excerpted:

> Should the TLS version be configurable by the user? Where? In the GUI or
> the file preferences.xml?

Charles would almost certainly have made TLS version a file-pref only.  
AFAIK that would be in keeping with gnome's policy of trying to keep the 
gui simple.

Tho I should mention I'm biased and prefer kde/plasma in part because in 
general it exposes more choices via GUI to the user.  Of course I'm a 
gentoo user for the same reason, more choice to configure exactly what I 
want how I want, so I won't contest a claim that I'm rather far tilted 
toward the power-user side than the vast majority, but it is what it is.

Heinrich... you'd need to ask him to be sure, but he seemed to favor 
putting the options in the gui, or at least all the configuration for the 
features he added was available via gui, which of course I'm absolutely 
fine with, but as I said I'm biased.

FWIW I think the optimum, if it's not too difficult to achieve, would be 
to let it be auto-negotiated, of course favoring the newer versions if 
the server supports them as well.  If getting the negotiation right is 
too difficult, I'd suggest making it configurable, at /least/ via file, 
but of course I'd personally prefer gui.

The problem if it's not auto-negotiated, particularly if it's not exposed 
in the gui, is what to make the default.  Arguably we should go for the 
newer version for security reasons, but of course that might end up being 
a regression for some who need a gui for such config, who can connect 
now, but who connect to servers that don't support the newer version and 
would thus not be able to connect once the update goes in, if the 
configuration wasn't exposed in the gui.


Meanwhile, it's worth keeping the whole thing in perspective.  Until a 
relatively recent patch, while pan /could/ do an encrypted connection, 
storing the certificate was broken (the file stored was a seriously 
broken binary of some sort instead of the ASCII-armored cert that should 
have been stored), leaving people with two choices, either set pan to 
auto-accept whatever cert was presented, thus allowing MiTM attacks 
without detection, or manually verify and accept the certificate each 
time you connected.  It sucked, but it was still better than the previous 
no encryption at all unless you setup an encrypted tunnel manually and 
had pan use it, which was what we were telling people to do for about a 
decade, I guess, until pan finally did get the encryption feature.

Given that, an actually verified TLS-1.0 is /way/ better than the 
unverified and thus easily MiTM-able setup we had until quite recently, 
and /that/ is better than entirely unencrypted, setup a third party 
tunnel and use that if you want encryption, which was what we had for I 
believe about the first decade I was using pan.

Of course newer TLS will be even better... at least as long as we don't 
end up breaking the certificate storage or something, once again.

So if it's something you can do, great, but if not, at least we have 
encrypted connections in the first place, now, and at least attempting an 
MiTM will require /some/ effort, now -- probably more than ISPs, etc, are 
likely to be doing for a /few/ more years yet, and if you've gotten the 
attention of a nation-state level actor... I'd expect they'll simply get 
a warrant and log your activity from the server end in any case.

-- 
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