When our server was hijacked by a third party, the access security could not be guaranteed because the public key obtained by the client had been replaced by its public key by the third party. This installment will cover the basics of SSL or TSL, starting with CA authentication.

SSL 1.0, 2.0, and 3.0 Netscape developed the original SSL protocol, and Taher Elgamal, chief scientist of Netscape Communications, was called the "father of SSL" from 1995 to 1998. SSLVersion 1.0 was never released publicly because of serious security vulnerabilities in the protocol. Version 2.0, released in February 1995, contained so many security vulnerabilities that version 3.0 had to be designed. SSL version 3.0 was released in 1996 and represented a complete redesign of the protocol developed by Paul Kocher. In collaboration with Netscape engineers Phil Karlton and Alan Freier, and Consensus Development's Christopher Allen and Tim Dierks for reference implementations. Newer VERSIONS of SSL/TLS are based on SSL 3.0. The IETF published the SSL 3.0 draft as a historical document in RFC 6101 in 1996. TLS 1.0 was originally defined in RFC 2246 in January 1999 as an upgrade to SSL 3.0, written by Consensus developers Christopher Allen and Tim Dierks. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not significant, but they are significant enough to prevent interoperability between TLS 1.0 and SSL 3.0." TLS 1.0 does include TLS implementations that degrade connections to SSL 3.0, thereby weakening security. In October 2018, Apple, Google, Microsoft, and Mozilla jointly announced that they would be abandoning TLS 1.0 and 1.1, after the PCI Council recommended that organizations migrate from TLS 1.0 to TLS 1.1 or later by June 30, 2018Copy the code

From wikipedia, https://en.wikipedia.org/wiki/Transport_Layer_Security

So what is SSL? You know the four-tier model of TCP/IP? Application layer (HTTP,TELNET), transport layer (TCP), network layer (IP), and network interface layer (ARP). SSL exists as the security layer between the traditional application layer and transport layer.

In fact, after all the stuff we talked about last time, it is essentially about one thing: ensuring that the distribution of keys is secure enough to protect against man-in-the-middle attacks. So in TSL we added an authoritative third party CA.

CA certification

As we mentioned earlier, asymmetric encryption can be hijacked when our server communicates with clients, since both public and private keys can be issued by the owner. Therefore, people later introduced the concept of CA (Certificate Authority), which is a Certificate Authority as its name implies. It exists as a trusted third party (sort of like the public security Bureau) in the communication between the server and the client. The server must provide its public key to the CA. The CA uses its private key to encrypt the public key of the server to issue a CA certificate to the server.

A certificate contains the following information: the public key of the applicant, the organization information and personal information of the applicant, the information about the issuing authority (CA), the validity time, and the serial number of the certificate, and a signature.

Thus, the client and server have the following interactions when communicating:

  1. Client: tells the server its symmetric encryption mode and key
  2. Server: Provides CA certificate to client (original public key provision process)
  3. Client: After receiving the CA certificate, the client uses the root certificate in its own root certificate library (mainstream browsers have a built-in root certificate library) to verify the CA certificate. During authentication, the client uses the root certificate to decrypt the CA certificate and compares the summary information. If the summary information is consistent, the certificate is valid. Then, the client continues to verify the validity of the domain name and validity period of the certificate. If the authentication succeeds, the CA certificate is provided by a legitimate server.
  4. Client: After the authentication succeeds, the client generates a random set of keys, encrypts them using the public key in the certificate, and provides them to the server.
  5. The server uses its private key to decrypt the packet and obtain the random key. A handshake message encrypted with the private key is returned to the client
  6. Client: Decrypt and compare handshake information. If yes, data transfer begins. In subsequent communication, random keys are used for symmetric encryption to improve communication efficiency.

Certificate type

  • CA Organization certificate (root certificate, intermediate certificate)
  • Service certificate

Certificates are divided into two types: CA organization certificates and service certificates. The CA certificate represents the certificate held by the issuing authority for issuance, while the service certificate is the certificate for communication between our actual service and the client.

And the CA certificate because the top CA institutions and only a limited number of organizations cannot accept all certificate applications. Therefore, they will authorize some other third-party institutions to exist as intermediary CA institutions. The intermediate CA can also act as the top CA to re-authorize the subordinate organizations. So here comes the concept of a certificate chain.

The certificate chain

Take the browser as the client as an example

  1. When the browser receives a certificate from the server, it can first trace its parent certificate from the certificate until it finds the root certificate.
  2. After the root certificate is found, the public key of the root certificate is used to decrypt the signature of the lower certificate. When the decryption succeeds, the summary information is compared. When the validity verification of the summary information passes, the public key of this level can be used to verify the certificate of the lower level. And so on, when the final service certificate is verified to be valid. Indicates that the validity check of the entire CA certificate succeeds during the second session.

That’s all for this issue, I’m IHAP Yanan Xiao Meng Xin, more exciting content, all in IHAP technology black hole.