public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
Date: Tue, 1 Jun 2021 09:22:34 -0400	[thread overview]
Message-ID: <CAGfcS_nLbwkuwX83cV0a3ZdQeUY+9=U4zNqO+WPh9oTy=zMeJQ@mail.gmail.com> (raw)
In-Reply-To: <9e56e085f91a57cfe81f857675118517f12ea5b8.camel@gentoo.org>

On Tue, Jun 1, 2021 at 8:16 AM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote:
> >
> > So what would you recommend for someone in the case Joost cites? I'm in that
> > position, being a home user of a small network but no registered Internet
> > name.
> >
>
> A self-signed certificate combined with a browser extension that lets
> you "pin" it. With pinning, you can keep your browser usable on the WWW
> while still rejecting any forged certificates for your own hosts. The
> end result works pretty much like SSH keys do.

Can't really argue with this.  However, for those who aren't
completely following along it is probably worth pointing out that the
way you're doing it is different from how 99.999% of the way the world
is doing it.

So, if you're talking about securing communications between hosts you
control what mjo suggests is a much better solution than the standard
solution (at least security-wise).  There are probably better ways to
do it, but not much that is standard.

However, if you're working with others then that solution isn't such a
good one, as it isn't really standard.  That said, it isn't uncommon
for more sophisticated companies to pin certificates from their
partners so that a random CA can't do an end-run around security.  I
have vendors I work with who regularly send out notices of pending
certificate changes to technical contacts to allow for this.

Really though the entire SSL CA infrastructure needs a massive
overhaul.  Using something like DNSSEC as a trust root would be one
way to go about it.  Another might be to restrict the scope that CAs
could sign within and have some way to automate that.  Self-signed
certs aren't a good solution for the average user and no SSL is an
even worse one (at best it removes security theater, but at the cost
of allowing attackers to not even bother with subverting the CA
system, which opens up a lot more attacks).  Right now you can browse
using SSL to army.mil for the first time and in theory your browser
won't complain if the certificate is signed by the PLA...

-- 
Rich


  parent reply	other threads:[~2021-06-01 13:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-29  1:08 [gentoo-user] app-misc/ca-certificates zcampe
2021-05-29  6:26 ` Walter Dnes
2021-06-01  4:45   ` J. Roeleveld
2021-06-01  5:15     ` William Kenworthy
2021-06-01 10:44       ` Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates) karl
2021-06-01 11:17         ` J. Roeleveld
2021-06-01 11:40           ` Michael Orlitzky
2021-06-01 12:02             ` Peter Humphrey
2021-06-01 12:16               ` Michael Orlitzky
2021-06-01 12:24                 ` Peter Humphrey
2021-06-01 13:22                 ` Rich Freeman [this message]
2021-06-01 13:17             ` karl
2021-06-01 13:20               ` karl
2021-06-01 13:17           ` karl
2021-06-01 11:59       ` [gentoo-user] app-misc/ca-certificates Adam Carter
2021-06-01 13:29         ` Rich Freeman
2021-06-02  1:13           ` William Kenworthy
2021-06-03  9:06           ` Adam Carter
2021-06-01 21:25       ` Grant Taylor
2021-06-01 21:38         ` Michael Orlitzky
2021-06-02  1:51           ` Grant Taylor
2021-06-02  7:21             ` J. Roeleveld
2021-06-02 20:22               ` Grant Taylor
2021-06-02  7:48             ` Fannys
2021-06-02 20:23               ` Grant Taylor
2021-06-01 22:28     ` Fannys
2021-06-02  7:23       ` J. Roeleveld
2021-06-01 21:05   ` Grant Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGfcS_nLbwkuwX83cV0a3ZdQeUY+9=U4zNqO+WPh9oTy=zMeJQ@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox