Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On 07/03/2014 02:26 PM, Bernhard R. Link wrote:
> * Hans-Christoph Steiner  [140703 18:10]:
>> You are correct that HTTPS would not entirely address #2, but it does
>> improve the situation over HTTP.  For example, an ISP, network operator,
>> or government could block an entire mirror or all mirrors by redirecting
>> requests to their own mirror which does not get updates.  That would be
>> transparent to the user.
> 
> - An ISP could just offer to host a mirror, thus getting the certificates
>   for free. All you could avoid is getting in the way of someone willfully
>   wasting bandwith by using a specific far away mirror.
> - A goverment could likely just do the same, but with any
>   certificates/private keys of any mirrors near you.

Yes, there are definitely still possible attacks, even when using HTTPS+Tor
onion address. I never said what I propose is perfect, just a large improvement.


> - It is only "Transparent" in a very abstract sense of the word. People
>   know what security updates there are. Sending outdated stuff to many
>   people is hard to hide. So you need a targeted attack, which would
>   even cause more suspicion if someone realizes it.
>   If someone updates the packages manually detection chances are
>   astronomically high. If things are updated manually then a targeted
>   attack might as well block the traffic and also block the mails
>   going out about the automated update failing.

In cases like the Great Firewall of China, they do country-wide things like
this.  They are quite good at blocking Tor all over China, for example.  The
vast majority of Debian/Ubuntu/etc. users only know there are updates because
apt tells them so.


> And then there is still the massive negative aspect of using https,
> which any positive aspects have to trumph: If using https, people might
> actually think they can just use a browser or the like to download
> things and get a validated file. Which of course it is not, as so many
> people can trivially inject something. An false feeling of having
> security can be much worse than anything else often.
> 
>   Bernhard R. Link

Yes, HTTPS should not be promoted as the thing that keeps the packages secure.
 That is the GPG signature.  HTTPS mostly serves to obscure the traffic
details from network observers.  Many people think nothing of downloading and
installing random software from an HTTP connection, so the bar is not
currently very high.

And there happens to be some concrete data on why this is important, it turns
out that NSA/Five Eyes attempts to track everyone who lives outside the USA
who searches for or downloads Tor:

https://arstechnica.com/tech-policy/2014/07/report-rare-leaked-nsa-source-code-reveals-tor-servers-targeted/



.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b5b4f3.2030...@at.or.at

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On 07/03/2014 03:08 PM, Michael Stone wrote:
> On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote:
>> Google uses SPKI pinning heavily, for example,
>> but they still use CA-signed certificates so their HTTPS works with Firefox,
>> IE, Opera, etc.
> 
> Yes, and MS does similar. The difference is, they own their infrastructure and
> debian relies on donations. It's a lot harder for debian to control the
> certificates on third party machines than it is for a big company to control
> the certificates on its own machines.
> 
> Mike Stone

This is true.  But Debian owns apt, and apt is the key piece of software that
has to talk this encrypted protocol.  It would be nice if it worked in the
browser, but that is far from a requirement.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b5b070.1060...@at.or.at

Re: Debian mirrors and MITM

[Michael Stone]

On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote:

Google uses SPKI pinning heavily, for example,
but they still use CA-signed certificates so their HTTPS works with Firefox,
IE, Opera, etc.


Yes, and MS does similar. The difference is, they own their 
infrastructure and debian relies on donations. It's a lot harder for 
debian to control the certificates on third party machines than it is 
for a big company to control the certificates on its own machines.


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/44a67e28-02e5-11e4-943d-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Bernhard R. Link]

* Hans-Christoph Steiner  [140703 18:10]:
> You are correct that HTTPS would not entirely address #2, but it does
> improve the situation over HTTP.  For example, an ISP, network operator,
> or government could block an entire mirror or all mirrors by redirecting
> requests to their own mirror which does not get updates.  That would be
> transparent to the user.

- An ISP could just offer to host a mirror, thus getting the certificates
  for free. All you could avoid is getting in the way of someone willfully
  wasting bandwith by using a specific far away mirror.
- A goverment could likely just do the same, but with any
  certificates/private keys of any mirrors near you.
- It is only "Transparent" in a very abstract sense of the word. People
  know what security updates there are. Sending outdated stuff to many
  people is hard to hide. So you need a targeted attack, which would
  even cause more suspicion if someone realizes it.
  If someone updates the packages manually detection chances are
  astronomically high. If things are updated manually then a targeted
  attack might as well block the traffic and also block the mails
  going out about the automated update failing.

And then there is still the massive negative aspect of using https,
which any positive aspects have to trumph: If using https, people might
actually think they can just use a browser or the like to download
things and get a validated file. Which of course it is not, as so many
people can trivially inject something. An false feeling of having
security can be much worse than anything else often.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140703182620.ga2...@client.brlink.eu

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On 07/03/2014 12:58 PM, Reid Sutherland wrote:
> 
> On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner  wrote:
>>
>> SSH uses entirely unsigned keys, and it has proven a lot more reliable than
>> HTTPS/TLS.  You use HTTPS/TLS keys the same way as SSH, but TLS requires
>> signed keys, self-signed works.  The signatures are only worth the trust path
>> behind them, and CAs have not proven to be reliable trust paths.  So if you
>> can't rely on the signatures, why bother using them?  This is not just my
>> opinion, but of many others.  Google uses SPKI pinning heavily, for example,
>> but they still use CA-signed certificates so their HTTPS works with Firefox,
>> IE, Opera, etc.
>>
> 
> SSH is hand verified when you connect initially (thus creating a “signature”).

That is not a crypto signature like on a TLS certificate or OpenPGP key.  But
I guess you could call writing the public key to ~/.ssh/known_hosts a
signature of sorts.


> Are you are going to hand-verify each signature / key?  And then against 
> what?  Why not just verify the CD download once and be done with it?  If you 
> are paranoid, build a trust relationship with a mirror that provides SSL and 
> save their cert.
> 
> Anyway, I’m really over this.
> 
> Have a good day.
> 

I suggest you read the links that I included, they discuss these questions and
more.  Pinning means that the SPKI comes included in the software, like in the
iso that you mention.  In SSH speak, that would be like distributing an SSH
known_hosts file along with the iso.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b58d10.1070...@at.or.at

Re: Debian mirrors and MITM

[Reid Sutherland]

On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner  wrote:
> 
> SSH uses entirely unsigned keys, and it has proven a lot more reliable than
> HTTPS/TLS.  You use HTTPS/TLS keys the same way as SSH, but TLS requires
> signed keys, self-signed works.  The signatures are only worth the trust path
> behind them, and CAs have not proven to be reliable trust paths.  So if you
> can't rely on the signatures, why bother using them?  This is not just my
> opinion, but of many others.  Google uses SPKI pinning heavily, for example,
> but they still use CA-signed certificates so their HTTPS works with Firefox,
> IE, Opera, etc.
> 

SSH is hand verified when you connect initially (thus creating a “signature”).

Are you are going to hand-verify each signature / key?  And then against what?  
Why not just verify the CD download once and be done with it?  If you are 
paranoid, build a trust relationship with a mirror that provides SSL and save 
their cert.

Anyway, I’m really over this.

Have a good day.


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3d3dc714-4833-47c3-89aa-d42b14d22...@vianet.ca

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On 07/03/2014 12:38 PM, Reid Sutherland wrote:
> On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner  wrote:
>> As for how to manage making HTTPS by default, this does not require every 
>> mirror buying HTTPS certificates every year from Certificate Authorities.  
>> There are workable solutions based on self-signed certificates.
>>
>> In Android apps, there are two approaches that are gaining traction: 
>> including certificate pins based on the Subject Public Key Info (SPKI) in an 
>> apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html).  
>> And using "Trust On First Use/Persistence of Pseudonym" aka "Memorizing 
>> Trust Manager" (https://github.com/ge0rg/MemorizingTrustManager) to do 
>> ssh-style trust with a yes/no prompt the first time.  These can also be 
>> optionally combined with the classic Certificate Authority, to provide a 
>> redundant check.
>>
>> We've been thinking about to make this workable, here are some notes:
>> https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification
>>
>> Or there could be a password-based CA-replacement like http://tack.io
> 
> 
> Self-signed?  Really?
> 
> This is full of issues.  Just because someone spends time on an idea, doesn’t 
> mean it’s a good one.

SSH uses entirely unsigned keys, and it has proven a lot more reliable than
HTTPS/TLS.  You use HTTPS/TLS keys the same way as SSH, but TLS requires
signed keys, self-signed works.  The signatures are only worth the trust path
behind them, and CAs have not proven to be reliable trust paths.  So if you
can't rely on the signatures, why bother using them?  This is not just my
opinion, but of many others.  Google uses SPKI pinning heavily, for example,
but they still use CA-signed certificates so their HTTPS works with Firefox,
IE, Opera, etc.


