Mailing List Archive

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

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

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

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

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

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

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

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.

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

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

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

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?

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

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

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

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

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