HTTPS SSL Protocol detailed

HTTPS protocol detailed SSL (Secure Socket Layer)

HTTPS (Secure hypertext Transfer Protocol) Secure Hypertext Transfer Protocol

HTTPS protocol detailed
HTTPS is developed for the purpose of secrecy and is simply a secure version of HTTP. Its security base is the SSL protocol, so the details of the encryption look at SSL. Full name hypertext Transfer Protocol over Secure Socket Layer.

It is a URI scheme with syntax similar to http: System. It uses HTTP, but HTTPS has a different default port than HTTP and an encryption/authentication layer (between HTTP and TCP). Originally developed by Netscape, this protocol provides an authentication and encryption method of communication, which is now widely used for security-sensitive communications on the Internet, such as transaction payments.

SSL is extremely difficult to eavesdrop and provides reasonable protection against man-in-the-middle attacks. Strictly Academic statement HTTPS is a combination of two protocols, the Transport Layer ss+ the application layer http.
HTTPS uses TCP port 443 by default (HTTP is TCP port 80 by default), or you can specify a different TCP port.
For the protocol to function properly, at least the server must have a PKI certificate, while the client is not necessarily.
Its encryption strength relies on the correct implementation of the software, as well as the support of both the server client encryption algorithm.

Even if HTTPS is implemented correctly, the following human factors are still available:
Impersonate a website
Phishing attack
Creating fake URLs similar to the original site and inducing customer visits, common examples are imitation bank websites.

Middleman attack
Tamper with the certificate in the middle of the communication line, thus acting as the intermediary between the client and the website, so as to know all the communication content. It is only possible to check the certificate to find the middleman.

Impersonate a customer
Because certificates are expensive, only Web servers typically have certificates. Often the customer's identity is not verified.
SSL certificates can only correspond to IP before TLS 1.1, so that HTTPS cannot function properly on the virtual host (domain name only). The current TLS 1.1 already fully supports domain-based virtual hosts.

The difference between HTTPS and http:
The HTTPS protocol requires a certificate to be applied to the CA, and the general free certificate is very small and requires a fee.
HTTP is a Hypertext Transfer Protocol, the information is plaintext transmission, HTTPS is a secure SSL encryption transport protocol
HTTP and HTTPS use a completely different connection method with the same port, the former is 80, the latter is 443.
The HTTP connection is simple and stateless.
HTTPS protocol is a network protocol built by Ssl+http protocol which can encrypt transmission and authentication, which is more secure than HTTP protocol.

HTTPS resolves the issue:
1. The problem of trusting the host. Server with HTTPS must request a certificate from the CA that is used to certify the server's purpose type. The client trusts the secondary host only when the certificate is used for the corresponding server. So at present, all the banking system website, the key part of the application is HTTPS. The client trusts the host by trusting the certificate. In fact, this is inefficient, but banks are more focused on security. This does not make any sense to us, our server, the use of certificates regardless of their own issue or from the public place issue, the client is one of our own, so we will certainly trust the server.

2. Disclosure and tampering of data in the course of communication
1. In general, HTTPS means that the server has a certificate.
A) The main purpose is to ensure that server is the server he claims to be. This is the same as the 1th.
b) All communication between the server and the client is encrypted.
I. Specifically, the client generates a symmetric key that is exchanged through the server's certificate. The handshake process in the general sense.
II. All information exchanged is encrypted. A third party, even if intercepted, does not make any sense. Because he doesn't have a key. Of course, there's no point in tampering.

2. A small amount of client-side requirements, the client will also be required to have a certificate.
A) Here the client certificate, in fact, similar to the personal information, in addition to the user name/password, there is a CA authenticated identity. Should be a personal certificate in general, others cannot emulate, all of which can further confirm their identity.
b) Currently a small number of personal banking Professional Edition is this practice, the specific certificate may be to take a USB flash drive as a backup carrier.

HTTPS must be cumbersome.
A) originally a simple HTTP protocol, a get a response. Because HTTPS is required to also encrypt the key and confirm the encryption algorithm. A single handshake requires 6/7 round trips.
I. In any application, excessive round trip will definitely affect performance.
b) Then the specific HTTP protocol, each response or request, requires the client and the server to encrypt/decrypt the contents of the session.
I. Although symmetric encryption/decryption efficiency is high, but still consumes too much CPU, for this there is a dedicated SSL chip. If the CPU signal is low, it will certainly degrade performance, thus not serve more requests.
II. The impact of the amount of data after encryption. So, there are so many security certification tips