> But this does trigger another idea; Debian could create their own CA for 
> managing the project’s SSL infrastructure.  Then we would just need to trust 
> the Debian CA.

That is also an option.  That could also be done in parallel with what I 
proposed.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b588f5.7060...@at.or.at

Re: Debian mirrors and MITM

[Reid Sutherland]

On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner  wrote:
> As for how to manage making HTTPS by default, this does not require every 
> mirror buying HTTPS certificates every year from Certificate Authorities.  
> There are workable solutions based on self-signed certificates.
> 
> In Android apps, there are two approaches that are gaining traction: 
> including certificate pins based on the Subject Public Key Info (SPKI) in an 
> apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html).  And 
> using "Trust On First Use/Persistence of Pseudonym" aka "Memorizing Trust 
> Manager" (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style 
> trust with a yes/no prompt the first time.  These can also be optionally 
> combined with the classic Certificate Authority, to provide a redundant check.
> 
> We've been thinking about to make this workable, here are some notes:
> https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification
> 
> Or there could be a password-based CA-replacement like http://tack.io


Self-signed?  Really?

This is full of issues.  Just because someone spends time on an idea, doesn’t 
mean it’s a good one.

But this does trigger another idea; Debian could create their own CA for 
managing the project’s SSL infrastructure.  Then we would just need to trust 
the Debian CA.

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8eb7df12-c21b-4a86-a71e-79f4dc0e4...@vianet.ca

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On Jul 3, 2014, at 12:10 PM, Hans-Christoph Steiner wrote:

> 
> On Jul 3, 2014, at 11:52 AM, Michael Stone wrote:
> 
>> On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote:
>>> I definitely agree there are legitimate concerns that using HTTPS on apt 
>>> mirrors would help, and people who suggest otherwise are out of date on 
>>> what the threats are.  I think the integrity of the package itself is not 
>>> reason enough to use HTTPS since the GPG signing is much more reliable for 
>>> that task.  I break it down into 4
>>> 
>>> 1. package authenticity
>>> (software can be modified while being downloaded)
>>> 
>>> 2. repo availability
>>> (internet services can be blocked by governments and companies)
>>> 
>>> 3. package availability
>>> (software security updates can be individually blocked)
>>> 
>>> 4. who’s downloading what package (currently visible to anyone who can see 
>>> the network traffic, including open wifi, etc.)
>>> 
>>> 
>>> The current apt model covers #1 well, but only covers #2 and #3 with a two 
>>> week window (the expiration date on the repo metadata).  And it does not 
>>> cover #4 at all.
>> 
>> HTTPS won't address #1 completely in the presence of mirrors, and debian 
>> doens't have the resources to serve all users without mirrors. It will not 
>> address #2. It may address #3, but less reliably than the current siutation. 
>> It may make #4 harder for certain scenarios, but not others (traffic 
>> analysis of specific host).
>> 
>> Something like tor will be a better solution for #2, & #4 while the current 
>> system provides #1 & #3. (And also provides #2 for all practical purposes, 
>> given the length of the mirror list.)
>> 
>> Mike Stone
> 
> You are correct that HTTPS would not entirely address #2, but it does improve 
> the situation over HTTP.  For example, an ISP, network operator, or 
> government could block an entire mirror or all mirrors by redirecting 
> requests to their own mirror which does not get updates.  That would be 
> transparent to the user.  This would make for a two week block on all updates 
> (until the repo data expires).  Using Using HTTPS and/or Tor with an onion 
> address makes that a lot more difficult to do.  Just connecting to an HTTP 
> mirror via Tor would not prevent this.
> 
> But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to 
> the mirrors are blocked.
> 
> .hc


As for how to manage making HTTPS by default, this does not require every 
mirror buying HTTPS certificates every year from Certificate Authorities.  
There are workable solutions based on self-signed certificates.

In Android apps, there are two approaches that are gaining traction: including 
certificate pins based on the Subject Public Key Info (SPKI) in an apt in 
advance (https://www.imperialviolet.org/2011/05/04/pinning.html).  And using 
"Trust On First Use/Persistence of Pseudonym" aka "Memorizing Trust Manager" 
(https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a 
yes/no prompt the first time.  These can also be optionally combined with the 
classic Certificate Authority, to provide a redundant check.

We've been thinking about to make this workable, here are some notes:
https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification

Or there could be a password-based CA-replacement like http://tack.io

.hc




--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/cd4e3945-532a-4dad-9cfa-4742dfdcf...@at.or.at

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On Jul 3, 2014, at 11:52 AM, Michael Stone wrote:

> On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote:
>> I definitely agree there are legitimate concerns that using HTTPS on apt 
>> mirrors would help, and people who suggest otherwise are out of date on what 
>> the threats are.  I think the integrity of the package itself is not reason 
>> enough to use HTTPS since the GPG signing is much more reliable for that 
>> task.  I break it down into 4
>> 
>> 1. package authenticity
>> (software can be modified while being downloaded)
>> 
>> 2. repo availability
>> (internet services can be blocked by governments and companies)
>> 
>> 3. package availability
>> (software security updates can be individually blocked)
>> 
>> 4. who’s downloading what package (currently visible to anyone who can see 
>> the network traffic, including open wifi, etc.)
>> 
>> 
>> The current apt model covers #1 well, but only covers #2 and #3 with a two 
>> week window (the expiration date on the repo metadata).  And it does not 
>> cover #4 at all.
> 
> HTTPS won't address #1 completely in the presence of mirrors, and debian 
> doens't have the resources to serve all users without mirrors. It will not 
> address #2. It may address #3, but less reliably than the current siutation. 
> It may make #4 harder for certain scenarios, but not others (traffic analysis 
> of specific host).
> 
> Something like tor will be a better solution for #2, & #4 while the current 
> system provides #1 & #3. (And also provides #2 for all practical purposes, 
> given the length of the mirror list.)
> 
> Mike Stone

You are correct that HTTPS would not entirely address #2, but it does improve 
the situation over HTTP.  For example, an ISP, network operator, or government 
could block an entire mirror or all mirrors by redirecting requests to their 
own mirror which does not get updates.  That would be transparent to the user.  
This would make for a two week block on all updates (until the repo data 
expires).  Using Using HTTPS and/or Tor with an onion address makes that a lot 
more difficult to do.  Just connecting to an HTTP mirror via Tor would not 
prevent this.

But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to 
the mirrors are blocked.

.hc

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/f3c70ec9-e2e9-48ca-87d9-7ce3f8296...@at.or.at

Re: Debian mirrors and MITM

[micah]

Hans-Christoph Steiner  writes:

> I should add: apt-transport-tor is a great project to improve this situation 
> as well that is probably more secure than HTTPS, but at a cost of probably 
> much slower download speeds.  Using an apt mirror with an onion address would 
> entirely supplant HTTPS.
>
> So don't get me wrong, I don't think HTTPS is a great system, what I'm saying 
> is that the current state of apt mirrors (HTTP and GPG signing) is not 
> enough.  HTTPS can help, especially when used with some kind of 
> certificate/SPKI pinning.  Tor can help too, especially when used with onion 
> addresses.

Are there any mirrors with a hidden service onion address? If so, I
would like to know where!

Are there any mirror operators out there who might be interested in
adding a tor hidden service, but don't know how? If so, contact me, I'd
be happy to help you set it up.

micah


pgpWPzlVCRj4v.pgp
Description: PGP signature

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On Jul 3, 2014, at 11:55 AM, Reid Sutherland wrote:

> On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner  wrote:
> 
>> 
>> On Jun 2, 2014, at 9:29 AM, Jann Horn wrote:
>> 
>>> On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote:
 Now I don't want to call into question the esteemed authors of said
 program, and depending libraries, but I do think that providing https
 mirrors gives us two distinct advantages over plain http:
 
  . in the case that there is a bug in apt, or gpg, or something
  else, having https would provide at minimum a minor set of
  defense against bulk, non-targeted quantum insert and foxacid
  attacks, not to mention MiTM compromises from a hostile local
  network
>>> 
>>> Heh. Because SSL/TLS libraries are so impenetrable and secure? :D
>> 
>> Even GnuPG has had exploitable bugs.  Adding layers of different security 
>> techniques can help make the apt distribution system less fragile when such 
>> bugs inevitably arise.
>> 
> 
> 
> Adding another layer of code does not always improve security.  Using the 
> argument of bugs, what happens when your vulnerable SSL clients connects to a 
> malicious mirror?
> 
> You suggest that GnuPG could have security flaws, but you promote software 
> line that has already demonstrated numerous security problems.
> 
> On a side, SSL is already available in apt, anyone is free to implement SSL 
> on their mirror server and use it in their apt client.  If you need to secure 
> the initial installation download use the verification information found here 
> .

