[gentoo-user] app-misc/ca-certificates

[gentoo-user] app-misc/ca-certificates

[zcampe]

125 config files in /etc/ssl/certs needs update.

For certificates I would expect the old and invalid ones to be replaced
by newer ones without user intervention.

bb.zven

Re: [gentoo-user] app-misc/ca-certificates

[Walter Dnes]

On Sat, May 29, 2021 at 03:08:39AM +0200, zcampe@gmail.com wrote
> 
> 125 config files in /etc/ssl/certs needs update.
> 
> For certificates I would expect the old and invalid ones to be replaced
> by newer ones without user intervention.

  Looking through them is "interesting".  There seem to be a lot of
/etc/ssl/certs/????????.0 files, where "?" is either a random number or
a lower case letter.  These all seem to be symlinks to
/etc/ssl/certs/<Some_Name>.pem.  Each of those files is in turn a
symlink to /usr/share/ca-certificates/mozilla/<Some_Name>.crt.  How much
do we trust China?  There are a couple of certificates in there named
/usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt  and
/usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt.  Any
other suspicious regimes in there?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] app-misc/ca-certificates

[J. Roeleveld]

On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
> On Sat, May 29, 2021 at 03:08:39AM +0200, zcampe@gmail.com wrote
> 
> > 125 config files in /etc/ssl/certs needs update.
> > 
> > For certificates I would expect the old and invalid ones to be replaced
> > by newer ones without user intervention.
> 
>   Looking through them is "interesting".  There seem to be a lot of
> /etc/ssl/certs/????????.0 files, where "?" is either a random number or
> a lower case letter.  These all seem to be symlinks to
> /etc/ssl/certs/<Some_Name>.pem.  Each of those files is in turn a
> symlink to /usr/share/ca-certificates/mozilla/<Some_Name>.crt.  How much
> do we trust China?  There are a couple of certificates in there named
> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt  and
> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt.  Any
> other suspicious regimes in there?

I've always wondered about the amount of CAs that are auto-trusted on any 
system. Including several from countries with serious human rights issues.

I could do with a tool where I can easily select which CAs to trust based on 
country.

--
Joost

Re: [gentoo-user] app-misc/ca-certificates

[William Kenworthy]

On 1/6/21 12:45 pm, J. Roeleveld wrote:
> On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
>> On Sat, May 29, 2021 at 03:08:39AM +0200, zcampe@gmail.com wrote
>>
>>> 125 config files in /etc/ssl/certs needs update.
>>>
>>> For certificates I would expect the old and invalid ones to be replaced
>>> by newer ones without user intervention.
>>   Looking through them is "interesting".  There seem to be a lot of
>> /etc/ssl/certs/????????.0 files, where "?" is either a random number or
>> a lower case letter.  These all seem to be symlinks to
>> /etc/ssl/certs/<Some_Name>.pem.  Each of those files is in turn a
>> symlink to /usr/share/ca-certificates/mozilla/<Some_Name>.crt.  How much
>> do we trust China?  There are a couple of certificates in there named
>> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt  and
>> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt.  Any
>> other suspicious regimes in there?
> I've always wondered about the amount of CAs that are auto-trusted on any 
> system. Including several from countries with serious human rights issues.
>
> I could do with a tool where I can easily select which CAs to trust based on 
> country.
>
> --
> Joost


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.

Getting a bit OT, but interesting none the less.

BillK

Ref:

https://checkthefirewall.com/blogs/fortinet/ssl-inspection

https://us-cert.cisa.gov/ncas/alerts/TA17-075A

Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[karl]

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

Regards,
/Karl Hammar

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[J. Roeleveld]

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

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[Michael Orlitzky]

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...

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[Peter Humphrey]

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.

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[Michael Orlitzky]

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.

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[Peter Humphrey]

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.

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[Rich Freeman]

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

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[karl]

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

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[karl]

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

Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)

[karl]

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

Re: [gentoo-user] app-misc/ca-certificates

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

>
> 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).


