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

Groups > linux.debian.security > #5289 > unrolled thread

HTTPS enabled Debian Security repository

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

Contents

  HTTPS enabled Debian Security repository Marek Sebera <marek.sebera@gmail.com> - 2017-10-26 10:50 +0200
    Re: HTTPS enabled Debian Security repository 林博仁 <buo.ren.lin@gmail.com> - 2017-10-26 10:50 +0200
      Re: HTTPS enabled Debian Security repository Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2017-10-26 20:30 +0200
        Re: HTTPS enabled Debian Security repository Hans-Christoph Steiner <hans@at.or.at> - 2017-10-27 12:50 +0200
          Re: HTTPS enabled Debian Security repository Morris Taylor <morris@eml.cc> - 2017-10-27 16:00 +0200
            Re: HTTPS enabled Debian Security repository Luca Filipozzi <lfilipoz@debian.org> - 2017-10-27 16:30 +0200
          Re: HTTPS enabled Debian Security repository Henrique de Moraes Holschuh <hmh@debian.org> - 2017-10-28 05:00 +0200
            Re: HTTPS enabled Debian Security repository Ansgar Burchardt <ansgar@debian.org> - 2017-10-28 10:30 +0200
              Re: HTTPS enabled Debian Security repository Hans-Christoph Steiner <hans@at.or.at> - 2017-10-30 10:10 +0100
                Re: HTTPS enabled Debian Security repository Russell Coker <russell@coker.com.au> - 2017-10-30 12:40 +0100
                  Re: HTTPS enabled Debian Security repository Rob van der Putten <rob@sput.nl> - 2017-10-31 00:40 +0100
        Re: HTTPS enabled Debian Security repository Marek Sebera <marek.sebera@gmail.com> - 2017-11-09 11:00 +0100
          Re: HTTPS enabled Debian Security repository Paul Wise <pabs@debian.org> - 2017-11-09 11:20 +0100
            Re: HTTPS enabled Debian Security repository Marek Sebera <marek.sebera@gmail.com> - 2017-11-09 11:40 +0100
              Re: HTTPS enabled Debian Security repository Paul Wise <pabs@debian.org> - 2017-11-09 12:00 +0100
    Re: HTTPS enabled Debian Security repository Paul Wise <pabs@debian.org> - 2017-10-26 11:00 +0200
    Re: HTTPS enabled Debian Security repository Tototechy <angelmarckus@rediffmail.com> - 2020-01-16 17:00 +0100

#5289 — HTTPS enabled Debian Security repository

[Multipart message — attachments visible in raw view] — view raw

Hi,

please advise, is there any repository, that is both official mirror of
security.debian.org and enabled with SSL (HTTPS) access?

Accessing https://security.debian.org/ results in insecure certificate
protected domain mirror-conova.debian.org (SHA-1 signed certificate)

I've used unofficial mirrors for some time (ie. https://debian.ethz.ch),
but it get harder over time to find one that is at least bit up-to-date
and does provide secure SSL configuration.

also https://security.debian.org/debian-security/ =404
mirror conova does not provide debian security files

and it's IP is the only one in DNS that does accept connections on
443(https) port

;; ANSWER SECTION:
security.debian.org.	3466	IN	A	212.211.132.32
security.debian.org.	3466	IN	A	212.211.132.250
security.debian.org.	3466	IN	A	195.20.242.89
security.debian.org.	3466	IN	A	217.196.149.233

Thank you
Best Regards
Marek Sebera

[toc] | [next] | [standalone]

#5290

[Multipart message — attachments visible in raw view] — view raw

I believe that there's no benefit on accessing Debian archive with HTTPS as
they uses GnuPG for authentication

林博仁 <Buo.Ren.Lin@gmail.com>


2017-10-26 16:43 GMT+08:00 Marek Sebera <marek.sebera@gmail.com>:

> Hi,
>
> please advise, is there any repository, that is both official mirror of
> security.debian.org and enabled with SSL (HTTPS) access?
>
> Accessing https://security.debian.org/ results in insecure certificate
> protected domain mirror-conova.debian.org (SHA-1 signed certificate)
>
> I've used unofficial mirrors for some time (ie. https://debian.ethz.ch),
> but it get harder over time to find one that is at least bit up-to-date
> and does provide secure SSL configuration.
>
> also https://security.debian.org/debian-security/ =404
> mirror conova does not provide debian security files
>
> and it's IP is the only one in DNS that does accept connections on
> 443(https) port
>
> ;; ANSWER SECTION:
> security.debian.org.    3466    IN      A       212.211.132.32
> security.debian.org.    3466    IN      A       212.211.132.250
> security.debian.org.    3466    IN      A       195.20.242.89
> security.debian.org.    3466    IN      A       217.196.149.233
>
> Thank you
> Best Regards
> Marek Sebera
>
>
>

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

#5292

[Multipart message — attachments visible in raw view] — view raw

林博仁 wrote...

> I believe that there's no benefit on accessing Debian archive with HTTPS as
> they uses GnuPG for authentication

GnuPG indeed serves the purposes of authenticity and integrity very
well. Modulo bugs every now and then, but they happen on other layers as
well.

Also, nobody should rely on the privacy in this case since the server
content is public and the clients have a fairly simple access pattern.
Decoding the transfers from this isn't trival but seems doable with some
effort - one day I'll write a prove of concept for this.

There is however a reason for https, a sad one though: Braindead
"security" applicances that do deep packet inspection and might reject
the download of packages.

    Christoph

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

#5293

Christoph Biedl:
> 林博仁 wrote...
> 
>> I believe that there's no benefit on accessing Debian archive with HTTPS as
>> they uses GnuPG for authentication
> 
> GnuPG indeed serves the purposes of authenticity and integrity very
> well. Modulo bugs every now and then, but they happen on other layers as
> well.
> 
> Also, nobody should rely on the privacy in this case since the server
> content is public and the clients have a fairly simple access pattern.
> Decoding the transfers from this isn't trival but seems doable with some
> effort - one day I'll write a prove of concept for this.
> 
> There is however a reason for https, a sad one though: Braindead
> "security" applicances that do deep packet inspection and might reject
> the download of packages.
> 
>     Christoph
> 

This idea that GPG signatures on the index files is enough has been
totally disproven.  There was a bug in apt where Debian devices could be
exploited by feeding them crafted InRelease files:

https://www.debian.org/security/2016/dsa-3733

If HTTPS was used, that would mean exploiting that would require
compromising the mirror servers.  With HTTP only, anyone that can see
the network traffic can exploit the Debian box.  Plus there are other
things that using HTTPS improves:

https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/

HTTPS does not entirely solve all these problems, but it does
drastically improve things.

.hc

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

#5294

I would vote for enabling HTTPs on apt related service. The main idea is
that help to prevent users from leaking the version info of installed
packages. Say, if someone can eavesdrop the communication between the
server and client for a period of time, he/she might be able to know if
the installed packages on the client is vulnerable to some known
attacks. And the other reason is serving packages over HTTPS can help to
mitigate some unwanted problems when the connection is under DPI or
other conditions. 

--
BR, Morris

On Fri, Oct 27, 2017, at 06:42 PM, Hans-Christoph Steiner wrote:
> 
> 
> Christoph Biedl:
> > 林博仁 wrote...
> > 
> >> I believe that there's no benefit on accessing Debian archive with HTTPS as
> >> they uses GnuPG for authentication
> > 
> > GnuPG indeed serves the purposes of authenticity and integrity very
> > well. Modulo bugs every now and then, but they happen on other layers as
> > well.
> > 
> > Also, nobody should rely on the privacy in this case since the server
> > content is public and the clients have a fairly simple access pattern.
> > Decoding the transfers from this isn't trival but seems doable with some
> > effort - one day I'll write a prove of concept for this.
> > 
> > There is however a reason for https, a sad one though: Braindead
> > "security" applicances that do deep packet inspection and might reject
> > the download of packages.
> > 
> >     Christoph
> > 
> 
> This idea that GPG signatures on the index files is enough has been
> totally disproven.  There was a bug in apt where Debian devices could be
> exploited by feeding them crafted InRelease files:
> 
> https://www.debian.org/security/2016/dsa-3733
> 
> If HTTPS was used, that would mean exploiting that would require
> compromising the mirror servers.  With HTTP only, anyone that can see
> the network traffic can exploit the Debian box.  Plus there are other
> things that using HTTPS improves:
> 
> https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/
> 
> HTTPS does not entirely solve all these problems, but it does
> drastically improve things.
> 
> .hc
> 

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