The point is to figure out a better way that is included by default.  

.hc

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/995ae110-08f9-47ff-9072-ade90c0bd...@at.or.at

Re: Debian mirrors and MITM

[Reid Sutherland]

On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner  wrote:

> 
> On Jun 2, 2014, at 9:29 AM, Jann Horn wrote:
> 
>> On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote:
>>> Now I don't want to call into question the esteemed authors of said
>>> program, and depending libraries, but I do think that providing https
>>> mirrors gives us two distinct advantages over plain http:
>>> 
>>>   . in the case that there is a bug in apt, or gpg, or something
>>>   else, having https would provide at minimum a minor set of
>>>   defense against bulk, non-targeted quantum insert and foxacid
>>>   attacks, not to mention MiTM compromises from a hostile local
>>>   network
>> 
>> Heh. Because SSL/TLS libraries are so impenetrable and secure? :D
> 
> Even GnuPG has had exploitable bugs.  Adding layers of different security 
> techniques can help make the apt distribution system less fragile when such 
> bugs inevitably arise.
> 


Adding another layer of code does not always improve security.  Using the 
argument of bugs, what happens when your vulnerable SSL clients connects to a 
malicious mirror?

You suggest that GnuPG could have security flaws, but you promote software line 
that has already demonstrated numerous security problems.

On a side, SSL is already available in apt, anyone is free to implement SSL on 
their mirror server and use it in their apt client.  If you need to secure the 
initial installation download use the verification information found here 
.


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/edd089f0-30e2-4946-8276-d3fa45696...@vianet.ca

Re: Debian mirrors and MITM

[Michael Stone]

On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote:

I definitely agree there are legitimate concerns that using HTTPS on apt 
mirrors would help, and people who suggest otherwise are out of date on what 
the threats are.  I think the integrity of the package itself is not reason 
enough to use HTTPS since the GPG signing is much more reliable for that task.  
I break it down into 4

1. package authenticity
(software can be modified while being downloaded)

2. repo availability
(internet services can be blocked by governments and companies)

3. package availability
(software security updates can be individually blocked)

4. who’s downloading what package (currently visible to anyone who can see the 
network traffic, including open wifi, etc.)


The current apt model covers #1 well, but only covers #2 and #3 with a two week 
window (the expiration date on the repo metadata).  And it does not cover #4 at 
all.


HTTPS won't address #1 completely in the presence of mirrors, and debian 
doens't have the resources to serve all users without mirrors. It will 
not address #2. It may address #3, but less reliably than the current 
siutation. It may make #4 harder for certain scenarios, but not others 
(traffic analysis of specific host).


Something like tor will be a better solution for #2, & #4 while the 
current system provides #1 & #3. (And also provides #2 for all practical 
purposes, given the length of the mirror list.)


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/e4cb4f22-02c8-11e4-904c-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On Jul 3, 2014, at 11:05 AM, Hans-Christoph Steiner wrote:

> 
> On May 30, 2014, at 10:06 AM, micah anderson wrote:
> 
>> Kurt Roeckx  writes:
>> 
>>> On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
 On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
> On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
>> The public Debian mirrors seem like an obvious target for governments to
>> MITM. I know that the MD5s are also published, but unless you're
>> verifying them with third parties, what's stopping the MD5s being
>> compromised too?
> 
> The cryptographic signatures that are validated automatically by apt. 
 
 What's stopping the attacker from serving a compromised apt?
>>> 
>>> apt will check that the new apt is properly signed.
>> 
>> This entire secure artifice depends entirely on the integrity of
>> apt, and presumably the various libraries that it depends on.
>> 
>> Now I don't want to call into question the esteemed authors of said
>> program, and depending libraries, but I do think that providing https
>> mirrors gives us two distinct advantages over plain http:
>> 
>>   . in the case that there is a bug in apt, or gpg, or something
>>   else, having https would provide at minimum a minor set of
>>   defense against bulk, non-targeted quantum insert and foxacid
>>   attacks, not to mention MiTM compromises from a hostile local
>>   network
>> 
>>   . keeps an adversary who may be listening on the wire from
>>   looking at what you are installing. who cares what you are
>>   installing? well it turns out that is very interesting
>>   information. If you can see that I've just installed X package,
>>   and you then just look over at our security tracker and find
>>   that this package has an exploit...
>> 
>> micah
> 
> I definitely agree there are legitimate concerns that using HTTPS on apt 
> mirrors would help, and people who suggest otherwise are out of date on what 
> the threats are.  I think the integrity of the package itself is not reason 
> enough to use HTTPS since the GPG signing is much more reliable for that 
> task.  I break it down into 4 
> 
> 1. package authenticity
> (software can be modified while being downloaded)
> 
> 2. repo availability
> (internet services can be blocked by governments and companies)
> 
> 3. package availability
> (software security updates can be individually blocked)
> 
> 4. who’s downloading what package (currently visible to anyone who can see 
> the network traffic, including open wifi, etc.)
> 
> 
> The current apt model covers #1 well, but only covers #2 and #3 with a two 
> week window (the expiration date on the repo metadata).  And it does not 
> cover #4 at all.
> 
> Using HTTPS for apt repos is a simple way to improve the security of all 4.  
> It adds a weak backup security layer for #1, it makes it much more difficult 
> for the attacker to do #2, #3, and #4.
> 
> For those who want to find HTTPS mirrors, try my script here:
> https://guardianproject.info/2013/10/31/issues-when-distributing-software/
> 
> .hc

I should add: apt-transport-tor is a great project to improve this situation as 
well that is probably more secure than HTTPS, but at a cost of probably much 
slower download speeds.  Using an apt mirror with an onion address would 
entirely supplant HTTPS.

So don't get me wrong, I don't think HTTPS is a great system, what I'm saying 
is that the current state of apt mirrors (HTTP and GPG signing) is not enough.  
HTTPS can help, especially when used with some kind of certificate/SPKI 
pinning.  Tor can help too, especially when used with onion addresses.

.hc

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/578d5f80-c054-4d04-b1cd-39cebef3a...@at.or.at

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On Jun 2, 2014, at 9:29 AM, Jann Horn wrote:

> On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote:
>> Now I don't want to call into question the esteemed authors of said
>> program, and depending libraries, but I do think that providing https
>> mirrors gives us two distinct advantages over plain http:
>> 
>>. in the case that there is a bug in apt, or gpg, or something
>>else, having https would provide at minimum a minor set of
>>defense against bulk, non-targeted quantum insert and foxacid
>>attacks, not to mention MiTM compromises from a hostile local
>>network
> 
> Heh. Because SSL/TLS libraries are so impenetrable and secure? :D

Even GnuPG has had exploitable bugs.  Adding layers of different security 
techniques can help make the apt distribution system less fragile when such 
bugs inevitably arise.

For example, if there was an exploitable bug in the GPG signing or checksum 
hash algorithms used by apt, anyone fetching packages over HTTP could have 
malicious versions inserted by systems like FOXACID.  If HTTPS was in use, then 
that would required the attacker to modify the files on the servers where they 
are stored in order to use the initial GPG/hash exploit.  So using HTTPS 
greatly reduces the attack surface.

.hc

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/13319bed-07af-4cab-9969-8f8d663bc...@at.or.at

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

On May 30, 2014, at 10:06 AM, micah anderson wrote:

> Kurt Roeckx  writes:
> 
>> On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
>>> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
 On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
> The public Debian mirrors seem like an obvious target for governments to
> MITM. I know that the MD5s are also published, but unless you're
> verifying them with third parties, what's stopping the MD5s being
> compromised too?
 
 The cryptographic signatures that are validated automatically by apt. 
>>> 
>>> What's stopping the attacker from serving a compromised apt?
>> 
>> apt will check that the new apt is properly signed.
> 
> This entire secure artifice depends entirely on the integrity of
> apt, and presumably the various libraries that it depends on.
> 
> Now I don't want to call into question the esteemed authors of said
> program, and depending libraries, but I do think that providing https
> mirrors gives us two distinct advantages over plain http:
> 
>. in the case that there is a bug in apt, or gpg, or something
>else, having https would provide at minimum a minor set of
>defense against bulk, non-targeted quantum insert and foxacid
>attacks, not to mention MiTM compromises from a hostile local
>network
> 
>. keeps an adversary who may be listening on the wire from
>looking at what you are installing. who cares what you are
>installing? well it turns out that is very interesting
>information. If you can see that I've just installed X package,
>and you then just look over at our security tracker and find
>that this package has an exploit...
> 
> micah

I definitely agree there are legitimate concerns that using HTTPS on apt 
mirrors would help, and people who suggest otherwise are out of date on what 
the threats are.  I think the integrity of the package itself is not reason 
enough to use HTTPS since the GPG signing is much more reliable for that task.  
I break it down into 4 

1. package authenticity
(software can be modified while being downloaded)

2. repo availability
(internet services can be blocked by governments and companies)

3. package availability
(software security updates can be individually blocked)

4. who’s downloading what package (currently visible to anyone who can see the 
network traffic, including open wifi, etc.)


The current apt model covers #1 well, but only covers #2 and #3 with a two week 
window (the expiration date on the repo metadata).  And it does not cover #4 at 
all.

Using HTTPS for apt repos is a simple way to improve the security of all 4.  It 
adds a weak backup security layer for #1, it makes it much more difficult for 
the attacker to do #2, #3, and #4.

For those who want to find HTTPS mirrors, try my script here:
https://guardianproject.info/2013/10/31/issues-when-distributing-software/

.hc

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/476000fe-7a7d-4dab-b344-a928ef9e3...@at.or.at

Re: Debian mirrors and MITM

[Jann Horn]

On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote:
> Now I don't want to call into question the esteemed authors of said
> program, and depending libraries, but I do think that providing https
> mirrors gives us two distinct advantages over plain http:
> 
> . in the case that there is a bug in apt, or gpg, or something
> else, having https would provide at minimum a minor set of
> defense against bulk, non-targeted quantum insert and foxacid
> attacks, not to mention MiTM compromises from a hostile local
> network

Heh. Because SSL/TLS libraries are so impenetrable and secure? :D


signature.asc
Description: Digital signature

Re: Debian mirrors and MITM

[Giuseppe Mazzotta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 31-05-14 12:55, Patrick Schleizer wrote:
> Joey Hess:> [...] there are situations where
>> debootstrap is used without debian-archive-keyring being
>> available, [...]
> 
> Please elaborate, which situations are these?
> 
> 
Let me answer this: using debootstrap on non-Debian systems, a
scenario likely to become more frequent with Debian running in Linux
containers (LXC).

However, caveats apply in these scenarios, I will illustrate one way
to think about this - if not just to gather feedback (it applies not
only to LXC/VMs but in general for the case of spawning new Debian
systems):

1) you have a Debian CD that you have verified being authentic thanks
to your web of trust, this will be the system you trust most with
trust level T0. Let's say you got it from the warm hands of your
favourite DD and you are jealously storing it away as good wine
2) you are running a non-Debian system as host, let's say you have a
trust level Tx on this operative system (it can be anything, but also
Debian)
3) using debootstrap *without* a trust path to get the archive signing
keys is enough of a mistake, in this case drinking the HTTPS cool-aid
doesn't fix the trust path e.g. you would multiply Tx by zero (APT
security != SSL CA security)
4) to overcome the problem above, you have to use your host system
(with trust level Tx) to get the archive signing keys or to get an
already "seeded" Debian chroot. I prefer the latter, thus I would
download an official CD or net install ISO (verifiable thanks to
https://www.debian.org/CD/verify), that we will label with trust level Ty
5) at this point you can continue the installation of your derived
Debian system, that will have same trust level Ty

Theorem: in absolutely no case you can create a system with a higher
trust level than its parent:

Tx >= Ty

Let's depict scenarios where you want to achieve Ty = T0.

If at (3) you went forward without trusted archive signing keys, Ty is
0 (this covers the case Tx > Ty), so let's drop this scenario.

If your host system with trust Tx is let's say SuperSecureLinux
downloaded from malwareland, then:

Ty >= T0 iif (if and only if) Tx >= T0

(You must trust malwareland more than or equally as Debian)

If instead your host system has trust level T0 (you installed it with
that lovely CD), then chain of trust is respected (given that you
followed [4] and not [3]):

Tx = T0 => Ty = T0

Sorry for the pseudo logic, hope it adds positively to the
understanding & discussion.

Related threads:
https://lists.debian.org/debian-devel/2004/06/msg01499.html

Kind regards,
- --
  Giuseppe Mazzotta
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTidwBAAoJEKWX1kB3NXekxNgIAIdCDjMnIN5i9EtuQsqMvbYG
lFmmgpygoQZFcibptEJsoIYxsY6RK1XlcPh8F4SvOSa4EGDKa9PTF/9uHW/K0bpW
fWpmJuMr2r04DadUp9mQe8hNDnNqeog6OavwjkZ7ruM1BldyZVWD1IAcGFb0b0B6
gnZW3/CuDDD2u7OWBVhan4Aru7WdXa/gqCNMhOe1YjKku4bOdx+DpsWKpVAtXgK0
iSMqwYk4x8rV80uWRvdD14ft3Dx9wX170l/rfN4q9/ut2gzqq/FPVs/RehURJSzD
ZNP92nTrqt6yqRxLTNDZiV2HbBYjcMri8ACT3ycuNjLdKTEfwVHfq5OvszdV7oM=
=PMc1
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5389dc01.1050...@bitonic.nl

Re: Debian mirrors and MITM

[Patrick Schleizer]

Joey Hess:> [...] there are situations where
> debootstrap is used without debian-archive-keyring being available, [...]

Please elaborate, which situations are these?


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5389b537.4020...@riseup.net

Re: Debian mirrors and MITM

[Patrick Schleizer]

Peter Palfrader:
> On Fri, 30 May 2014, Joey Hess wrote:
> 
>> Alfie John wrote:
>>> Taking a look at the Debian mirror list, I see none serving over HTTPS:
>>>
>>>   https://www.debian.org/mirror/list
>>
>> https://mirrors.kernel.org/debian is the only one I know of.
>>
>> It would be good to have a few more, because there are situations where
>> debootstrap is used without debian-archive-keyring being available, and
>> recent versions of debootstrap try to use https in that situation, to at
>> least get the weak CA level of security.
> 
> That doesn't buy you anything.  Mirrors, even if you trusted them, don't
> use authenticated syncing protocols.
> 

Looks like another issue worth fixing under the encrypt/authenticate all
the things credo.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5389b3db.5020...@riseup.net

Re: Debian mirrors and MITM

[Peter Palfrader]

On Fri, 30 May 2014, Joey Hess wrote:

> Alfie John wrote:
> > Taking a look at the Debian mirror list, I see none serving over HTTPS:
> > 
> >   https://www.debian.org/mirror/list
> 
> https://mirrors.kernel.org/debian is the only one I know of.
> 
> It would be good to have a few more, because there are situations where
> debootstrap is used without debian-archive-keyring being available, and
> recent versions of debootstrap try to use https in that situation, to at
> least get the weak CA level of security.

That doesn't buy you anything.  Mirrors, even if you trusted them, don't
use authenticated syncing protocols.

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140531091020.gp20...@anguilla.noreply.org

Re: Debian mirrors and MITM

[Paul Wise]

On Fri, May 30, 2014 at 8:15 PM, Alfie John wrote:

> Taking a look at the Debian mirror list, I see none serving over HTTPS:
>
>   https://www.debian.org/mirror/list

Then you aren't trying hard enough, several of them support https,
these ones at least:

https://mirrors.kernel.org/debian/
https://mirrors.xmission.com/debian/
https://mirrors.ocf.berkeley.edu/debian/
https://mirrors.bloomu.edu/debian/
https://mirror.hmc.edu/debian/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FEZWZKx1dLf=R977L1a81bxToUUMB-=k_as+ndiud...@mail.gmail.com

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 09:43:47PM +0200, Erwan David wrote:

Note that at least debian.org DNS is segned by DNSSEC and DANE is used,
which allows to check that the certificate used by a debian.org site is
the real one.


We're not at the point where that can be relied on in the real world. 
There are still resolvers that filter out DNSSEC records. (Sad, but 
true.)


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/8bcb9ec8-e84b-11e3-9d19-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Erwan David]

Le 30/05/2014 22:02, Henrique de Moraes Holschuh a écrit :
> On Fri, 30 May 2014, Erwan David wrote:
>> Le 30/05/2014 21:30, Joey Hess a écrit :
>>> Alfie John wrote:
 Taking a look at the Debian mirror list, I see none serving over HTTPS:
   https://www.debian.org/mirror/list