HTTPS protocol Analysis
HTTPS (full name: Hypertext Transfer Protocol over secure Socket Layer) is a security-targeted HTTP channel and is simply a secure version of HTTP. That is, the SSL layer is added under HTTP, the security base of HTTPS is SSL, so the detailed content of encryption needs SSL. It is a URI scheme (abstract identifier system) with syntax similar to http: System. For secure HTTP data transfer. Https:url indicates that it uses HTTP, but HTTPS has a different default port than HTTP and an encryption/authentication layer (between HTTP and TCP). The initial development of the system, conducted by Netscape, provides an authentication and encryption method of communication, which is now widely used in security-sensitive communications on the World Wide Web, such as transaction payments.

Brief introduction:
It is developed by Netscape and built into its browser to compress and decompress data and return the results that are sent back on the network. HTTPS actually applies the Netscape Secure Sockets Layer (SSL) as a sub-layer of the HTTP application layer. (HTTPS uses port 443 instead of using port 80来 and TCP/IP to communicate like HTTP.) SSL uses 40-bit keywords as the RC4 stream encryption algorithm, which is appropriate for the encryption of business information. HTTPS and SSL support use of the digital authentication of the number, and if necessary, the user can confirm who the sender is.

In other words, its main function can be divided into two kinds: one is to establish an information security channel to ensure the security of data transmission, and the other is to confirm the authenticity of the website.

The difference between HTTPS and HTTP
First, the HTTPS protocol requires a certificate to the CA, the general free certificate is very small and requires a fee. 　　Second, HTTP is a Hypertext Transfer Protocol, the information is plaintext transmission, HTTPS is a secure SSL encryption Transfer protocol. 　　Third, HTTP and HTTPS use a completely different way of connection, with the same port, the former is 80, the latter is 443. Four, HTTP connection is very simple, is stateless; The HTTPS protocol is a network protocol built by the SSL+HTTP protocol to encrypt the transmission and authentication, which is more secure than the HTTP protocol.

Protocol structure
HTTP messages consist of requests from the client to the server and responses from the server to the client. The request message format is as follows:
Request line-General Information header-Request header-Entity header-the message body request line starts with the Method field, followed by the URL field and the HTTP Protocol version field, ending with CRLF. SP is a delimiter. In addition to the last CRLF sequence CF and LF are required, others can be not. 　　For general information headers, the specific contents of the request header and the entity header can be referenced in the relevant files. The response message format is as follows: status line-General information header-Response Head-Entity header-The message body status code element consists of 3 digits that indicate whether the request is understood or is satisfied. The cause analysis is a brief description of the status code of the original text, which is used to support automatic operation, and the reason analysis is used by the user. The client does not need to check or display the syntax. For the general information header, the response header and entity header aspects of the specific content can refer to the relevant files.

Issues that are resolved by HTTPS
One, the problem of trusting the host.
The server using HTTPS must request a certificate from the CA (Certificate authority) to prove the server's purpose type. The client trusts this host only when the certificate is used for the corresponding server. So at present, all the banking system website, the key part of the application is HTTPS. The client trusts the host by trusting the certificate. In fact, this is inefficient, but banks are more focused on security. This does not make any sense to us, our server, the use of the certificate whether it is published by itself or from the public, its client is one of our own, so we will certainly trust the server. Second, the communication process of data disclosure and tampering

Second, the communication process of data disclosure and tampering
1. In general, HTTPS means that the server has a certificate.
A) The main purpose is to ensure that the server is the server he claims, which is the same as the 1th.
b) All communication between the server and the client is encrypted.
I. Specifically, it is the client that generates a symmetric key, exchanging the key through the server's certificate, that is, the handshake process in the general sense.
II. All the information that follows is encrypted. Even if a third party intercepts, it doesn't make any sense, because he doesn't have a key, and of course it doesn't make sense to tamper with it.

2. A small amount of client-side requirements, the client will also be required to have a certificate.
A) Here the client certificate, in fact, similar to the personal information, in addition to the user name/password, there is a CA authenticated identity. Because personal certificates are generally not emulated by others, all this can be a deeper confirmation of their identity.
b) Currently a small number of personal banking Professional Edition is this practice, the specific certificate may be to take a U-Shield as a backup carrier.


Overview
Its security relies on the correct implementation of the browser and the support of the server software and the actual encryption algorithm.
A common misconception is that "bank users use HTTPS online: they can fully and thoroughly protect their bank card numbers from theft." "In fact, the part of the encrypted connection to the server that protects the bank card number is only the user-to-server connection and the server itself. It is not absolutely guaranteed that the server itself is secure, and this has even been exploited by attackers, a common example of phishing attacks that mimic bank domain names. A few rare attacks occur when a website transmits customer data, and an attacker attempts to eavesdrop on the data in transit.