CAs who issue such dodgy certs tend to get booted from certificate stores,
since they cannot be trusted.
https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29

https://en.wikipedia.org/wiki/Certificate_Transparency helps keep CAs
honest.

The way i like to frame it is "any certificate should only be trusted as
much as the *least* trustworthy CA in your certificate store"

AFAIK in an enterprise MITM works by having a local CA added to the cert
stores of the workstation fleet, and having that CA auto generate the certs
for MITM. That didn't work with certificate pinning, but pinning has been
deprecated.


> If its only your own communications and not with a third,
> commercial party self signed seems a lot more secure.
>

Yes, I imagine there are some circumstances where it would make sense to
remove all the certs from your certificate store and then just add your
local CA's cert. In this case, the least trustworthy CA in the store is
your own :)

[-- Attachment #2: Type: text/html, Size: 2200 bytes --]

Re: [gentoo-user] app-misc/ca-certificates

[Rich Freeman]

On Tue, Jun 1, 2021 at 7:59 AM Adam Carter <adamcarter3@gmail.com> wrote:
>>
>> 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).
>
> AFAIK in an enterprise MITM works by having a local CA added to the cert stores of the workstation fleet, and having that CA auto generate the certs for MITM. That didn't work with certificate pinning, but pinning has been deprecated.

So, I don't know all the ways that pinning is implemented, but if
you're talking about using MITM to snoop on enterprise devices on the
enterprise network I'd think that pinning wouldn't be an issue,
because you control the devices from cradle to grave.  Just ensure the
pinned certificates are the ones that let you MITM the connections.

Now, if your organization has some sort of guest network for
non-enterprise devices then pinning would obviously block MITM of
connections made by those devices.  Really though I'm not sure you'd
want to be snooping stuff like this - it seems like more legal
headaches than it is worth.  You want to sniff your OWN traffic for
IDS/etc or other unauthorized use, and since you're sniffing traffic
from devices you own you don't have the same legal issues (I won't say
no legal issues, but certainly monitoring your own devices is very
different from monitoring those you don't own).  You shouldn't even be
allowing uncontrolled devices on those networks in the first place.
If you want to detect unauthorized devices MITM isn't really the best
solution - just use positive authentication of known-good devices
up-front and anything that doesn't pass that test is treated as a
threat and shouldn't even be able to send traffic.

-- 
Rich

Re: [gentoo-user] app-misc/ca-certificates

[William Kenworthy]

On 1/6/21 9:29 pm, Rich Freeman wrote:
> On Tue, Jun 1, 2021 at 7:59 AM Adam Carter <adamcarter3@gmail.com> wrote:
>>> 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).
>> AFAIK in an enterprise MITM works by having a local CA added to the cert stores of the workstation fleet, and having that CA auto generate the certs for MITM. That didn't work with certificate pinning, but pinning has been deprecated.
> So, I don't know all the ways that pinning is implemented, but if
> you're talking about using MITM to snoop on enterprise devices on the
> enterprise network I'd think that pinning wouldn't be an issue,
> because you control the devices from cradle to grave.  Just ensure the
> pinned certificates are the ones that let you MITM the connections.
>
> Now, if your organization has some sort of guest network for
> non-enterprise devices then pinning would obviously block MITM of
> connections made by those devices.  Really though I'm not sure you'd
> want to be snooping stuff like this - it seems like more legal
> headaches than it is worth.  You want to sniff your OWN traffic for
> IDS/etc or other unauthorized use, and since you're sniffing traffic
> from devices you own you don't have the same legal issues (I won't say
> no legal issues, but certainly monitoring your own devices is very
> different from monitoring those you don't own).  You shouldn't even be
> allowing uncontrolled devices on those networks in the first place.
> If you want to detect unauthorized devices MITM isn't really the best
> solution - just use positive authentication of known-good devices
> up-front and anything that doesn't pass that test is treated as a
> threat and shouldn't even be able to send traffic.

When discussing what traffic is looked at in an educational setting it
looked like the system examined everything except mainline banking URL's

