[feature-request] Implement newer TLS Version in neawsreader pan?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[feature-request] Implement newer TLS Version in neawsreader pan?

neutral2016
Dear member,

i have seen on the feature list, that pan can only use TLS 1.0 . This Version ist outdated and unsecure. Can you implement a newer version of the TLS Protocol?
Especially für Ubuntu 16.04 LTS would be great.

Thank you very much.

sincerelly yours,

netraul2016

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Duncan-42
neutral2016-htSm2yLGOjU posted on Tue, 04 Jul 2017 21:27:39 +0200 as
excerpted:

> i have seen on the feature list, that pan can only use TLS 1.0 . This
> Version ist outdated and unsecure. Can you implement a newer version of
> the TLS Protocol?

As a long-term list participant trying to help people with pan where I
can, but not a dev...

Updating the TLS code would be useful, but keep in mind for requests such
as this that historically, pan development has always come in fits and
starts, with lots of activity, updates, new features, etc, for perhaps a
year or two, as a particular dev takes a strong interest, especially in
scratching some of his own itches but bringing new code to all,
interspersed with periods of several years with little more than
maintenance patches from the various distro maintainers and others
building it themselves and offering patches, primarily to keep pan
building with updated of libraries and build toolchain.

Currently, pan is in one of those primarily maintenance-mode periods, so
unless such a contributor takes an interest in updating the TLS code and
provides a patch, it's unlikely to happen for some time.

That said, now that you've mentioned it, the chances are greatly
improved. =:^)

> Especially für Ubuntu 16.04 LTS would be great.

That's /extremely/ unlikely.  Unless things have changed at Ubuntu in
this regard recently, they don't tend to update pan at all in released
versions, even when there's a security update[1] and an Ubuntu bug filed
about it, as happened some years ago.  As a result, Ubuntu users don't
normally get pan version updates unless they build it themselves, until
they install a new version of Ubuntu that happens to ship a newer pan as
part of it.

Security updates aside (you'll need to talk to Ubuntu about that),
there's a reason versions are labeled LTS.  Tho they're /supposed/ to get
security updates, the point of running an LTS is that you /don't/ get
normal version updates, because the new versions bring new code, likely
with new bugs, and users choose an LTS because they prefer not to deal
with the risk and hassle involved in that sort of change, even at the
cost of not getting new features such as support for newer TLS.

So if you're interested in new features such as newer TLS support in
packages such as pan, I suggest that an LTS that blocks such version
upgrades by policy may not be your best choice.

---
[1] Security update:  Arguably, it was a minor one, and pan, as an
optional-installation minor component, probably wasn't considered worth
the trouble.

FWIW, the security issue was that pan wasn't taking care to strip the
executable bit from saved files.  Some groups have people posting malware
(tho it's usually MS-platform executables), and in theory at least, they
could have posted something targeted at *ix with the executable bit set.  
If a user happened to download and save that malware, presumably in the
middle of a bunch of other downloads, and then click on it while
browsing...

A workaround was to ensure that the umask was set to mask the executable
bits before pan was started, and I actually had (and still have) a
wrapper script that I use to launch pan that does just that (among other
things I've found useful over the years), but the problem then becomes
that pan can't dynamically create and enter new directories, because that
requires the executable bit set on the directory.  Once pan's directories
are already created and the executable bit set appropriately, that's
fine, but as I've found over the years, if pan needs to create a new dir,
such a wrapper means problems, requiring a manual intervention to fix.  
Not so bad if you're the one who created the wrapper and thus presumably
are familiar enough with Unix style permissions to recognize the problem
and know how to fix it, but it'd be a breaking bug for many users.

Ubuntu updated pan to the new version that properly masked the executable
bit on saved files in their next release, but that was months later.  
Meanwhile, Ubuntu users remained exposed.  Like I said, they probably
didn't figure it was worth the trouble (if they noticed the bug filing at
all, IIRC no Ubuntu dev ever replied on it), because pan is a non-core
optional component that few would have installed, but the fact that they
left their users exposed for months despite people going to the trouble
of filing the security bug, and despite /other/ distros fixing it and
closing their bugs within a month or so, as you no doubt figured out from
the discussion above, continues to grate on me to this day.

I'm sure it's obvious by now that I don't run either Ubuntu or LTSs, but
of course, your computer, your choice.  While I might differ in my
choices for my systems, I'd not /dream/ of trying to overrule yours for
yours, tho of course that doesn't mean I can't try to convince you to
change them. =:^)

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


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Duncan-42
In reply to this post by neutral2016
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


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Duncan-42
Duncan posted on Thu, 06 Jul 2017 01:14:18 +0000 as excerpted:

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

Thinking about it a bit more...

Even better would be auto-negotiation, but with a configured minimum
version, which would of course default to 1.0 for backward compatibility,
but users could up that to 1.3 or whatever if they knew their provider
supported it.  Then if pan couldn't negotiate the configured minimum,
instead of falling back to something less secure it'd hard-fail.

Then the configuration could be servers.xml only without either
regression if only the existing 1.0 was server-supported, or too big a
security compromise if higher was, because the auto-negotiation would
then get that, for gui-only users.

I believe that'd be my ideal, with gui or no-gui config left up to a vote
here or the person doing the patch, I guess.

--
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Duncan-42
Detlef Graef posted on Thu, 06 Jul 2017 19:40:58 +0200 as excerpted:

> For a quick test I have replaced line number 813 in the file
> socket-impl-openssl.cc with the following line:
>
>  "NONE:+VERS-TLS-ALL:+CIPHER-ALL:+COMP-ALL:+KX-ALL:SIGN-ALL:+CURVE-ALL:
> +CTYPE-ALL:+MAC-ALL", NULL);
>
> This enables all TLS versions (1.0, 1.1, 1.2) and all other options.
>
> See: https://gnutls.org/manual/html_node/Priority-Strings.html
>
> After building Pan with gnu-tls option enabled everything seems to work
> in my setup.

Is there a debug method to tell you what was actually used?  Did you
verify that it was TLS v 1.2 (assuming your server supports it)?

> I think a good solution would be to add a additional option in the file
> servers.xml for each server so that a specific TLS version can be set by
> the user if a problem occurs with a certain server.
>
> Something like:
>
> <tlsver>TLS-VER-ALL</tlsver> with TLS-VER-ALL as the default value.
>
> possible other values:
>
> <tlsver>VERS-TLS1.0</tlsver> force TLS ver. 1.0
> <tlsver>VERS-TLS1.1</tlsver> force tLS ver. 1.1
> <tlsver>VERS-TLS1.2</tlsver> force TLS ver. 1.2
> <tlsver>VERS-TLS1.3</tlsver>   (in the future)

LGTM. =:^)