Commercial websites are expected to quickly introduce new special handlers to the financial gateway as soon as possible, preserving only the transmission code (transaction number). But they often store bank card numbers in the same database. Few of those databases and servers can be attacked and compromised by unauthorized users. Before TLS 1.1

This section is only for situations prior to TLS 1.1. Because SSL is at the next level of HTTP and does not understand higher-level protocols, SSL servers are typically only allowed to be certified to specific ip/port combinations. This means that it is often not possible to combine HTTPS with HTTP normally on a virtual host (domain-based).

This has been updated by the upcoming TLS 1.1-type full support for domain-based virtual hosts.

SSL Introduction
SSL (Secure Socket Layer)
Developed for Netscape to secure data transmission over the Internet, the use of encryption (encryption) technology ensures that data is not intercepted and tapped during transmission over the network. At present, the general General specification is the safety standard of the double bit, but the United States has introduced the higher safety standard of the bit, but restricted the exit. As long as the 3.0 version above the i.e. or Netscape browser can support SSL.

The current version is 3.0. It has been widely used for authentication and encrypted data transfer between Web browsers and servers.

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: SSL record Protocol (SSL recorder Protocol): It is based on a reliable transport protocol (such as TCP) to provide high-level protocol data encapsulation, compression, encryption and other basic functions of support. SSL Handshake Protocol (SSL handshake Protocol): It is based on the SSL logging Protocol, which is used to authenticate, negotiate cryptographic algorithms, exchange encryption keys, etc. before the actual data transfer begins.

What are the main services provided by the SSL protocol?
1) Authenticate users and servers to ensure that data is sent to the correct client and server;
2) Encrypt data to prevent the data from being stolen in the middle;
3) Maintain the integrity of the data and ensure that the data is not changed during transmission.

The workflow of the SSL protocol:
Server Authentication phase: 1) The client sends a start message "Hello" to the server to start a new session connection; 2) The server determines whether a new master key needs to be generated based on the customer's information and, if necessary, the server will contain the information needed to generate the master key when responding to the customer's "Hello" information ; 3) The customer generates a master key based on the received server response information, encrypts it with the server's public key and transmits it to the server; 4) The server recovers the master key and returns it to the customer with a master key authentication information to enable the client to authenticate the server. User Authentication phase:

Prior to this, the server has passed the customer certification, this phase is mainly to complete the customer certification. The certified server sends a question to the customer, and the customer returns a (digital) signature question and its public key, thereby providing authentication to the server.

From the service provided by the SSL protocol and its workflow, it can be seen that the SSL protocol runs on the basis of the merchant's commitment to the confidentiality of consumer information, which is beneficial to the merchant and not the consumer. In the initial stage of e-commerce, because the operation of e-commerce enterprises are mostly reputable large companies, so this problem has not been fully exposed. However, with the development of e-commerce, small and medium-sized companies are also involved, so that in the electronic payment process of the single certification problem is more and more prominent. Although the authentication of both the browser and the Web server can be achieved through digital signature and digital certificate in SSL3.0, there are still some problems with the SSL protocol, for example, it can only provide the mutual authentication between the client and the server in the transaction, and the SSL protocol does not coordinate the secure transmission and trust relationship between the parties in the electronic transactions involving multi-party. In this case, the two major credit card organizations, Visa and MasterCard, set up a set agreement that provides a global standard for online credit card payments.

Handshake process for SSL protocol
To facilitate a better understanding and understanding of the SSL protocol, this article focuses on the SSL protocol Handshake protocol. SSL protocol uses both public-key cryptography and symmetric encryption technology, although symmetric encryption technology is faster than public-key cryptography, but public key cryptography provides better authentication technology. The SSL handshake protocol is very effective in enabling mutual authentication between the client and the server, and the main process is as follows:

The browser of the ① client transmits the version number of the client SSL protocol to the server, the type of cryptographic algorithm, the random number generated, and the various information needed to communicate between the server and the client.

The ② server transmits the version number of the SSL protocol to the client, the type of encryption algorithm, the random number, and other related information, and the server also transmits its own certificate to the client.

③ customers use the information sent by the server to verify the legitimacy of the server, the legitimacy of the server includes: whether the certificate expires, the issuing server certificate of the CA is reliable, the publisher certificate's public key can correctly unlock the server certificate "publisher's digital signature", the server certificate on the domain name and the server's actual domain name match. If the legitimacy verification is not passed, the communication will be disconnected, and if the legitimacy validation passes, the fourth step will continue.

