Re: APT vulnerability [DSA 4371-1]

[Hans-Christoph Steiner]

FYI, I wrote a script to check the amd64 packages against the published
hash, if anyone wants to use it, it is attached.

.hc

Evgeny Kapun:
> On 22.01.2019 16:59, Vladislav Kurz wrote:
>> Hello everybody,
>>
>> is this vulnerability affecting also apt-get ?
> 
> Yes, the vulnerability is in http backend, which is used by apt-get.
> 
>> If yes, will there be another DSA soon?
> 
> No, because apt-get tool is in the package apt.
> 
>> I'm also encountering many errors when using
>>   apt -o Acquire::http::AllowRedirect=false update
>>   apt -o Acquire::http::AllowRedirect=false upgrade
>>
>> As written in announcement: This is known to break some proxies when
>> used against security.debian.org.
>>
>> However I do not use proxy at all. I have problems with jessie/updates,
>> cdn.debian.net, and http.debian.net
> 
> Try these URLs: http://cdn-fastly.deb.debian.org/debian,
> http://cdn-fastly.deb.debian.org/debian-security. The domains
> cdn.debian.net and http.debian.net are deprecated, use deb.debian.org
> instead.
> 
>> Err http://security.debian.org jessie/updates/main i386 Packages
>>    302  Found [IP: 217.196.149.233 80]
>> Err http://security.debian.org jessie/updates/contrib i386 Packages
>>    302  Found [IP: 217.196.149.233 80]
>> Err http://security.debian.org jessie/updates/non-free i386 Packages
>>    302  Found [IP: 217.196.149.233 80]
>> Fetched 151 kB in 9s (16.2 kB/s)
>>
>> Err:14 http://cdn.debian.net/debian stretch Release
>>    302  Found [IP: 2001:4f8:1:c::15 80]
>> Err:15 http://cdn.debian.net/debian stretch-updates Release
>>    302  Found [IP: 2001:4f8:1:c::15 80]
>> Err:16 http://cdn.debian.net/debian stretch-backports Release
>>    302  Found [IP: 2001:4f8:1:c::15 80]
>>
>> Err:7 http://http.debian.net/debian stretch Release
>>    302  Found [IP: 2001:67c:2564:a119::148:14 80]
>> Err:8 http://http.debian.net/debian stretch-updates Release
>>    302  Found [IP: 2001:67c:2564:a119::148:14 80]
>> Err:9 http://http.debian.net/debian stretch-backports Release
>>    302  Found [IP: 2001:67c:2564:a119::148:14 80]
>>
>>
> 


check.sh
Description: application/shellscript


signature.asc
Description: OpenPGP digital signature

Re: HTTPS enabled Debian Security repository

[Hans-Christoph Steiner]

Ansgar Burchardt:
> Henrique de Moraes Holschuh writes:
>> On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote:
>>> This idea that GPG signatures on the index files is enough has been
>>> totally disproven.  There was a bug in apt where Debian devices could be
>>> exploited by feeding them crafted InRelease files:
>>>
>>> https://www.debian.org/security/2016/dsa-3733
>>
>> This was the *one* bug of this sort in the entire lifetime of apt thus
>> far, AFAIK.
> 
> No, there was also
>https://security-tracker.debian.org/tracker/CVE-2013-1051
> which I found.  That one was fairly easy to exploit (concatenate
> manipulated Release with wrong "-BEGIN PGP SIGNATURE" markers and
> correctly signed InRelease; gpg would verify the signature at the end,
> but apt would use the unsigned, manipulated Release from the beginning)
> 
> Similar bugs were present in several other places in Debian's
> infrastructure as well.
> 
> The one from 2016 is harder to exploit: I asked on #-apt back then and
> the sample exploit had a 1/4 success change with a 1.3 GB InRelease file
> on a memory starved i386 system).

That hit rate is enough to build malware around...


>>> If HTTPS was used, that would mean exploiting that would require
>>
>> One of the dozens of zero-days already found in the TLS stack we had to
>> run like crazy to patch ?
> 
> That is still valid of course, though I'm not sure if GnuPG or TLS
> libraries get wider testing...
> 
> Ansgar
> 

Don't get me wrong, I agree that HTTPS is very overcomplicated and
terrible in a lot of ways.  But the days of plain HTTP/TCP are over.
All connections need to be moving towards encryption.  Even with HTTPS'
faults, we are better off using it than plain HTTP.

.hc

Re: HTTPS enabled Debian Security repository

[Hans-Christoph Steiner]

Christoph Biedl:
> 林博仁 wrote...
> 
>> I believe that there's no benefit on accessing Debian archive with HTTPS as
>> they uses GnuPG for authentication
> 
> GnuPG indeed serves the purposes of authenticity and integrity very
> well. Modulo bugs every now and then, but they happen on other layers as
> well.
> 
> Also, nobody should rely on the privacy in this case since the server
> content is public and the clients have a fairly simple access pattern.
> Decoding the transfers from this isn't trival but seems doable with some
> effort - one day I'll write a prove of concept for this.
> 
> There is however a reason for https, a sad one though: Braindead
> "security" applicances that do deep packet inspection and might reject
> the download of packages.
> 
> Christoph
> 

This idea that GPG signatures on the index files is enough has been
totally disproven.  There was a bug in apt where Debian devices could be
exploited by feeding them crafted InRelease files:

https://www.debian.org/security/2016/dsa-3733

If HTTPS was used, that would mean exploiting that would require
compromising the mirror servers.  With HTTP only, anyone that can see
the network traffic can exploit the Debian box.  Plus there are other
things that using HTTPS improves:

https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/

HTTPS does not entirely solve all these problems, but it does
drastically improve things.

.hc

Re: embedding openssl source in sslcan

[Hans-Christoph Steiner]

Seems like a decent idea for this, if other packages need an insecure
openssl. As for making it hard to link to, the .so can be put into a
non-standard dir so it has to be explicitly enabled both with a
-lcrypto-insecure and -L/usr/lib/openssl-insecure.

.hc

Jonathan Yu:
> Given that this would be useful for other tools, perhaps it's best to
> create an "openssl-insecure" package which would ship a version of openssl
> that has all the bells-and-whistles enabled (including the insecure ones).
> We would have to take care that nothing is unintentionally linked to the
> library. It would be a useful companion to software like testssl.sh (which
> has similar requirements to sslscan)
> 
> I certainly don't have strong feelings about this, especially given that I
> haven't done any of the work... Just a thought :)
> 
> On Fri, Dec 23, 2016 at 9:53 AM, Moritz Mühlenhoff  wrote:
> 
>> Sebastian Andrzej Siewior  schrieb:
>>
>> Please use t...@security.debian.org if you want to reach the security
>> team, not debian-security@ldo.
>>
>>> tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its
>>> source?
>>
>> That's for post-stretch, right? Right now it can simply link against
>> the 1.0.2 copy,
>>
>> Seems fine to me for that use case, and it won't need any security
>> updates to the embedded openssl copy for all practical purposes anyway.
>>
>> Cheers,
>> Moritz
>>
>>
> 
> 

Re: HTTPS needs to be implemented for updating

[Hans-Christoph Steiner]

Hans-Christoph Steiner:
> 
> 
> Peter Lawler:
>>
>>
>> On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
>>> second point requires a lot of work
>>> to resolve.
>>>
>>> Regards,
>>> Christoph
>>>
>>
>> Monday morning yet-to-be-caffienated thoughts...
>>
>> I'm going to ignore the 'inconvenience' because I think in this case
>> that's a specious argument.
>>
>> I acknowledge there's a bucketload of work to implement this. Just gets
>> me to thinking, staging a switch over may be better. eg, a new apt
>> config for https as either 'required' 'desired' and 'off'. This reduces
>> the initial workload. Start with the default 'off', then at some future
>> release move to 'desired' then 'required'.
>>
>> Further, I suggest perhaps an automated survey of the major mirrors to
>> find which ones already support https may be in order. Perhaps the
>> resultant data could be used by the apt-transport-https package for now,
>> as well as deciding when the above mentioned switch over might occur.
>>
>> As I say, decaffienated Monday morning thoughts.
>>
> 
> Here's a script I wrote to do just that, find all Debian mirrors that
> support HTTPS:
> 
> https://gist.github.com/eighthave/7285154
> 
> .hc

Also, it would be really awesome if there was:

https://httpsredir.debian.org/debian

Which automatically redirected to mirrors that support HTTPS.  I filed
an issue here:
https://github.com/rgeissert/http-redirector/issues/78

.hc

Re: HTTPS needs to be implemented for updating

[Hans-Christoph Steiner]

Peter Lawler:
> 
> 
> On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
>> second point requires a lot of work
>> to resolve.
>>
>> Regards,
>> Christoph
>>
> 
> Monday morning yet-to-be-caffienated thoughts...
> 
> I'm going to ignore the 'inconvenience' because I think in this case
> that's a specious argument.
> 
> I acknowledge there's a bucketload of work to implement this. Just gets
> me to thinking, staging a switch over may be better. eg, a new apt
> config for https as either 'required' 'desired' and 'off'. This reduces
> the initial workload. Start with the default 'off', then at some future
> release move to 'desired' then 'required'.
> 
> Further, I suggest perhaps an automated survey of the major mirrors to
> find which ones already support https may be in order. Perhaps the
> resultant data could be used by the apt-transport-https package for now,
> as well as deciding when the above mentioned switch over might occur.
> 
> As I say, decaffienated Monday morning thoughts.
> 

Here's a script I wrote to do just that, find all Debian mirrors that
support HTTPS:

https://gist.github.com/eighthave/7285154