For OpenVPN through a MiTM SSL proxy: Double wrap in SSL - outer one
uses their cert so it does not fail that test - inner one uses your self
signed cert for OpenVPN running on port 443 TCP.  At the destination use
the sslh multiplexor to divert SSL to stunnel/second sslh instance etc.
to strip the SSL wrapping appropriately. Works using a combination of
proxytunnel on the Windows side and stunnel on the linux end if needed -
very flexible).  There are are a few other enhancements for pinholing
more  difficult sites.  Performance is entirely adequate for a road
warrior setup when travelling (via a Raspberry Pi AP).  I have had to
get a lot more sophisticated than back in the day when httptunnel was
all that was needed :)

BillK

Re: [gentoo-user] app-misc/ca-certificates

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Tue, Jun 1, 2021 at 11:29 PM Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Jun 1, 2021 at 7:59 AM Adam Carter <adamcarter3@gmail.com> wrote:
> >>
> >> 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).
> >
> > AFAIK in an enterprise MITM works by having a local CA added to the cert
> stores of the workstation fleet, and having that CA auto generate the certs
> for MITM. That didn't work with certificate pinning, but pinning has been
> deprecated.
>
> So, I don't know all the ways that pinning is implemented, but if
> you're talking about using MITM to snoop on enterprise devices on the
> enterprise network I'd think that pinning wouldn't be an issue,
> because you control the devices from cradle to grave.  Just ensure the
> pinned certificates are the ones that let you MITM the connections.
>

After seeing Grant's mention of CAA records I think I may have conflated
pinning with them, or perhaps there were some special controls in Chrome to
check that google certs were issued by the correct CA? Sorry i'm not clear
on this now (and may have never been).

[-- Attachment #2: Type: text/html, Size: 2002 bytes --]

Re: [gentoo-user] app-misc/ca-certificates

[Grant Taylor]

On 5/31/21 11:15 PM, William Kenworthy wrote:
> And another "wondering" - all the warnings about trusting self signed
> certs seem a bit self serving.

No, it's not self serving.

Considerably more people than public certificate authorities bemoan self 
signed certificates.

Consider this:

1)  Your web site uses a self signed certificate and you have trained 
users to blindly accept and trust the certificate presented to them.
2)  Someone decides to intercept the traffic and presents a different 
self signed certificate to the end users while proxying the traffic on 
to you.
3)  Your end users have no viable way to differentiate between your self 
signed certificate and the intercepting self signed certificate.

Without someone - which you trust - vouching for the identity of the 
party that you're connecting to, you have no way to know that you are 
actually connecting to the partying that you are intending to connect to.

> Yes, they are trying to certify who you are, but at the expense of 
> probably allowing access to your communications by "authorised parties"

Nope.  Not at all.  (Presuming that it's done properly.  More below.)

The /only/ thing that the certificate does / provides is someone - whom 
end users supposedly trust - vouching that you are who you say they are. 
  The CA has nothing in the actual communications path.  Thus they can't 
see the traffic if they want to.

The proper way configure certificates is:

1)  Create a key on the local server.
2)  Create a Certificate Signing Request (a.k.a. CSR) which references, 
but does not include, the key.
3)  As a CA to sign the CSR.
4)  Use the certificate from the CA.

The important thing is that the key, which is integral to the encryption 
*NEVER* *LEAVES* *YOUR* *CONTROL*!

Thus there is no way that a CA is even capable of getting in the middle 
of the end-to-end communications between you and your client.

There have been some CAs in the past that would try to do everything on 
their server.  But in doing so, they violate the security model.  Don't 
use those CAs.

*YOU* /must/ generate the key /locally/.  Anything else is broken security.

> (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).

This is actually exceedingly difficult to do, at least insofar as 
decryption and re-encrypting the traffic.  Certificate Transparency logs 
help ensure that a CA doesn't ... inadvertantly ... issue a certificate 
that they should not.  Or at least it makes it orders of magnitude 
easier to identify and detect when such ... mistakes happen.

