Security https-Full details symmetric encryption, asymmetric encryption, digital signatures, digital certificates and HTTPS "under"

1. HTTPS1.1. What is HTTPS

HTTPS (Hypertexttransfer Protocol Secure) is a secure HTTP. The security foundation for HTTPS is the Secure Sockets Layer (secure Sockets layer,ssl). HTTP works at the application layer (the highest layer of the OSI model), and the SSL protocol works in a lower sub-layer, between the TCP/IP protocol and the HTTP protocol. Encrypt the HTTP message before it is transmitted and decrypt it when it arrives. Strictly speaking, HTTPS is not a separate protocol, but an HTTP protocol that works on the SSL protocol.

TLS is an extension of SSL and is a successor to SSL, but there is little difference between the two, and the following discussion does not strictly differentiate between TLS and SSL.

There are two main functions of https: (1) confirm the identity of both sides of the communication, (2) establish a secure channel to ensure the security of data transmission. 1.2. HTTPS's main role 1.2.1. Confirming the identities of both parties to the communication

HTTPS communication, through the signature technology communication between the two sides can confirm the identity of each other. Identity authentication is divided into one-way authentication and two-way authentication. One-way authentication only the server side has the certificate, two-way authentication in the server and the client has the certificate. A typical HTTPS site only has a certificate for the server and no certificate for the client.

One-way certification is a simplified version of two-way certification, the discussion process in this article without special instructions are considered to be two-way authentication.

1.2.2. Establish a secure channel for secure data transmission

SSL protocol-based communication The two parties can negotiate a key for symmetric encryption, which is a hard-to-crack random number, and relies on the communication between the certificate, the private key and so on to negotiate. After the key negotiation, the two parties use the key to decrypt the data, thus ensuring the data security.

1.3. HTTPS and HTTP protocol differences

(1). HTTP URL is the "http://" Start, HTTPS URL is "https://" start;

(2). The default port for HTTP default port is 80,https is 443;

(3). Web server with HTTPS needs to request a certificate from the CA;

(4). HTTPS is implemented by HTTP+SSL, can be encrypted transmission, identity authentication, etc., than HTTP security

(5). HTTP information is transmitted in plaintext, and HTTPS information is encrypted for transmission

2. Public key Encryption 2.1. What is public key encryption?

Public Key encryption is also known as asymmetric key encryption, which uses two different keys: the encryption key and the secret key. The former public, also known as public key, referred to as the public key, the latter is confidential, also known as private key, referred to as private. The two keys are mathematically related, and the information obtained by encrypting a user's encryption key can only be decrypted with that user's decryption key. The RSA algorithm (by the inventor Rivest,shmir and Adleman initials) is a well-known public key encryption algorithm.

Another use of public-key cryptography is authentication: information that is encrypted with the private key, which can be decrypted with the public key, which the recipient would tell that the message really came from someone with a private key. The process of encrypting private keys is a digital signature.

Data encrypted with the public key can only be decrypted by the private key, whereas the data encrypted with the private key can only be decrypted by the public key, and it is this asymmetry that makes the public-key cipher system widely used.

2.2. Advantages

Compared with symmetric key encryption, the advantage is that no shared universal key is required, and the decrypted private key is not sent to any user. Even if the public key is intercepted on the internet, it cannot be decrypted if there is no private key that matches it, and the public key being intercepted is useless.

2.3. Process

Assume that two users, a, B, communicate with a public key of C, a private key of D, and a clear text of X.

Step 1. A the plaintext is encrypted with the public key to form ciphertext C (x), and then the ciphertext is transmitted;

Step 2. b receives ciphertext, decrypts the cipher with the private key D (c (x)), and obtains the plaintext to be communicated

2.4. Symmetric key encryption

Symmetric key encryption is also called private key encryption, that is, both the sending and receiving data must use the same key to encrypt and decrypt the plaintext.

3. Digital certificates and CA3.1. Confirm the authenticity of the host

Server with HTTPS (server) must request a digital certificate (or CA certificate) from the CA (certificateauthority) that is used to certify the server's purpose type. The client trusts this host only when the certificate is used for the corresponding server.

CA (Certificate authority), or "certification authority", is the authority responsible for issuing certificates, certifying certificates, managing issued certificates, and is at the core of PKI (public key Infrastructure, key Infrastructure). It develops policies and specific steps to verify, identify, and sign user certificates to ensure the identity of the certificate holder and the ownership of the public key.