.hc

Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252

[Hans-Christoph Steiner]

Patrick Schleizer:
> Julian Andres Klode:
>> (2) look at the InRelease file and see if it contains crap
>> after you updated (if it looks OK, it's secure - you need
>> fairly long lines to be able to break this)
> 
> Thank you for that hint, Julian!
> 
> Can you please elaborate on this? (I am asking for Qubes and Whonix
> (derivatives of Debian) build security purposes. [1])
> 
> Could you please provide information on how long safe / unsafe lines are
> or how to detect them?
> 
> Ideally could you please provide some sanity check command that could be
> used to detect malicious InRelease files such as 'find /var/lib/apt
> -name '*InRelease*' -size +2M' or so?
> 
> The problem is,
> 
> - debootstrap can only bootstrap from one source such as
> 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt.
> (Correct me if I am wrong, I would hope to be wrong on that one.)
> 
> - bootstrapping from 'http://security.debian.org' is not possible
> [contains only security updates, not a complete repository].
> 
> - So in conclusion one has a chance to get compromised when
> bootstrapping from 'http://ftp.de.debian.org/debian' and then apt-get
> upgrading from 'http://security.debian.org'.
> 
> Is there any way to break this cycle?
> 
> Best regards,
> Patrick
> 
> [1] https://github.com/QubesOS/qubes-issues/issues/2520
> 

One thing that would help a lot with future issues like this is to use
only encrypted connections in /etc/apt/sources.list.  That can be either
HTTPS or a Tor Hidden Service .onion address.  For in depth discussion
of this, see:

* https://labs.riseup.net/code/issues/8143

*
https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/

*
https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/


For the official Debian Tor Hidden Service addresses including apt
mirrors, see:
https://onion.debian.org/

.hc

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

[Hans-Christoph Steiner]

The Android SDK is really probably more like Eclipse.  About 5 years of
support, they are still maintaining Android 2.3.3 to some degree and
that's at least 5 years old.
https://android.stackexchange.com/a/84816

Also, the security profile is relatively low risk for the Android SDK in
general:

* mostly various user utilities
* no setuid or special permissions
* only one daemon-like thing, adb, with no net access by default
* a good chunk is just files on the filesystem (e.g. libs for Android apps)

.hc

Hans-Christoph Steiner:
> 
> BoringSSL is just a part of the Android SDK.  It has an unstable API
> because it is only the C backing to a single Java library called
> conscrypt.  That library is in turn only used as part of the Android
> SDK.  Using the upstream build system, all of the source code is checked
> out at once from many git repos, and built together.  Compare this to
> Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of
> source code that are organized internally as "libraries".
> 
> We are packaging these chunks separately because we believe it will make
> it easier to maintain.  Security updates can happen only in the
> particular package rather than having to build the whole Android SDK
> together as one giant source tree.
> 
> Upstream is already good at providing security fixes for all of the
> various bits, and they maintain quite a few stable releases in parallel.
>  Security maintenance for the Android SDK packages will mostly be a
> matter of just including any new patch versions (i.e. 6.0.1_r14 vs
> 6.0.1_r15).
> 
> .hc
> 
> Ralph Sanchez:
>> My opinion might not mean much, but as a user, I agree with this. If
>> i'm installing from the stable depository, we expect certain things
>> from packages there and everything must be held to those guidelines.
>> And mostly if we are using it from unstable, we are hoping to see it
>> evolve into being put into the stable form, not just stagnate or we
>> won't use it, which is bad for the both the user (losing out on
>> promising programs) and the company (losing out on users), i think
>>
>> On Tue, May 17, 2016 at 11:27 AM, Michael Stone <mst...@debian.org> wrote:
>>> On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote:
>>>>
>>>> BoringSSL is also free software, as long as there are maintainers who
>>>> are willing to spend time on it, I think it has rights to exist in
>>>> Debian. Well I have been contributing to Debian for not long, so
>>>> please point me out my mistakes. :)
>>>
>>>
>>> The question is, "who does the security updates for the package 5 years from
>>> now". As a general rule, we don't allow private embedded copies of libraries
>>> because then a security update for a library means chasing down and fixing
>>> any number of copies. (In historic terms, this was a huge issue, for
>>> example, with zlib bugs.) On top of that, if the upstream says flat-out that
>>> it's an unstable API, putting it into a debian release seems like a bad
>>> idea. Putting it unstable and never letting it make it to stable is a
>>> possibility, but the point of unstable is to eventually get packages into a
>>> released version so that seems somewhat an abuse of the system. If it's
>>> really a standalone component that's expected to change a lot and not
>>> interact with anything else in debian, then putting it in an external
>>> repository seems like a better fit.
>>>
>>> Mike Stone
>>>
>>
> 

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

[Hans-Christoph Steiner]

BoringSSL is just a part of the Android SDK.  It has an unstable API
because it is only the C backing to a single Java library called
conscrypt.  That library is in turn only used as part of the Android
SDK.  Using the upstream build system, all of the source code is checked
out at once from many git repos, and built together.  Compare this to
Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of
source code that are organized internally as "libraries".

We are packaging these chunks separately because we believe it will make
it easier to maintain.  Security updates can happen only in the
particular package rather than having to build the whole Android SDK
together as one giant source tree.

Upstream is already good at providing security fixes for all of the
various bits, and they maintain quite a few stable releases in parallel.
 Security maintenance for the Android SDK packages will mostly be a
matter of just including any new patch versions (i.e. 6.0.1_r14 vs
6.0.1_r15).

.hc

Ralph Sanchez:
> My opinion might not mean much, but as a user, I agree with this. If
> i'm installing from the stable depository, we expect certain things
> from packages there and everything must be held to those guidelines.
> And mostly if we are using it from unstable, we are hoping to see it
> evolve into being put into the stable form, not just stagnate or we
> won't use it, which is bad for the both the user (losing out on
> promising programs) and the company (losing out on users), i think
> 
> On Tue, May 17, 2016 at 11:27 AM, Michael Stone  wrote:
>> On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote:
>>>
>>> BoringSSL is also free software, as long as there are maintainers who
>>> are willing to spend time on it, I think it has rights to exist in
>>> Debian. Well I have been contributing to Debian for not long, so
>>> please point me out my mistakes. :)
>>
>>
>> The question is, "who does the security updates for the package 5 years from
>> now". As a general rule, we don't allow private embedded copies of libraries
>> because then a security update for a library means chasing down and fixing
>> any number of copies. (In historic terms, this was a huge issue, for
>> example, with zlib bugs.) On top of that, if the upstream says flat-out that
>> it's an unstable API, putting it into a debian release seems like a bad
>> idea. Putting it unstable and never letting it make it to stable is a
>> possibility, but the point of unstable is to eventually get packages into a
>> released version so that seems somewhat an abuse of the system. If it's
>> really a standalone component that's expected to change a lot and not
>> interact with anything else in debian, then putting it in an external
>> repository seems like a better fit.
>>
>> Mike Stone
>>
> 

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

René Mayrhofer wrote:
 On 2014-09-25 06:24, Hans-Christoph Steiner wrote:

 W. Martin Borgert wrote:
 On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
 * the signature files sign the package contents, not the hash of
   whole .deb file (i.e. control.tar.gz and data.tar.gz).
 So preinst and friends would not be signed? Sounds dangerous to me.
 All package contents would be signed, except the signature itself.  The
 signature would be a separate file in the ar archive of the .deb that signs
 control.tar.gz and data.tar.gz. See jar or apk format for an example of how
 this works.
 I know I'm late to the discussion, but for the record, I fully agree
 with this approach as the probably best compromise between usability
 (don't underestimate that, see the emergence of the various app shops
 for Linux applications), security, and flexibility. If anybody wants to
 work on that, I'm happy to support it in the University Linz context
 (i.e. as student work, thesis, etc.) and contribute to the process
 (although, depressingly but realistically, not the implementation).
 
 Rene

Since you mention Austria, I'll be based in Vienna from Oct 30th until March
3rd, perhaps we could even arrange a dev meeting/sprint on this topic in Linz
or Vienna.

.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/543fe36a.5070...@at.or.at

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

Daniel Kahn Gillmor wrote:
 Thanks for the discussion, Hans.
 
 On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote:
 Packages should not be accepted into any official repo, sid included, without
 some verification builds.  A .deb should remain unchanged once it is accepted
 into any official repo (maybe experimental could be an exception, but not
 sid).  I think that is essential.
 
 But some repositories could have different rules for package inclusion
 than others, right?  for example, say debian wanted to offer an
 unstable-reproducible suite, which only permitted packages that had been
 independently rebuilt reproducibly by multiple DDs and at least two
 different buildds.  Ideally, the packages that are shared between this
 repository and other repositories would be identical.
 
 Note that if .deb files are internally signed, two developers *cannot*
 create the same exact .deb if they do not share their secret keys.

You're missing one key detail here, let's see if I can suss it out:

* the builds are _exactly_ the same, except the signatures
* the embedded signature does not sign the signature files (see
  jar and apk formats, which are almost the same, for examples)
* anyone can just copy other dev's signature into the package and it
  will validate because the package contents are exactly the same
* the signature files sign the package contents, not the hash of
  whole .deb file (i.e. control.tar.gz and data.tar.gz).

