On Fri, 11 Nov 2016, Christoph Biedl wrote:
> a proof of concept for all this (I can resist, though). The apt programs
> could obfuscate their request behaviour, the TLS layer could add random
> padding of data and time, but I doubt this would help much.
AFAIK, the TLS layer *does* bit-stuffing an
Henrique de Moraes Holschuh wrote...
> There are some relevant issues, here.
>
> 1. It does protect against passive snooping *from non-skilled
> attackers*.
Well, yes, no. The tools become better so thinking a few years into
the future sophisticated programs for that purpose might be available t
On Thu, Nov 10, 2016 at 12:39:40PM -0200, Henrique de Moraes Holschuh wrote:
> I'd prefer if we enhanced apt transports to run a lot more protected
> (preferably under seccomp strict) before any such push for enabling
> https transports in apt. It would reduce the security impact a great
> deal.
On Mon, Oct 24, 2016, at 00:28, Russ Allbery wrote:
> The value of HTTPS lies in its protection against passive snooping.
There are some relevant issues, here.
1. It does protect against passive snooping *from non-skilled
attackers*. And this is not being made anywhere clear enough.
2. It is u
On Sun, Nov 06, 2016 at 12:03:03AM +0100, Philipp Kern wrote:
> On 2016-11-05 22:23, Adrian Bunk wrote:
> > The solution you are trying to sell is apt-transport-https as default.
> [...]
> > Your solution would be a lot of work with relatively little improvement.
>
> Well, the client-side exists a
On 2016-11-05 22:23, Adrian Bunk wrote:
The solution you are trying to sell is apt-transport-https as default.
[...]
Your solution would be a lot of work with relatively little
improvement.
Well, the client-side exists and works. Then it boils down if the mirror
sponsors would be willing to
On Tue, Oct 25, 2016 at 11:06:23AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> So, I'm not quite sure how to put this, since I don't know how much work
> you've done professionally in computer security, and I don't want to
> belittle that. It's entirely possible that we have equivalen
Adrian Bunk writes:
> If I were looking at the apt traffic, the most interesting for me would
> be the traffic to security.debian.org that a computer running Debian
> stable usually produces.
> Just collecting the data when and how much HTTPS traffic is happening
> should be sufficient to deter
On Tue, 25 Oct 2016, Ian Jackson wrote:
> Adrian Bunk writes ("Re: client-side signature checking of Debian archives
> (Re: When should we https our mirrors?)"):
> > snake oil
> > snake oil
>
> The phrase "snake oil" is very insulting. I have asked y
Adrian Bunk writes ("Re: client-side signature checking of Debian archives (Re:
When should we https our mirrors?)"):
> snake oil
> snake oil
The phrase "snake oil" is very insulting. I have asked you several
times to to stop.
Publicly CCing listmaster this ti
On Mon, Oct 24, 2016 at 04:33:57PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> > I would assume this can be pretty automated, and that by NSA standards
> > this is not a hard problem.
>
> Since the entire exchange is encrypted, it's not completely trivial to map
> size of data transfe
Paul Wise writes:
> Debian has Tor onion service frontends to various Debian services,
> including several Debian machines with archive mirrors, this is
> implemented in an automated way using Puppet and onionbalance. So we do
> not rely on Tor exit nodes, just relays and the onion service system
On Tue, Oct 25, 2016 at 7:33 AM, Russ Allbery wrote:
> Tor is easier for us as a project, since we don't really have to do
> anything (assuming we just rely on existing exit nodes).
Debian has Tor onion service frontends to various Debian services,
including several Debian machines with archive m
Adrian Bunk writes:
> The government operating or having access to the mirror you are using is
> a lot more realistic and easier than the MITM with a fake certificate
> you were talking about.
Both of those were also in the category of things that I think are
unlikely attacks unless the governme
On Mon, Oct 24, 2016 at 09:22:39AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>
> >>...
> >> The value of HTTPS lies in its protection against passive snooping. Given
> >> the sad state of the public CA infrastructure, you c
Hi Kristian,
To one of your side questions,
On 24.10.2016 02:33, Kristian Erik Hermansen wrote:
>> 1) Checking chain (e.g. gpgv and its callers) have bugs. True, same as
>> checking layer for secure transports also have bugs.
>
> Agreed. Please let me know of a good test case to validate that y
Adrian Bunk writes:
> On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>>...
>> The value of HTTPS lies in its protection against passive snooping. Given
>> the sad state of the public CA infrastructure, you cannot really protect
>> against active MITM with HTTPS without certificate
(Disclaimer: I am a maintainer of apt-transport-tor… but also of
-https and apt itself, so I am biased beyond hope in this matter)
On Sun, Oct 23, 2016 at 07:20:35PM -0700, Russ Allbery wrote:
> Paul Wise writes:
> > On Mon, Oct 24, 2016 at 7:21 AM, Kristian Erik Hermansen wrote:
> >> The point i
On Mon, Oct 24, 2016 at 2:33 AM, Adrian Bunk wrote:
> You are implicitely assuming that mirrors can be trusted,
> and even that is not true.
No, not actually. Just presuming that NSA doesn't operate ALL mirrors.
Of course they can operate single servers or a number of servers, but
that increases
On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>...
> The value of HTTPS lies in its protection against passive snooping. Given
> the sad state of the public CA infrastructure, you cannot really protect
> against active MITM with HTTPS without certificate pinning.
You are implicite
Hi Russ, Kristian,
On 24.10.2016 07:19, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery wrote:
>> The idea is to *add* HTTPS protection on top of the protections we already
>> have. You're correct that it doesn't give you authentication of the
>> packages without a
On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery wrote:
> The idea is to *add* HTTPS protection on top of the protections we already
> have. You're correct that it doesn't give you authentication of the
> packages without a bunch of work, and we should assume that the general
> public CA system is c
On Sun, Oct 23, 2016 at 6:46 PM, Paul Wise wrote:
> Better privacy than https can be had using Tor:
>
> https://onion.debian.org/
If Debian is open to improving SecureAPT's out of the box
configuration by utilizing Tor, then that is fine, but I highly doubt
Debian operators will enjoy the slownes
"Eugene V. Lyubimkin" writes:
> I'm not sure that benefits outweight the costs. HTTPS requires that I
> trust the third-parties -- mirror provider and CA. Gpgv doesn't require
> third parties.
It's critical here that we do not drop GPG. We continue using GPG for the
integrity and authenticatio
Paul Wise writes:
> On Mon, Oct 24, 2016 at 7:21 AM, Kristian Erik Hermansen wrote:
>> The point is to improve privacy.
> Better privacy than https can be had using Tor:
> https://onion.debian.org/
Yeah, but this is *way* harder than just using TLS. You get much of the
benefit by using TLS, a
On Mon, Oct 24, 2016 at 7:21 AM, Kristian Erik Hermansen wrote:
> The point is to improve privacy.
Better privacy than https can be had using Tor:
https://onion.debian.org/
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Sun, Oct 23, 2016 at 4:43 PM, Russ Allbery wrote:
> susceptible to traffic analysis. You can make some pretty good guesses
> from the size of the object downloaded, particularly if you can watch over
> time and see what happens when updated packages are released.
>
> Of course, it's much harde
On Sun, Oct 23, 2016 at 10:03 AM, Eugene V. Lyubimkin wrote:
> Thank you for the long list of examples what could go wrong. I'm happy I
> don't have urgent fixes to apply.
Well, I would say the privacy issues are rather concerning. Security
is generally broken down into at least the following th
Ivan Shmakov writes:
> My understanding is that the suggestion being discussed is to
> use TLS /alongside/ the usual Debian/APT signatures – not
> instead of them; and the primary goal is to improve user’s
> privacy. That is: only the mirror operator will remain
> e
On Sun, Oct 23, 2016 at 10:45 AM, Ivan Shmakov wrote:
> use TLS /alongside/ the usual Debian/APT signatures – not
> instead of them; and the primary goal is to improve user’s
> privacy. That is: only the mirror operator will remain
>
Exactly right. The point is to improve
> Eugene V Lyubimkin writes:
[…]
> I'm not sure that benefits outweigh the costs. HTTPS requires that
> I trust the third-parties – mirror provider and CA. Gpgv doesn't
> require third parties.
It does; you have to trust whatever source you’ve /initially/
got the public
Hi,
[ please don't CC me directly ]
On 23.10.2016 17:20, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin
> wrote:
>> I'm a developer of a tool which downloads and validates Debian archives
>> in a similar way APT does.
>>
>> As you use the word "theoretical
Hi :)
On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin wrote:
> I'm a developer of a tool which downloads and validates Debian archives
> in a similar way APT does.
>
> As you use the word "theoretically", that suggests that practically
> one can bypass the validation. Could you please list a
33 matches
Mail list logo
