On Tue, 2014-06-24 at 08:29 +0200, Matthias Urlichs wrote:
> The difference is that while pinning a bunch of certificates is indeed a
> lot of on-going work, pinning the CA cert used to sign these is not (set up
> the CA and install it into our software once, sign server certificates with
> that fo
Hi,
Russell Stuart:
> This looks like pinning under another name to me. And quoting you
> above, in this very same email, you say pinning is too hard because you
> have to "hard code all the single Debian host certs in all programs that
> use TLS/SSL (or at least with Debian services)". And yet
On Mon, 2014-06-23 at 17:26 +0200, Christoph Anton Mitterer wrote:
> Maybe my understanding of DKIM is too little... but I thought it would
> be only some technique to verify the authenticity of sender addresses?
DKIM, OpenPGP, X.509 - they are all the same thing with different names.
They all com
On Mon, 2014-06-23 at 08:58 +1000, Russell Stuart wrote:
> > Well first, AFAIK, there are no mirrors for the BTS... and then
> > securing something like BTS with OpenPGP is quite difficult.
> There is a straight forward solution to handling BTS messages. You just
> DKIM sign them with an appropri
On Sun, 2014-06-22 at 15:49 +0200, Christoph Anton Mitterer wrote:
> On Sun, 2014-06-22 at 14:21 +1000, Russell Stuart wrote:
> > Sure, but you are no longer discussing a PKI system here. If you are
> > going to abandon X.509 PKI
> Well first of all,... PKI is just "public key infrastructure" and
On Sun, 2014-06-22 at 14:21 +1000, Russell Stuart wrote:
> Sure, but you are no longer discussing a PKI system here. If you are
> going to abandon X.509 PKI
Well first of all,... PKI is just "public key infrastructure" and not
necessarily means X.509.
> , why not just use OpenPGP and just have
>
On 2014-06-22 06:21, Russell Stuart wrote:
Don't understand what you talk about... AFAICS you can't download any
netinst images via https at all.
Hmm. You are right. The situation is worse than I thought.
Well, there are debian-installer-$VER-netboot-$ARCH in oldstable and
stable.
Kind re
On Sun, 2014-06-22 at 03:34 +0200, Christoph Anton Mitterer wrote:
> Well as it should be clear to everyone by now... with a own CA and with
> specifically checking for certs issued by *only that* CA you can fully
> secure things like apt-listbugs.
Sure, but you are no longer discussing a PKI syst
On Sun, 2014-06-22 at 10:52 +1000, Russell Stuart wrote:
> The problem isn't that government security agencies can in all
> likelihood MITM any connection they wish. I'm sure that's true, but I'm
> equally sure they don't do it that often for fear of being caught. It's
> actually far worse than
On Sat, 2014-06-21 at 17:58 +0200, Christoph Anton Mitterer wrote:
> Take Turktrust as an example... IIRC the case correctly, they
> "accidentally" (whoever believes that) issued a cert which was a
> intermediate CA and which was used to issue forged Google certs.
> After days and only after long d
On Sat, 2014-06-21 at 16:40 +0200, Tollef Fog Heen wrote:
> That user trusts us to build a distro fairly competently, something we
> have a history of doing.
Well it's not that we'd have never made mistakes there...
> That user would then trust us to run a CA competently, something we as a
> pro
]] Christoph Anton Mitterer
> And if your concern is that a Debian CA could be used to forge
> certificates for non-Debian stuff... given that we have >150 root certs
> in the Mozilla bundle... many of them already completely untrustworthy
> and many of them probably introducing intermediate CAs
]] Christoph Anton Mitterer
> A user of Debian already fully trusts us (by using our distro, where we
> could do basically everything).
That user trusts us to build a distro fairly competently, something we
have a history of doing.
> If he ultimately trusts our X.509 root, he doesn't give us mo
On Fri, 2014-06-20 at 22:58 +0200, Christoph Anton Mitterer wrote:
> > But after you've sent them money or downloaded their software
> > you have formed a trust relationship with whoever controls that cert far
> > stronger than the assurances X.509 provides. That is true in the
> > positive sense
On Sat, 2014-06-21 at 03:41 +0200, Matthias Urlichs wrote:
> Christoph Anton Mitterer:
> > In OpenPGP you have the additional problems that:
> > - at least until know communication with the keyservers is usually
> > unsecured: so not only the keyserver operator can attack you, but anyone
> > else
Hi,
Christoph Anton Mitterer:
> In OpenPGP you have the additional problems that:
> - at least until know communication with the keyservers is usually
> unsecured: so not only the keyserver operator can attack you, but anyone
> else that can MitM.
Fortunately, that only matters when checking for
On Wed, 2014-06-18 at 10:05 -0700, Russ Allbery wrote:
> This is only true if the root CA is maintained with the same level of
> security as the PGP signing key for the archive.
Well and currently, people trust GANDI when they download (then possibly
forged) Debian images?
Actually even less, sinc
On Wed, 2014-06-18 at 15:29 +0200, Vincent Lefevre wrote:
> At least you
> need some 3rd party to check certificate revocation. But if it is
> malicious, it could tell you that the certificate has been revoked
> (even if it isn't), and you have the same problem as now... well,
> almost.
It's actu
On Wed, 2014-06-18 at 14:20 +1000, Russell Stuart wrote:
> Precisely. It has a horrible design bug.
>
> Given the nature of the net, where we want to deal securely with some
> entity never dealt with or of heard of before like, www.shop.com, we
> are forced to rely on a third party to assure us
On Wed, Jun 18, 2014 at 10:27:23AM -0700, Russ Allbery wrote:
> Luca Filipozzi writes:
> > On Wed, Jun 18, 2014 at 10:05:32AM -0700, Russ Allbery wrote:
>
> >> This is only true if the root CA is maintained with the same level of
> >> security as the PGP signing key for the archive. While that's
Luca Filipozzi writes:
> On Wed, Jun 18, 2014 at 10:05:32AM -0700, Russ Allbery wrote:
>> This is only true if the root CA is maintained with the same level of
>> security as the PGP signing key for the archive. While that's
>> something that we could probably do (although it's worth not
>> unde
On Wed, Jun 18, 2014 at 10:05:32AM -0700, Russ Allbery wrote:
> Vincent Lefevre writes:
> > On 2014-06-17 13:20:59 +0100, Simon McVittie wrote:
>
> >> It should be possible to make a CA certificate that is only considered to
> >> be valid for the spi-inc.org and debian.org subtrees, and then trus
Vincent Lefevre writes:
> On 2014-06-17 13:20:59 +0100, Simon McVittie wrote:
>> It should be possible to make a CA certificate that is only considered
>> to be valid for the spi-inc.org and debian.org subtrees, and then trust
>> the assertion that SPI control that certificate - but in widely-use
On 2014-06-18 14:20:10 +1000, Russell Stuart wrote:
> So you need X.509 PKI (even with all its flaws) during that first
> contact. But after you've sent them money or downloaded their software
> you have formed a trust relationship with whoever controls that cert far
> stronger than the assurances
On 2014-06-17 13:20:59 +0100, Simon McVittie wrote:
> It should be possible to make a CA certificate that is only considered
> to be valid for the spi-inc.org and debian.org subtrees, and then trust
> the assertion that SPI control that certificate - but in widely-used
> applications, that isn't po
On Wed, 2014-06-18 at 04:54 +0200, Christoph Anton Mitterer wrote:
> Well https with X.509 has inherent problems which we won't be able to
> solve...
Precisely. It has a horrible design bug.
Given the nature of the net, where we want to deal securely with some
entity never dealt with or of heard
On Tue, 2014-06-17 at 21:00 +0200, Kurt Roeckx wrote:
> This should be supported by all libraries, and is being used.
> More and more intermediate CAs are in the process of becomming
> constrained.
Which doesn't really help, if you have still >150 "root" CA certs in
Mozilla... which can just do wh
On Tue, 2014-06-17 at 13:20 +0100, Simon McVittie wrote:
> * my browser vendor doesn't trust this CA at all, and indeed my browser
> will not let me access https sites secured with it, even though it
> will let me access an equally MITM-prone http version of the same
> content
>
> * my bro
On Mon, 2014-06-16 at 18:25 +, Luca Filipozzi wrote:
> But I don't expect that to be anywhere close to sufficient for other distros
> to
> include the Debian CA (by which you probably mean the SPI CA) into their
> certificate stores.
I didn't mean their Mozilla/NSS cert stores, if you were ta
On Tue, Jun 17, 2014 at 02:34:27PM +0200, Jakub Wilk wrote:
> * Simon McVittie , 2014-06-17, 13:20:
> >It should be possible to make a CA certificate that is only considered to
> >be valid for the spi-inc.org and debian.org subtrees, and then trust the
> >assertion that SPI control that certificate
* Simon McVittie , 2014-06-17, 13:20:
It should be possible to make a CA certificate that is only considered
to be valid for the spi-inc.org and debian.org subtrees, and then trust
the assertion that SPI control that certificate - but in widely-used
applications, that isn't possible.
In theor
On Tue, Jun 17, 2014 at 8:20 PM, Simon McVittie wrote:
> Expanding on that a little...
That is a great non-technical summary of how bad the situation with
SSL and browser implementations is, thank you!
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-req
On 12/06/14 19:16, Tollef Fog Heen wrote:
> ]] Christoph Anton Mitterer
>
>> Supplying the Debian Root CA to people not using Debian could have been
>> easily done by a *single* site that uses a cert available in all
>> browsers... which offers the Debian Root CA for secure and "trusted"
>> downl
On Mon, Jun 16, 2014 at 07:54:40PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2014-06-12 at 20:16 +0200, Tollef Fog Heen wrote:
> > > Supplying the Debian Root CA to people not using Debian could have been
> > > easily done by a *single* site that uses a cert available in all
> > > browsers.
On Thu, 2014-06-12 at 20:16 +0200, Tollef Fog Heen wrote:
> > Supplying the Debian Root CA to people not using Debian could have been
> > easily done by a *single* site that uses a cert available in all
> > browsers... which offers the Debian Root CA for secure and "trusted"
> > download.
>
> Tha
]] Christoph Anton Mitterer
> Supplying the Debian Root CA to people not using Debian could have been
> easily done by a *single* site that uses a cert available in all
> browsers... which offers the Debian Root CA for secure and "trusted"
> download.
That's a nice theory. It does not align par
On Thu, 2014-06-12 at 10:56 +0200, Jakub Wilk wrote:
> $ grep -r /soap.cgi lib/
> lib/debian/btssoap.rb:
> @server="http://#{host}:#{port}/cgi-bin/soap.cgi";
:-(
> bts(1) and reportbug(1) don't use HTTPS either, AFAICS.
:-(
> I noticed that http://bugs.debian.org/ started redirecting to
37 matches
Mail list logo