>>> https://mirrors.kernel.org/debian is the only one I know of.
>>>
>>> It would be good to have a few more, because there are situations where
>>> debootstrap is used without debian-archive-keyring being available, and
>>> recent versions of debootstrap try to use https in that situation, to at
>>> least get the weak CA level of security.
>>>
>> Note that at least debian.org DNS is segned by DNSSEC and DANE is used,
>> which allows to check that the certificate used by a debian.org site is
>> the real one.
> We don't ship a DNSSEC-enabled resolver by default, and fixing THAT would
> require some very careful considerations and large-scale testing.
>
> That said, AFAIC it is a critical bug on debootstrap that it doesn't just
> keel over and die very loudly when run without a trust path to verify the
> downloaded packages [as usual, this means we'd need to make it possible to
> provide such trust paths for the harder usecases as well].
>

I understand it is not so simple... However it is a first step toward a
more secure path.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5388e670.9070...@rail.eu.org

Re: Debian mirrors and MITM

[Henrique de Moraes Holschuh]

On Fri, 30 May 2014, Erwan David wrote:
> Le 30/05/2014 21:30, Joey Hess a écrit :
> > Alfie John wrote:
> >> Taking a look at the Debian mirror list, I see none serving over HTTPS:
> >>   https://www.debian.org/mirror/list
> > https://mirrors.kernel.org/debian is the only one I know of.
> >
> > It would be good to have a few more, because there are situations where
> > debootstrap is used without debian-archive-keyring being available, and
> > recent versions of debootstrap try to use https in that situation, to at
> > least get the weak CA level of security.
> >
> Note that at least debian.org DNS is segned by DNSSEC and DANE is used,
> which allows to check that the certificate used by a debian.org site is
> the real one.

We don't ship a DNSSEC-enabled resolver by default, and fixing THAT would
require some very careful considerations and large-scale testing.

That said, AFAIC it is a critical bug on debootstrap that it doesn't just
keel over and die very loudly when run without a trust path to verify the
downloaded packages [as usual, this means we'd need to make it possible to
provide such trust paths for the harder usecases as well].

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530200202.ga4...@khazad-dum.debian.net

Re: Debian mirrors and MITM

[Erwan David]

Le 30/05/2014 21:30, Joey Hess a écrit :
> Alfie John wrote:
>> Taking a look at the Debian mirror list, I see none serving over HTTPS:
>>
>>   https://www.debian.org/mirror/list
> https://mirrors.kernel.org/debian is the only one I know of.
>
> It would be good to have a few more, because there are situations where
> debootstrap is used without debian-archive-keyring being available, and
> recent versions of debootstrap try to use https in that situation, to at
> least get the weak CA level of security.
>
Note that at least debian.org DNS is segned by DNSSEC and DANE is used,
which allows to check that the certificate used by a debian.org site is
the real one.




signature.asc
Description: OpenPGP digital signature

Re: Debian mirrors and MITM

[Joey Hess]

Alfie John wrote:
> Taking a look at the Debian mirror list, I see none serving over HTTPS:
> 
>   https://www.debian.org/mirror/list

https://mirrors.kernel.org/debian is the only one I know of.

It would be good to have a few more, because there are situations where
debootstrap is used without debian-archive-keyring being available, and
recent versions of debootstrap try to use https in that situation, to at
least get the weak CA level of security.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 10:35:58AM -0700, Jeremie Marguerie wrote:

In the end, the PPA can do pretty much whatever it wants from your
system and this is scary. This is a hard problem to protect against
and the only protection I see is... only install PPAs you can trust.


Yup; any pinning mechanism you add could be removed by a trusted 
malicious package.


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/240fd966-e828-11e3-9f93-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Denis Nikolaenko]

On 30.05.2014 21:35, Jeremie Marguerie wrote:
To "protect" openssh-server you would need to prevent modification of 
its dependency. But the PPA could just install a program that 
overrides the openssh-server manually (without doing that from APT). 
In this case, unless you run debsums you wouldn't notice it. 
Any package can do whatever it wants, for example, in postinst script 
which is run as root.
Unless every piece of software from PPA is totaly sandboxed somehow, 
loopholes are inevitable

if arbitrary code should be run during installation/upgrade/removal.
--
Denis Nikolaenko


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5388c850.1040...@nikolaenko.ru

Re: Debian mirrors and MITM

[Jeremie Marguerie]

On Fri, May 30, 2014 at 10:03 AM, Hans Spaans  wrote:
> What basically is missing for a running system is repository signing key
> pinning for packages that would "prevent" that a third party repository
> could upgrade components provided by the base OS. How many of us didn't
> added debian-multimedia.org repositories and their PGP-keys to our
> systems in the past? How many of us didn't added some weird PPA? And who
> did remove remove both repo-lines AND PGP-keys when not needed anymore?
> And how many of those keys have proper rollover/revoke/maintenance
> procedure?
>
> Currently Debian checks if a package is signed by a trusted source, but
> not if the package is trusted for the package that you're going to
> update. Looks like a fun excise to offer a new apt package through the
> debian-multimedia infra for example and see who will notice. Or a
> modified openssh-server/client package through a populair PPA-repo.

Thanks for bringing that issue! I feel the same way when I install a
packet from a non-official PPA.

It's definitely a problem of trust: I trust this PPA to install (say)
firefox beta but I don't trust it enough to replace openssh.
In this case you could think that pinning openss-server on the
"official" repository would make the work but since the PPA could also
rewrite a library used by openssh-server, it could inject code into it
easily without alarming anyone (who cares when a PPA updates libfreebl
?).

To "protect" openssh-server you would need to prevent modification of
its dependency. But the PPA could just install a program that
overrides the openssh-server manually (without doing that from APT).
In this case, unless you run debsums you wouldn't notice it.

In the end, the PPA can do pretty much whatever it wants from your
system and this is scary. This is a hard problem to protect against
and the only protection I see is... only install PPAs you can trust.

-- 
Jérémie MARGUERIE


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caks89grgnv6yj2qakyduxxrk97ka6rhwsfbh2dexu81ebm+...@mail.gmail.com

Re: Debian mirrors and MITM

[Hans Spaans]

