[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HTTPS everywhere!

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 appropriate key when they are received.
Maybe my understanding of DKIM is too little... but I thought it would
be only some technique to verify the authenticity of sender addresses?

And as I've said... just signing somehow all the single mails that
arrive at the BTS, which could be verified by clients when they read it
is not enough.
That would allow an attacker to easily filter out single messages...
somehow you need to secure the series of all messages,... and also
things like negative replies (e.e. "there is no bug for package xyz).
And since many people interact with the BTS via web (well at least for
reading) you're anyway obliged to support some https solution.

> > Given that these services are used more and more for development, I
> > think it's more and more important to secure them as far as possible.
> 90% of what you want could be achieved with a working version of
> Certificate Patrol.
Well CP is at first unmaintained and it has many issues... and lacks
many features (like telling it exactly which cert and or 1-n CAs to
expect for a domain)...

Then you have the problem that people don't just access https content
via browsers, where one can easily integrate something like CP... they
may make use of https in svn, git, etc.
So you'd have to write something like CP for all these tools.

And even if that would be done... you still have the main problem - and
regardless of what you say this won't go away since it's an inherent
problem of any strictly hierarchical PKI - that you cannot guarantee
full security when you need trust some untrustworthy CA (i.e. any CA
that is not under our - Debian's - control).
Even if you have some pinning technique like CP in place,... than a
non-Debian rogue CA can simply attack you on your first visit of
https://whatever.debian.org/ and your CP is useless.

> Ship it as a standard part of iceweasel, pre
> configured with a few certs and enabled by default.
Well again,... it's not only iceweasel that would needed to be secured
but any other browser, git, svn, etc. pp.
And even if you'd do that (really hardcoding the actual host certs)...
than you have a completely unmaintainable system... you need to patch
all programs for any new Debian host cert, for any one that expires or
is revoked.
This is probably 100 times the efforts of running a own CA.

> That nice thing about getting Certificate Patrol working is it helps
> everyone - not just Debian.
Again... using CP alone won't make things secure - unless you really
hard code all the single Debian host certs in all programs that use
TLS/SSL (or at least with Debian services).
And actually... just hard coding all our host certs wouldn't be
enough... code would need to be added, that no other (i.e.
non-hard-coded) cert may be used for any debian.org/net service.

IMHO far too much effort.
It's much easier to run our own Debian CA plus:
- for most non-browser programs that allow to specify which CAs are
trusted, only add that Debian CA
- for browsers: hard code that Debian CA as the only one for debian.org|


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: