Re: HTTPS enabled Debian Security repository

2020-01-16 Thread Tototechy
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



Re: HTTPS enabled Debian Security repository

2017-11-09 Thread Paul Wise
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


signature.asc
Description: This is a digitally signed message part


Re: HTTPS enabled Debian Security repository

2017-11-09 Thread Marek Sebera
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/
> 



signature.asc
Description: OpenPGP digital signature


Re: HTTPS enabled Debian Security repository

2017-11-09 Thread Paul Wise
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



Re: HTTPS enabled Debian Security repository

2017-11-09 Thread Marek Sebera
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
> 



signature.asc
Description: OpenPGP digital signature


Re: HTTPS enabled Debian Security repository

2017-10-30 Thread Rob van der Putten

Hi there


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




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



Re: HTTPS enabled Debian Security repository

2017-10-30 Thread Russell Coker
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 Bloghttp://doc.coker.com.au/



Re: HTTPS enabled Debian Security repository

2017-10-30 Thread Hans-Christoph Steiner


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



Re: HTTPS enabled Debian Security repository

2017-10-28 Thread 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).

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



Re: HTTPS enabled Debian Security repository

2017-10-27 Thread Henrique de Moraes Holschuh
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



Re: HTTPS enabled Debian Security repository

2017-10-27 Thread Luca Filipozzi
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



Re: HTTPS enabled Debian Security repository

2017-10-27 Thread Morris Taylor
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
> 



Re: HTTPS enabled Debian Security repository

2017-10-27 Thread Hans-Christoph Steiner


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



Re: HTTPS enabled Debian Security repository

2017-10-26 Thread 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


signature.asc
Description: Digital signature


Re: HTTPS enabled Debian Security repository

2017-10-26 Thread Paul Wise
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



Re: HTTPS enabled Debian Security repository

2017-10-26 Thread 林博仁
I believe that there's no benefit on accessing Debian archive with HTTPS as
they uses GnuPG for authentication

林博仁 


2017-10-26 16:43 GMT+08:00 Marek Sebera :

> 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.3466IN  A   212.211.132.32
> security.debian.org.3466IN  A   212.211.132.250
> security.debian.org.3466IN  A   195.20.242.89
> security.debian.org.3466IN  A   217.196.149.233
>
> Thank you
> Best Regards
> Marek Sebera
>
>
>


HTTPS enabled Debian Security repository

2017-10-26 Thread Marek Sebera
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.3466IN  A   212.211.132.32
security.debian.org.3466IN  A   212.211.132.250
security.debian.org.3466IN  A   195.20.242.89
security.debian.org.3466IN  A   217.196.149.233

Thank you
Best Regards
Marek Sebera




signature.asc
Description: OpenPGP digital signature