On vr, 2014-05-30 at 10:53 -0400, Michael Stone wrote:
> On Sat, May 31, 2014 at 12:46:12AM +1000, Alfie John wrote:
> >Sorry for asking questions.
> 
> Don't apologize for asking questions, it's perfectly reasonable to do so 
> and you'll find that many people in debian are more than happy to answer 
> questions. Just make sure that you put in enough effort yourself to 
> ensure that you can actually engage constructively when you get an 
> answer. (And if some of the answers point to documentation, make sure 
> that you can't find the answers in the documentation.)

While Alfie should have done some homework first (at least asked Google
for example, but who didn't made that mistake?) there is some loophole
currently. It was discusses shortly a while ago on IRC and done away as
not important, but the loophole still exist as far as I'm aware of it.

What basically is missing for a running system is repository signing key
pinning for packages that would "prevent" that a third party repository
could upgrade components provided by the base OS. How many of us didn't
added debian-multimedia.org repositories and their PGP-keys to our
systems in the past? How many of us didn't added some weird PPA? And who
did remove remove both repo-lines AND PGP-keys when not needed anymore?
And how many of those keys have proper rollover/revoke/maintenance
procedure?

Currently Debian checks if a package is signed by a trusted source, but
not if the package is trusted for the package that you're going to
update. Looks like a fun excise to offer a new apt package through the
debian-multimedia infra for example and see who will notice. Or a
modified openssh-server/client package through a populair PPA-repo.

Hans


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

Re: Debian mirrors and MITM

[Horatio Leragon]

 From: Daniel 
To: Alfie John ; debian-security@lists.debian.org 
Sent: Friday, May 30, 2014 10:16 PM
Subject: Re: Debian mirrors and MITM
 

> The thing is: When you download an .iso file, that .iso file also contains a 
> signing key used to verify each package it downloads during the 
> installation.

> The .iso file already contains a public key, and verifies every package it 
> downloads along the way. You can disable that by hacking a bit in the 
> installer, but it does requires an effort.

> For the next problem: Some mirror might theoretically have an .iso file which 
> has been tampered with, but you should check the checksum for 
> that file with what you find in the debian web-pages. If you download a .iso 
> file via HTTP, it might have been tampered with, and if someone is
> intercepting your request for the public key, it might be changed. But i 
> think that would be a problem anyways...

Hello guys,

I am very confused after reading the exchanges on this topic.

Could someone tell me whether what I have done is correct?

1. I download the *.iso file from a Debian mirror together with the SHA512SUMS 
and SHA512SUMS.sig

2. On the relevant Debian Wiki page (which is served via https), I search for 
the fingerprint of the key used to sign the downloaded *.iso file

3. On some Debian user forums, I make inquiries as to the fingerprint of the 
signing key for my *.iso file. I compare it with the one given by Debian Wiki. 
If the fingerprints are identical, I will download the signing key from 
pgp.mit.edu keyserver.

4. I use the signing key to verify SHA512SUMS file. If the signature is good, I 
proceed to verify the SHA512 hashsum against my downloaded *.iso file

Are the above steps sufficient to verify the authenticity of the downloaded 
*.iso file?

Re: Debian mirrors and MITM

[Michael Stone]

On Sat, May 31, 2014 at 12:46:12AM +1000, Alfie John wrote:

Sorry for asking questions.


Don't apologize for asking questions, it's perfectly reasonable to do so 
and you'll find that many people in debian are more than happy to answer 
questions. Just make sure that you put in enough effort yourself to 
ensure that you can actually engage constructively when you get an 
answer. (And if some of the answers point to documentation, make sure 
that you can't find the answers in the documentation.)


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/90cece00-e809-11e3-b232-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Alfie John]

On Sat, May 31, 2014, at 12:39 AM, Michael Stone wrote:
> On Sat, May 31, 2014 at 12:32:59AM +1000, Alfie John wrote:
> >I'm definitely wanting to engage in serious discussion. I'm an avid
> >Debian user and am wanting to protect its users. This *is* the Debian
> >security mailing list after all right? All I was trying to do is ask
> >questions as to why it is currently not being HTTPS-enforced and I
> >got flamed for it.
>
> Well, you haven't shown any sign of having studied the publically
> available documentation or checked the public archives relating to the
> design decisions. Yes it's the debian-security mailing list, but that
> doesn't mean that it's scalable for debian to provide a personal
> walkthrough of the entire package signing architecture for everyone
> who sends an email to the list, does it?

I haven't read the docs. And you right, it's not a scalable solution.
Sorry for asking questions.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401461172.30245.123322097.6b61a...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Reid Sutherland]

On May 30, 2014, at 10:11 AM, Alfie John  wrote:
> 
>>. keeps an adversary who may be listening on the wire from
>>  looking at what you are installing. who cares what you are
>>  installing? well it turns out that is very interesting
>>  information. If you can see that I've just installed X
>>  package, and you then just look over at our security tracker
>>  and find that this package has an exploit...
> 
> It's only metadata, so who cares right? Only kidding. This is a totally
> legitimate scenario which I didn't think of. Nice.


I don’t think it’s Debian's responsibility to protect the user from metadata 
snooping.  Plus this adds complexity and excessive cost to distribution.  If 
you want to partially solve this problem, mirror the entire repository 
(including security) to a private location.



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/fc595976-3fb8-485e-8cf3-eb697427f...@vianet.ca

Re: Debian mirrors and MITM

[Jason Fergus]

I have to laugh at this, my phone was going off constantly this morning,
and I was thinking "I don't have this much email normally!"  Looked over
the discussion and thought, "didn't this discussion happen recently?"  

It was something I was randomly thinking about one day too, but really
plain-text over http isn't really what's happening anyhow, and if you
want to change it, change it to ftp transport, not many people trying to
look there!  (yes that bit is a joke, but still, I don't think HTTPS
would really help a whole lot, except as someone else mentioned, you may
be able to see the packages being installed without it.)

On Fri, 2014-05-30 at 15:26 +0200, Estelmann, Christian wrote:
> Yes, but I think this time it will not be better...
> 
> Some (most?) mirrors are supporting https. If you want to use https just try 
> which mirrors are supporting it.
> ftp.us.d.o will not work very good because of the DNS round robin.
> 
> On 30. Mai 2014 15:16:29 MESZ, Alfie John  wrote:
> >On Fri, May 30, 2014, at 11:03 PM, Estelmann, Christian wrote:
> >> In Oct 2013 a similar discussion startet
> >> https://lists.debian.org/debian-security/2013/10/msg00027.html
> >
> >Thanks for the link, but that discussion went nowhere pretty fast.
> >
> >Alfie
> 
> 



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

Re: Debian mirrors and MITM

[Alfie John]

On Sat, May 31, 2014, at 12:11 AM, Michael Stone wrote:
> On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote:
> >Several times (public and private) I tried to explain how the
> >download of APT (the binary itself) on an initial Debian install
> >could be compromised via MITM since it's over plaintext. Then the
> >verification of packages could simply be skipped (hence NOP). I'm not
> >sure why you're bringing libc and libgpg into the conversation.
>
> You were given a solution which is cryptographically sound and with a
> verifiable trust path, and you're rejecting it because you simply
> don't like it and would rather see a different solution with a weaker
> trust path. I'm not sure why you're continuing this argument.

I'm not rejected it. I'm pretty happy with verifying packages via
checksums hosted on a canonical Debian HTTPS site. My reaction was
referring to Reid Sutherland's comments telling me in private that there
was nothing to fear because there are smarter people in the room looking
after everything.

> If you want to engage in a serious discussion about enhancing the
> current implementation or adding additional options, I'd suggest that
> you first study how the current implementation works, why it was
> implemented the way it was, the constraints inherent in the
> distributed mirror model, etc.

I'm definitely wanting to engage in serious discussion. I'm an avid
Debian user and am wanting to protect its users. This *is* the Debian
security mailing list after all right? All I was trying to do is ask
questions as to why it is currently not being HTTPS-enforced and I got
flamed for it.

I understand the issue of distributing to mirrors and then the problem
of trusting each other, but that's another discussion entirely.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401460379.27062.123315561.30584...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Michael Stone]

On Sat, May 31, 2014 at 12:32:59AM +1000, Alfie John wrote:

I'm definitely wanting to engage in serious discussion. I'm an avid
Debian user and am wanting to protect its users. This *is* the Debian
security mailing list after all right? All I was trying to do is ask
questions as to why it is currently not being HTTPS-enforced and I got
flamed for it.


Well, you haven't shown any sign of having studied the publically 
available documentation or checked the public archives relating to the 
design decisions. Yes it's the debian-security mailing list, but that 
doesn't mean that it's scalable for debian to provide a personal 
walkthrough of the entire package signing architecture for everyone who 
sends an email to the list, does it?


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/d07185d6-e807-11e3-8a0e-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Michael Stone]

On Sat, May 31, 2014 at 12:11:28AM +1000, Alfie John wrote:

On Sat, May 31, 2014, at 12:06 AM, micah anderson wrote:

. keeps an adversary who may be listening on the wire from
  looking at what you are installing. who cares what you are
  installing? well it turns out that is very interesting
  information. If you can see that I've just installed X
  package, and you then just look over at our security tracker
  and find that this package has an exploit...


It's only metadata, so who cares right? Only kidding. This is a totally
legitimate scenario which I didn't think of. Nice.


So your solution to adding privacy is to make sure that every debian 
system checks in with debian directly rather than using a distributed 
infrastructure? I'd suggest looking at apt-transport-tor instead.


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/68c76176-e807-11e3-91cf-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Daniel]

On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote:
> Several times (public and private) I tried to explain how the download
> of APT (the binary itself) on an initial Debian install could be
> compromised via MITM since it's over plaintext. Then the verification of
> packages could simply be skipped (hence NOP). I'm not sure why you're
> bringing libc and libgpg into the conversation.
> 
> Alfie
> 

Hello.

The thing is: When you download an .iso file, that .iso file also
contains a signing key used to verify each package it downloads during
the installation. Encryption is not important in this aspect, because
what you are downloading is already publicly available and not secret.
Everyone can download the same packages as the installer. Those are
already public.

The important bit is to verify that what you are downloading either
manually, or via the installer, hasn't been tampered with. That is
verification, and that is what is interesting here. The .iso file
already contains a public key, and verifies every package it downloads
along the way. You can disable that by hacking a bit in the installer,
but it does requires an effort.

For the next problem: Some mirror might theoretically have an .iso file
which has been tampered with, but you should check the checksum for that
file with what you find in the debian web-pages. If you download a .iso
file via HTTP, it might have been tampered with, and if someone is
intercepting your request for the public key, it might be changed. But i
think that would be a problem anyways...


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530141605.GC17668@s1.t11.local

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote:

Several times (public and private) I tried to explain how the download
of APT (the binary itself) on an initial Debian install could be
compromised via MITM since it's over plaintext. Then the verification of
packages could simply be skipped (hence NOP). I'm not sure why you're
bringing libc and libgpg into the conversation.


You were given a solution which is cryptographically sound and with a 
verifiable trust path, and you're rejecting it because you simply don't 
like it and would rather see a different solution with a weaker trust 
path. I'm not sure why you're continuing this argument.


If you want to engage in a serious discussion about enhancing the 
current implementation or adding additional options, I'd suggest that 
you first study how the current implementation works, why it was 
implemented the way it was, the constraints inherent in the distributed 
mirror model, etc.



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530141153.gb29...@mathom.us

Re: Debian mirrors and MITM

[Alfie John]