Therefore two developers can easily create the same .deb if that have access
to the signature file since they can just copy it.  No need to run the signing
process again.  If people create their own .deb files in a reproducible
process, then copy in the same signature files, then the hash of the .deb will
be the same.


 I see no reason for changing the .deb between sid and testing, except for
 perhaps how existing implementations are doing it.  It is usually worth the
 work to do things right way, rather than the easy way.
 
 I agree with this sentiment, i think we're trying to sort out what is
 the right way.
 
 The build verification process needs to happen between the package upload and
 publishing to sid or security updates.  Two builds is easy: the .deb that the
 uploader generates and the one the Debian process makes.  That is probably 
 enough.

 In Debian's case, it probably is too complicated to include multiple
 signatures.  In that case, there should be only one canonical signature by 
 dak
 once the build verification signature threshold has been passed. Then all of
 the other signatures could be added to .buildinfo or .changes or whatever
 other file.
 
 but the .buildinfo file is designed to say i generated the .deb that
 matches this digest exactly, which the corroborating builder cannot do,
 because they cannot produce the internal signature.

No need to produce the signature, just copy it!


 Plus, we now have two different places to look for signatures.  one
 canonical one and then some external ones, and the signatures
 themselves have different properties (one signs parts of the deb, the
 other signs the whole .deb; one signs the build environment, the other
 does not, etc)

Definitely look at jar signing, it handles multiple signatures fine.  I see no
reason why you can't include an unlimited number of signatures in a .deb.
Changing the number of signatures will change the hash of the .deb, that is
why there needs to be a canonical set of signatures for each .deb.

As for signing the hash of the entire .deb, that is what apt already gives us,
that does not need to be reproduced in the dpkg-sig embedded signature. For
people who want to verify the contents of a .deb with any kind of signature,
then a tool will have to compare the hashes of control.tar.gz and data.tar.gz.


 Another option is to do it like f-droid.org does.  F-droid.org generates a 
 APK
 signing key for each app, then manages the signing on a specialized signing
 server.  Or another option is just requiring all the signers to be from the
 debian-keyring, rather than an exact match for previous signers.
 
 Again, i think this is getting ahead of the discussion.  i'm not
 proposing that we try to set debian (or other derived distro) archive
 policy here, i just think we want to think
 
  In any case, the .deb needs to remain unchanged.
 
 right.  but it can't be unchanged if the archive distributor decides
 that a different signer is the canonical signer.  So you're making the
 contents of the .deb dependent on archive policy, rather than the other
 way around.
 
 I *want* ubuntu and debian and mint to all ship the exact same .deb for
 any packages that are reproducible (and eventually, all packages!) that
 they share, and i also want those different distros to be able to
 produce the reproducible .deb independently of one another.  If
 foo_1.2-3_mipsel.deb is built first on the ubuntu builders and ubuntu
 decides to include it in the archive, and then debian is able to
 reproduce that build

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

W. Martin Borgert wrote:
 On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
 * the signature files sign the package contents, not the hash of
   whole .deb file (i.e. control.tar.gz and data.tar.gz).
 
 So preinst and friends would not be signed? Sounds dangerous to me.

All package contents would be signed, except the signature itself.  The
signature would be a separate file in the ar archive of the .deb that signs
control.tar.gz and data.tar.gz. See jar or apk format for an example of how
this works.

.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/5423991b.5010...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

Holger Levsen wrote:
 Hi Hans,
 
 On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote:
 What I'm talking about already exists in Debian, but is rarely used. 
 dpkg-sig creates a signature that is embedded in the .deb file.  So that
 means no matter how the .deb file got onto a system, that signature can be
 verified. I'm proposing to start making dpkg-sig a standard part of
 official .deb files. This can be done in stages to make it manageable. 
 Here's a rough idea of that:
 
 how about you file a bug against dpkg-sig and put your plan and justification 
 in there. Here on the mailinglist it will just be lost...

Finally did this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153

And someone else filed a bug to get apt-transport-https included in apt:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756535

.hc



signature.asc
Description: OpenPGP digital signature

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/17/2014 08:20 AM, Joel Rees wrote:
 A little context?
 
 On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner h...@at.or.at wrote:
 [...]
 * TAILS is a Debian-based live CD
 * the core system image by definition cannot be modified (live CD)
 * it has a feature for persistent storage of files on a USB thumb drive
 
 What happens when you put your live-image CD or USB in a box whose
 boot ROM or BIOS ROM has been overwritten through some vulnerability
 and now contains a hook to a backdoor?
 
 I'm not going to say that the whole idea of a live-image system is
 full of holes, but I personally do not trust anything important to any
 of the live images I use from time to time on hardware I don't
 control, except for the live CDs I use for repairing systems that have
 gone belly-up.
 
 I have, in the past, brought live USBs home from work and booted them
 on my home hardware. I don't do that any more. (I'd have to mount the
 USB on a running system at home and verify the parts of the file
 system that shouldn't change.)

_All_ software installed is vulnerable to this kind of exploit.  Using a live
CD does not address the issue of an untrusted BIOS any more than using a
normal Debian install.  The live CD does address lots of other issues that
cannot be addressed easily in a normal Debian install.

Same goes with offline vs online systems, both are entirely vulnerable to
already exploited BIOSes.  An offline machine reduces the risk since an
exploited BIOS could only be installed by gaining physical access.


 * it also can save apt cache/lib to that persistent store
 * it will automatically install packages on boot from that store
 * mostly people use TAILS in online mode
 * there is a fully offline mode in development
 * offline TAILS cannot verify the packages if apt lists are  2 weeks
 
 Yes it can.

Not without modifying the apt config.  The point here is to have a working
system that is tested and audited, rather than just a set of instructions or
recommendations.

.hc


 * updating the apt cache/lib is painful on an offline machine
 
 Don't turn your nose up at wrappers. Lots of very useful stuff around
 that is just wrapping something else. Quite stable, if the wrapper
 does its job fully.
 
 * an offline machine's threat model is drastically simpler
 
 I disagree with that, as you see.
 
 On top of all that, each update increases risk of compromise on offline
 machines because each new update provides a vector to run a script or
 introduce new code that otherwise does not exist (no network!).
 
 I suggest looking at the reasons for that again.
 
  And any
 decent attacker with physical access to the machine will always get in.
 
 Isn't this a red herring?
 
 Other people want to be able to directly download .deb packages and have then
 verified as part of the install process.  This is not my primary concern, but
 I do think it is a valid one.  It would also be addressed by fully support of
 dpkg-sig.

 .hc

 
 I understand the hesitation. Having individual packages signed is a
 good lead to a false sense of security.
 
 One point I strongly suggest considering is, for example, that
 firefox, direct from mozilla.org, on stock debian, is more likely to
 have vulnerabilities than firefox (iceweasel) loaded from the debian
 packages archives.
 


-- 
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/53c7ffee.6060...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/16/2014 08:06 AM, Holger Levsen wrote:
 Hi,
 
 On Mittwoch, 16. Juli 2014, Michael Stone wrote:
 Yes you are--what you described is exactly how the Release files work.
 
 Well, there are (many) other .debs on the net which are not part of our 
 releases, so it still seems to me that making .changes files accessable in 
 standardized ways could be very useful.

What I'm talking about already exists in Debian, but is rarely used.  dpkg-sig
creates a signature that is embedded in the .deb file.  So that means no
matter how the .deb file got onto a system, that signature can be verified.
I'm proposing to start making dpkg-sig a standard part of official .deb files.
 This can be done in stages to make it manageable.  Here's a rough idea of that:

1. Adding a 'builder' signature should be easy to start with, make `debsign`
also run `dpkg-sig --sign builder` on any .deb files it finds.  I believe that
`dpkg -i` will already try to verify a signature if it exists.

2. add something like `dpkg --require-debsig` to force checking of the
dpkg-sig signature.  This would be optional to start with, and complimentary
to the already existing `dpkg --no-debsig`.