The CA also has a certificate (public key included) and a private key . Public users on the Internet trust the CA by verifying the CA's signature, and anyone can get the CA's certificate (with the public key) to verify the certificate it has issued.

3.2. What is a digital certificate

Digital certificate ( CA certificate is a certified digital certificate ) is a tool for authenticating identities in Internet communications, issued by the Authority--CA Agency (Certificate authority). Its role is similar to driver's license and Citizen ID card. The CA acts as an impartial third party to ensure the validity of the certificate [6]. There are multiple CA institutions nationwide (as long as you have credibility you can also set up a CA agency).

A digital certificate contains a public key and information about the owner of the key. The certificate is also marked with an expiration date and signed by another key (CA private key) , which guarantees the authenticity of these attributes, and most importantly, the authenticity of the public key itself [14]. The simplest certificate contains a public key, a name, and a digital signature for the certificate authority (the public key is only part of the certificate ). At present, the format and verification methods of certificates generally follow the international standard.

The CA institution itself also has a certificate ( public key included ) and a private key.

If the user wants a digital certificate, he should first apply to the CA, the CA examines the applicant's identity, assigns him a public key, and binds the public key to the applicant's identity, signs it with his private key, and eventually generates a certificate for the applicant, and also sends a private key associated with the public key to the requester. The contents of the certificate include: CA information, CA signature, certificate owner information, certificate public key and certificate validity period, etc.

When someone needs to verify a certificate, they use the public key of the CA that issued the certificate to decrypt their signature information to verify that the certificate is trustworthy. The CA certificate also needs to be validated, verifying that the CA certificate is a recursive process, and the validation process terminates at the root certificate. The root certificate is a special certificate, and its issuer is itself, and downloading the root certificate indicates that the user trusts both the root certificate and the certificate it has issued.

3.3. Fundamentals of digital certificates

The digital certificate uses the public key encryption system , and uses a strong correlation key pair to add and decrypt. The certificate owner saves his or her private key, decrypts and signs it, and exposes the public key for sharing by a group of users for encrypting and validating the signature.

1, encryption: When sending data, the sender uses the receiver's public key to encrypt the data, the receiver decrypts with the private key, and restores the message. The algorithm guarantees that the public key encrypted data can only be decrypted by the corresponding private key .

2, digital signature: The certificate owner uses the private key to encrypt the information, because the private key is only for me, so that the other people can not forge the data, the data is digital signature . With digital signatures, you can confirm the following two points:

(1) The guarantee information is sent by the signer, the signer can not deny or difficult to deny;

(2) To ensure that the information has not been modified since it was issued, and that the documents issued are real documents.

The algorithm guarantees that only the public key can decrypt the private key encryption information.

3.4. How to generate a digital certificate

Slightly

4. SSL4.1. What is SSL

SSL is a security protocol that provides privacy and integrity between communication applications that use TCP/IP. Transport Layer Security (Transport layer SECURITY,TLS) upgrades SSL to become a successor to SSL.

4.2. Encryption Process

The SSL protocol uses both the public-key cryptography (asymmetric encryption) and the symmetric encryption technology.

Step 1: Use public key cryptography (usually RSA) to authenticate each other (sometimes the server does not need to authenticate the client ) and negotiate the symmetric encryption key used in STEP2 communication;

Step 2: Encrypt data on the server side and client communication with symmetric key cryptography (such as DES, or RC4).

The advantages of this are: Public key encryption is relatively complex, slow, can be used to complete security requirements of authentication, key negotiations and other transactions; Symmetric key encryption technology is relatively simple and fast, which can be used to encrypt the transmission content of large data volume.

4.3. Composition

The advantage of the SSL protocol is that it is independent of the application-layer protocol. High-level application layer protocols (such as Http, FTP, Telnet, and so on) can be transparently built on top of the SSL protocol. The SSL protocol is used to encrypt the data, negotiate the communication key and authenticate the server before the application layer protocol communication. After this, the data transmitted by the application layer protocol will be encrypted, thus guaranteeing the privacy of the communication.