On Sat, May 31, 2014, at 12:06 AM, micah anderson wrote:
> >> > The cryptographic signatures that are validated automatically by
> >> > apt.
> >>
> >> What's stopping the attacker from serving a compromised apt?
> >
> > apt will check that the new apt is properly signed.
>
> This entire secure artifice depends entirely on the integrity of apt,
> and presumably the various libraries that it depends on.
>
> Now I don't want to call into question the esteemed authors of said
> program, and depending libraries, but I do think that providing https
> mirrors gives us two distinct advantages over plain http:
>
> . in the case that there is a bug in apt, or gpg, or something
>   else, having https would provide at minimum a minor set of
>   defense against bulk, non-targeted quantum insert and
>   foxacid attacks, not to mention MiTM compromises from a
>   hostile local network

Yep, already mentioned this one. This is my biggest issue. I'm beginning
to this should be classified as a security bug in Debian.

> . keeps an adversary who may be listening on the wire from
>   looking at what you are installing. who cares what you are
>   installing? well it turns out that is very interesting
>   information. If you can see that I've just installed X
>   package, and you then just look over at our security tracker
>   and find that this package has an exploit...

It's only metadata, so who cares right? Only kidding. This is a totally
legitimate scenario which I didn't think of. Nice.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401459088.20943.123308065.4e198...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Reid Sutherland]

On May 30, 2014, at 9:50 AM, Alfie John  wrote:
>> 
>> The whole point here is that Debian is already verifying the content it
>> is receiving from any given data source.  This was done from the very
>> beginning because anyone can mirror and distribute Debian software.  So
>> unless there is a flaw with libc and libgpg, we are safe for downloading
>> the public Debian content from anywhere.
> 
> Several times (public and private) I tried to explain how the download
> of APT (the binary itself) on an initial Debian install could be
> compromised via MITM since it's over plaintext. Then the verification of
> packages could simply be skipped (hence NOP). I'm not sure why you're
> bringing libc and libgpg into the conversation.


I think you are on the right track, the MD5SUMS of each release does not seem 
to be available via SSL from debian.org.



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e89fece8-7c01-45c3-9d7f-03919b612...@vianet.ca

Re: Debian mirrors and MITM

[micah anderson]

Kurt Roeckx  writes:

> On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
>> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
>> > On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
>> > >The public Debian mirrors seem like an obvious target for governments to
>> > >MITM. I know that the MD5s are also published, but unless you're
>> > >verifying them with third parties, what's stopping the MD5s being
>> > >compromised too?
>> > 
>> > The cryptographic signatures that are validated automatically by apt. 
>> 
>> What's stopping the attacker from serving a compromised apt?
>
> apt will check that the new apt is properly signed.

This entire secure artifice depends entirely on the integrity of
apt, and presumably the various libraries that it depends on.

Now I don't want to call into question the esteemed authors of said
program, and depending libraries, but I do think that providing https
mirrors gives us two distinct advantages over plain http:

. in the case that there is a bug in apt, or gpg, or something
else, having https would provide at minimum a minor set of
defense against bulk, non-targeted quantum insert and foxacid
attacks, not to mention MiTM compromises from a hostile local
network

. keeps an adversary who may be listening on the wire from
looking at what you are installing. who cares what you are
installing? well it turns out that is very interesting
information. If you can see that I've just installed X package,
and you then just look over at our security tracker and find
that this package has an exploit...

micah


pgp50ulNq1plS.pgp
Description: PGP signature

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:37 PM, Reid Sutherland wrote:
> >> Oh, and those key fingerprints are on an https page for those who
> >> actually trust the CA system.
> > 
> > That was my next question. If the fingerprints are on a HTTPS served
> > page, then yes that seems like a valid solution.
> > 
> > And thanks Reid Sutherland for telling me I have no clue. Much
> > appreciated.
> 
> 
> In your private response to me, you didn’t.
>
> The whole point here is that Debian is already verifying the content it
> is receiving from any given data source.  This was done from the very
> beginning because anyone can mirror and distribute Debian software.  So
> unless there is a flaw with libc and libgpg, we are safe for downloading
> the public Debian content from anywhere.

Several times (public and private) I tried to explain how the download
of APT (the binary itself) on an initial Debian install could be
compromised via MITM since it's over plaintext. Then the verification of
packages could simply be skipped (hence NOP). I'm not sure why you're
bringing libc and libgpg into the conversation.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401457832.14998.123299485.589aa...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Reid Sutherland]

On May 30, 2014, at 9:30 AM, Alfie John  wrote:

> On Fri, May 30, 2014, at 11:27 PM, Michael Stone wrote:
>> On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote:
>>> That's why you verify the initial install media per the link I posted
>>> earlier...
>> 
>> Oh, and those key fingerprints are on an https page for those who
>> actually trust the CA system.
> 
> That was my next question. If the fingerprints are on a HTTPS served
> page, then yes that seems like a valid solution.
> 
> And thanks Reid Sutherland for telling me I have no clue. Much
> appreciated.


In your private response to me, you didn’t.

The whole point here is that Debian is already verifying the content it is 
receiving from any given data source.  This was done from the very beginning 
because anyone can mirror and distribute Debian software.  So unless there is a 
flaw with libc and libgpg, we are safe for downloading the public Debian 
content from anywhere.


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/f8cb8b56-fbf3-471d-9c06-94f03f05e...@vianet.ca

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:29 PM, Michael Stone wrote:
> On Fri, May 30, 2014 at 11:25:58PM +1000, Alfie John wrote:
> >Well yes, that's something. But serving Debian over HTTPS would prevent
> >the need for this.
> 
> No, it wouldn't--you'd just have a different set of problems. Given that 
> mirrors are distributed, it would probably be much more likely that 
> you'd improperly rely on a compromised mirror simply because it's 
> serving files via https.

If the fingerprints where on a canonical Debian server (aka non-mirror)
being served over HTTPS, then I would be happy with that too.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401456752.11334.123293437.379eb...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:27 PM, Michael Stone wrote:
> On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote:
> >That's why you verify the initial install media per the link I posted
> >earlier...
>
> Oh, and those key fingerprints are on an https page for those who
> actually trust the CA system.

That was my next question. If the fingerprints are on a HTTPS served
page, then yes that seems like a valid solution.

And thanks Reid Sutherland for telling me I have no clue. Much
appreciated.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401456637.10889.123292765.031db...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 11:25:58PM +1000, Alfie John wrote:

Well yes, that's something. But serving Debian over HTTPS would prevent
the need for this.


No, it wouldn't--you'd just have a different set of problems. Given that 
mirrors are distributed, it would probably be much more likely that 
you'd improperly rely on a compromised mirror simply because it's 
serving files via https.


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1db1c630-e7fe-11e3-b616-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 09:24:47AM -0400, Michael Stone wrote:
That's why you verify the initial install media per the link I posted 
earlier...


Oh, and those key fingerprints are on an https page for those who 
actually trust the CA system.



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/f2a5e71e-e7fd-11e3-bb9d-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Estelmann, Christian]

Yes, but I think this time it will not be better...

Some (most?) mirrors are supporting https. If you want to use https just try 
which mirrors are supporting it.
ftp.us.d.o will not work very good because of the DNS round robin.

On 30. Mai 2014 15:16:29 MESZ, Alfie John  wrote:
>On Fri, May 30, 2014, at 11:03 PM, Estelmann, Christian wrote:
>> In Oct 2013 a similar discussion startet
>> https://lists.debian.org/debian-security/2013/10/msg00027.html
>
>Thanks for the link, but that discussion went nowhere pretty fast.
>
>Alfie


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c7a69a47-8ca7-4c4b-baaf-9ea1c4a25...@email.android.com

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:24 PM, Michael Stone wrote:
> On Fri, May 30, 2014 at 11:13:31PM +1000, Alfie John wrote:
> >As what I posted earlier, all you would need to do is to MITM the
> >install of APT during an install. Who cares what the signatures look
> >like since you've NOPed the checksumming code!
> 
> That's why you verify the initial install media per the link I posted 
> earlier...

Well yes, that's something. But serving Debian over HTTPS would prevent
the need for this.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401456358.9280.123291613.503b4...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 11:13:31PM +1000, Alfie John wrote:

As what I posted earlier, all you would need to do is to MITM the
install of APT during an install. Who cares what the signatures look
like since you've NOPed the checksumming code!


That's why you verify the initial install media per the link I posted 
earlier...



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/90ebee24-e7fd-11e3-89ae-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:17 PM, Reid Sutherland wrote:
> > As what I posted earlier, all you would need to do is to MITM the
> > install of APT during an install. Who cares what the signatures look
> > like since you've NOPed the checksumming code!
> 
> So OpenSSL can be flawed and nobody bats an eye, APT uses GnuPG and
> everyone (this guy) loses their mind?

