[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: eliezer at ngtech.co.il


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