November 24, 2014 at 15:13SSL-certificates: to everyone, to everyone, and let no one go offended
As previously reported at GeekTimes, EFF, with the support of Mozilla, Cisco, Akamai, IdenTrust, and researchers from the University of Michigan, have created a new Certificate Authority Let's Encrypt [1] . The aim of the project is to accelerate the transition of the World Wide Web from HTTP to HTTPS.
As stated in [2] , despite the fact that HTTP has become very widespread (which is a sign of a successful protocol), its disadvantage is insecurity (openness of transmitted data) by-design. Whenever a user connects to a site via HTTP, he is exposed to a number of potential problems, such as hijacking accounts, intercepting traffic, monitoring by state and commercial organizations, embedding malicious code (scripts) in page code, and censorship.
Researchers note that HTTPS, although it is not a panacea, solves these problems, so the transition to its widespread use is an important task.
The project is scheduled to be launched in the summer (June?) 2015. Let's Encrypt will automatically issue free certificates for any site that requests them. It is planned. that switching from HTTP to HTTPS when using this service will be done by submitting just one command or pressing a button (cloud technologies - automation to the masses).
It should be noted here that researchers consider the complexity, bureaucracy and cost of certificates required for HTTPS to be the most significant problems when deploying HTTPS. Many users have repeatedly encountered warnings and errors resulting from certificate problems.
The process of obtaining a certificate is bureaucratic, complex, and is the leading reason that sites continue to use HTTP instead of HTTPS.
One of the goals of the Let's Encrypt project is to eliminate unnecessary links and automate the process, which, according to informal measurements by the developers, will reduce the encryption setup time from 1-3 hours to 20-30 seconds.
The project is based on a number of innovative approaches and technologies for managing secure automatic domain verification and certificate issuance. To do this, it is planned to use the ACME protocol developed for these purposes between the web server and CA. Verification will, among other things, use the services of SSL Observatory (EFF), scans.io (MichU), Certificate Transparency (Google).
A new non-profit organization Internet Security Research Group (ISRG) is being created to operate the new CA.
Anyone who has configured HTTPS from scratch knows that obtaining a certificate is not the easiest procedure (while walking, for someone it’s already worked out and is quite understandable). The creators of the project suggest [3] that with the launch of the project it will be enough to execute a couple of commands:
After which example.com becomes available.
The script (set of scripts) Let's Encrypt will do the following:
All this - without confirmation by email, editing configuration files, and for free.
For the functioning of the system, an agent implementing the ACME protocol (Automatic Certificate Management Environment) is launched on your server. The process of proving domain ownership is as follows [4] :
After authorization of the agent, he can request, renew or revoke certificates for his domain (s). Corresponding messages must be signed by an authorized key pair. To obtain a certificate for the domain, the agent generates a Certificate Signing Request (CSR) PKCS # 10 with a request to Let's Encrypt CA to issue a certificate for example.com with the specified public key. As usual, the CSR is signed with the private key corresponding to the public key in the request. Additionally, the CSR is signed with an authorized domain key to confirm the legitimacy of the request to the CA. Upon receipt of the request, the CA verifies both signatures. If they are correct, it issues a certificate for example.com with the public key from the CSR and returns it to the agent. Other procedures (update, recall) work in a similar way.
The ACME protocol is discussed in detail in [5] . Certificates in the X.509 PKI (Public Key Infrastructure, Public Key Infrastructure) are used for various purposes, the most significant of which is domain name authentication. Thus, PKI Certificate Authorities (CAs) are “trusted” with the certificate that the party requesting the certificate (applicant) legitimately represents the domain names listed in the certificate. Currently, verification is carried out through a set of private indirect mechanisms. The creators of ACME set out a way to interact directly and automatically verify and issue certificates.
In established practice [5] , obtaining a certificate consists of a number of mainly manual operations:
The main idea for ACME was to obtain certificates for Web sites (HTTPS [7] ). In this case, each server is responsible for one or more domains, and the process (described above) is designed to verify this correspondence.
For various purposes, it is possible to use different types of certificates [8] :
Of these, DV is probably the most popular (here, price, minimal labor and sufficiency are the main factors). It is important that for verification at DV level, all checks can be performed by the CA automatically, without operator intervention. This is the key feature of the ACME solution - issuing DV certificates, comparable in complexity to issuing a self-signed certificate.
To demonstrate that the server (the applicant) is indeed authorized to send messages on behalf of a certain domain, a CA working under the ACME protocol will request a solution to a set of tasks of the following types (assuming that example.com must be allowed to an agent-controlled site) be via A or AAAA record):
Exchange of the client (agent) with the ACME server (CA) is carried out via the HTTPS protocol with the exchange of JSON messages. Each ACME message is a dictionary, with an obligatory field of type (type), which determines the composition of the remaining fields of the message. All messages are sent to a common HTTPS URI, wired to the client. The client, in general, behaves like a browser, sending requests using the POST method, following redirects (statuses 301, 302). Responses usually come with a status of 200, error information is encoded in JSON responses of type “error”.
The creators of the protocol, in my opinion, prudently provided a “defer” response type, which allows the client to wait for a given time interval before retrying the request. Because Since the service is likely to be very popular, the ability to ask the client to wait if, for example, the server is overloaded and the request is queued will allow the creators of Let's encrypt (and future services based on this protocol) to reduce infrastructure costs.
When processing CSR (sent as base-64 encoded; DER [10]), the server checks the validity of the fields before issuing the certificate. It is assumed that the CA will drop from the issued certificate the names of entities (Subject Alt Name) for which the requesting client (applicant) does not have authorization. In response, the JSON containing the certificate of the applicant includes the certificate itself (base-64 encoded; DER) and the chain of parent certificates in the form of an array of base64, DER, in the order required for the TLS handshake according to [11] , i.e. so that the first certificate in the array confirms the certificate of the applicant, the second certificate of the array confirms the first certificate of the array (each subsequent confirms the immediate predecessor; the root certificate can be discarded, since it is assumed that it is already on the client).
The client part is written in Python, there is a preview on GitHub: https://github.com/letsencrypt/lets-encrypt-preview and it already knows how to configure Apache (there is a stub for nginx)
The server part is written in JS, GitHub: https: / /github.com/letsencrypt/node-acme
In the project wiki you can find information on how to try all this on your server.
Illustrations from letsencrypt.org .
What is the point?
As stated in [2] , despite the fact that HTTP has become very widespread (which is a sign of a successful protocol), its disadvantage is insecurity (openness of transmitted data) by-design. Whenever a user connects to a site via HTTP, he is exposed to a number of potential problems, such as hijacking accounts, intercepting traffic, monitoring by state and commercial organizations, embedding malicious code (scripts) in page code, and censorship.
Researchers note that HTTPS, although it is not a panacea, solves these problems, so the transition to its widespread use is an important task.
The project is scheduled to be launched in the summer (June?) 2015. Let's Encrypt will automatically issue free certificates for any site that requests them. It is planned. that switching from HTTP to HTTPS when using this service will be done by submitting just one command or pressing a button (cloud technologies - automation to the masses).
It should be noted here that researchers consider the complexity, bureaucracy and cost of certificates required for HTTPS to be the most significant problems when deploying HTTPS. Many users have repeatedly encountered warnings and errors resulting from certificate problems.
The process of obtaining a certificate is bureaucratic, complex, and is the leading reason that sites continue to use HTTP instead of HTTPS.
One of the goals of the Let's Encrypt project is to eliminate unnecessary links and automate the process, which, according to informal measurements by the developers, will reduce the encryption setup time from 1-3 hours to 20-30 seconds.
The project is based on a number of innovative approaches and technologies for managing secure automatic domain verification and certificate issuance. To do this, it is planned to use the ACME protocol developed for these purposes between the web server and CA. Verification will, among other things, use the services of SSL Observatory (EFF), scans.io (MichU), Certificate Transparency (Google).
A new non-profit organization Internet Security Research Group (ISRG) is being created to operate the new CA.
How will it work?
Anyone who has configured HTTPS from scratch knows that obtaining a certificate is not the easiest procedure (while walking, for someone it’s already worked out and is quite understandable). The creators of the project suggest [3] that with the launch of the project it will be enough to execute a couple of commands:
$ sudo apt-get install lets-encrypt$ lets-encrypt example.comAfter which example.com becomes available.
The script (set of scripts) Let's Encrypt will do the following:
- Automatically “prove” to the CA Let's Encrypt server that you control the site (domain)
- Receive a certificate that browsers will trust and install it on your server, making the necessary configuration changes
- Will track the expiration of the certificate and request its renewal
- Will help with revocation of the certificate if necessary
All this - without confirmation by email, editing configuration files, and for free.
What's under the hood?
For the functioning of the system, an agent implementing the ACME protocol (Automatic Certificate Management Environment) is launched on your server. The process of proving domain ownership is as follows [4] :
- The agent on the server sends a request to Let's Encrypt CA with the domain to be confirmed (example.com)
- CA evaluates the domain and generates one or more challenge sets, the solution of which by the agent proves the domain belongs. Such tasks are divided into two types:
- creating a DNS record for the example.com subdomain
- creating an HTTP accessible resource on a known URI at example.com
- In addition to domain validation tasks, a temporary attribute (data object) is generated, which the agent on the server will sign with its private key to prove ownership.
- The agent performs one of the task sets and signing the attribute and notifies the CA of the readiness for verification.
- CA begins verification by verifying electronic digital signature (EDS) and file / subdomain availability
- If the EDS is correct and the problem is solved correctly, CA considers that the agent identified by some public key is authorized to manage certificates for the example.com domain. The key pair used by the agent becomes the “authorized key pair” for example.com.
After authorization of the agent, he can request, renew or revoke certificates for his domain (s). Corresponding messages must be signed by an authorized key pair. To obtain a certificate for the domain, the agent generates a Certificate Signing Request (CSR) PKCS # 10 with a request to Let's Encrypt CA to issue a certificate for example.com with the specified public key. As usual, the CSR is signed with the private key corresponding to the public key in the request. Additionally, the CSR is signed with an authorized domain key to confirm the legitimacy of the request to the CA. Upon receipt of the request, the CA verifies both signatures. If they are correct, it issues a certificate for example.com with the public key from the CSR and returns it to the agent. Other procedures (update, recall) work in a similar way.
Learn a little more?
Problem
The ACME protocol is discussed in detail in [5] . Certificates in the X.509 PKI (Public Key Infrastructure, Public Key Infrastructure) are used for various purposes, the most significant of which is domain name authentication. Thus, PKI Certificate Authorities (CAs) are “trusted” with the certificate that the party requesting the certificate (applicant) legitimately represents the domain names listed in the certificate. Currently, verification is carried out through a set of private indirect mechanisms. The creators of ACME set out a way to interact directly and automatically verify and issue certificates.
In established practice [5] , obtaining a certificate consists of a number of mainly manual operations:
- Generate PKCS # 10 Request [6] - CSR
- Copy-Paste CSR on CA Page
- Prove domain ownership using one of the following methods:
- Place the issued CA object (URI challenge) at a specified location on the server
- Place the CA-issued line (DNS challenge) in the specified DNS host corresponding to the domain being verified
- Receive a message from CA (email challenge) at the (theoretically) domain administrator-controlled email address and enter the received code on the CA page
- Download the issued certificate and install it on the server.
The main idea for ACME was to obtain certificates for Web sites (HTTPS [7] ). In this case, each server is responsible for one or more domains, and the process (described above) is designed to verify this correspondence.
For various purposes, it is possible to use different types of certificates [8] :
- Extended Validation (EV) - CA checks the legitimacy of the use of the domain name and characteristics of the organization by the applicant (exists, documents are in order, the domain belongs to the organization, the organization requested a certificate; more details in [9] )
- Organization Validation (OV) - CA verifies that the applicant is using the organization’s domain name and domain name
- Domain Validation (DV) - CA validates domain applicant's legitimacy
Of these, DV is probably the most popular (here, price, minimal labor and sufficiency are the main factors). It is important that for verification at DV level, all checks can be performed by the CA automatically, without operator intervention. This is the key feature of the ACME solution - issuing DV certificates, comparable in complexity to issuing a self-signed certificate.
How is domain ownership confirmed?
To demonstrate that the server (the applicant) is indeed authorized to send messages on behalf of a certain domain, a CA working under the ACME protocol will request a solution to a set of tasks of the following types (assuming that example.com must be allowed to an agent-controlled site) be via A or AAAA record):
- creation of a TXT record in the DNS domain of the form _acme-challenge.example.com. containing some coolrandomealfanumerictoken issued by the server
- place the file so that it is accessible by the URI example.com/magnificientalfanumerictrictoken , GET verification by CA
- place the file so that it is accessible by the URI example.com/yetanothertoken , for which the agent “hastily” raises HTTPS; GET verification from CA
- Raise HTTPS (using a self-signed certificate) and accept the TLS connection from CA. The certificate is generated in this way. to contain (in subjectAltName) a verified domain and a domain of the form
.acme.invalid ", where Z = SHA-256 (R || S), (R - random value reported by the server during the exchange; S - random reported by the client) - the list can be further expanded, for example, planned email, DNSSEC, WHOIS
How is the client-server exchange?
Exchange of the client (agent) with the ACME server (CA) is carried out via the HTTPS protocol with the exchange of JSON messages. Each ACME message is a dictionary, with an obligatory field of type (type), which determines the composition of the remaining fields of the message. All messages are sent to a common HTTPS URI, wired to the client. The client, in general, behaves like a browser, sending requests using the POST method, following redirects (statuses 301, 302). Responses usually come with a status of 200, error information is encoded in JSON responses of type “error”.
The creators of the protocol, in my opinion, prudently provided a “defer” response type, which allows the client to wait for a given time interval before retrying the request. Because Since the service is likely to be very popular, the ability to ask the client to wait if, for example, the server is overloaded and the request is queued will allow the creators of Let's encrypt (and future services based on this protocol) to reduce infrastructure costs.
When processing CSR (sent as base-64 encoded; DER [10]), the server checks the validity of the fields before issuing the certificate. It is assumed that the CA will drop from the issued certificate the names of entities (Subject Alt Name) for which the requesting client (applicant) does not have authorization. In response, the JSON containing the certificate of the applicant includes the certificate itself (base-64 encoded; DER) and the chain of parent certificates in the form of an array of base64, DER, in the order required for the TLS handshake according to [11] , i.e. so that the first certificate in the array confirms the certificate of the applicant, the second certificate of the array confirms the first certificate of the array (each subsequent confirms the immediate predecessor; the root certificate can be discarded, since it is assumed that it is already on the client).
Show me your code!
Disclaimer
(Here you need to, just in case, notice that the code is not mine, I'm just sympathetic)
The client part is written in Python, there is a preview on GitHub: https://github.com/letsencrypt/lets-encrypt-preview and it already knows how to configure Apache (there is a stub for nginx)
The server part is written in JS, GitHub: https: / /github.com/letsencrypt/node-acme
In the project wiki you can find information on how to try all this on your server.
Sources and links
- https://letsencrypt.org/
- https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
- https://letsencrypt.org/howitworks/
- letsencrypt.org/howitworks/technology
- https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md
- http://www.ietf.org/rfc/rfc2314.txt
- http://tools.ietf.org/html/rfc2818
- https://www.globalsign.com/ssl-information-center/types-of-ssl-certificate.html
- https://cabforum.org/ev-code-signing-certificate-guidelines/
- https://en.wikipedia.org/wiki/X.690#DER_encoding
- http://tools.ietf.org/html/rfc5246
Illustrations from letsencrypt.org .