The SSL protocol is located between the TCP/IP protocol and various application layer protocols, providing security support for data communication. the SSL protocol can be divided into two tiers: the Logging protocol (SSL record Protocol) and the Handshake Protocol (SSL handshake Protocol). The logging protocol is based on a reliable transport protocol (such as TCP) and provides support for high-level protocols, such as handshake protocols, for data encapsulation, compression, and decryption. The handshake protocol is based on the SSL record Protocol, which is used to authenticate the two parties, negotiate encryption algorithm, exchange encryption key, etc. before the actual data transfer begins. after the handshake protocol negotiates the encryption algorithm, the compression algorithm and the symmetric encryption key, etc., the application layer data transfer (such as the HTTP protocol data transfer) begins. The data transmission of the application layer is also working on the record Protocol, which is encrypted by the record layer and decrypted by the negotiated key to ensure the data security.

4.4. RSA algorithm

In 1977, the United States MIT Ron Rivest, Adi Shamirh and Lenadleman invented the RSA encryption algorithm. The algorithm is based on a very simple number theory fact: it is easy to multiply two large primes, but it is extremely difficult to factorization the product.

4.5. The authentication of the SSL protocol and the negotiation 4.5.1 of the symmetric encryption key. TSL Protocol Interaction Process

The process of identity authentication and key negotiation for TSL is outlined as follows (consider only the case of a new session, regardless of restarting the session):

STEP1: Client sends ClientHello message to server side

Message characteristics: The message is the first message sent when the client connects to the server side.

Message composition:

(1). The TLS protocol version used.

(2). random number; used to calculate the "master password" for symmetric encryption.

(3). Session ID, which is useful when re-connecting, can be empty.

(4). List of cryptographic algorithms, the list of cryptographic algorithms supported by the client, and follow the client's preference from going to the back row.

(5). A list of compression algorithms, a list of compression algorithms supported by the client, and follow the client's preference from going to the back row.

(6). Extended information.

Message function: Used for initiating session, exchanging random number, negotiating encryption algorithm, compressing algorithm and so on.

STEP2: Server-side validation ClientHello message, main authentication:

(1) Whether the message format is lawful;

(2) Can at least support the client to enumerate a cryptographic algorithm and a compression algorithm.

Verify that the message is dropped without passing the session, and verify that the next step is done.

Step3: The server sends a SERVERHELLO message to the client.

Message characteristics: The message is the first message returned to the client after the server receives ClientHello.

Message composition:

(1). The TLS protocol version used.

(2). random number; the "Master password" used to calculate symmetric encryption (this random number is the server sent to the client, which is different from the random number in the first step, the first one is sent to the service by the client)

(3). A cryptographic algorithm; the server selects an encryption algorithm from the list of cryptographic algorithms for the client.

(4). A compression algorithm; the server selects a compression algorithm from the client's compression algorithm list.

(5). session ID; A new unique session ID.

(6). extended information.

Message function: Used to exchange random number, determine encryption algorithm, compression algorithm and so on.

STEP4: The server sends a certificate message to the client.

Message characteristics: The message must be sent immediately after the Serverhello has been sent. If this is an anonymous negotiation, you do not need to send the message.

Message composition:

(1). certificate list; The certificate for the server must be the first of the certificate list, followed by the certificate that issued the server certificate, and so on, and the last certificate is the certificate signed by the root certificate. The root certificate is not in the list of certificates, it is given to the client by other means. (many times the browser is preinstalled)

Message function: Send server certificate, or certificate chain.

STEP5: The server sends a SERVERKEYEXCHANGE message to the client.

Message Features:

(1). The message must be sent immediately after certificate is sent (if it is an anonymous negotiation, the message is immediately after Serverhello).

(2). This message is only required if the certificate message does not provide enough information for the client to complete the "pre-master password" Exchange.

Message composition:

(1). Key exchange algorithm

Message function: The message is used to send a key exchange algorithm to the client. The client can use these algorithms and the server side to complete the "pre-master password" Exchange.

STEP6: The server sends a CERTIFICATEREQUEST message to the client.

Message Features:

(1). A non-anonymous server can use this message to require the client to send a certificate to verify its identity.

(2). If the message is sent, the message is sent immediately after Serverkeyexchange is sent (if the interaction does not send Serverkeyexchange, the message immediately follows the certificate message)

Message composition:

(1). certificate Type list; The client's certificate type must be one of the certificate type lists.

(2). List of signature and hash algorithms; Lists the signature algorithms and hashing algorithms supported by the server.

(3). CA Name list; The server only accepts certificates that are issued by the CA listed in the list, and other certificates cannot be verified.

Message function: The requesting client sends a certificate to verify its identity. (Only two-way authentication is required, that is, the server also needs to authenticate the client)

STEP7: The server sends a SERVERHELLODONE message to the client.

Message Features:

Message composition:

(1). No message content.

