What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Eliezer Croitoru

OK so from the real world:

What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

 

I have a setup which one of the requirements is to restrict access to sites which depends on Let’s encrypt generated certificates.

The issue is that these sites are encrypted but do not offer any way of assuring real ISO and couple other compatibilities of the ORG.

For a simple home user it’s fine most of the time but for some it’s not.

The most simple way is to block the specific domain but I need to know if the site certificate is from Let’s encrypt.


I was thinking about an external ACL helper that might check it for squid if squid or openssl doesn’t have currently an option to implement it.

 

Thanks,

Eliezer

 

----

Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]

 


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Alex Rousskov
On 1/20/19 3:02 PM, Eliezer Croitoru wrote:

> What's the best way to ban Let's encrypt based certificates? or
> whitelist a very narrow list of Root and Intermediates CA?

A requirement to ban all Let's Encrypt sites sounds invalid to me, but
you can use certificate validator to do that. Same for whitelisting CAs.
The corresponding squid.conf directives are sslcrtvalidator_program and
sslcrtvalidator_children. For a rough description of the helper messages
format, please see "certificate validator" at

    https://wiki.squid-cache.org/Features/AddonHelpers

Squid distribution also includes a minimal certificate validation
helper: security_fake_certverify.pl


> I was thinking about an external ACL helper

Some use cases can be addressed using %ssl::<cert_issuer, but it would
be difficult to supply the right info the the external ACL helper in
general because Squid lacks logformat %codes that relay all intermediate
certificates.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Andrea Venturoli
In reply to this post by Eliezer Croitoru
On 1/20/19 11:02 PM, Eliezer Croitoru wrote:

> The issue is that these sites are encrypted but do not offer any way of
> assuring real ISO and couple other compatibilities of the ORG.
>
> For a simple home user it’s fine most of the time but for some it’s not.

Just out of curiosity, could you better explain this?
Pointer are enough if you prefer.

  bye & Thanks
        av.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Amos Jeffries
Administrator
In reply to this post by Eliezer Croitoru
On 21/01/19 11:02 am, Eliezer Croitoru wrote:
> OK so from the real world:
>
> What's the best way to ban Let's encrypt based certificates? or
> whitelist a very narrow list of Root and Intermediates CA?
>


Besides what Alex has answered to your first question. I think the
simpler approach would be the second, and probably more what you need
anyway...

 tls_outgoing_options default-ca=off cafile=X.pem cafile=Y.pem


That makes Squid outgoing connections *not* use the global Trusted CA
set. Then explicitly load the individual one(s) you *do* want to trust.

A whitelist - but only for the root / self-signed CA certs. Intermediary
CAs inherit their trust (or lack) from their root CA.

If intermediary CA trust matters to your situation then a custom
validator as mentioned by Alex would be necessary.

NP: You can list cafile=... as many times as you wish to load multiple
files and should be able to load multiple CA certs in any of the
file(s). But have not confirmed that latter.

cache_peer has matching options with "tls-" prefix.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Eliezer Croitoru
In reply to this post by Andrea Venturoli
OK so,

Every Root CA have differ level of certification.
For example there are Root CA's which are allowed to sign only for encryption
...and basic domain ownership validation which can be verified against a Domain Regristrar.
Compared to this there are couple other level's of Certificates like what is name "EV" (the one of banks and such critical ORG's).
Let's encrypt brings to domain ownership the ability to being verified as the domain owner or it's proxy.

The Root CA that the bank of America uses has the license to offer not only encryption but also:
* Ensures the identity of a remote computer
* Proves your identity to a remote computer
* Protects e-mail messages
* Ensures software came from software publisher
* Protects software from alteration after publication
* Allows data to be signed with the current time

Compared to Let's encrypt that is an intermediate CA with the next license:
* Protects e-mail messages
* Ensures the identity of a remote computer
* Proves your identity to a remote computer
* Allows data to be signed with the current time
* Allows data on disk to be encrypted
* 2.23.140.1.2.1
* 1.3.6.1.4.1.44947.1.1.1
* Document Signing

Which doesn't includes:
* Ensures software came from software publisher

Which is critical for ISO bounded web services.

In another words:
If the certificate is not EV ie the name of the corporation or business it means that it's not ISO compliance regarding
paying using a credit/visa/other card.

So if you are going to pay to someone over the Internet only pay if you know and validated the identity of the owner and\or orginzation.
This concept was introduced to prevent phishing and other things.
One of the exception I have seen is Paypal main site which does have EV named license/certificate but the name is not embedded into the certificate so I prefer not to buy in this specific site but buy locally.

All The Bests,
Eliezer

* For others paypal might be good enough...

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]



-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Andrea Venturoli
Sent: Monday, January 21, 2019 10:51
To: [hidden email]
Subject: Re: [squid-users] What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

On 1/20/19 11:02 PM, Eliezer Croitoru wrote:

> The issue is that these sites are encrypted but do not offer any way
> of assuring real ISO and couple other compatibilities of the ORG.
>
> For a simple home user it’s fine most of the time but for some it’s not.

Just out of curiosity, could you better explain this?
Pointer are enough if you prefer.

  bye & Thanks
        av.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Amos Jeffries
Administrator


On 23/01/19 7:59 pm, Eliezer Croitoru wrote:

> OK so,
>
> Every Root CA have differ level of certification.
> For example there are Root CA's which are allowed to sign only for encryption
> ...and basic domain ownership validation which can be verified against a Domain Regristrar.
> Compared to this there are couple other level's of Certificates like what is name "EV" (the one of banks and such critical ORG's).
> Let's encrypt brings to domain ownership the ability to being verified as the domain owner or it's proxy.
>
> The Root CA that the bank of America uses has the license to offer not only encryption but also:
> * Ensures the identity of a remote computer
> * Proves your identity to a remote computer
> * Protects e-mail messages
> * Ensures software came from software publisher
> * Protects software from alteration after publication
> * Allows data to be signed with the current time
>
> Compared to Let's encrypt that is an intermediate CA with the next license:
> * Protects e-mail messages
> * Ensures the identity of a remote computer
> * Proves your identity to a remote computer
> * Allows data to be signed with the current time
> * Allows data on disk to be encrypted
> * 2.23.140.1.2.1
> * 1.3.6.1.4.1.44947.1.1.1
> * Document Signing
>

Those listed things above sound like the X.509 certificate 'use'
properties are what you actually need to be checking. Am I right?

> Which doesn't includes:
> * Ensures software came from software publisher
>
> Which is critical for ISO bounded web services.
>
> In another words:
> If the certificate is not EV ie the name of the corporation or business it means that it's not ISO compliance regarding
> paying using a credit/visa/other card.
>
> So if you are going to pay to someone over the Internet only pay if you know and validated the identity of the owner and\or orginzation.
> This concept was introduced to prevent phishing and other things.
> One of the exception I have seen is Paypal main site which does have EV named license/certificate but the name is not embedded into the certificate so I prefer not to buy in this specific site but buy locally.
>

A validator which checks for existence or non-existence of certain X.509
permissions would be the better approach instead of a curated whitelist
of CA names. That way;
 * you are not limited to whitelisting and its inherent "human error" or
incompleteness component biasing for/against any particular CAs,
 * you can publish the required criteria for transparency,
 * CAs can choose for themselves whether they adjust certs permissions
to be blocked or un-blocked without involving any tricky politics to
lower your required standard of proof.


Some CAs might for example have a special root CA with restricted
policies to comply with the ISO requirement, and another for their wider
use.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

Eliezer Croitoru
Amos,

Thanks for the feedback.

Now that we write about the subject in clear text it's making things a bit clear.
I wasn't sure about the  purpose of the helpers to begin with.

As you wrote before, for specific use cases these X.509 properties are what this specific organization need to verify.
From my point of view most users(non-technical) are yet to understand these properties good enough and these are things
that us and our kids needs to learn about the Internet: "not every Encrypted traffic means secure!".

Specifically Let's encrypt makes sure that the world of encryption will be more popular and there for more secure.
So +*2 for them but still the point stays with then that encryption might not always be the right way.
SFTP ,MS and OpenSSL + others proved that encryption is a must in our world but not always the right answer.

..Also DNSSec and/or EDNS makes this picture much clear.

Eliezer

* If I missed someone it's because there are too many to say thank you to/for.

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Amos Jeffries
Sent: Wednesday, January 23, 2019 12:57
To: [hidden email]
Subject: Re: [squid-users] What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?



On 23/01/19 7:59 pm, Eliezer Croitoru wrote:

> OK so,
>
> Every Root CA have differ level of certification.
> For example there are Root CA's which are allowed to sign only for encryption
> ...and basic domain ownership validation which can be verified against a Domain Regristrar.
> Compared to this there are couple other level's of Certificates like what is name "EV" (the one of banks and such critical ORG's).
> Let's encrypt brings to domain ownership the ability to being verified as the domain owner or it's proxy.
>
> The Root CA that the bank of America uses has the license to offer not only encryption but also:
> * Ensures the identity of a remote computer
> * Proves your identity to a remote computer
> * Protects e-mail messages
> * Ensures software came from software publisher
> * Protects software from alteration after publication
> * Allows data to be signed with the current time
>
> Compared to Let's encrypt that is an intermediate CA with the next license:
> * Protects e-mail messages
> * Ensures the identity of a remote computer
> * Proves your identity to a remote computer
> * Allows data to be signed with the current time
> * Allows data on disk to be encrypted
> * 2.23.140.1.2.1
> * 1.3.6.1.4.1.44947.1.1.1
> * Document Signing
>

Those listed things above sound like the X.509 certificate 'use'
properties are what you actually need to be checking. Am I right?

> Which doesn't includes:
> * Ensures software came from software publisher
>
> Which is critical for ISO bounded web services.
>
> In another words:
> If the certificate is not EV ie the name of the corporation or business it means that it's not ISO compliance regarding
> paying using a credit/visa/other card.
>
> So if you are going to pay to someone over the Internet only pay if you know and validated the identity of the owner and\or orginzation.
> This concept was introduced to prevent phishing and other things.
> One of the exception I have seen is Paypal main site which does have EV named license/certificate but the name is not embedded into the certificate so I prefer not to buy in this specific site but buy locally.
>

A validator which checks for existence or non-existence of certain X.509
permissions would be the better approach instead of a curated whitelist
of CA names. That way;
 * you are not limited to whitelisting and its inherent "human error" or
incompleteness component biasing for/against any particular CAs,
 * you can publish the required criteria for transparency,
 * CAs can choose for themselves whether they adjust certs permissions
to be blocked or un-blocked without involving any tricky politics to
lower your required standard of proof.


Some CAs might for example have a special root CA with restricted
policies to comply with the ISO requirement, and another for their wider
use.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users