There is also the Certificate Authority Authorization record that you 
can put in DNS that authorizes which CA(s) can issue certificates for a 
domain.  A few years ago we passed the deadline where all CAs had to 
adhere to the CAA record.  As in the Certificate Authority / Browser 
forum / consortium / term??? has non-renewed anybody who wasn't adhering 
to CAA.  This is water so far under the bridge that it's over the 
waterfall, out to ocean, evaporated, and is raining down again.

Also, DNSSEC protects DNS in that it makes it possible to authenticate 
the information you receive.  Thus you can detect when things aren't 
authenticated and you know they should be.

> If its only your own communications and not with a third, commercial 
> party self signed seems a lot more secure.

Nope.  3rd parties don't have access to the encrypted communications. 
The only thing they have access to is saying if you are you or not. 
Yes, that's Bob over there in the corner.  But I have no idea what he's 
talking about b/c MATH.

Note the words "signed" and "signing".  A Certificate Authority signs a 
certificate signing request, thus vouching for the identity of the 
entity submitting the CSR.  You obviously can sign your own CSR.  That's 
what a self-signed certificate comes from.  But you have nobody vouching 
for who the far entity is, much less who vouched for them.

Spekaing of who vouched for them, and how do we trust them?  That's 
where the hashes in /etc/ssl (or wherever it is) come into play.  Your 
system has a public key for /trusted/ root CAs.  Thus when your system 
sees a certificate signed by a CA, it computes the hash, looks for the 
public key as the hash file on your local system.  If the file exists 
and all the math passes, then the root certificate is trusted.  If the 
root certificate is trusted, then your system will trust the certificate 
that the CA is vouching for.

This is all ... something ... having to do with who is vouching for whom 
and do you trust the vouching party or not.

But at no time does a CA have access to the encrypted communications. 
As long as things were done properly in that the keys were generated 
locally.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] app-misc/ca-certificates

[Michael Orlitzky]

On Tue, 2021-06-01 at 15:25 -0600, Grant Taylor wrote:
> 
> The proper way configure certificates is:
> 
> 1)  Create a key on the local server.
> 2)  Create a Certificate Signing Request (a.k.a. CSR) which references, 
> but does not include, the key.
> 3)  As a CA to sign the CSR.
> 4)  Use the certificate from the CA.
> 
> The important thing is that the key, which is integral to the encryption 
> *NEVER* *LEAVES* *YOUR* *CONTROL*!
> 

*Any* CA can just generate a new key and sign the corresponding
certificate. All browsers will treat their fake certificate
corresponding to the fake key on their fake web server as completely
legitimate. The "real" original key that you generated has no special
technical properties that distinguish it.

Re: [gentoo-user] app-misc/ca-certificates

[Grant Taylor]

On 6/1/21 3:38 PM, Michael Orlitzky wrote:
> *Any* CA can just generate a new key and sign the corresponding 
> certificate.

This is where what can /technically/ be done diverges from what is 
/allowed/ to be done.

CAs adhering to the CA/B Forum's requirements on CAA records mean that 
they aren't allowed to issue a certificate for a domain that doesn't 
list them in the CAA record.

If a CA violates the CAA record requirement, then the CA has bigger 
issues and will be subject to distrusting in mass.

Certificate Transparency logs make it a lot easier to identify if such 
shenanigans are done.  --  I think that the CA/B Forum is also requiring 
C.T. Logs.

Also, CAs /should/ *NOT* be generating keys.  The keys should be 
generated by the malicious party trying to pull the shenanigans that 
you're talking about.

> All browsers will treat their fake certificate corresponding to the 
> fake key on their fake web server as completely legitimate. The "real" 
> original key that you generated has no special technical properties 
> that distinguish it.

Not /all/ browsers.  I know people that have run browser extensions to 
validate the TLS certificate that they receive against records published 
via DANE in DNS, which is protected by DNSSEC.  So it's effectively 
impossible for a rogue CA and malicious actor to violate that chain of 
trust in a way that can't be detected and acted on.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] app-misc/ca-certificates