Strawman much? What does bring up OpenSSL have anything to do with
Debian mirrors being MITM?

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401456195.8866.123289337.07259...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Reid Sutherland]

On May 30, 2014, at 9:13 AM, Alfie John  wrote:

> On Fri, May 30, 2014, at 11:08 PM, Adam D. Barratt wrote:
 The cryptographic signatures that are validated automatically by apt.
>>> 
>>> What's stopping the attacker from serving a compromised apt?
>> 
>> How would you get the client's system to install it in the first place? 
>> (More specifically, how would you get the cryptographic signature to 
>> match your package, given a lack of access to any of the keys trusted by 
>> the client's system?)
> 
> As what I posted earlier, all you would need to do is to MITM the
> install of APT during an install. Who cares what the signatures look
> like since you've NOPed the checksumming code!


So OpenSSL can be flawed and nobody bats an eye, APT uses GnuPG and everyone 
(this guy) loses their mind?

Anyway, this is covered by GnuPG, unless it is flawed, we don’t have an issue.


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/d8754ebf-3f4d-4c90-a016-ccc195e33...@vianet.ca

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:03 PM, Estelmann, Christian wrote:
> In Oct 2013 a similar discussion startet
> https://lists.debian.org/debian-security/2013/10/msg00027.html

Thanks for the link, but that discussion went nowhere pretty fast.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401455789.7468.123287497.4aee6...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 11:08 PM, Adam D. Barratt wrote:
> >> The cryptographic signatures that are validated automatically by apt.
> > 
> > What's stopping the attacker from serving a compromised apt?
> 
> How would you get the client's system to install it in the first place? 
> (More specifically, how would you get the cryptographic signature to 
> match your package, given a lack of access to any of the keys trusted by 
> the client's system?)

As what I posted earlier, all you would need to do is to MITM the
install of APT during an install. Who cares what the signatures look
like since you've NOPed the checksumming code!

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401455611.6597.123286253.5d5a4...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Kurt Roeckx]

On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
> > On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
> > >The public Debian mirrors seem like an obvious target for governments to
> > >MITM. I know that the MD5s are also published, but unless you're
> > >verifying them with third parties, what's stopping the MD5s being
> > >compromised too?
> > 
> > The cryptographic signatures that are validated automatically by apt. 
> 
> What's stopping the attacker from serving a compromised apt?

apt will check that the new apt is properly signed.

During instalation there will be a package installed called
debian-archive-keyring, and that is used to verify other things
you download.  So really the question is how you can be sure that
the initial file that you downloaded are authentic and and contain
the real key.

And it depends on what you use as medium to do your installlation.
For instance if you download a CD image, there are also files with
the MD5/SHA1/SHA256.  There is also a signed file there that you
can use to verify that the hashes haven't been modified.  So the
question becomes if you have a trust path to who signed those
files or not, which might not be the case for most people.

Having this on a random website with HTTPS doesn't add anything to
verify that the files you're downloading are the real ones or not,
it doesn't give you an alternative trust path.  That mirror might
not have verified that the files haven't been tampered with, it
might be compromised, it might be doing the attack itself.
Having the mirrors do HTTPS doesn't solve your problem of having
trust in the initial thing you download.

So I basicly see 2 solutions:
- The part that needs to be trusted needs to be downloaded over
  HTTPS from a debian.org host.  I'm not sure cdimage.debian.org
  can offer HTTPS for everything.  But maybe the files with the
  hashes alone can be enough?
- Instead of using PGP to sign something we (also) use X509
  certificates to sign something.  But I don't know how easy it
  would be for people to actually verify that.


Kurt


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530131107.ga7...@roeckx.be

Re: Debian mirrors and MITM

[Adam D. Barratt]

On 2014-05-30 13:43, Alfie John wrote:

On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:

On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
>The public Debian mirrors seem like an obvious target for governments to
>MITM. I know that the MD5s are also published, but unless you're
>verifying them with third parties, what's stopping the MD5s being
>compromised too?

The cryptographic signatures that are validated automatically by apt.


What's stopping the attacker from serving a compromised apt?


How would you get the client's system to install it in the first place? 
(More specifically, how would you get the cryptographic signature to 
match your package, given a lack of access to any of the keys trusted by 
the client's system?)


There's something of a chicken and egg problem to your idea.

Regards,

Adam


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/f78d4218bec9db44c0d491e4318f2...@mail.adsl.funky-badger.org

Re: Debian mirrors and MITM

[Estelmann, Christian]

In Oct 2013 a similar discussion startet
https://lists.debian.org/debian-security/2013/10/msg00027.html

On 30. Mai 2014 14:15:01 MESZ, Alfie John  wrote:
>Hi guys,
>
>Taking a look at the Debian mirror list, I see none serving over HTTPS:
>
>  https://www.debian.org/mirror/list
>
>The public Debian mirrors seem like an obvious target for governments
>to
>MITM. I know that the MD5s are also published, but unless you're
>verifying them with third parties, what's stopping the MD5s being
>compromised too?
>
>Is there any compelling reason why the public Debian mirrors aren't
>served over HTTPS? If there isn't any, then further to this, is there
>any reason why not to mandate all public Debian mirrors HTTPS-only?
>
>Alfie


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/5291f9a3-7d3a-46c2-a606-9eaff4ba4...@email.android.com

Re: Debian mirrors and MITM

[Chris]

On 30/05/2014 8:52 PM, Michael Stone wrote:

On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:

What's stopping the attacker from serving a compromised apt?


https://www.debian.org/CD/verify


That will cover the installer, for the packages see: 
https://wiki.debian.org/SecureApt



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53887f7a.2050...@shthead.com

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 10:49 PM, Chris Boot wrote:
> >> The cryptographic signatures that are validated automatically by apt. 
> > 
> > What's stopping the attacker from serving a compromised apt?
> 
> Oh god not this again.
> 
> How exactly does using HTTPS solve this particular problem, anyway? If
> we assume a compromised APT then surely it can pass invalid SSL
> certificates as perfectly valid, too. It's not like sponsored attackers
> don't have access to all the SSL certificates they might ever want
> anyway.

By mandating HTTPS, it would prevent QuantumInsert and FoxAcid being
implemented during Debain installs and later package installs/updates.

If you're worried about SSL certificates being compromised, going down
the path of Debian self-signing its own certificate and distributed it
via SneakerNet would be a way to prevent it. 

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401454841.3847.123280441.07217...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Chris Boot]

On 30/05/14 13:43, Alfie John wrote:
> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
>> On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
>>> The public Debian mirrors seem like an obvious target for governments to
>>> MITM. I know that the MD5s are also published, but unless you're
>>> verifying them with third parties, what's stopping the MD5s being
>>> compromised too?
>>
>> The cryptographic signatures that are validated automatically by apt. 
> 
> What's stopping the attacker from serving a compromised apt?

Oh god not this again.

How exactly does using HTTPS solve this particular problem, anyway? If
we assume a compromised APT then surely it can pass invalid SSL
certificates as perfectly valid, too. It's not like sponsored attackers
don't have access to all the SSL certificates they might ever want anyway.

-- 
Chris Boot
bo...@bootc.net


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53887e4b.90...@bootc.net

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 10:43 PM, Alfie John wrote:
> > The cryptographic signatures that are validated automatically by apt. 
> 
> What's stopping the attacker from serving a compromised apt?

Thinking about this more, If I wanted to target a Debian system via
MITM, serving a compromised APT would be all I needed. In the future, a
modified package could be served and it wouldn't matter what the
signatures were seeing is I could have control of APT.

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401454416.2074.123278697.7b672...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:

What's stopping the attacker from serving a compromised apt?


https://www.debian.org/CD/verify


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2169b45e-e7f9-11e3-851d-00163eeb5...@msgid.mathom.us

Re: Debian mirrors and MITM

[Alfie John]

On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
> On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
> >The public Debian mirrors seem like an obvious target for governments to
> >MITM. I know that the MD5s are also published, but unless you're
> >verifying them with third parties, what's stopping the MD5s being
> >compromised too?
> 
> The cryptographic signatures that are validated automatically by apt. 

What's stopping the attacker from serving a compromised apt?

Alfie

-- 
  Alfie John
  alf...@fastmail.fm


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1401453836.31698.123277245.0bfa1...@webmail.messagingengine.com

Re: Debian mirrors and MITM

[Michael Stone]

On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:

The public Debian mirrors seem like an obvious target for governments to
MITM. I know that the MD5s are also published, but unless you're
verifying them with third parties, what's stopping the MD5s being
compromised too?


The cryptographic signatures that are validated automatically by apt. 



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/bfad3c3a-e7f4-11e3-8753-00163eeb5...@msgid.mathom.us