The ④ client randomly generates a "symmetric password" for subsequent communication, encrypts it with the server's public key (obtained from the server's certificate in step ②), and then passes the encrypted "pre-master password" to the server.

⑤ If the server requires a customer's authentication (optional during the handshake), the user can create a random number and then sign the data to the server with the random number of signatures, along with the client's own certificate and the encrypted "pre-master password".

⑥ If the server requires customer authentication, the server must verify the legitimacy of the client certificate and the signature random number, the specific legality verification process includes: whether the customer's certificate use date is valid, to provide a certificate to the client CA is reliable, the issuing CA's public key can correctly unlock the client certificate of the issuing CA's digital signature, Check that the client's certificate is in the certificate revocation list (CRL). If the test is not passed, the communication is interrupted immediately; If authenticated, the server will use its own private key to unlock the encrypted "master password" and then perform a series of steps to generate the primary communication password (the client will also generate the same master communication password in the same way).

⑦ server and client use the same master password as the "Call password", a symmetric key for the SSL protocol of Secure data communication encryption and decryption communication. At the same time in the process of SSL communication to complete the integrity of data communication, to prevent any changes in data communication.

The ⑧ client sends a message to the server that indicates that subsequent data traffic will use the master password in the ⑦ as the symmetric key, and notifies the server client that the handshake process is complete.

The ⑨ server sends a message to the client indicating that the subsequent data traffic will use the master password in the ⑦ as the symmetric key, and notifies the client that the server side of the handshake process is complete.

⑩ssl The handshake part ends, the SSL secure channel data communication begins, the client and the server begin to use the same symmetric key for data communication, while the integrity of the communication test.

SSL Introduction:

Secure SocketsLayer,SSLProtocol is a protocol for securely exchanging information between a Web browser and a Web server, providing two basic security services: Authentication and confidentiality.

SSL was developed by Netscape in 1994 and later became the world's most famous web security mechanism, with all major browsers supporting SSL protocol

There are currently three versions:2,3,3.1, the most commonly used is the 3 version, is released in 1995 year.

Three features of the SSL protocol

① Confidentiality: After the session key is defined in the handshake protocol, all messages are encrypted.

② identification: Optional client authentication, and mandatory server-side authentication.

③ Integrity : Messages that are delivered include message integrity checks (using MAC).

Location of SSL

SSL is between the application layer and the TCP layer. The application layer data is no longer passed directly to the transport layer, but is passed to the SSL layer, whichencrypts the data received from the application layer and adds its own SSL header.

How SSL Works

Handshake Protocol (Handshake Protocol)

Recording Protocol (recordprotocol)

Alarm Protocol (Alertprotocol)

1. Handshake protocol

The handshake protocol is the first sub-protocol used by both the client and the server to communicate with SSL connections, which includes a series of messages between the client and the server. The most complex protocol in SSL is the handshake protocol. This protocol allows the server and client to authenticate each other, negotiate encryption and Mac algorithms, and a secret key to protect the data sent in the SSL record. The handshake protocol is used before the application's data transfer.

Each handshake protocol consists of the following 3 fields
(1) Type: represents one of 10 message types
(2) Length: Indicates the length of the message bytes
(3) Content: message-related parameters

4 Stages of a handshake protocol

1.1 Building security capabilities

The first phase of the SSL handshake initiates a logical connection that establishes the security capability of the connection. First the client sends a client Hello message to the server and waits for the server to respond, then the server returns the server Hello message to the client and confirms the information in the client Hello message.
The Client hello message includes information such as Version,random,session Id,cipher Suite,compression method.

ClientHello the customer to send Cilenthello information, including the following content:

(1) The maximum number of SSL versions a client can support

(2) A random number of 32 bytes used to generate the master secret. (What is the main secret?)

(3) A session ID that determines the session.

(4) A list of cipher suites that a client can support.

Cipher Suite format: Each suite starts with "SSL", followed by a key exchange algorithm. Use the word "with" to separate the key exchange algorithm, encryption algorithm, hashing algorithm, for example: Ssl_dhe_rsa_with_des_cbc_sha, the Dhe_rsa (with the RSA digital signature of the temporary Diffie-hellman) defined as the key exchange algorithm ; DES_CBC is defined as a cryptographic algorithm, and SHA is defined as a hashing algorithm.

(5) A list of compression algorithms that a client can support.

Serverhello Server uses Serverhello information to answer customers, including the following content

(1) An SSL version number. The highest version number supported by the client and the lower of the highest version number supported by the server.

