TL;DR: Any encrypted transport protocol (e.g. https) breaks caching.
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> This could be useful for both the "I've got a slow uplink and would like
> it to not be overwhelmed at the BSP I'm hosting for my Debian friends"
> type as well
On Sat, Aug 21, 2021 at 10:28:04AM +0200, Wouter Verhelst wrote:
> On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote:
> > On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> > > On 8/19/21 3:46 PM, Simon Richter wrote:
> > > > For the most part, users would configure https if
On Sat, Aug 21, 2021 at 11:05:23PM +, Stephan Verbücheln wrote:
> What about HTTP 304 Not Modified?
What about them? Care to give details?
Note that APT nowadays hardly makes requests which can legally be
replied to with 304 as it knows which index files changed (or not)
based on comparing
What about HTTP 304 Not Modified?
Regards
On 2021-08-21 12:04:32 +0100 (+0100), Phil Morrell wrote:
> On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
[...]
> > However, I've not been able to come up with a scheme which is simple
> > enough to be doable on a LAN while at the same time be usable by larger
> > network
On Sat, Aug 21, 2021 at 09:45:54AM +0200, Tomas Pospisek wrote:
> On 21.08.21 09:14, Philipp Kern wrote:
> > defense in depth if we wanted to, but maybe the world just agreed that
> > you need to get your clock roughly correct. ;-)
>
> I remember seeing apt-get refusing to update packages or the
On Sat, Aug 21, 2021 at 12:04:32PM +0100, Phil Morrell wrote:
> On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> > On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> > > Yes transparent proxies or overridden DNS lookups could be used to
> > > direct deb.debian.org
On 8/20/21 4:56 PM, Russ Allbery wrote:
> Jeremy Stanley writes:
>
>> I agree with all of the above, my point was that the current state of
>> HTTPS doesn't especially improve integrity for Debian package management
>> over the signed indices and checksums we already rely on, and trying to
>>
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> > Yes transparent proxies or overridden DNS lookups could be used to
> > direct deb.debian.org and security.debian.org to your alternative
> > location,
>
> I've
Wouter Verhelst writes:
> On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
>> Yes transparent proxies or overridden DNS lookups could be used to
>> direct deb.debian.org and security.debian.org to your alternative
>> location,
>
> I've been thinking for a while that we should bake
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> > Yes transparent proxies or overridden DNS lookups could be used to
> > direct deb.debian.org and security.debian.org to your alternative
> > location,
>
> I've
On Sat, Aug 21, 2021 at 12:31:26PM +0200, Simon Richter wrote:
> Hi,
>
> On 21.08.21 10:40, Wouter Verhelst wrote:
>
> > I've been thinking for a while that we should bake a feature in apt
> > whereby a network administrator can indicate somehow that there is a
> > local apt mirror and that apt
Hi,
On 21.08.21 10:40, Wouter Verhelst wrote:
I've been thinking for a while that we should bake a feature in apt
whereby a network administrator can indicate somehow that there is a
local apt mirror and that apt should use that one in preference to
deb.debian.org.
I've been thinking the
On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> Yes transparent proxies or overridden DNS lookups could be used to
> direct deb.debian.org and security.debian.org to your alternative
> location,
I've been thinking for a while that we should bake a feature in apt
whereby a
On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote:
> On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> > On 8/19/21 3:46 PM, Simon Richter wrote:
> > > For the most part, users would configure https if they are behind a
> > > corporate firewall that disallows http, or
On 21.08.21 09:14, Philipp Kern wrote:
On 20.08.21 21:11, Russ Allbery wrote:
The way I would put it is that the security benefit of using TLS for apt
updates is primarily that it makes certain classes of attempts to mess
with the update channel more noisy and more likely to produce immediate
Hi all,
Thanks for your comments!
It seems that no big blocker to make https default for deb.debian.org
and security.debian.org.
On Thu, 19 Aug 2021 22:38:20 +0900
Hideki Yamane wrote:
> Now deb.debian.org and security.debian.org provide https access
> but created sources.list file use
On 20.08.21 21:11, Russ Allbery wrote:
The way I would put it is that the security benefit of using TLS for apt
updates is primarily that it makes certain classes of attempts to mess
with the update channel more noisy and more likely to produce immediate
errors.
One thing of note is that it
On Sat, 21 Aug 2021, Vincent Lefevre wrote:
On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
The most naive attempt to mess with the update channel (intercepting the
http connection and replacing a package with a malicious one) will fail
immediately with both http or https. The primary
On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
> The most naive attempt to mess with the update channel (intercepting the
> http connection and replacing a package with a malicious one) will fail
> immediately with both http or https. The primary difference in that case
> with https is that
Ansgar writes:
> On Fri, 2021-08-20 at 23:37 +0200, Simon Richter wrote:
>> I was thinking of VPS hosting for the most part, where users will run
>> apt or auto-apt inside their virtual server.
> Hosting providers or ISPs messing with their customers' traffic with
> Debian mirrors seems like
On Fri, 2021-08-20 at 23:37 +0200, Simon Richter wrote:
> I was thinking of VPS hosting for the most part, where users will run
> apt or auto-apt inside their virtual server.
Hosting providers or ISPs messing with their customers' traffic with
Debian mirrors seems like something we should not
Hi,
On 8/20/21 9:04 PM, Russ Allbery wrote:
One of the things that confuses me about this user story is why are your
containers doing non-trivial amounts of apt traffic at runtime? Generally
the whole point of a container is that you only do this during container
build time. I'm not sure I
On Fri, 2021-08-20 at 12:11 -0700, Russ Allbery wrote:
> The way I would put it is that the security benefit of using TLS for apt
> updates is primarily that it makes certain classes of attempts to mess
> with the update channel more noisy and more likely to produce immediate
> errors.
APT is not
Quoting Jeremy Stanley (2021-08-20 18:34:22)
> > If so, I think the next step would be to open a bug with a summary of this
> > discussion. I'm happy to do that, but I'm not sure what package owns this
> > configuration.
> It's not owned directly by a particular package, I think D-I and various
>
On 2021-08-20 12:04:02 -0700 (-0700), Russ Allbery wrote:
> Simon Richter writes:
>
> > I support that idea in principle, but one of our user stories is
> > "I have a datacenter with a few thousand containers in it, so I
> > want to redirect accesses to the local mirror to reduce external
> >
Paul Gevers writes:
> I was told and I relayed early in this thread [1] that https gives you
> some (delayed) protection against man-in-the-middle attacks serving you
> old data.
Yes, it gives you some protection. Jeremy is more cynical about the
utility of that protection than I am, although
Simon Richter writes:
> I support that idea in principle, but one of our user stories is "I have
> a datacenter with a few thousand containers in it, so I want to redirect
> accesses to the local mirror to reduce external network traffic."
Just checking that I understand. You have several
On 2021-08-20 20:52:43 +0200 (+0200), Paul Gevers wrote:
[...]
> I was told and I relayed early in this thread [1] that https gives you
> some (delayed) protection against man-in-the-middle attacks serving you
> old data. Does everybody agree that this is either not prevented or not
> giving you
Hi,
On 20-08-2021 17:48, Russ Allbery wrote:
> It sounds like we have a general consensus in this thread that, while
> changing our default to HTTPS probably won't make anything more secure in
> practice, we should still do it?
I was told and I relayed early in this thread [1] that https gives
On 8/20/21 2:37 PM, Simon Richter wrote:
This is a use case where HTTPS does hurt, and where I can't think of
any good mitigation strategies that wouldn't be worse from a security
PoV than the status quo.
Such situations are the exception rather than the norm. If https is
detrimental to
Hi,
"Use HTTPS everywhere that supports it" is simple and actionable advice
for the average person that will make them more secure.
There are
applications and sites where HTTPS doesn't really help, but other than
some unusual performance edge cases that are pretty rare in practice, it
On 2021-08-20 08:48:11 -0700 (-0700), Russ Allbery wrote:
[...]
> It sounds like we have a general consensus in this thread that,
> while changing our default to HTTPS probably won't make anything
> more secure in practice, we should still do it?
Coincident with any default change, it would
Jeremy Stanley writes:
> Yes, this is a much nicer way of rephrasing it, but basically still what
> I said. Turning on HTTPS by default wouldn't be addressing any
> particular user risk, it would simply keep everyone from having to
> discuss and explain it ad nauseum. Much like replacing older
On 2021-08-20 07:56:33 -0700 (-0700), Russ Allbery wrote:
[...]
> Do you think using HTTPS makes security worse?
[...]
No, obviously not, except insofar that instilling a false sense of
security can be harmful in the long term because it excuses people
from thinking about the actual problems
On 8/20/21 10:56 AM, Russ Allbery wrote:
Do you think using HTTPS makes security worse?
No idea whether I qualify as a "security expert" but as someone who has
spent a fair amount of time working in security, my concern is making
advice simple enough for people to follow. Complicated,
Jeremy Stanley writes:
> I agree with all of the above, my point was that the current state of
> HTTPS doesn't especially improve integrity for Debian package management
> over the signed indices and checksums we already rely on, and trying to
> use HTTPS for privacy/secrecy (which isn't really
On 2021-08-20 11:36:41 +0200 (+0200), Bjørn Mork wrote:
> Jeremy Stanley writes:
>
> > While this does complicate it, a snooping party can still know the
> > site they're connecting to via SNI happening unencrypted,
>
> I believe this can be fixed with TLS 1.3?
>
> > and packet sizes/pacing
Jeremy Stanley writes:
> While this does complicate it, a snooping party can still know the
> site they're connecting to via SNI happening unencrypted,
I believe this can be fixed with TLS 1.3?
> and packet sizes/pacing likely give away which pages or files are
> being retrieved based on their
On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> On 8/19/21 3:46 PM, Simon Richter wrote:
> > For the most part, users would configure https if they are behind a
> > corporate firewall that disallows http, or modifies data in-flight so
> > signature verification fails, everyone else is
On 8/19/21 3:46 PM, Simon Richter wrote:
For the most part, users would configure https if they are behind a
corporate firewall that disallows http, or modifies data in-flight so
signature verification fails, everyone else is better off using plain
http.
Or they might configure https on the
On 19.08.21 21:48, Paul Gevers wrote:
On 19-08-2021 21:46, Simon Richter wrote:
For the most part, users would configure https if they are behind a
corporate firewall that disallows http, or modifies data in-flight so
signature verification fails, everyone else is better off using plain http.
Hi,
On 19-08-2021 21:46, Simon Richter wrote:
> For the most part, users would configure https if they are behind a
> corporate firewall that disallows http, or modifies data in-flight so
> signature verification fails, everyone else is better off using plain http.
Except for the security
Hi,
On 8/19/21 3:38 PM, Hideki Yamane wrote:
Now deb.debian.org and security.debian.org provide https access
but created sources.list file use http for those. Is there any
reason to use http instead of https for them? (traffic, policy,
etc...) If not, how about to change it?
There is
Is there any way to estimate what proportion of clients are behind a
proxy? security.debian.org in particular could possibly see a lot more
traffic when there are things like kernel updates.
(Clearly it's not possible to determine how many clients a caching proxy
might be serving)
Are there any
Hi,
Now deb.debian.org and security.debian.org provide https access
but created sources.list file use http for those. Is there any
reason to use http instead of https for them? (traffic, policy,
etc...) If not, how about to change it?
--
Hideki Yamane
46 matches
Mail list logo