3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full`
to sign packages.

4. etc.

As for Michael's complaint that I have not described a real problem, I have
tried already in the thread, so I'll try again in bullet points:

* TAILS is a Debian-based live CD
* the core system image by definition cannot be modified (live CD)
* it has a feature for persistent storage of files on a USB thumb drive
* it also can save apt cache/lib to that persistent store
* it will automatically install packages on boot from that store
* mostly people use TAILS in online mode
* there is a fully offline mode in development
* offline TAILS cannot verify the packages if apt lists are  2 weeks
* updating the apt cache/lib is painful on an offline machine
* an offline machine's threat model is drastically simpler

On top of all that, each update increases risk of compromise on offline
machines because each new update provides a vector to run a script or
introduce new code that otherwise does not exist (no network!).  And any
decent attacker with physical access to the machine will always get in.

Other people want to be able to directly download .deb packages and have then
verified as part of the install process.  This is not my primary concern, but
I do think it is a valid one.  It would also be addressed by fully support of
dpkg-sig.

.hc



signature.asc
Description: OpenPGP digital signature

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/14/2014 01:57 PM, Michael Stone wrote:
 On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote:
 Or, you could make use of the Check-Valid-Until and Min-ValidTime options in
 apt.conf. There's a reason things are done the way they are, and you 
 probably
 aren't going to find a lot of interest in getting people to do a lot of work
 to create a system which is duplicative at best and less secure at worst.

 Sure, those options would work well for people who understand them and want 
 to
 tweak them. I'm not interested in that.  I'm currently working on a
 TAILS-based system for running build and signing processes on machines that
 _never_ go online.  So that means that changing the apt config is not an
 option.  I'm working with apt-offline currently and that helps a lot.
 
 You're making an assertion and not supporting it. Changing a configuration
 parameter is unacceptable, but switching to an entirely different package
 trust model is ok? You care very much about the trust path to debian packages
 but not anything else (like the software that's installing them?) Seems like a
 weird problem, but maybe you're just not fully explaining it. If that's really
 the constraint set I guess it may be a case of you created your problem, so
 you get to fix it.
 
 TAILS is a live CD, but provides a method of installing and maintaining new
 packages on top of what is provided by the live CD.  That means those 
 packages
 are stored in an encrypted stash, and are installed on each boot.  So in 
 order
 to use this feature, the apt cache needs to be refreshed using apt-offline at
 least every two weeks, otherwise the packages won't be installed since apt 
 can
 no longer validate them.
 
 Have you actually tried setting Acquire::Check-Valid-Until off; in apt.conf?
 What was the result?

How do you propose managing a distro that mostly needs apt as is, but other
times need Acquire::Check-Valid-Until off;?  In other words, how would you
manage a distro that sometimes uses apt as it was designed, and other times
has to tweak in ways that would break the main use case?  That sounds like a
recipe for lots of edge cases and bad bugs.

The situation in TAILS in not like normal Debian installed, but it basically
the same for any live CD that has the option of installing additional packages
from a persistent store.

TAILS is mostly meant to be on online system, but fully offline support is in
the works.  Having signatures in .debs is entirely complementary to the
existing apt system.  It does not change how apt works at all in the normal
network mode.  The apt metadata would be used to verify that repo information
is up-to-date, downloaded packages are intact, etc.  Then the moment of
install would use the signature in the .deb to verify that the .deb is intact
and signed by a trusted key.  Right now, `dpkg -i package.deb` does not verify
against any signature.

So for the offline system, if the .deb files have signatures, the .deb files
can be copied on the offline machine however (apt-offline is a good option,
but others are possible), then they can be installed, uninstalled, etc. after
verifying that the signature in the .deb is trusted.  So really, this would
not be modifying apt so much as modifying `dpkg -i`.

.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/53c564a8.4000...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/15/2014 02:11 PM, Michael Stone wrote:
 On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote:
 How do you propose managing a distro that mostly needs apt as is, but other
 times need Acquire::Check-Valid-Until off;?  In other words, how would you
 manage a distro that sometimes uses apt as it was designed, and other times
 has to tweak in ways that would break the main use case?  That sounds like a
 recipe for lots of edge cases and bad bugs.
 
 Um, so does your suggested change. Using apt with the valid check off is
 fundamentally equivalent to using signed .debs. Both mechanisms have the same
 failure modes, but one is a configuration change and one reworks the trust
 path to get to the same place.
 is up-to-date, downloaded packages are intact, etc.  Then the moment of
 install would use the signature in the .deb to verify that the .deb is intact
 and signed by a trusted key.  Right now, `dpkg -i package.deb` does not 
 verify
 against any signature.
 
 This is funcationally the same thing as checking that the hash of the deb is
 the same as the one listed in the Releases file (or apt-cache show) before
 installing the deb. You could do that in a wrapper.
 
 So for the offline system, if the .deb files have signatures, the .deb files
 can be copied on the offline machine however (apt-offline is a good option,
 but others are possible), then they can be installed, uninstalled, etc. after
 verifying that the signature in the .deb is trusted.  So really, this would
 not be modifying apt so much as modifying `dpkg -i`.
 
 Right, as I said, a complete reworking of the trust path (new code, new bugs,
 etc.) to get essentially the same result. It sounds like what you need to do
 to get the result you're talking about is grab the releases file along with
 the deb, validate the sig on the releases file (except ignoring the
 expiration), verify the hash of the .deb, then install the .deb. Depending on
 the specifics of the implementation you could do that from an apt command line
 by setting the Check-Valid-Until via -o
 or by writing a dpkg wrapper. In any event it shouldn't be all that much code
 and certainly much less what you're proposing. (I'd also hope that your front
 end would at least tell the user how old the Release file is, and that the
 distributor recommends checking for a newer version. The expiration mechanism
 is important to ensure that people aren't installing old/vulnerable versions
 of trusted packages--which may be equivalent to installing trojan packages.)
 
 Mike Stone

There is already an existing format for signing and verifying .debs, the
signing keys infrastructure is already in place, there is a clear spot to
validate on install, doing some hacked together dpkg wrapper sounds like a
good way to prototype, but a bad way to widely deploy a working system.

I'm not saying that adding .deb signature validation to `dpkg -i` would be
trivial and without risk.  But the idea of validating signed package files on
install is hardly revolutionary or even novel any more. Indeed it is pretty
widespread: think Android, Fedora, Java, iOS, etc.  I think it is the cleanest
approach for the problem that I've outlined.

.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/53c58e06.3030...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

I agree that .deb packages should be individually signed, but I don't think
that the current apt system is vulnerable to package corruption.
 Having a signature in the .deb. would make things a lot more flexible in
terms of distribution because a .deb could be verified no matter how it ends
up on your system.  That lets people experiment and create their own
distribution systems, or use the tools that they already know when apt does
not work for them (internet outages, blocks, etc).

Having individually signed .deb packages would not change the existing
workflow since uploaders already have to sign packages before uploading them
to Debian.  This has been discussed in the past.  I really think it is just a
matter of someone doing the work.

.hc

On 07/09/2014 08:29 PM, Kitty Cat wrote:
 For years I have been concerned with MITM attacks on Debian mirrors.
 
 I think the only valid solution would be to individually sign EACH package
 with a valid GPG
 signature from a trusted source.
 
 I think EACH official package from Debian should be GPG signed by both
 package maintainers and
 also signed by official Debian release people.
 
 For example... What is secure about this download link?
 
 http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/debian-7.5.0-i386-netinst.iso
 
 Sure I can also download and check the signatures from here:
 
 http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/
 
 However, what if http://cdimage.debian.org/ is actually an NSA mirror site
 and not the real one?
 
 Lets say that I want download anything from http://cdimage.debian.org/
 http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/
 
 My downloader resolves http://cdimage.debian.org/
 http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ to NSA mirror
 site through DNS cache poisoning
 or some other means. So, whatever I am downloading is already compromised.
 All signatures are valid
 but are from the NSA.
 
 So there is no way for me to actually check that I have downloaded valid
 files if everything that I see is
 actually faked!
 
 If I go edit apt sources list and manage to get an actual real Debian
 server update, then apt tells me that
 all packages available to download are security compromised.
 
 Or lets say that I get a real install ISO disc and then later on my apt
 mirror site is redirected to NSA mirror.
 Apt will tell me that all packages available to download are security
 compromised.
 
 One of the two scenarios above has actually happened to me!!! I don't know
 if it is actually the NSA but it
 DID happen to me. Aptitude was telling me that every single package
 available for download was compromised!
 
 Think about this for a minute. If my ISP or upstream provider is secretly
 cooperating with the NSA and the
 NSA wants to compromise my machine, they can make it so that everything
 that I download is through an
 NSA source!
 
 *Remember, the NSA can create VALID SSL certificates for any website on the
 fly.*
 
 Your web browser trusts many certificate authorities and which ones are
 cooperating with the NSA?
 
 So how can we really be sure that our Debian install has not been
 compromised from the beginning?
 
 
 
 
 
 
 
 On Thu, Jul 3, 2014 at 8:44 PM, Hans-Christoph Steiner h...@at.or.at
 wrote:
 

 After the latest revelation about NSA tracking all Tor downloads[1] (with
 source code!) and the whole Debian mirrors and MITM redux, I think we
 should
 start talking about concrete steps that we can take to improve the
 situation.

 The first things that came to mind would be quite easy to do:

 * include apt-transport-https by default in Debian
 * include existing HTTPS mirrors wherever Debian mirrors are listed
   * https://www.debian.org/mirror/list
   * netselect-apt
   * http://http.debian.net/
   * apt-get's mirror://
 * make http://cdn.debian.net/ have an only-HTTPS version
 * encourage mirror operators to set up a Tor Hidden Service

 There is already a good collection of HTTPS mirrors to choose from
 (not-counting all the ones that have HTTPS enabled without a proper
 certificate).

 https://mirror.i3d.net/pub/debian/
 https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/
 https://mirror.cse.unsw.edu.au/debian/
 https://mirrors.kernel.org/debian/
 https://the.earth.li/debian/
 https://mirror.vorboss.net/debian/
 https://ftp.arnes.si/pub/packages/debian/
 https://ftp.iitm.ac.in/debian/
 https://ftp.uni-erlangen.de/debian/
 https://ftp-stud.hs-esslingen.de/debian/
 https://mirrors.ustc.edu.cn/debian/
 https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/
 https://dennou-q.gfd-dennou.org/debian/
 https://dennou-k.gfd-dennou.org/debian/
 https://dennou-h.gfd-dennou.org/debian/


 .hc

 [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html


 --
 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/53b6150a.3000...@at.or.at


 


-- 
To UNSUBSCRIBE, email

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/14/2014 12:31 PM, Paul Wise wrote:
 On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote:
 
 I agree that .deb packages should be individually signed
 ...
 This has been discussed in the past.  I really think it is just a
 matter of someone doing the work.
 
 The work has been done many years ago and has been in the archive for
 ages but has probably bitrotten since apt repo signing won (mostly,
 some derivatives don't sign their repos) and now no-one uses deb
 signing (probably). The packages are dpkg-sig debsigs debsig-verify.
 

Ah yes, I had forgotten about those.  What I'd like to see is that stuff being
integrated into the existing Debian packaging process, so that when you sign
an upload, the .deb is automatically signed as well.

One place that this will help a lot is managing completely offline machines,
like machines for running secure build and signing processes.  Right now, in
order to install a package securely on an offline machine, I have to make sure
that the apt-get cache is no older than two weeks, otherwise apt-get considers
the info expired and no longer trusted.  It make sense to have a listing of
packages and updates expire.  It does not make sense to have the signature on
an individual package expire.  Debian does not provide the later option.

I'd like to contribute to this effort, so the first question are what are any
issues that might block including this into normal package signing process
when someone is uploading to Debian?  That seems like the easiest and lowest
risk place to start.

.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/53c40932.4070...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/14/2014 12:59 PM, Paul Wise wrote:
 On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote:
 
 I'd like to contribute to this effort
 
 First thing is to get #733029 fixed, which involves disabling signing
 by default (signing should be done after testing not before) and
 adding a signing tool to dpkg-dev. Then debsign/debuild need adapting
 to the new default and the new signing tool. Then you can modify the
 dpkg signing tool to sign .deb files using code from the old stuff and
 convince the dpkg maintainers to accept it. Somewhere in there the old
 approaches/code should be looked at, checked if they still work and
 the old documentation and external websites (some of them only on
 archive.org) and mailing list discussions.

I agree that dpkg-buildpackage should not sign try to sign by default unless
the signer in debian/changelog matches the currently logged in person.

But there should always be at least builder signature on every .deb.  That
signature is not there to testify that it is a tested release, it is there to
verify that the package was not modified since the builder created it.

The Android security model is a good example: you cannot even install an .apk
(like an Android .deb) that does not have a signature in it.  All .apks must
have a valid signature in order to be installed.  For debug builds, the
Android build tools make it dead simple to use a debug key to sign .apks.

.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/53c40fcc.7050...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/14/2014 01:12 PM, Michael Stone wrote:
 On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote:
 One place that this will help a lot is managing completely offline machines,
 like machines for running secure build and signing processes.  Right now, in
 order to install a package securely on an offline machine, I have to make 
 sure
 that the apt-get cache is no older than two weeks, otherwise apt-get 
 considers
 the info expired and no longer trusted.  It make sense to have a listing of
 packages and updates expire.  It does not make sense to have the signature on
 an individual package expire.  Debian does not provide the later option.
 
 Or, you could make use of the Check-Valid-Until and Min-ValidTime options in
 apt.conf. There's a reason things are done the way they are, and you probably
 aren't going to find a lot of interest in getting people to do a lot of work
 to create a system which is duplicative at best and less secure at worst.
 
 Mike Stone

Sure, those options would work well for people who understand them and want to
tweak them. I'm not interested in that.  I'm currently working on a
TAILS-based system for running build and signing processes on machines that
_never_ go online.  So that means that changing the apt config is not an
option.  I'm working with apt-offline currently and that helps a lot.

TAILS is a live CD, but provides a method of installing and maintaining new
packages on top of what is provided by the live CD.  That means those packages
are stored in an encrypted stash, and are installed on each boot.  So in order
to use this feature, the apt cache needs to be refreshed using apt-offline at
least every two weeks, otherwise the packages won't be installed since apt can
no longer validate them.

Having a system that verifies existing .deb files against their own signature
would eliminate this problem entirely.  The apt expiration is only meant to
protect against network attacks, so having to work around the expiration on a
completely offline machine only complicates the process of running an offline
machine, which also has security ramifications.

For more info:
https://dev.guardianproject.info/projects/psst/wiki/CleanRoom
https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html
https://tails.boum.org/blueprint/remember_installed_packages/
https://labs.riseup.net/code/issues/7208

.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/53c411c2.4070...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/07/2014 06:43 PM, Jeremie Marguerie wrote:
 On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote:
 If I'm looking at a catalog page from a shoe store on my table,
 connected via the phone network, getting close to my 2G cap for my
 wireless router for the month. My battery's getting low. Do I want
 to waste bandwidth and CPU cycles for TLS encoding, just for
 pictures of shoes?

 Let's try to turn our focus back to the question at hand, which is
 whether there are merits to promoting https mirrors for users who have
 concerns about being watchlisted based on their software choices. I
 think client cpu cycle and bandwidth concerns are a bit of an
 anachronism these days anyway.
 
 I think you pulled out the only reason why using https for mirrors
 would be useful.
 
 The threat analysis doesn't show any practicable way for the any
 attacker to prevent alter packages even with control of the network.
 He could block updates but the client-side would noticed: out-of-date
 repository and package list, failed to download specific packages.
 
 HTTPS is a solution to this risk scenario:
  A) I don't want anyone to know which package I download (passive listening)
  B) I don't want a third party to selectively prevent me from
 downloading a package/update (active man i the middle)
 
 Scenario A is more likely to happen or to already be in place.
 
 HTTPS in this case is *not* about security but just privacy.
 
 1) Performance concern: The CPU cycles for encrypting is now low
 enough so that it seems feasible. Not all package providers need to
 provide https-based repository but having a few of those and give them
 visibility would be greatly appreciated.
 
 2) TLS certificates: we do not need the package to be behind a
 debian certificate, just to be behind a certificate trusted by a
 recognized third party (same requirement as for websites). Since we do
 not seek authentication of the package but just privacy, we only need
 to ensure that we talk to the server we wanted to, whichever it is.

I'm trying to practice what I preach here, so I set up my very first debian
mirror.  It is hosted on my home connection, so be gentle.  It is only
debian-security for amd64 and i386:

deb http://dju2peblv7upfz3q.onion/debian-security/ wheezy/updates main

This is a test repo, so be sure to keep a real debian-security mirror in your
sources.list!  Just put it after the above line, and apt-get will prefer the
tor hidden service, but still get the latest updates available from
debian-security.

.hc





signature.asc
Description: OpenPGP digital signature

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/06/2014 10:20 PM, Michael Stone wrote:
 On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote:
 And you know, the funny thing is that MSIE took to warning people
 when there was a mix of encrypted and unencrypted data on a page. How
 long ago? Yeah, I know, it was so they could display that red herring
 of a lock for secured pages.

 You don't need a warning when you are looking at un-encrypted data.
 You only need a warning if you are _sending_ un-encrypted data.
 
 This kind of threat analysis is why so many of us are still skeptical of the
 need for HTTPS package mirrors.
 
 Mike Stone

Do you have another idea for making it difficult for network observers to keep
track of the software people are using?

Do you think it does not matter that governments and companies are tracking
the packages that people are downloading?


.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/53baecd7.3080...@at.or.at

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/06/2014 10:31 PM, Lou RUPPERT wrote:
 Joel Rees:
 On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT
 hims...@louruppert.com wrote:

 As someone pointed out, verifying the mirror we've connected to is
 not useful when we don't particularly have, or want, a way to
 prevent a spook-owned mirror from joining the pool.
 
 OK so supposing the NSA offers its own mirror. The package
 installation process verifies PGP signatures. What is the actual
 scenario you're trying to prevent?

apt repositories are great because the users do not have to rely on the
servers that host the repositories in order to know that they packages are
authentic and unmodified.

Tor provides the same resilience in terms of privacy.  If apt-get is accessing
the NSA mirror using Tor, then even the NSA will not be able to see the IP
address of the computer that is downloading from that mirror.  And as long as
apt does not leak much metadata, it would be quite difficult for the NSA to
de-anonymize that connection.

.hc





signature.asc
Description: OpenPGP digital signature

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/04/2014 11:43 AM, Lou RUPPERT wrote:
 Joel Rees:
 On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
 h...@at.or.at wrote:

 [rhetoric encouraging the use of TLS transport for mirrors] [list
 of current https mirrors]
 
 Far be it from me to argue with ucalgary.ca, but one thing that 
 bothers me about using TLS as a download transport is that, if I
 were the spooks, and I wanted a huge sample of crypts from a known 
 plaintext, I could think of worse ways to go than to get the 
 opensource crowd to provide them for me.
 
 Any popular site with relatively static content would do that. Apple
 store or Play store would probably provide a more useful dataset for
 them anyway. But if you configure it and the clients to favor
 ephemeral keys you reduce the usefulness of captured traffic in being
 able to simulate the server itself.
 
 I mean, yeah, they probably have the resources to simulate the
 debian download infrastructure in their internal server farms, but
 why do their work for them and free their resources up for other
 jobs?
 
 I'm not sure that's a realistic scenario.
 
 Especially when the only real advantage of using TLS download 
 transport is (the illusion of) being able to download what you
 want without them knowing exactly what you downloaded.
 
 Yeah they could probably infer it based on the session size. They do
 that for other encrypted streams, like determining successful SSH logins.
 
 But TLS also serves as a sort of sloppy authentication mechanism,
 assuring you that someone someplace has vouched for the fact that
 you've connected to the system you intended to connect to. It's not
 terribly useful when you already sign your packages, but layers etc.

I'm with Lou on this one, there are already much bigger and better data sets
for that.  According to this paper[1], Fedora 11+, Red Hat, SUSE, Google
updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and
others all use HTTPS for their updates.   Debian is behind the curve here,
HTTPS for updates is becoming the norm.  Plus if the HTTPS it set up with
Forward Secrecy ciphers, the keys are frequently rotated.

And on the flipside of Joel's argument, right now, the NSA tries to store as
much encrypted data as possible.  That way when they get the key later, they
can go back and decrypt old traffic.  So generating more HTTPS traffic means
they can't keep up as much.  But this is probably not really important in this
case since they would probably notice that the sites are mirrors and ignore
the traffic.

.hc

[1] http://freehaven.net/~arma/tuf-ccs2010.pdf  or
https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf



signature.asc
Description: OpenPGP digital signature

Re: PPA security (was: Debian mirrors and MITM)

[Hans-Christoph Steiner]

On May 30, 2014, at 2:41 PM, W. Martin Borgert wrote:

 Quoting Jeremie Marguerie jere...@marguerie.org:
 Thanks for bringing that issue! I feel the same way when I install a
 packet from a non-official PPA.
 
 Unfortunately, every package can do anything: pre-inst, post-inst,
 pre-rm, post-rm run as root. If you don't trust a PPA the same way
 you trust your OS vendor (Debian, Ubuntu or whoever), install only
 in a VM or a container (not sure, whether a docker container is
 considered safe enough, but chroot is not sufficient).
 
 Alternatively, download the package, unpack it, remove maintainer
 script or check them carefully, check for s-bits on binaries etc.
 repack it and install. I'm probably missing more checks here.
 
 While it would be nice to have sth. like less trusted sources and
 allow their packages only certain kinds of install/de-install
 operations (i.e. no maintainer scripts) etc., it's  hard to get
 right and a broken solution would put users at risk.

This could be approached another way.  There could be scripts in the packaging 
tools that mark a package if it does not run anything in any of the scripts 
that does not come from the packaging tools.  I think many many packages would 
qualify here, most packages do not touch the pre/post scripts, so the ones that 
are included are generated by debhelper or whatever.

Then you could see whether a package is requesting to run its own scripts as 
root, and make the call there.  A package that does not add anything to those 
scripts would be pretty safe to install, at least.

.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/9145da3f-12d4-42fc-80a3-2b918e510...@at.or.at

Re: Debian mirrors and MITM

[Hans-Christoph Steiner]

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

 Kurt Roeckx k...@roeckx.be 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

[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 Jul 3, 2014, at 11:05 AM, Hans-Christoph Steiner wrote:

 
 On May 30, 2014, at 10:06 AM, micah anderson wrote:
 
 Kurt Roeckx k...@roeckx.be 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 Jul 3, 2014, at 11:55 AM, Reid Sutherland wrote:

 On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner h...@at.or.at 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 
 https://www.debian.org/CD/verify.

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

[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

[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 07/03/2014 12:38 PM, Reid Sutherland wrote:
 On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner h...@at.or.at 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

[Hans-Christoph Steiner]

On 07/03/2014 12:58 PM, Reid Sutherland wrote:
 
 On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner h...@at.or.at 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

[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

[Hans-Christoph Steiner]

On 07/03/2014 02:26 PM, Bernhard R. Link wrote:
 * Hans-Christoph Steiner h...@at.or.at [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

concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

After the latest revelation about NSA tracking all Tor downloads[1] (with
source code!) and the whole Debian mirrors and MITM redux, I think we should
start talking about concrete steps that we can take to improve the situation.

The first things that came to mind would be quite easy to do:

* include apt-transport-https by default in Debian
* include existing HTTPS mirrors wherever Debian mirrors are listed
  * https://www.debian.org/mirror/list
  * netselect-apt
  * http://http.debian.net/
  * apt-get's mirror://
* make http://cdn.debian.net/ have an only-HTTPS version
* encourage mirror operators to set up a Tor Hidden Service

There is already a good collection of HTTPS mirrors to choose from
(not-counting all the ones that have HTTPS enabled without a proper 
certificate).

https://mirror.i3d.net/pub/debian/
https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/
https://mirror.cse.unsw.edu.au/debian/
https://mirrors.kernel.org/debian/
https://the.earth.li/debian/
https://mirror.vorboss.net/debian/
https://ftp.arnes.si/pub/packages/debian/
https://ftp.iitm.ac.in/debian/
https://ftp.uni-erlangen.de/debian/
https://ftp-stud.hs-esslingen.de/debian/
https://mirrors.ustc.edu.cn/debian/
https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/
https://dennou-q.gfd-dennou.org/debian/
https://dennou-k.gfd-dennou.org/debian/
https://dennou-h.gfd-dennou.org/debian/


.hc

[1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html


-- 
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/53b6150a.3000...@at.or.at

Re: NSA software in Debian

[Hans-Christoph Steiner]

On 01/26/2014 01:30 PM, Andrew McGlashan wrote:
 On 25/01/2014 7:39 PM, Emmanuel Thierry wrote:
 Then DNSSEC appeared ! :)
 
 I wish it was that simple  I don't believe it is today, but one day
 it will have to be the standard.
 
 I remind you it is really difficult to compromise DNS zones protected by 
 DNSSEC, even if you have control on root DNS servers (they probably have it) 
 and the knowledge of the complete root DNS key (they likely don't have it).

 There is no point in considering DNS as compromised, since it would be much 
 easier (and as difficult to hide) to subvert IP routing. By the way if you 
 succeeded in redirecting DNS traffic to your box, you probably have the 
 power of redirecting all the traffic to your box.
 
 It is technically very easy to compromise DNS for many people.  It often
 surprises me that people don't question absolutely whether or not a
 webpage is legitimate, they almost always take it on faith unless there
 is something very obviously wrong and even then the person will take
 some convincing (especially the lesser educated on these matters).
 
 Kind Regards
 AndrewM

I think the MITM attacks that the NSA does on the core internet routers are
likely based on IP rather than DNS.  The reports talk about the system is
setup to respond before any of the real servers can.  So my guess is that they
are replying to ARPs, thereby claiming an IP.  Just a guess...

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e82a63.4010...@at.or.at

Re: NSA software in Debian

[Hans-Christoph Steiner]

On 01/20/2014 12:22 PM, Octavio Alvarez wrote:
 On 01/20/2014 05:29 AM, Marco Saller wrote:
 I have read that the NSA proposed to include SELinux in linux 2.5. (Linux 
 Kernel Summit 2001)
 Don't you think that may be one of their fancy tricks to gain access to 
 computers running linux? Some news websites also mention vulnerabilities 
 similar to this one.
 It would be a great idea to include malicious software to kernel modules.
 
 It is easy to come up with that idea, and it's easy to fear to it. It's
 easy to write about it and to popularize it and cause mass-delusion.
 It's difficult to prove, though.
 
 If you consider that SELinux code available and with so many auditing
 humans and tools it's not as easy as it sounds. It can happen, but it's
 not as easy as they can, therefore they are.
 
 As others have said, the NSA doesn't need specific backdoors. There are
 many vulnerabilities in all software already available which are already
 being exploited.
 
 The more general problem is that not all programmers like or know
 formality and that not all developers like strict code and algorithm
 correctness. *That* is something to worry about.
 
 I wouldn't worry about SELinux specifically.


There are also so many vulnerabilities below the layer that Debian occupies.
There can be malware in BIOS and firmware blobs, there can even be malware
built into the hardware, or added later in between when it has been shipped
from the manufacturer and before it arrives at your house.  The NSA hardly has
exclusive domain over this stuff.  UK, Canada, Australia, Russia, China, Iran,
and many other countries have very capable intelligence services that are also
working on such exploits.  Then there are all the freelancers who just sell
exploits to the highest bidder.

I think the only way forward is to keep focusing on making progress and avoid
getting bogged down in the paranoia.

Deterministic Reproducible Builds is a good example of making key progress:
https://wiki.debian.org/ReproducibleBuilds

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ddf886.1050...@at.or.at

Re: SSL for debian.org/security?

[Hans-Christoph Steiner]

The whole card setup would be less that 50 Euros, that does not seem at all
like a significant amount of money.

You can get a card for 14€ and a USB reader for 18€
http://www.g10code.com/p-card.html

The cards have two modes with which they work with keys:

* generate the key on the card, export the public key
* import a secret key generated elsewhere

Having the key generated on the card is the most secure, since those cards are
designed so you can't read the secret key off of the card.  So the cost of
putting a new certificate on the card is only someone's time for generating
and uploading and new key to it.

.hc

On 11/12/2013 04:34 AM, Pedro Worcel wrote:
 Also, what is to prevent someone interfering with the creation of the
 certificate that will be embedded in the device (or poor pseudo-random
 while generating it, etc.), and what would be the cost of replacing the
 certificate inside the device once/if compromised?
 
 
 2013/11/12 Andreas Kuckartz a.kucka...@ping.de
 
 Hans-Christoph Steiner:
 The crypto smartcard (aka Hardware Security Module) are some work to
 setup,
 but not really all that much.  And they are easy to use once setup.  And
 they
 provide a huge boost in the security of the certificate.

 Such hardware also costs a significant amount of money. Are there better
 ways to spend money to improve the security ?

 Cheers,
 Andreas


 --
 To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: http://lists.debian.org/5281c93a.8040...@ping.de


 
 



signature.asc
Description: OpenPGP digital signature

Re: SSL for debian.org/security?

[Hans-Christoph Steiner]

On 11/12/2013 01:58 PM, Henrik Ahlgren wrote:
 On Tue, Nov 12, 2013 at 01:15:38PM -0500, Hans-Christoph Steiner wrote:
 Having the key generated on the card is the most secure, since those cards 
 are
 designed so you can't read the secret key off of the card.  So the cost of
 putting a new certificate on the card is only someone's time for generating
 and uploading and new key to it.
 
 But there is the significant downside that it is not possible to
 backup the key, so if the card gets destroyed in a fire or just fails
 and stops working, the key needs to be revoked, since only one
 physical copy of the private key exists. (Which also means that only
 one machine can sign with the key.)
 
 So for widely used keys it might be better to create the keypair in a
 trusted (airgapped from any network and diskless) machine running
 something like Debian Live or Tails, and in addition to uploading it
 to the smart card, make few backup copies to offline media (e.g. USB
 sticks) to be stored in a safe location.

That is also a good point.  The process needs to be designed to work in each
situation.

Having a single copy of a private key is not always a disadvantage, but it can
provide some interesting, unique advantages.  If you look at the example of
Lavabit, he was ordered by the government to turn over a copy of his secret
key.  If that key was generated on a smartcard, then it would not be possible
for him to give a copy of the key to someone else.

Having a key that is only on a single smartcard would make that key impervious
to secret orders.  Sure, a government could take that key by secret order, but
then the debian server would have to use a new one, so the action would not be
a secret.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52827f67.9070...@at.or.at

Re: SSL for debian.org/security?

[Hans-Christoph Steiner]

On 11/11/2013 07:41 PM, Jérémie Marguerie wrote:
 On Mon, Nov 11, 2013 at 2:48 PM, Mike Mestnik che...@mikemestnik.net wrote:
 I don't see how this is relevant?  Obviously if hardware is seized then the
 owners no longer have control.  If you have suggestions as to how to secure
 hardware that's great, but if you just want to point out that Nothing can
 be done.  That's not helpful.
 
 I think Jacob suggests to get a encryption hardware module that does
 not disclose the key.
 
 Let's get back to how can we protect the SSL certificate of the server?
 To protect against the certificate being stolen with physical access,
 you can encrypt the hard drive (it causes other problems, like how you
 enter the key to decrypt the disk -- you can SSH during the boot to
 provide the decryption key to Luks).
 But it does not protect against freezing the RAM of the server to
 extract the private key.
 
 But... this has both little chance to occur and little chance of the
 sysadmin/security guys not noticing it (and thus reacting to that
 immediately).
 This is also probably more complicated and dangerous than, say, being
 the US government and request a signed certificate from a US company
 under a sort of FISA warrant (that they cannot disclose) to do lawful
 interception. But all of this is very theoretical.
 
 What Jacob suggests is to have a HSM (Hardware Security Module) that
 contains the private certificate and make it impossible (understand:
 very very hard) to extract the key. The black box signs what it gets
 asked without revealing the certificate.
 And then the idea is to do certificate pinning in the distribution
 to make sure the SSL certificate hasn't be forged by a trusted third
 party (see the Comodo/Diginotar problem).
 
 I doubt/really hope that Debian doesn't need that much complicated
 system to securely its package.

The crypto smartcard (aka Hardware Security Module) are some work to setup,
but not really all that much.  And they are easy to use once setup.  And they
provide a huge boost in the security of the certificate.

As for certificate pinning, that is quite easy.  Debian already does it, more
or less, by including the SPI and cacert.org certificates.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52818c3a.6050...@at.or.at

Re: SSL for debian.org/security?

[Hans-Christoph Steiner]

On 10/30/2013 10:49 AM, Norbert Kiszka wrote:
 Dnia 2013-10-30, śro o godzinie 11:34 -0200, Djones Boni pisze:
 On 30-10-2013 11:05, Celejar wrote:
 You're snipping crucial context; my comment above was in response to
 this:
 For apt-get a self-signed certificate could be used which comes together
 with Debian. No CA required. This is both simpler and safer.
 I was pointing out that this comment makes no sense in the context of
 apt-get. It sounds like you're referring to the website or email system.
 I am talking about updates.

 Yes. Apt uses OpenPGP to verify the integrity and authenticity of the
 packages it downloads.
 But how does apt get these packages? Over insecure HTTP.

 Hacking DNS or MITM attack can hide updates from you or a country. Then
 you are vulnerable due out-of-date software and you don't even know
 about it.


 
 
 and you don't even know
 about it.
 
 Thats why I am on the debian-security@lists.debian.org

A governmental firewall could just as easily block an email as it could
block/filter information about security updates.  In order to understand why
tor and TLS would be useful here, it good to break down the various concerns
(or threats if you prefer):

1. package authenticity (provided by the GPG signatures)
2. package availability (can currently be manipulated by MITM)
3. repo availability (can be blocked by firewalls)
4. who's downloading what package (currently visible to anyone who can see the
network traffic)

Most people are used to thinking about #1 when thinking about the security of
Debian repos.  But 2-4 are also import, and currently not well addressed.
This is where TLS and Tor come in.  Both can help prevent MITM manipulations
as well as reduce the amount of information that is leaked to the network.
Tor can also help with #3 since Tor is difficult to block (though China and
Iran are effectively blocking tor traffic these days).

I think having official Debian repos available with both TLS and Tor available
as options is a very good idea.  I'm happy to help where I can, but I'm not on
the sysadmin team (though I was a sysadmin in a former life).

Also, there are a number of official mirrors that already support TLS.  I
haven't looked to see if there are any repos available from a Tor Hidden 
Service.

.hc





signature.asc
Description: OpenPGP digital signature

Re: process to include upstream jar sig in Debian-generated jar

[Hans-Christoph Steiner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/29/2013 10:56 AM, Michael Stone wrote:
 On Thu, Aug 29, 2013 at 11:35:47AM +0200, Sébastien Le Ray wrote:
 Yes but the whole thing looks weird, on one hand OP wants to include a 
 signed jar in the package, on the other hand he says signature could
 be omitted if quick update is needed… What's the point having signed
 JAR if unsigned JAR is legitimate too? Either you ban unsigned JARs or
 you don't use signed JAR at all…
 
 It leaves that decision of whether to run with the unsigned jar up to
 the user. I think this is a reasonable solution if it works in practice,
 and is similar in concept to what the openssl folks have done for FIPS
 validation.
 
 Mike Stone
 

Another idea is that it provides a public record of whether the upstream jar
matches the Debian jar, which is guaranteed to be built from source.  This
could then serve as a verification that the upstream jar did not have code
injected into it that is not in the source tarball.

One example of a worry of how this might happen is if a governmental agency
issues a secret order to implant a back door in said app.

.hc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJSH3pGAAoJEJ8P5Yc3S76BTXIP/inFL/bFGLOb6dAWvBwGmjxZ
VW++aWVd1tr9YUMR7n6EEcbrswmi6pg2PnezPekijIe/+VyfrL7YrKOGZ+HfAwOX
S3XlkrKYs0s/cTQHG6WGEFVWBnbISjQ0MT5YDLea8U/dK8x1tLbbi+ZruC/NDXqS
ruJSDSfcPFFHvNNwpqIHLDoTSzLe3iAX7HpLPmWjCzj3Wxtl8UzPElmQ72nlggfH
SgNoj0zovnSmUNpd36Uu+CIj5IZZr/Eu6Nrxcw/onKshvl2itSmOqc+SR4cvFvpU
P0b4xhzAItnkyfFzNtGxeFQGH/K81Vek1hu0/rblMFbwpPqzL9dMHB/PwIB6hXP8
6gbzGycupGV8ojX/X3QO+ws87Y1YCiiHkcsUcBRa26pRehv815gPZinNDU8GPxgK
JTAv8B2cVa/wxyZvCXUMGGjbvJ988/RhkcFh/r3/DEdM6RZ4bjd7z+afSxBvUTFg
cR6/7OEGWb926Q3U19NXPLw1bg8B3Yfbm6og6BTtozi6ljNwqVa9Hf29yRLxSp/C
U8K5vKt40UkwNi7yd5IKLXYQbTbtRuddU0vV7/ek/hsKZ0xgkZ7a4bnR5U9Ta0DG
8odIhg6mlY3u+iq7rLEbWq5KV2jlJeX5qXRwCWd9CGbRz8upLcSqRxHBtWnggW2R
q83YDbYWKqapQ/HWoUpA
=W0To
-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: http://lists.debian.org/521f7a4b.3070...@at.or.at

process to include upstream jar sig in Debian-generated jar

[Hans-Christoph Steiner]

I want to run an unusual idea by everyone here as an approach to getting an
outside signature into a packaged Java jar built from source on the Debian
build machines: we want to get http://martus.org packaged and into Debian.
Martus is an app that has high requirements for security, so they have a very
careful build and signing process.  They want to be able to include their jar
signature in the jar that is included in the Debian package.

We figured we could structure the build like this:

1) include the official martus.jar in the source tarball
2) after the Debian build process completes, verify that contents of the
Debian generated
   jar matches the contents of the martus generated jar, except for timestamps
3) if that passes, then set the timestamps in the Debian generated jar to
match the
   timestamps in the martus.jar, then copy the signing material into place in
the Debian
   generated jar

That should then result in a debian-generated jar that has the martus
signature on it.  If Debian Security needed to update the package to fix an
urgent issue, then they could still do so.  The package build process would
only include the upstream signature from martus.jar if it was an exact match.
 The security fixed version would then result in an unsigned jar, which is
standard for jars in Debian.

Is this a workable solution here?

.hc



signature.asc
Description: OpenPGP digital signature

Re: pre-screening new package: SQLCipher, based on SQLite3

[Hans-Christoph Steiner]

On Oct 12, 2012, at 9:03 PM, Hans-Christoph Steiner wrote:

 
 On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote:
 
 On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
 Hello Florian,
 
 On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer f...@deneb.enyo.de wrote:
 Okay.  Can your fork open unencrypted databases?  Are there any symbol
 collisions with vanilla SQLite?
 
 Yes, SQLCipher can open standard, unencrypted SQLite databases without a
 problem and it has the same public API  and symbols as vanilla SQLite. Many
 users take advantage of this today to allow substitution in languages like
 python and ruby. For example they may build SQLCipher in a separate
 directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library
 for use in their programs.
 
 I believe this is is the reason Hans opted to alter the library name to
 libsqlcipher, to ensure there wouldn't be any confusion between the two,
 but I'll let him comment on that further.
 
 Cheers,
 Stephen
 SQLCipher shares all of the public symbols that SQLite3 has, plus a few
 more related to the encryption.  It is a lightly modified version of
 SQLite3.  Like Stephen said, its possible to dynamically load the
 SQLCipher library for an app that was compiled against SQLite3 and it'll
 work.  Also, when not using encryption, SQLCipher works the same as
 SQLite3 in terms of SQL commands, C API, etc.
 
 To make it friendly to packaging, I've made the library called
 libsqlcipher.so with its own ABI version related to the SQLCipher
 version, then the headers are in /usr/include/sqlcipher so they don't
 get easily confused for the SQLite3 headers.
 
 Are you thinking that this package should replace the SQLite3 package in
 Debian?  I suppose that is a possibility.  I'm guessing that the headers
 would need to be split up.  Right now the SQLCipher symbols are just in
 sqlite3.h, and that header is in /usr/include/sqlcipher.  I suppose
 sqlite3.h could be untouched, then the SQLCipher symbols could go into
 /usr/include/sqlcipher.h or something like that.
 
 The question remaining there would be how to represent the ABI
 versions.  So far, there is no established ABI versioning scheme since
 SQLCipher has mostly been used on iOS and Android.  So that's the good
 news.  The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based
 on SQLite 3.7.9.  In other words, SQLCipher's release cycle is not
 necessarily in sync with SQLite3's release cycle.

We discussed this a bunch in early October and then the discussion died.  I 
just wanted to check in to see if anyone has any time to green light this 
packaging approach, or nail down a different way.  The discussion ended with 
the above: me asking for more information on an idea of whether the SQLCipher 
package could provide SQLite.

.hc


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4a222c87-cfab-4be9-8e23-e2cdb2c60...@eds.org

Re: pre-screening new package: SQLCipher, based on SQLite3

[Hans-Christoph Steiner]

On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote:

 On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
 Hello Florian,
 
 On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer f...@deneb.enyo.de wrote:
 Okay.  Can your fork open unencrypted databases?  Are there any symbol
 collisions with vanilla SQLite?
 
 Yes, SQLCipher can open standard, unencrypted SQLite databases without a
 problem and it has the same public API  and symbols as vanilla SQLite. Many
 users take advantage of this today to allow substitution in languages like
 python and ruby. For example they may build SQLCipher in a separate
 directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library
 for use in their programs.
 
 I believe this is is the reason Hans opted to alter the library name to
 libsqlcipher, to ensure there wouldn't be any confusion between the two,
 but I'll let him comment on that further.
 
 Cheers,
 Stephen
 SQLCipher shares all of the public symbols that SQLite3 has, plus a few
 more related to the encryption.  It is a lightly modified version of
 SQLite3.  Like Stephen said, its possible to dynamically load the
 SQLCipher library for an app that was compiled against SQLite3 and it'll
 work.  Also, when not using encryption, SQLCipher works the same as
 SQLite3 in terms of SQL commands, C API, etc.
 
 To make it friendly to packaging, I've made the library called
 libsqlcipher.so with its own ABI version related to the SQLCipher
 version, then the headers are in /usr/include/sqlcipher so they don't
 get easily confused for the SQLite3 headers.
 
 Are you thinking that this package should replace the SQLite3 package in
 Debian?  I suppose that is a possibility.  I'm guessing that the headers
 would need to be split up.  Right now the SQLCipher symbols are just in
 sqlite3.h, and that header is in /usr/include/sqlcipher.  I suppose
 sqlite3.h could be untouched, then the SQLCipher symbols could go into
 /usr/include/sqlcipher.h or something like that.
 
 The question remaining there would be how to represent the ABI
 versions.  So far, there is no established ABI versioning scheme since
 SQLCipher has mostly been used on iOS and Android.  So that's the good
 news.  The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based
 on SQLite 3.7.9.  In other words, SQLCipher's release cycle is not
 necessarily in sync with SQLite3's release cycle.

Since it been 11 days without a reply since Stephen and I replied, I just 
wanted to check in on this.  We're both currently available to work directly on 
further concerns, Stephen as upstream and me as packager, so it would be a 
great time for us to nail this stuff down.

.hc

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/92d0a24d-1de1-4ddb-9b01-10048c811...@at.or.at

Re: pre-screening new package: SQLCipher, based on SQLite3

[Hans-Christoph Steiner]

On 09/28/2012 04:23 PM, Florian Weimer wrote:
 * Hans-Christoph Steiner:

 The tricky part is that it is a modified version of SQLite3, and lintian
 properly gives an error about that. But because of the features that
 SQLCipher provides, it must modify the core of SQLite to work, therefore
 it cannot be made into a plugin.
 Why isn't it implemented as a VFS plugin?

I don't know of any other precedent for a VFS plugin for adding
encryption support, do you?  Maybe Stephen can speak more to that.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5069c924.3050...@eds.org

Re: pre-screening new package: SQLCipher, based on SQLite3

[Hans-Christoph Steiner]

On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
 Hello Florian,

 On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer f...@deneb.enyo.de wrote:
 Okay.  Can your fork open unencrypted databases?  Are there any symbol
 collisions with vanilla SQLite?

 Yes, SQLCipher can open standard, unencrypted SQLite databases without a
 problem and it has the same public API  and symbols as vanilla SQLite. Many
 users take advantage of this today to allow substitution in languages like
 python and ruby. For example they may build SQLCipher in a separate
 directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library
 for use in their programs.

 I believe this is is the reason Hans opted to alter the library name to
 libsqlcipher, to ensure there wouldn't be any confusion between the two,
 but I'll let him comment on that further.

 Cheers,
 Stephen
SQLCipher shares all of the public symbols that SQLite3 has, plus a few
more related to the encryption.  It is a lightly modified version of
SQLite3.  Like Stephen said, its possible to dynamically load the
SQLCipher library for an app that was compiled against SQLite3 and it'll
work.  Also, when not using encryption, SQLCipher works the same as
SQLite3 in terms of SQL commands, C API, etc.

To make it friendly to packaging, I've made the library called
libsqlcipher.so with its own ABI version related to the SQLCipher
version, then the headers are in /usr/include/sqlcipher so they don't
get easily confused for the SQLite3 headers.

Are you thinking that this package should replace the SQLite3 package in
Debian?  I suppose that is a possibility.  I'm guessing that the headers
would need to be split up.  Right now the SQLCipher symbols are just in
sqlite3.h, and that header is in /usr/include/sqlcipher.  I suppose
sqlite3.h could be untouched, then the SQLCipher symbols could go into
/usr/include/sqlcipher.h or something like that.

The question remaining there would be how to represent the ABI
versions.  So far, there is no established ABI versioning scheme since
SQLCipher has mostly been used on iOS and Android.  So that's the good
news.  The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based
on SQLite 3.7.9.  In other words, SQLCipher's release cycle is not
necessarily in sync with SQLite3's release cycle.

.hc


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/506a290e.2040...@eds.org

pre-screening new package: SQLCipher, based on SQLite3

[Hans-Christoph Steiner]

Hey all,

I'm reading to upload a new package called SQLCipher
(http://sqlcipher.net/) and I want to run it by y'all first.  The upside
is that it provides AES256 encrypted SQLite databases in a DFSG-free
package that has been pretty widely tested, deployed and audited.  You
can find out more here: http://sqlcipher.net/design

The tricky part is that it is a modified version of SQLite3, and lintian
properly gives an error about that. But because of the features that
SQLCipher provides, it must modify the core of SQLite to work, therefore
it cannot be made into a plugin.

The sqlcipher package is based off of the sqlite3 package and includes
most of its patches.  Hurd and Tcl support are not there yet, so those
are the omitted patches.  SQLCipher is currrently based off of SQLite3
3.7.12, so its reasonably current (squeeze's SQLite3 is 3.7.3, wheezy's
is 3.7.13).

Here's the full reasoning from the original author of SQLCipher:

On 09/27/2012 03:52 PM, Stephen Lombardo wrote:
 SQLCipher modifies SQLite itself, which is the reason we maintain a
 separate version of the full source tree. However, we do try very hard to
 minimize alterations to core SQLite code, especially to reduce the risk of
 things breaking when we merge in upstream changes.

 Unfortunately it would be exceedingly difficult / impossible to make
 SQLCipher a plugin to an unmodified SQLite for a number of reasons.


1. Enabling the codec system requires the compile-time definition of
SQLITE_HAS_CODEC, which is not present on standard, unmodified SQLite
builds.
2. Even when enabled, SQLite isn't setup to load codecs as plugins.
While SQLite does have a plugin function for loadable modules, this
doesn't
extend to any system internals (it mainly used to allow custom user
functions).
3. SQLCipher makes calls to internal functions that are not part of the
public SQLite API. Sometimes these APIs change even in between
minor SQLite
versions, and thus require inspection, testing and verification on each
update. Making SQLCipher portable across multiple versions of
SQLite would
not be feasible, nor could we easily force it to use only the
public API
(for instance, even the first critical step of attaching the codec
callback
to the pager uses an internal API).
4. SQLCipher modifies supporting functions to introduce special
pragmas,
built in functions, etc (e.g. PRAGMA cipher_*). Injecting this
functionality in a plugin architecture wouldn't be possible,
resulting in
major API changes.
5. SQLCipher's test harness needs to be built into libsqlite3  
testfixture to take advantage of the test API and various internal
checks
(memory reference counting, etc)
6. Even if it were possible to use a loadable plugin, dynamic libraries
aren't available on all supported platforms (e.g. iOS)

 It is definitely undesirable to maintain a separate parallel codebase for
 SQLCipher, but unfortunately I don't think there is a better way at this
 time.

 Cheers,
 Stephen



signature.asc
Description: OpenPGP digital signature