#5295

As already answered in this thread, this is already available.  Per
https://deb.debian.org/:

} The redirection service is also available on HTTPS, so with the
} apt-transport-https package installed, you can use:
}
} deb https://deb.debian.org/debian stable main
} deb https://deb.debian.org/debian-security stable/updates main

Thanks.

-- 
Luca Filipozzi

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

#5296

On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote:
> This idea that GPG signatures on the index files is enough has been
> totally disproven.  There was a bug in apt where Debian devices could be
> exploited by feeding them crafted InRelease files:
> 
> https://www.debian.org/security/2016/dsa-3733

This was the *one* bug of this sort in the entire lifetime of apt thus
far, AFAIK.

> If HTTPS was used, that would mean exploiting that would require

One of the dozens of zero-days already found in the TLS stack we had to
run like crazy to patch ?

In fact, the TLS stack is so complex, we can be reasonably sure there is
still at least one remotely-exploitable zero-day there.

Have you ever looked at the library stack in APT's http method, and
compared it with the one in APT's https method?

> HTTPS does not entirely solve all these problems, but it does
> drastically improve things.

That is *not* an opinion shared by everyone, to put it mildly.

-- 
  Henrique Holschuh

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

#5297

Henrique de Moraes Holschuh writes:
> On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote:
>> This idea that GPG signatures on the index files is enough has been
>> totally disproven.  There was a bug in apt where Debian devices could be
>> exploited by feeding them crafted InRelease files:
>> 
>> https://www.debian.org/security/2016/dsa-3733
>
> This was the *one* bug of this sort in the entire lifetime of apt thus
> far, AFAIK.

No, there was also
   https://security-tracker.debian.org/tracker/CVE-2013-1051
which I found.  That one was fairly easy to exploit (concatenate
manipulated Release with wrong "-----BEGIN PGP SIGNATURE" markers and
correctly signed InRelease; gpg would verify the signature at the end,
but apt would use the unsigned, manipulated Release from the beginning)

Similar bugs were present in several other places in Debian's
infrastructure as well.

The one from 2016 is harder to exploit: I asked on #-apt back then and
the sample exploit had a 1/4 success change with a 1.3 GB InRelease file
on a memory starved i386 system).

>> If HTTPS was used, that would mean exploiting that would require
>
> One of the dozens of zero-days already found in the TLS stack we had to
> run like crazy to patch ?

That is still valid of course, though I'm not sure if GnuPG or TLS
libraries get wider testing...

Ansgar

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

#5298

Ansgar Burchardt:
> Henrique de Moraes Holschuh writes:
>> On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote:
>>> This idea that GPG signatures on the index files is enough has been
>>> totally disproven.  There was a bug in apt where Debian devices could be
>>> exploited by feeding them crafted InRelease files:
>>>
>>> https://www.debian.org/security/2016/dsa-3733
>>
>> This was the *one* bug of this sort in the entire lifetime of apt thus
>> far, AFAIK.
> 
> No, there was also
>    https://security-tracker.debian.org/tracker/CVE-2013-1051
> which I found.  That one was fairly easy to exploit (concatenate
> manipulated Release with wrong "-----BEGIN PGP SIGNATURE" markers and
> correctly signed InRelease; gpg would verify the signature at the end,
> but apt would use the unsigned, manipulated Release from the beginning)
> 
> Similar bugs were present in several other places in Debian's
> infrastructure as well.
> 
> The one from 2016 is harder to exploit: I asked on #-apt back then and
> the sample exploit had a 1/4 success change with a 1.3 GB InRelease file
> on a memory starved i386 system).

That hit rate is enough to build malware around...


>>> If HTTPS was used, that would mean exploiting that would require
>>
>> One of the dozens of zero-days already found in the TLS stack we had to
>> run like crazy to patch ?
> 
> That is still valid of course, though I'm not sure if GnuPG or TLS
> libraries get wider testing...
> 
> Ansgar
> 

Don't get me wrong, I agree that HTTPS is very overcomplicated and
terrible in a lot of ways.  But the days of plain HTTP/TCP are over.
All connections need to be moving towards encryption.  Even with HTTPS'
faults, we are better off using it than plain HTTP.

.hc

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

#5299

