How can I suggest Let's Encrypt rather than paid options in the Brazilian government?


#1

Dear Let’s Encrypt team.

My name is Valério, I’m a IT analyst in a brazilian government position and we are using Let’s Encrypt in one of our web software.

Another government department asked us why we are using Let’s encrypt rather then a other brazilian paid option.

I need your help to sustain my position in keep using Let’s encrypt.

How can I explain to others the advantages of Let’s Encrypt over others paid options.

I wait your reply.

Thank you for your time.


#2

I see a lot of advantage in using Let’s Encrypt rather than a another certificate authority, nut let me enphasys first on one major drawback:

The main limit is Certificates per Registered Domain , (50 per week)

So if you create a lot of certificates under .gov.br you may hit that limit (there is an Exemption for Renewal)

See https://letsencrypt.org/docs/rate-limits/ for more details.

But, other that that, the main advantages of Let’s Encrypt for your use case (but you already know it):

  • Free
  • Automated

#3

Hi @valeriocarvalho

technical, there is no difference between the encryption using a domain validated or an extended / organisational validated certificate. Only the length of the certificate key (2048 or 4096 bit) and the configuration (tls.1.2, new cipher suites) is important.

So if you want to use Letsencrypt certificates with internal servers, there is no limitation.

It’s an interesting question if a government should use Letsencrypt with public servers without Extended validation.

But as @tdelmas wrote: The automation is the main thing. Manual installation is painful, I did this about years. Now customers can route their own domain to my service, a script runs - oh, there is a new certificate :wink:


#4

For public domains, of course (and a resolver publicly accessible must be able to answer DNS requests, at least for TXT records to solve the challenges)

For domains on a reserved prefix such as .gov.br I see no reason to do so: the domain name already says it’s a government domain. For domains on public prefix, it may be interesting.

Free too. not about the money, but because it’s often painful inside administration to obtain/unlock budget and/or means of payment, even more when it should be done every years for small amounts. And Brasil is known - as much as France - for his heavy bureaucratic procedures :wink:

Did they say why they think their solution is better?


#5

Thank you @tdelmas and @JuergenAuer!

About the question: Did they say why they think their solution is better?

They said whether it is really safe for the data to travel to another country.

But the biggest companies in the world are suggesting Let’s Encript. And if I were to question the functioning of Let’s encrypt because it is open and free I would have to do the same with all apaches, linux distributions, and opensources apps. They did not said a logical argument. Tell me what you think.

Thank again for your time.


#6

There is three points to consider:

  1. When your server asks for the certificate

Indeed, your server communicate to Let’s Encrypt server, which is in another country, but no confidentiality problem here.

  1. When somebody visits your website

The path taken by the data transferred between your server and your visitor isn’t dependent of your certificate. No problem there.

  1. When somebody visits your website, the browser need to check if the certificate is valid. For that, there is three solutions:
  • CRL : the browser downloads a “list of revoked certificates” from the certificate authority. It’s not implemented by Let’s Encrypt

  • OCSP: the browser asks the certificate authority “is this certificate expired” and the certificate authority gives a signed answer valid a few days. In that situation the certificate authority may knows who visited your website (but not which page/content is transferred)

  • OCSP Stapling: your server regularly asks the certificate authority the signed proof that your certificate is not expired, and when a user connects to your website, your server give him, so he doesn’t have to communicate with the certificate authority: No confidentiality problem in that situation.

You can consult https://letsencrypt.org/privacy/#relying-party about it:

Relying Party
When you use an HTTPS web site or other TLS service with a Let’s Encrypt certificate, your browser (or TLS client) may query Let’s Encrypt to check whether the certificate has been revoked (“OCSP request”). …

I personally think there is no problem using Let’s Encrypt.

If you can implement OCSP Stapling it’s better (and for performance reason too).

Exactly, it’s openness made it easier to understand!

Best of luck, and don’t hesitate to came back with the result!


#7

Oi @valeriocarvalho,

You can see that the use of Let’s Encrypt certificates within the Brazilian government has already become common.

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:true;domain:gov.br&lu=cert_search

In fact, it became so common that we had various threads on this forum related to rate limit exceptions for Brazilian state government subdomains. If you search this forum, you can find some of those threads and maybe contact some of the people who’ve been using Let’s Encrypt certificates in Brazilian state and federal government agencies.

I think it’s important to consider the threat models here. In addition to the examples that @tdelmas gave, some people mistakenly think that certificate authorities can intercept communications between users and the sites that use their certificates. This is not true because the certificate authority never possesses or accesses your private key. The certificate authority only knows your public key, which is the same information that end users of your sites and services will receive.

