Re: HTTPS enabled Debian Security repository
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
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
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
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
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
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
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
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
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
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
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
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
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
林博仁 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
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
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
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