Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #180081 > unrolled thread

ssl isues are Eating me alive.

Back to article view | Back to linux.debian.user

Contents

  ssl isues are Eating me alive. "Martin McCormick" <martin.m@suddenlink.net> - 2017-04-13 19:00 +0200
    Re: ssl isues are Eating me alive. Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-13 19:10 +0200
      Re: ssl isues are Eating me alive. Darac Marjal <mailinglist@darac.org.uk> - 2017-04-13 22:10 +0200
        Re: ssl isues are Eating me alive. Sven Hoexter <sven@timegate.de> - 2017-04-17 16:00 +0200
      Re: ssl isues are Eating me alive. "Martin McCormick" <martin.m@suddenlink.net> - 2017-04-13 22:50 +0200
      Re: ssl isues are Eating me alive. Reco <recoverym4n@gmail.com> - 2017-04-14 12:00 +0200
        Re: ssl isues are Eating me alive. davidson@freevolt.org - 2017-04-15 17:20 +0200
          Re: ssl isues are Eating me alive. Reco <recoverym4n@gmail.com> - 2017-04-15 19:20 +0200
            Re: ssl isues are Eating me alive. Sven Hoexter <sven@timegate.de> - 2017-04-17 16:10 +0200

#180081 — ssl isues are Eating me alive.

This started out a year or so ago with the occasional site in
which lynx would report that it was unable to establish a TLS
connection with this or that site. The next step on the road to
train reck is that lynx says it's trying an insecure connection
without TLS. That's nice that it tries and on some occasions,
some sites let this happen, but this is not good at all. Usually,
the next message is that there will be no session of any kind
from this site and that is actually a good thing since an
insecure connection invites all sorts of possibilities for leaks
of information useful to the whole menagerie of cyber scum.

	What needs to be updated to make most sites at least
display a page and not just bounce one back to whatever was going
on before the alert and disconnect?

	The only real pattern to all this is it's getting worse
by the day so something has expired and is starting to stink.

	Thanks for all constructive ideas.

Martin McCormick

[toc] | [next] | [standalone]

#180086

On Thu, Apr 13, 2017 at 11:54:32AM -0500, Martin McCormick wrote:
> This started out a year or so ago with the occasional site in
> which lynx would report that it was unable to establish a TLS
> connection with this or that site. [...]

It's not just lynx.  It's EVERY single terminal-based browser, and
as you noticed, it gets worse every day.

Apparently all of the terminal-based browsers in wheezy and jessie are
linked with libgnutls instead of libopenssl, and libgnutls (at least as
provided by jessie) is completely incapable of forming an SSL connection
with half of the Web.

Every time someone in IRC pastes an https://* link, it's a roll of the
dice whether I'll be able to open it in elinks.  https://paste.debian.net/
is one example of a site that does not work.  If you remove the 's'
and just go to http://paste.debian.net/ it's fine.

Most other paste sites don't offer a working option like that.

[toc] | [prev] | [next] | [standalone]

#180102

It looks[1] like Squid can do SSL Interception. I imagine it should be
possible, therefore, for squid to perform the HTTPS connection and
either downgrade it to HTTP or to re-encrypt it with a lower grade. YMMV


[1] http://wiki.squid-cache.org/Features/HTTPS

On 13/04/17 18:01, Greg Wooledge wrote:
> On Thu, Apr 13, 2017 at 11:54:32AM -0500, Martin McCormick wrote:
>> This started out a year or so ago with the occasional site in
>> which lynx would report that it was unable to establish a TLS
>> connection with this or that site. [...]
> It's not just lynx.  It's EVERY single terminal-based browser, and
> as you noticed, it gets worse every day.
>
> Apparently all of the terminal-based browsers in wheezy and jessie are
> linked with libgnutls instead of libopenssl, and libgnutls (at least as
> provided by jessie) is completely incapable of forming an SSL connection
> with half of the Web.
>
> Every time someone in IRC pastes an https://* link, it's a roll of the
> dice whether I'll be able to open it in elinks.  https://paste.debian.net/
> is one example of a site that does not work.  If you remove the 's'
> and just go to http://paste.debian.net/ it's fine.
>
> Most other paste sites don't offer a working option like that.
>

[toc] | [prev] | [next] | [standalone]

#180204

On Thu, Apr 13, 2017 at 09:04:01PM +0100, Darac Marjal wrote:
> It looks[1] like Squid can do SSL Interception. I imagine it should be
> possible, therefore, for squid to perform the HTTPS connection and
> either downgrade it to HTTP or to re-encrypt it with a lower grade. YMMV

Well automatic downgrade to HTTP could work, not sure how to implement it,
but often you'll experience issues due to missing SNI support.
For example in the case of elinks you can find the following open wishlist bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797968
So that issue will continue to exist in stretch but that's not the fault of
GNUTLS but an application issue.

In regards of cipher support at least GNUTLS from jessie should work with
most public sites. For wheezy the situation might be more complicated.

Regarding Squid I *think* it's also missing SNI support at the moment and
for sure in wheezy.

Long story short: You need a somewhat recent GNUTLS release (jessie should
be fine) and application level support en par with that.