It’s true that certificate authorities can facilitate attacks against web sites by issuing false or inaccurate certificates. In this case the false certificate could be used by an active attacker to spy on the visitors to the site, if the attacker controls part of the network that the visitors are using. A very famous example of this was when someone in Iran hacked certificate authorities in the Netherlands and the United States and issued false certificates for major web sites, which were then used by the Iranian government to spy on visitors to those sites. However, an important thing to consider about that case is that those sites were not customers of the hacked certificate authorities. Using a hacked certificate authority to attack a site did not require that the site have any existing relationship with the certificate authority at all. There’s no obvious reason that their vulnerability to this attack would have been any greater, or any less, based on which certificate authority they were using, because generally any public certificate authority always has the authority to issue certificates for any web site.

The other examples that @tdelmas gives are also quite valid.

Someone might also want to limit (1) the public disclosure of internal host names, or (2) the technical ability of foreign certificate authorities to issue certificates for a particular site. Currently, the most popular web browser, in its default configuration, does not provide any options that would allow someone to achieve these goals, because all host names in certificates must be publicly disclosed by every publicly-trusted certificate authority, and every publicly-trusted certificate authority has the ability to issue certificates for every site. The only way to achieve either of these goals, then, is with a custom browser configuration, using a non-publicly-trusted certificate authority.

An exception is the use of wildcard certificates, which don’t publicly disclose exact host names because they are valid for any subdomain of a particular name. So for example you could have a certificate for *.sigiloso.gov.br and it would be valid for segredo.sigiloso.gov.br, without publicly mentioning that specific name in the certificate.

Several governments, including the Brazilian government, have operated internal public-key infrastructure including their own certificate authorities. This could be a very good idea for government security requirements, because it could be part of a strategy to avoid trusting foreign entities with the power to certify the government’s infrastructure, but it probably only improves security at all if all of the site visitors are using custom browsers. That’s because the site visitors should (1) trust the government PKI, and (2) not trust other certificate authorities for specified government-related domains. That won’t work if members of the public or government employees have to visit the site using off-the-shelf browsers or devices.

Participating in a public PKI (including simply by supporting off-the-shelf browsers like Chrome) comes with security trade-offs. The industry is trying to make these trade-offs better with mechanisms like Certificate Transparency, so that if someone issues fraudulent certificates for your domain name, you should be able to find out about the problem (which was not quite true at the time of the Iranian attack I mentioned above).

Espero que isso faça sentido e posso discutir o assunto em português também se tiver outras dúvidas.


#8

Parts of the Brazilian government have adopted the ICP PKI

https://www.iti.gov.br/icp-brasil/

and suggested that visitors to government sites add the Autoridade Certificadora Raiz to their browsers.

I don’t think this is a good idea if the intended users are the general public (within Brazil or elsewhere) because it’s both cumbersome risky to add new trusted roots to one’s browser, including because there isn’t a straightforward, easy way to figure out whether you’re adding the right one! (Someone could make a phishing site that tries to persuade people that a different certificate is the ICP’s AC-Raiz; if they believe it, that phisher gets a powerful option for attacking their visits to all Internet sites in the future. What’s more, the attacker can potentially automatically detect when a target has installed the root by embedding a single-pixel tracker from a site signed by the fake CA. Users who load that image are vulnerable, while users who don’t aren’t.)

Alternatives that work together better with the existing PKI and browser model would include:

  • Getting the root added to browsers’ default trust list (which may be difficult)
  • Getting a name-constrained version of the root added to browsers’ default trust list (so that it can only issue trusted certificates under .gov.br)
  • Getting a name-constrained version of the root cross-signed by an existing public CA
  • Using existing public CAs
  • Issuing a Brazilian government browser, or one or more apps that use certificate pinning, specifically to be used for connecting to Brazilian government sites

The last option has the advantage that we have better mechanisms right now for verifying the origin and integrity of some kinds of published software than for verifying the origin and integrity of root CAs that we’re asked to trust in our existing browser. Also, if we want to trust the CA only for some purposes, using separate software that trusts it would be safer than trusting it for all sites in our default browsing environment.

I once heard someone associated with the ICP give a speech that was oriented toward the idea that using domestic CAs was important for Brazil’s autonomy and national sovereignty. There may be some merit in this idea, but the browsers’ root programs have also been an important force for good in reducing the power of CAs and increasing their accountability. While a government might not want its power over digital certification to be limited by foreign browsers’ root programs’ rules and scrutiny, users might well want appreciate this.


#9

Thank you @schoen. This list you provided was very useful. I have already accumulated the arguments in favor of lets encrypt and I see as something with no return. This is the way to go.

In portuguese: Obrigado por se dispor a discutir em português.