(2) A random number of 32 bytes used to generate the master secret. (Client one, server-side one)

(3) Session ID

(4) A cipher suite selected from the client's cipher suite list

(5) Compression method selected from the list of compression methods of the client

After this phase, the client server knows the following:

(1) SSL version

(2) Key exchange, information verification and encryption algorithm

(3) Compression method

(4) About two random numbers generated by the key.

1.2 Server authentication and key exchange

The server initiates the SSL handshake phase 2nd, which is the only sender of all messages at this stage, and the client is the only recipient of all messages. This phase is divided into 4 steps:
(a) Certificate: The server sends the digital certificate and the entire chain to the root CA to the client, enabling the client to authenticate the server with the server's public key in the server certificate.
(b) Server key exchange (optional): This depends on the key exchange algorithm
(c) Certificate request: The server may require the customer to authenticate itself.
(d) Server handshake completion: End of second phase, signal starting at phase three

Here we focus on the authentication and key exchange of the server. The preceding (a) certificate and (b) Server key exchange in this phase are based on the key exchange method. There are 6 types of key exchange algorithms in SSL: Invalid (no key exchange), RSA, anonymous Diffie-hellman, temporary diffie-hellman, fixed Diffie-hellman, Fortezza.

In Phase 1, the process client negotiates with the server to determine which key exchange algorithm to make.

If the RSA Exchange key is determined during negotiation, the process is as follows:

In this method, the server sends the RSA encryption/decryption public key certificate in its first message. However, because the master secret is generated and sent by the client at the next stage, the second message is empty. Note that the public key certificate is validated from the server to the client. When the server receives a prestaged master secret, it uses the private key to decrypt it. Having a private key on the server side is an evidence that it is a required entity in the public key certificate it sends in the first message.

Several other key exchange algorithms are not introduced here. You can refer to Behrouz A.forouzan, "Cryptography and Cyber security".

1.3 Client Authentication and key exchange:

The client initiates the SSL handshake phase 3rd, which is the only sender of all messages at this stage, and the server is the only recipient of all messages. This phase is divided into 3 steps: (a) certificate (optional): In order to prove itself to the server, the customer sends a certificate information, which is optional, and can be configured in IIS to enforce client certificate authentication. (b) Client key exchange (Pre-master-secret): Here the client sends the master key to the server, noting that it is encrypted using the server's public key. (c) certificate validation (optional), signing of the pre-secret and random number to prove that the public key of the certificate has (a). The following also focuses on the RSA method of client authentication and key exchange.

In this case, there is no certificate information unless the server explicitly requests it in phase II. The client key exchange method includes the preliminary master key that is received by the RSA public key in Phase II. After Phase III, the customer has to have the server to authenticate, and the client and the server are aware of the prestaged master key.

1.4 Complete

The client initiates the 4th phase of the SSL handshake and ends the server. The stage is divided into 4 steps, the first 2 messages from the client, and the last 2 messages from the server.

1.5 Key generation Process

So the handshake protocol is complete, and below is what the master key is, and how it is generated. To ensure the integrity and confidentiality of information, SSL requires six encryption secrets: Four keys and two IV. For the credibility of the information, the client needs a key (HMAC), in order to encrypt to have a key, in order to block encryption to a IV, the service is the same. SSL requires a one-way key that differs from those in other directions. If there is an attack in one direction, this attack is not affected in the other direction. The build process is as follows:

2. Record Agreement

The logging protocol is used after the client and server handshake are successful, that is, after the client and server identify the other party and determine the algorithm used for secure information exchange, enter the SSL logging protocol, Logging protocol provides two services to SSL connections: (1) Confidentiality: implementation of the secret key defined by the Handshake Protocol (2) Integrity: The handshake protocol defines the process by which the MAC is used to guarantee the message Integrity Logging protocol:

3. Alarm protocol

When the client and server find an error, an alert message is sent to the other party. If it is a fatal error, the algorithm immediately shuts down the SSL connection, and the parties will first delete the associated session number, secret, and key. Each alert message has a total of 2 bytes, the 1th byte represents the error type, and if it is an alert, the value is 1, if it is a fatal error, the value is 2, and the 2nd byte is the actual error type. Summing up SSL, using the handshake protocol to negotiate encryption and MAC algorithm and secret key, using the handshake protocol to encrypt and sign the data exchanged, using the alert protocol to define the data transmission process, the problem is how to solve. The whole process is more complicated, if everyone has not understand and I do not describe the place, you are welcome to correct it!

HTTPS SSL protocol detailed (GO)