[FWIW, pan says I didn't write enough for what I quoted.  I don't tend to
get that warning very often. =:^) But I don't have anything else to
add... or delete in the quote... but this note of side interest.  It's
pan behavior in the pan newsgroup/list, so it's on topic. =:^)  If this
goes thru it was enough, if not I'll mention that instead of this
sentence and send anyway.]

--
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Steve Davies-2
In reply to this post by Duncan-42


On Thu, 6 Jul 2017 at 18:41 Detlef Graef <[hidden email]> wrote:
Something like:

<tlsver>TLS-VER-ALL</tlsver>    with TLS-VER-ALL as the default value.

possible other values:

<tlsver>VERS-TLS1.0</tlsver>    force TLS ver. 1.0
<tlsver>VERS-TLS1.1</tlsver>    force tLS ver. 1.1
<tlsver>VERS-TLS1.2</tlsver>    force TLS ver. 1.2
<tlsver>VERS-TLS1.3</tlsver>   (in the future)

 
In case it helps, there are MANY SSL capable servers and clients out there, and rather than reinvent the wheel, how these guys configure their software should probably be taken into consideration (they've been doing it for a long time ;) )

Here's a link to the nginx config page for SSL, which I chose because it is fairly representative http://nginx.org/en/docs/http/configuring_https_servers.html

To me this would translate to XML of something like:

<ssl_protocol>ALL</ssl_protocol>
<ssl_ciphers>ALL</ssl_ciphers>

or

<ssl_protocol>TLSv1.2</ssl_protocol>
<ssl_ciphers>HIGH:!aNULL:!MD5</ssl_ciphers>

or maybe a good compromise between compatibility and safety that I've used ;-)

<ssl_protocol>TLSv1 TLSv1.1 TLSv1.2</ssl_protocol>
<ssl_ciphers>EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5</ssl_ciphers>

Just my 2p.
Steve



_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Petr Kovar-2
In reply to this post by Duncan-42
On Thu, 6 Jul 2017 19:40:58 +0200
Detlef Graef <[hidden email]> wrote:

> Am 06.07.2017 um 04:30 schrieb Duncan:
> > Duncan posted on Thu, 06 Jul 2017 01:14:18 +0000 as excerpted:
> >
> >> 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.
> >
> > Thinking about it a bit more...
> >
> > Even better would be auto-negotiation, but with a configured minimum
> > version, which would of course default to 1.0 for backward compatibility,
> > but users could up that to 1.3 or whatever if they knew their provider
> > supported it.  Then if pan couldn't negotiate the configured minimum,
> > instead of falling back to something less secure it'd hard-fail.
> >
> > Then the configuration could be servers.xml only without either
> > regression if only the existing 1.0 was server-supported, or too big a
> > security compromise if higher was, because the auto-negotiation would
> > then get that, for gui-only users.
> >
> > I believe that'd be my ideal, with gui or no-gui config left up to a vote
> > here or the person doing the patch, I guess.
>
> The GnuTLS library does auto-negotiation.
>
> It is possible to set the TLS version to "VERS-TLS-ALL" then the TLS
> version is auto-negotiated. Other parameters can be set too.
>
> For a quick test I have replaced line number 813 in the file
> socket-impl-openssl.cc with the following line:
>
>  "NONE:+VERS-TLS-ALL:+CIPHER-ALL:+COMP-ALL:+KX-ALL:SIGN-ALL:+CURVE-ALL:+CTYPE-ALL:+MAC-ALL", NULL);
>
> This enables all TLS versions (1.0, 1.1, 1.2) and all other options.
>
> See: https://gnutls.org/manual/html_node/Priority-Strings.html
>
> After building Pan with gnu-tls option enabled everything seems to work
> in my setup.

Detlef's patch addressing this landed in master yesterday. Please test it
and report back should there be any secure connection issues.

Thanks!

Cheers,
pk

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Loading...