[J. Roeleveld]

On Wednesday, June 2, 2021 3:51:06 AM CEST Grant Taylor wrote:
> On 6/1/21 3:38 PM, Michael Orlitzky wrote:
> > All browsers will treat their fake certificate corresponding to the
> > fake key on their fake web server as completely legitimate. The "real"
> > original key that you generated has no special technical properties
> > that distinguish it.
> 
> Not /all/ browsers.  I know people that have run browser extensions to
> validate the TLS certificate that they receive against records published
> via DANE in DNS, which is protected by DNSSEC.  So it's effectively
> impossible for a rogue CA and malicious actor to violate that chain of
> trust in a way that can't be detected and acted on.

Do you know which extensions add this?

Re: [gentoo-user] app-misc/ca-certificates

[Grant Taylor]

On 6/2/21 1:21 AM, J. Roeleveld wrote:
> Do you know which extensions add this?

I don't remember exactly (they weren't compatible with Firefox 78) but 
from memory, they were from the CZ NIC operator.  They have many things 
related to this.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] app-misc/ca-certificates

[Fannys]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On June 2, 2021 1:51:06 AM UTC, Grant Taylor <gtaylor@gentoo.tnetconsulting.net> wrote:
>On 6/1/21 3:38 PM, Michael Orlitzky wrote:
>> *Any* CA can just generate a new key and sign the corresponding 
>> certificate.
>
>This is where what can /technically/ be done diverges from what is 
>/allowed/ to be done.
>
>CAs adhering to the CA/B Forum's requirements on CAA records mean that 
>they aren't allowed to issue a certificate for a domain that doesn't 
>list them in the CAA record.
>
>If a CA violates the CAA record requirement, then the CA has bigger 
>issues and will be subject to distrusting in mass.
>
>Certificate Transparency logs make it a lot easier to identify if such 
>shenanigans are done.  --  I think that the CA/B Forum is also
>requiring 
>C.T. Logs.
>
>Also, CAs /should/ *NOT* be generating keys.  The keys should be 
>generated by the malicious party trying to pull the shenanigans that 
>you're talking about.
>
>> All browsers will treat their fake certificate corresponding to the 
>> fake key on their fake web server as completely legitimate. The
>"real" 
>> original key that you generated has no special technical properties 
>> that distinguish it.
>
>Not /all/ browsers.  I know people that have run browser extensions to 
>validate the TLS certificate that they receive against records
>published 
>via DANE in DNS, which is protected by DNSSEC.  So it's effectively 
>impossible for a rogue CA and malicious actor to violate that chain of 
>trust in a way that can't be detected and acted on.

From my understanding its all based on trust and faith unless I take steps from my side. That doesnt seem very safe.
Tech should be based on tech. Not faith and trust on the other party.

Marinus

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2208 bytes --]

Re: [gentoo-user] app-misc/ca-certificates

[Grant Taylor]

On 6/2/21 1:48 AM, Fannys wrote:
> Tech should be based on tech. Not faith and trust on the other party.

That's where detection of breach of trust comes into play.  Thus DNSSEC 
and things related.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] app-misc/ca-certificates

[Fannys]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" <joost@antarean.org> wrote:
>On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
>> On Sat, May 29, 2021 at 03:08:39AM +0200, zcampe@gmail.com wrote
>> 
>> > 125 config files in /etc/ssl/certs needs update.
>> > 
>> > For certificates I would expect the old and invalid ones to be
>replaced
>> > by newer ones without user intervention.
>> 
>>   Looking through them is "interesting".  There seem to be a lot of
>> /etc/ssl/certs/????????.0 files, where "?" is either a random number
>or
>> a lower case letter.  These all seem to be symlinks to
>> /etc/ssl/certs/<Some_Name>.pem.  Each of those files is in turn a
>> symlink to /usr/share/ca-certificates/mozilla/<Some_Name>.crt.  How
>much
>> do we trust China?  There are a couple of certificates in there named
>> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt  and
>> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt.  Any
>> other suspicious regimes in there?
>
>I've always wondered about the amount of CAs that are auto-trusted on
>any 
>system. Including several from countries with serious human rights
>issues.
>
>I could do with a tool where I can easily select which CAs to trust
>based on 
>country.
>
>--
>Joost