On Monday, 30 October 2017 8:57:00 AM AEDT Hans-Christoph Steiner wrote:
> > The one from 2016 is harder to exploit: I asked on #-apt back then and
> > the sample exploit had a 1/4 success change with a 1.3 GB InRelease file
> > on a memory starved i386 system).
> 
> That hit rate is enough to build malware around...

25% hit rate is enough to be worth exploiting, but 1.3G of extra data greatly 
reduces the incidence.  The small i386 systems tend not to have fast enough 
networking that 1.3G of data could be downloaded without notice.

> Don't get me wrong, I agree that HTTPS is very overcomplicated and
> terrible in a lot of ways.  But the days of plain HTTP/TCP are over.
> All connections need to be moving towards encryption.  Even with HTTPS'
> faults, we are better off using it than plain HTTP.

I agree.  There's little downside nowadays.  Squid doesn't work particularly 
well caching APT repositories nowadays (strange timeouts and hangs during 
downloads) so the caching benefit of non-SSL has mostly gone away.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

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

#5300

Hi there


On 30/10/17 12:24, Russell Coker wrote:

<cut>

> I agree.  There's little downside nowadays.  Squid doesn't work particularly
> well caching APT repositories nowadays (strange timeouts and hangs during
> downloads) so the caching benefit of non-SSL has mostly gone away.

I have no problems with Squid caching apt repositories.
Squid can be made to act as a man in the middle, caching HTTPS, but this 
incompatible with DANE.


Regards,
Rob

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

#5314

[Multipart message — attachments visible in raw view] — view raw

Thank you for support, so is the https enabled repository coming up?

Marek

On 10/26/2017 08:19 PM, Christoph Biedl wrote:
> 林博仁 wrote...
> 
>> I believe that there's no benefit on accessing Debian archive with HTTPS as
>> they uses GnuPG for authentication
> 
> GnuPG indeed serves the purposes of authenticity and integrity very
> well. Modulo bugs every now and then, but they happen on other layers as
> well.
> 
> Also, nobody should rely on the privacy in this case since the server
> content is public and the clients have a fairly simple access pattern.
> Decoding the transfers from this isn't trival but seems doable with some
> effort - one day I'll write a prove of concept for this.
> 
> There is however a reason for https, a sad one though: Braindead
> "security" applicances that do deep packet inspection and might reject
> the download of packages.
> 
>     Christoph
> 

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

#5315

On Thu, Nov 9, 2017 at 5:57 PM, Marek Sebera wrote:

> Thank you for support, so is the https enabled repository coming up?

One of the CDNs backing deb.d.o supports https, see the last para here:

http://deb.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#5316

[Multipart message — attachments visible in raw view] — view raw

Thank you, this seems to work. Is this up-to-date repository or manually
synced mirror?

Also note I had to set (C=US, S=Arizona, L=Scottsdale, O="Starfield
Technologies, Inc.", CN=Starfield Services Root Certificate Authority -
G2) as trused in system certificates

Marek

On 11/09/2017 11:19 AM, Paul Wise wrote:
> On Thu, Nov 9, 2017 at 5:57 PM, Marek Sebera wrote:
> 
>> Thank you for support, so is the https enabled repository coming up?
> 
> One of the CDNs backing deb.d.o supports https, see the last para here:
> 
> http://deb.debian.org/
> 

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

#5317

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2017-11-09 at 11:30 +0100, Marek Sebera wrote:

> Is this up-to-date repository or manually synced mirror?

Neither, it is a pair of CDNs, hosted by Fastly and Amazon, although
only the Amazon CDN supports https.

> Also note I had to set ... as trused in system certificates

Normally it already would be.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#5291

On Thu, Oct 26, 2017 at 4:43 PM, Marek Sebera wrote:

> please advise, is there any repository, that is both official mirror of
> security.debian.org and enabled with SSL (HTTPS) access?

One of the CDNs backing deb.d.o supports https, see the last para here:

http://deb.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#5746

Nice query you have asked in this forum. Thanks for your information, this is
very good topic for those who get difficulties to access their https
redirect. Why not try this podcast addict which is a free download software
application for pc, mac or laptop. Try this and don't about your security
repository. Thanks you!



-----
https://tototechy.com/podcast-addict-for-pc-free-download-windows-7-8-10-mac/ 


--
Sent from: http://debian.2.n7.nabble.com/Debian-Security-f2050754.html

[toc] | [prev] | [standalone]

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

csiph-web