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?

[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: elie...@ngtech.co.il


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Amos Jeffries
Sent: Wednesday, January 23, 2019 12:57
To: squid-users@lists.squid-cache.org
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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

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?

[Amos Jeffries]

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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

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?

[Eliezer Croitoru]

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: elie...@ngtech.co.il



-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Andrea Venturoli
Sent: Monday, January 21, 2019 10:51
To: squid-users@lists.squid-cache.org
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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

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?

[Amos Jeffries]

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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

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?

[Andrea Venturoli]

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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

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?

[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::http://lists.squid-cache.org/listinfo/squid-users

[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?

[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: elie...@ngtech.co.il



 

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users