Is there actually any tool that can let me pick my certificates?
If i go and start deleting randomly certificates from regimes i dont like will there be any "breaking change"? 
I suppose firefox uses its own certificate store though.

Marinus

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2208 bytes --]

Re: [gentoo-user] app-misc/ca-certificates

[J. Roeleveld]

On Wednesday, June 2, 2021 12:28:49 AM CEST Fannys wrote:
> On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" <joost@antarean.org> wrote:
> >On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
> >> On Sat, May 29, 2021 at 03:08:39AM +0200, zcampe@gmail.com wrote
> >> 
> >> > 125 config files in /etc/ssl/certs needs update.
> >> > 
> >> > For certificates I would expect the old and invalid ones to be
> >
> >replaced
> >
> >> > by newer ones without user intervention.
> >> > 
> >>   Looking through them is "interesting".  There seem to be a lot of
> >> 
> >> /etc/ssl/certs/????????.0 files, where "?" is either a random number
> >
> >or
> >
> >> a lower case letter.  These all seem to be symlinks to
> >> /etc/ssl/certs/<Some_Name>.pem.  Each of those files is in turn a
> >> symlink to /usr/share/ca-certificates/mozilla/<Some_Name>.crt.  How
> >
> >much
> >
> >> do we trust China?  There are a couple of certificates in there named
> >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt  and
> >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt.  Any
> >> other suspicious regimes in there?
> >
> >I've always wondered about the amount of CAs that are auto-trusted on
> >any
> >system. Including several from countries with serious human rights
> >issues.
> >
> >I could do with a tool where I can easily select which CAs to trust
> >based on
> >country.
> >
> >--
> >Joost
> 
> Is there actually any tool that can let me pick my certificates?
> If i go and start deleting randomly certificates from regimes i dont like
> will there be any "breaking change"? I suppose firefox uses its own
> certificate store though.

If the CA is removed from your system/app/..., any key signed by that CA will 
be seen as "untrusted" (treated as if self-signed) and you need to go through 
the usual hoops to allow that certificate to be used.

--
Joost

Re: [gentoo-user] app-misc/ca-certificates

[Grant Taylor]

On 5/29/21 12:26 AM, Walter Dnes wrote:
> Looking through them is "interesting".  There seem to be a lot of 
> /etc/ssl/certs/????????.0 files, where "?" is either a random number 
> or a lower case letter.

They aren't random at all.  They are a fingerprint (hash) of signing (?) 
certificates.  The fingerprint is generated in a deterministic manner.

The sym-links (or hard links) are a convenient way to associate a hash 
back to the cert file that it's representing.

root@host#  ln -s /path/to/cert /etc/ssl/certs/$(openssl x509 -noout 
-hash -in /path/to/cert)

The hash is what things validating things use.  They have no good way to 
determine what the file name would be.  So they compute and look up the 
hash.

You could name all the files with hashes.  But that would make it quite 
annoying ~> difficult, impractical, bordering on impossible for a human 
to maintain.  So, instead, the trusted root certificates are stored by a 
human friendly name and the hashes point to the file via a sym-link.

> These all seem to be symlinks to /etc/ssl/certs/<Some_Name>.pem. 

Quite likely.

> Each of those files is in turn a symlink 
> to/usr/share/ca-certificates/mozilla/<Some_Name>.crt.

Maybe / probably.  Definitely for root certificates that are part of the 
Mozilla Security Suite.  But it's definitely possible to have other root 
certificates through the same system.  E.g. you run your own private / 
enterprise CA.

> Any other suspicious regimes in there?

I'm confident that it depends on where you are in the world.

Let's keep things apolitical and purely technical.



-- 
Grant. . . .
unix || die