Message function: This message is used to tell the client that Serverhello and the attached message have been sent. the server waits for a client message after the message is sent.

STEP8: The client sends a CLIENTCERTIFICATE message to the server side.

Message Features:

(1). The message is sent only when the server Certificaterequest is received, that is, the server requires that the client be authenticated.

(2). If the message is sent, the message must be the first message sent to the server after the client receives the Serverhellodone message.

Message composition:

(1). List of certificates.

Message function: Sends a client certificate to the server for authentication. (Only two-way authentication is required, that is, the server also needs to authenticate the client)

STEP9: The client sends a CLIENTKEYEXCHANGE message to the server side.

Message Features:

(1). If there is a clientcertificate message, the message must be sent immediately thereafter, and if there is no clientcertificate message, the message is the first message sent to the server after the Serverhellodone message is received.

(2). The message uses the RSA algorithm or the Diffie-hellman parameter to negotiate the pre-master password.

(3). When using RAS encryption to negotiate a pre-master password, sir into a long random number, by the random number and the client's TSL version number constitute a struct, with the server certificate of the public key (obtained from the server certificate) to encrypt the structure, and the encrypted data to the server.

(4). Diffie-hellman parameter negotiation is more complicated and is not discussed at this stage.

Message composition: Varies by encryption algorithm.

Message function: Negotiate a pre-master password

STEP10: The client sends a CERTIFICATEVERIFY message to the server side.

Message Features:

(1). The message is sent only when the client certificate has the ability to sign (TENFY: There is a client certificate, and the certificate is both public and private), otherwise it is not sent (certificates with no fixed Diffie-hellman parameters have the ability to sign).

(2). The message must be sent immediately after the Clientkeyexchange has been sent.

(3). The message is encrypted with the private key information in the client certificate .

Message composition:

(1). Take all the messages before the message as parameters, and use the private key to sign it to obtain a copy of the data, which is the message body.

Message function: Verifies the client's identity through the signing method.

StepOne: The server decrypts the Clientkeyexchange message with the server private key to "pre-master password". The server and client compute the "master password" with the same algorithm. The master password calculation is based on the pre-master password, the random number in the ClientHello, and the random number in the Serverhello . After calculating the master password, each party sends a CHANGECIPHERSPEC message to each other:

Message Features:

(1). The message must be sent before the finished message is sent after all handshake messages have been sent.

(2). The message must be received before receiving the finished message after all handshake messages have been received.

Message composition:

(1). Confirm the message.

Message function: Confirm the use of the proposed compression algorithm, encryption algorithm, master password and so on to transmit subsequent data.

Step12: When either party receives the CHANGECIPHERSPEC message, it tells itself that the record layer is read state by reading wait state and uses a new way to pass the data. and send the finished message to the other end.

Message Features:

(1). The message is sent immediately after receiving the Changecipherspec.

(2). This message is the first time to use a negotiated compression algorithm, encryption algorithm, master password and so on to transmit data.

Message composition:

(1). Take most of the previous handshake messages as parameters, using the same algorithm to calculate a value.

Message function: The completion of the compression algorithm, encryption algorithm and other negotiations, began to transfer to the application layer data transmission.

Step13: Both sides verify the received message and verify that the application layer data transfer is started, otherwise disconnected.

TSL communication time is one-way authentication and two-way authentication. One -way authentication requires only the server-side certificate (the public key is a part of the certificate) and the private key, where the certificate is public, the private key is kept, and both the server and the client are required to provide both the certificate and the private key, the certificate is public and the private key is kept. These two are not bound to the certificate, the private key pair, the actual programming when they as two independent certificate, private key pair to handle.

The server side does not validate the client certificate when one-way authentication occurs. Therefore the server does not need to send the Certificaterequest message request client certificate, the client does not need to send the certificate related clientcertificate and certificateverify message.

4.5.2. Message validation in the TSL protocol

The message must be sent and received strictly as described above in the communication process. Once the receiving party receives the message, once it finds that: (1) The message is missing, (2) The message is in the wrong order, (3) the message format (such as encryption format) is wrong, (4) The message content is wrong, (5) Its fatal error, etc., the receiving party sends the Erroralert message to the sender via alert protocol immediately Tell the other person to terminate this session. If it is a tolerable error, no message will be sent to prevent the other party from actively disconnecting the session.

Several important verification instructions:

1. The client verifies the server's certificate message. The main verification content is:

(1). The server certificate usage date is valid.

