The two articles in this series cover cryptographic hashing, digital signature, encryption and decryption, and digital certificates. You can find these codes and command line examples in the ZIP file of my website.
Let's review SSL in OpenSSL name first.
Secure Sockets Layer (SSL) is an encryption protocol published by Netscape in 1995. This protocol layer can be located above HTTP, thus providing S: secure for HTTPS. SSL protocol provides various security services, including two services that are crucial in HTTPS:
There are many versions of SSL (such as SSLv2 and SSLv3). In 1999, a similar protocol, Transport Layer Security (TLS), appeared based on SSLv3. TLSv 1 is similar to SSLv3, but not enough to work together. However, SSL/TLS is usually called the same protocol. For example, the name of OpenSSL function often contains SSL, even if TLS is used instead of SSL. In addition, calling openssl command-line utility starts with OpenSSL.
Except man pages, OpenSSL documents are scattered, which are difficult to find and use in view of the large OpenSSL toolkit. Command lines and code examples can highlight topics. Let's talk about a familiar example (accessing a website with HTTPS), and then use this example to select the encrypted part that we are interested in.
The client program shown here connects to Google via HTTPS:
You can compile and execute the program from the command line (note the lowercase letter L in -lssl and -lcrypto):
The program tried to open a secure connection to the www.google.com website. During TLS handshake with Google Web server, the client program will receive one or more digital certificates, and the program will try to verify them (but failed on my system). Nevertheless, the client program continues to obtain the Google home page through a secure channel. This program relies on the aforementioned security components, although only the digital certificate is highlighted in the above code. But other artifacts still play a role behind the scenes, which will be explained in detail later.
Usually, a C or C++ client program that opens an HTTP (non-secure) channel will use structures such as file descriptors or network sockets, which are the endpoints of the connection between two processes (for example, this client program and Google Web server). On the other hand, the file descriptor is a non-negative integer value, which is used to identify the structure of any file class that the program opens in the program. Such a program will also use a structure to specify detailed information about the Web server address.
These relatively low-level structures will not appear in client programs, because OpenSSL libraries will encapsulate socket infrastructure and address specifications in higher-level security structures. The result is a simple API. Let's first look at the security details in the client program example.
During the handshake with the Web server, the client program will receive one or more digital certificates to verify the identity of the server. However, the client program will not send its own certificate, which means that this authentication is one-way. (Web servers usually don't have client certificates. Although the verification of the Web server certificate failed, the client program continued to obtain the Google homepage through a secure channel connected to the Web server.
Why did the attempt to verify Google Certificate fail? The typical OpenSSL installation directory is /etc/ssl/certs, which contains the ca-certificates.crt file. This directory and file contains the digital certificate attached to OpenSSL, which constitutes a trust base. You can update the trust base as needed, especially including newly trusted certificates, and delete certificates that are no longer trusted.
The client program received three certificates from the Google Web server, but the OpenSSL truststore on my computer does not contain the exact matching certificates. According to the current writing, the client program will not solve this problem by verifying the digital signature on the Google certificate (used to prove the signature of the certificate). If the signature is trusted, the certificate containing the signature should also be trusted. Nevertheless, the client program continues to get the page and then prints out Google's home page. The next section will introduce these in more detail.
Let's start with the security component (digital certificate) visible in the client example, and then consider how other security components are related to it. The main format standard of digital certificate is X509, and the certificate of production level is issued by certification bodies (CA) such as Verisign.
A digital certificate contains various information (for example, activation date and expiration date, as well as the owner's domain name), as well as the issuer's identity and digital signature (which is an encrypted hash value). The certificate also has an unencrypted hash value that is used as its identity fingerprint.
Hash values come from mapping any number of binary bits to fixed-length digests. It doesn't matter what these bits represent (accounting reports, novels or digital movies). For example, the 5 (Message Digest Version 5)(MD5) hashing algorithm maps the input bits of any length to the 128-bit hash value, while the SHA 1 (Secure Hash Algorithm Version 1) algorithm maps the input bits to the 160-bit hash value. Different input bits will lead to different (actually statistically unique) hash values. The next article will introduce it in more detail, focusing on what makes hash function have encryption function.
The types of digital certificates are different (such as root certificate, intermediate certificate and final entity certificate), which forms a hierarchical structure reflecting these certificate types. As the name implies, the root certificate is at the top of the hierarchy, and the certificates below it inherit the trust of the root certificate. OpenSSL libraries and most modern programming languages have X509 data types and functions to handle such certificates. The certificate from Google is in X509 format, and the client program will check whether the certificate is X509_V_OK.
X509 certificate is based on public key infrastructure (PKI), which includes the algorithm for generating key pairs (RSA is the main algorithm): public key and its paired private key. The public key is an identity: Amazon's public key identifies it, and mine identifies me. The private key should be kept secret by its owner.
Keys that appear in pairs have standard usage. You can encrypt a message with a public key and then decrypt it with a private key in the same key pair. The private key can also be used to sign documents or other electronic artifacts (such as programs or emails), and then the public key in the key pair can be used to verify the signature. The following two examples add some details.
In the first example, Alice distributed her public key to the whole world, including Bob. Then, Bob encrypts the email with Alice's public key, and then sends the encrypted email to Alice. Messages encrypted with Alice's public key will be decrypted with her private key (assuming it is her own private key), as follows:
In theory, messages can be decrypted without Alice's private key, but in practice, if the system is paired with an encryption key like RSA, it will be impossible in calculation.
Now, for the second example, please sign the document to prove its authenticity. The signature algorithm uses the private key in the key pair to process the encrypted hash of the document to be signed:
Suppose Alice digitally signs the contract sent to Bob. Bob can then use the public key in Alice's key pair to verify the signature:
Without Alice's private key, it is impossible to forge Alice's signature easily: therefore, it is necessary for Alice to keep her private key secret.
In the client program, except for the digital certificate, these security are not clearly displayed. The next article will use examples of OpenSSL utilities and library functions to fill in more detailed information.
Meanwhile, let's take a look at OpenSSL command-line utilities: in particular, the utility that checks the certificate from the Web server during TLS handshake. Calling the openssl utility can use the OpenSSL command and then add a combination of parameters and flags to specify the required operation.
Please look at the following command:
The output is a list of related algorithms that make up the cryptographic suite (). The following is the beginning of the list, with notes to clarify abbreviations:
The next command uses the parameter s_client to open a secure connection to www.google.com and displays all information about this connection on the screen:
Major websites such as Google usually send multiple certificates for authentication.
The output ends with a summary of the TLS session, including details of the encryption algorithm suite:
The client program uses the protocol TLS 1.2, and the Session-ID uniquely identifies the connection between openssl utility and Google Web server. Password entries can be parsed in the following ways:
The suite of encryption algorithms is constantly developing. For example, not long ago, Google used RC4 stream encryption algorithm (Ron Rivest of RSA later developed Ron's Crypter version 4). RC4 now has a known vulnerability, which may be part of the reason why Google converted to AES 128.
We first learned about OpenSSL through a secure C Web client and various command line examples, which highlighted some topics that need further clarification. The next article will introduce in detail, starting with cryptographic hashing, and ending with a more comprehensive discussion on how digital certificates deal with key distribution challenges.
via:/article/ 19/6/cryptography-basics-OpenSSL-part- 1
Author: Marty Karin Title: lujun9972 Translator: wxy Proofreading: wxy