Sven

[toc] | [prev] | [next] | [standalone]

#180106

Greg Wooledge <wooledg@eeg.ccf.org> writes:
> Apparently all of the terminal-based browsers in wheezy and jessie are
> linked with libgnutls instead of libopenssl, and libgnutls (at least as
> provided by jessie) is completely incapable of forming an SSL connection
> with half of the Web.
> 
> Every time someone in IRC pastes an https://* link, it's a roll of the
> dice whether I'll be able to open it in elinks.  https://paste.debian.net/
> is one example of a site that does not work.  If you remove the 's'
> and just go to http://paste.debian.net/ it's fine.
> 
> Most other paste sites don't offer a working option like that.

	Yup. The one I needed to go to didn't.

	At least I don't feel like I just failed to keep
something up to date or am doing something stupid so I feel a
little better. Who knows? It might get fixed one day.

Thank you.

Martin

[toc] | [prev] | [next] | [standalone]

#180121

	Hi.

On Thu, Apr 13, 2017 at 01:01:24PM -0400, Greg Wooledge wrote:
> On Thu, Apr 13, 2017 at 11:54:32AM -0500, Martin McCormick wrote:
> > This started out a year or so ago with the occasional site in
> > which lynx would report that it was unable to establish a TLS
> > connection with this or that site. [...]
> 
> It's not just lynx.  It's EVERY single terminal-based browser, and
> as you noticed, it gets worse every day.
> 
> Apparently all of the terminal-based browsers in wheezy and jessie are
> linked with libgnutls instead of libopenssl, and libgnutls (at least as
> provided by jessie) is completely incapable of forming an SSL connection
> with half of the Web.

There's one notable exception to this in jessie and it's called w3m.

$ ldd /usr/bin/w3m | grep ssl
        libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

Reco

[toc] | [prev] | [next] | [standalone]

#180161

On Fri, 14 Apr 2017, Reco wrote:

> 	Hi.
>
> On Thu, Apr 13, 2017 at 01:01:24PM -0400, Greg Wooledge wrote:
>> On Thu, Apr 13, 2017 at 11:54:32AM -0500, Martin McCormick wrote:
>>> This started out a year or so ago with the occasional site in
>>> which lynx would report that it was unable to establish a TLS
>>> connection with this or that site. [...]
>>
>> It's not just lynx.  It's EVERY single terminal-based browser, and
>> as you noticed, it gets worse every day.
>>
>> Apparently all of the terminal-based browsers in wheezy and jessie are
>> linked with libgnutls instead of libopenssl, and libgnutls (at least as
>> provided by jessie) is completely incapable of forming an SSL connection
>> with half of the Web.
>
> There's one notable exception to this in jessie and it's called w3m.
>
> $ ldd /usr/bin/w3m | grep ssl
>        libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

In wheezy (at least) I've noticed that curl can also cope, when lynx
(and wget) cannot.

[toc] | [prev] | [next] | [standalone]

#180164

	Hi.

On Sat, 15 Apr 2017 15:14:29 +0000 (UTC)
davidson@freevolt.org wrote:

> On Fri, 14 Apr 2017, Reco wrote:
> 
> > 	Hi.
> >
> > On Thu, Apr 13, 2017 at 01:01:24PM -0400, Greg Wooledge wrote:
> >> On Thu, Apr 13, 2017 at 11:54:32AM -0500, Martin McCormick wrote:
> >>> This started out a year or so ago with the occasional site in
> >>> which lynx would report that it was unable to establish a TLS
> >>> connection with this or that site. [...]
> >>
> >> It's not just lynx.  It's EVERY single terminal-based browser, and
> >> as you noticed, it gets worse every day.
> >>
> >> Apparently all of the terminal-based browsers in wheezy and jessie are
> >> linked with libgnutls instead of libopenssl, and libgnutls (at least as
> >> provided by jessie) is completely incapable of forming an SSL connection
> >> with half of the Web.
> >
> > There's one notable exception to this in jessie and it's called w3m.
> >
> > $ ldd /usr/bin/w3m | grep ssl
> >        libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> 
> In wheezy (at least) I've noticed that curl can also cope, when lynx
> (and wget) cannot.

AFAIK jessie is the last Debian release that provides curl linked with
openssl.

Reco

[toc] | [prev] | [next] | [standalone]

#180205

On Sat, Apr 15, 2017 at 08:11:13PM +0300, Reco wrote:

Hi,

> AFAIK jessie is the last Debian release that provides curl linked with
> openssl.

We've three flavour of libcurl in the archive and the current "default"
is the one linked against openssl.
libcurl3 - easy-to-use client-side URL transfer library (OpenSSL flavour)
libcurl3-gnutls - easy-to-use client-side URL transfer library (GnuTLS flavour)
libcurl3-nss - easy-to-use client-side URL transfer library (NSS flavour)

That's also the case for wheezy and I did not check older releases, but it's
like that for a few years.

The curl binary itself is build against the libcurl3 - so the openssl flavour.
That is also the case for the upcoming stretch release.

Sven

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web