(2). Whether the CA that issued the server certificate is reliable.

(3). The publisher's public key can unlock the publisher digital signature on the server certificate.

(4). Whether the name on the server certificate (such as the domain name) matches the actual name of the server, etc. (you can choose whether to verify this option in PHP).

(TENFY: As can be seen here, the Client Authentication service, only need to verify the validity of the corresponding server certificate, do not need to verify that the corresponding server has a private key consistent with the certificate)

2. The server verifies the client's certificateverify message. The main verification content is:

(1). The client's public key can be used to decrypt the message encrypted by the client private key.

(TENFY: When the server authenticates the client, it also needs to verify that it has the private key corresponding to the certificate)

3. The server verifies the client's clientcertificate message. The main verification content is:

(1). Whether the customer's certificate use date is valid.

(2). Whether the CA that provides the certificate to the customer is reliable.

(3). Whether the public key of the issuing CA correctly unlocks the digital signature of the issuing CA for the client certificate.

(4). Check that the client's certificate is in the certificate revocation list (CRL).

Attached: Common certificate format 1.1. PEM

OpenSSL uses the PEM (RFC 1421-1424) document format. The PEM full name is privacyenhanced Mail, which defines the standard for encrypting a ready to send message. Its basic flow is this:

1, the information is converted to ASCII code or other encoding method;

2, using the symmetric algorithm to encrypt the converted message information;

3, using BASE64 to encode the message after encryption;

4, using some header definitions to encapsulate information, these header information format as follows (not necessarily required, optional):

proc-type,4:encrypted

Dek-info:cipher-name, Ivec

Where the first header information marks whether the file is encrypted, the possible value of the header information includes encrypted (information is encrypted and signed), Mic-only (information is digitally signed but not encrypted), Mic-clear (information is digitally signed but not encrypted, and is not encoded , can be read in non-PEM format) and clear (information is not signed and encrypted and is not encoded, it seems to be the extension of OpenSSL itself, but it is not really implemented); The second head message marks the encryption algorithm and the Ivec parameters used, What Ivec actually provides here should be a randomly generated sequence of data that is different from the initialization variable (IV) to be used in the Block encryption algorithm.

5, in front of this information, add the following form header callout information:

-----beginprivacy-enhanced MESSAGE-----

After this information, add the following form to the end callout information:

-----endprivacy-enhanced MESSAGE-----

Above is the basic structure of the OpenSSL Pem file, it is important to note that OpenSSL does not implement all the standards of PEM, it is only the implementation of some of the options required in OpenSSL, detailed PEM format, please refer to rfc1421-1424.

The Public-keycryptography Standards (PKCS) is a set of public key cryptography standards developed by RSA Data Security Inc. and its partners, including certificate requests, certificate updates, certificate deprecation table publishing, extended certificate content, and digital signatures, A series of related protocols on the format of digital envelopes.

1.2. PFX

The PFX (Personal information Exchange) certificate file is a certificate that is generated with the PKCS (the Public-keycryptography standards) standard. PKCS is a set of public-key cryptography standards developed by RSA Data Security Inc. and its partners, including a series of related protocols for certificate requests, certificate updates, certificate deprecation table publishing, extended certificate content, and digital signature, digital envelope format, and more.

A PFX file typically contains a certificate and a corresponding private key, and at this stage the certificate uses the PKCS #12 standard [14]. This type of file is highly sensitive and when you export a key pair, Windows provides a password to encrypt the. pfx file, and when you import the key pair, you must provide this password again to import.

1.3. CER

Files with a. cer extension are ASN.1 in X.509v3 format and signed by a CA. These files contain a public key and additional information. These files are typically used to provide business partners so that they can encrypt data using public keys.

1.4. Java Key Store

Java Key Store (JKS) is a password-protected file that is given in the Java language to store keys and certificates. JKs file is like a warehouse, in order to prevent others random random, warehouse can be set up a lock, that is, JKs file password (storepass). Multiple keys can be stored in the repository, such as public, private, and key pairs (consisting of the paired public and private keys). Each key has a name, called Alias. The public key in the warehouse you can look away if you can access the warehouse, the private key is a password (keypass), only allow the permission of the person to view the take away. Therefore, reading the public key from the JKs file requires only knowing the password of the JKs file (warehouse), but it must also have the password for the private key when reading the private key [1].

Security https-Full details symmetric encryption, asymmetric encryption, digital signatures, digital certificates and HTTPS "under"