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
> built for CA management.
Na... CAcert is really not that secure... and 2 (or was it 3)? People
can assert an identity... and it's not that difficult to get so many
people to gether.
> From my perspective, HTTPS Everywhere and Archive Security are not the same.
Actually I don't
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
A) into their
certificate stores. I'd expect them to ask us to follow processes similar to
Mozilla's (https://wiki.mozilla.org/CA:How_to_apply). It's not clear to me
that either SPI or Debian are prepared to do that. Maybe we should go with
cacert.org... but they failed to step through the proces
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
* Christoph Anton Mitterer , 2014-06-12, 01:06:
- not really secure APT related: apt-listbugs
Not sure whether it uses https for getting bug infos...
$ 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 HTTP
38 matches
Mail list logo
