Mailing List Archive

On Tuesday, June 1, 2021 12:44:47 PM CEST karl@aspodata.se wrote:
> BillK:
> ...
>
> > And another "wondering" - all the warnings about trusting self signed
> > certs seem a bit self serving. Yes, they are trying to certify who you
> > are, but at the expense of probably allowing access to your
> > communications by "authorised parties" (such as commercial entities
> > purchasing access for MITM access - e.g. certain router/firewall
> > companies doing deep inspection of SSL via resigning or owning both end
> > points). If its only your own communications and not with a third,
> > commercial party self signed seems a lot more secure.
>
> ...
>
> You can use https://letsencrypt.org/ instead of a self-signed cert:
>
> Let's Encrypt is a free, automated, and open certificate authority
> brought to you by the nonprofit Internet Security Research Group (ISRG).
>
> It was pretty simple to get it to work with
> https://github.com/diafygi/acme-tiny

It's not that easy to do it with internal-only systems as Let's Encrypt
requires the hostname to be known externally.
And there are plenty of devices you do not want the whole internet to know
about.

--
Joost

On Tue, 2021-06-01 at 13:17 +0200, J. Roeleveld wrote:
>
> It's not that easy to do it with internal-only systems as Let's Encrypt
> requires the hostname to be known externally.
> And there are plenty of devices you do not want the whole internet to know
> about.
>

And in this situation LetsEncrypt does nothing but make security worse:

* You have to trust the entire CA infrastructure rather than just your 
own CA. Many of the CAs are not just questionable, but like the 
governments of the USA and China, known to be engaged in large-scale
man-in-the-middle attacks.

* The LetsEncrypt certificates expire after three months, as opposed 
to 10+ years for a self-signed certificate. You're supposed to 
automate this... by running a script as root that takes input from 
the web? I'd rather not do that.

* LetsEncrypt verifies your identity over plain HTTP (like every other 
commercial CA), so it's all security theater in the first place.

There are plenty of arguments against LE even for public sites, but for
private ones, it's a lot more clear-cut...

On Tuesday, 1 June 2021 12:40:28 BST Michael Orlitzky wrote:
> On Tue, 2021-06-01 at 13:17 +0200, J. Roeleveld wrote:
> > It's not that easy to do it with internal-only systems as Let's Encrypt
> > requires the hostname to be known externally.
> > And there are plenty of devices you do not want the whole internet to know
> > about.
>
> And in this situation LetsEncrypt does nothing but make security worse:
>
> * You have to trust the entire CA infrastructure rather than just your
> own CA. Many of the CAs are not just questionable, but like the
> governments of the USA and China, known to be engaged in large-scale
> man-in-the-middle attacks.
>
> * The LetsEncrypt certificates expire after three months, as opposed
> to 10+ years for a self-signed certificate. You're supposed to
> automate this... by running a script as root that takes input from
> the web? I'd rather not do that.
>
> * LetsEncrypt verifies your identity over plain HTTP (like every other
> commercial CA), so it's all security theater in the first place.
>
> There are plenty of arguments against LE even for public sites, but for
> private ones, it's a lot more clear-cut...

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.

--
Regards,
Peter.

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.

On Tuesday, 1 June 2021 13:16:59 BST Michael Orlitzky 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.

Thanks Michael.

--
Regards,
Peter.

Joost:
> On Tuesday, June 1, 2021 12:44:47 PM CEST karl@aspodata.se wrote:
... [ about letsencrypt ] ...
> It's not that easy to do it with internal-only systems as Let's Encrypt
> requires the hostname to be known externally.
> And there are plenty of devices you do not want the whole internet to know
> about.

Just use a celf-certified cert and add an exeption in the web browser,
or set up your own CA, (I don't know how) and distribute its cert.

Regards,
/Karl Hammar

Michael Orilitzky:
...
> * The LetsEncrypt certificates expire after three months, as opposed 
> to 10+ years for a self-signed certificate. You're supposed to 
> automate this... by running a script as root that takes input from 
> the web? I'd rather not do that.

You can run most part of it as an unpriviliged user, here is my crontab:
0 0 1 * * acme /usr/local/sbin/acme_update.sh
10 0 1 * * root cat /etc/acme-tiny/domain.key /var/acme-tiny/signed_chain.crt > /etc/lighttpd/server.pem
20 0 1 * * root /etc/init.d/lighttpd restart

One could add a check to make sure that the downloaded crt is sensible.

> * LetsEncrypt verifies your identity over plain HTTP (like every other 
> commercial CA), so it's all security theater in the first place.
...

Ack.

Regards,
/Karl Hammar

Karl:
> Michael Orilitzky:

Sorry, I mistyped, it should be: Peter Humphrey

> ...
> > * The LetsEncrypt certificates expire after three months, as opposed 
> > to 10+ years for a self-signed certificate. You're supposed to 
> > automate this... by running a script as root that takes input from 
> > the web? I'd rather not do that.
>
> You can run most part of it as an unpriviliged user, here is my crontab:
> 0 0 1 * * acme /usr/local/sbin/acme_update.sh
> 10 0 1 * * root cat /etc/acme-tiny/domain.key /var/acme-tiny/signed_chain.crt > /etc/lighttpd/server.pem
> 20 0 1 * * root /etc/init.d/lighttpd restart
>
> One could add a check to make sure that the downloaded crt is sensible.
>
> > * LetsEncrypt verifies your identity over plain HTTP (like every other 
> > commercial CA), so it's all security theater in the first place.
> ...
>
> Ack.

Regards,
/Karl Hammar

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