SSL (Secure Socket Layer)
HTTPS (Secure Hypertext Transfer Protocol) Secure Hypertext Transfer Protocol
HTTPS protocol details
HTTPS is developed with the goal of confidentiality. In short, it is a secure version of HTTP. Its security is based on the SSL protocol. For details about encryption, see SSL. Hypertext Transfer Protocol over Secure Socket Layer.
It is a URI scheme with syntaxes similar to http: system. It uses HTTP, but HTTPS has a default port different from HTTP and an encryption/authentication layer (between HTTP and TCP ). The Protocol was initially developed by Netscape, which provides authentication and encrypted communication methods and is now widely used for secure and sensitive communications on the Internet, such as transaction payment.
SSL is extremely difficult to intercept and provides reasonable protection for man-in-the-middle attacks. Strictly speaking, https is a combination of the two Protocols, namely, transport layer SS + application layer HTTP.
HTTPS uses TCP port 443 by default (HTTP uses TCP port 80 by default). You can also specify other TCP ports.
To make the Protocol operate normally, at least the server must have a PKI certificate, while the client is not necessarily.
Its encryption strength depends on the correct implementation of the software and the support of encryption algorithms on both sides of the server client.
Even if HTTPS is correctly implemented, there are still the following factors:
Impersonate a website
Phishing Attacks
Create a fake website similar to the original website and induce customers to access it. A common example is to copy a bank website.
Man-in-the-middle attack
The certificate is tampered with midway through the communication line to act as the intermediary between the client and the website, so that you can know all the communication content. Check the certificate to discover the existence of man-in-the-middle.
Impersonate customer
Because the certificate is expensive, only the website server usually has a certificate. The customer's identity is often not verified.
Before TLS 1.1, the SSL certificate only corresponds to an IP address, so that HTTPS cannot operate on a VM (only a domain name. Currently, TLS 1.1 fully supports domain name-based virtual hosts.
Differences between HTTPS and http:
For HTTPS protocol, you need to apply for a certificate from the ca. Generally, there are few free certificates and you need to pay the fee.
HTTP is Hypertext Transfer Protocol, information is transmitted in plaintext, and HTTPS is a secure SSL encrypted transmission protocol.
HTTP and HTTPS use completely different connection methods with different ports, the former is 80, and the latter is 443.
The HTTP connection is simple and stateless.
HTTPS is a network protocol built by the SSL + HTTP protocol that supports encrypted transmission and identity authentication, which is more secure than HTTP.
Problems solved by https:
1. questions about trusted hosts. an https server must apply for a certificate from the CA to prove the purpose of the server. the client trusts the host only when the certificate is used for the corresponding server. therefore, the key applications of all banking system websites are HTTPS. the customer trusts the host by trusting the certificate. in fact, this is very inefficient, but banks are more focused on security. this does not make any sense to us. Our server adopts certificates, no matter whether it is our own issue or issue from the public, the client is our own, so we certainly trust the server.
2. Data leaks and tampering during communication
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. This is the same as that in section 1.1.
B) All communications between the server and the client are encrypted.
I. Specifically, the client generates a symmetric key and exchanges the key through the server certificate. In the general sense, the handshake process.
Ii. All the added information is encrypted. Even if a third party intercepts the information, it makes no sense because it does not have a key. Of course, tampering is meaningless.
2. If you have a few requirements on the client, the client must also have a certificate.
A) The client certificate is similar to a ca-authenticated identity in addition to the user name and password. the individual certificate is generally not simulated by others, so that you can further confirm your identity.
B) at present, this is the practice of Professional edition of a few individual banks. The specific certificate may be using a USB flash disk as a backup carrier.
HTTPS must be cumbersome.
A) The original simple http protocol, a get and a response. Because HTTPS needs to restore the key and confirm the encryption algorithm, a single handshake requires 6/7 round trips.
I. In any application, too many round trips will definitely affect the performance.
B) The next step is the specific HTTP protocol. Each response or request requires the client and server to encrypt/decrypt the session content.
I. although the efficiency of symmetric encryption/decryption is relatively high, it still consumes too much CPU. Therefore, it has a dedicated SSL chip. if the CPU signal can be relatively low, it will definitely reduce the performance and thus cannot serve more requests.
Ii. Data size after encryption. Therefore, so many security authentication prompts will appear.
HTTPS protocol analysis
HTTPS (full name: Hypertext Transfer Protocol over Secure Socket Layer) is an HTTP channel targeted at security. It is simply a secure version of HTTP. That is, the SSL layer is added under HTTP. The Security Foundation of HTTPS is SSL, so the detailed content of encryption requires SSL. It is a URI Scheme (Abstract identifier system) with syntaxes similar to http: system. Secure HTTP data transmission. Https: the URL indicates that HTTP is used, but HTTPS has a default port different from HTTP and an encryption/authentication layer (between HTTP and TCP ). The system was initially developed by Netscape, which provides authentication and encrypted communication methods and is now widely used for secure and sensitive communications on the World Wide Web, such as transaction payment.
Brief Introduction:
It is developed by Netscape and built in its browser. It is used to compress and decompress data and return the results of network upload and return. HTTPS actually uses Netscape's Secure Socket Layer (SSL) as the child layer of the HTTP application layer. (HTTPS uses port 443 instead of using port 80 as HTTP to communicate with TCP/IP .) SSL uses 40-bit keywords as the RC4 stream encryption algorithm, which is suitable for business information encryption. HTTPS and SSL support X.509 digital authentication. If necessary, you can confirm who the sender is.
That is to say, it has two main functions: one is to establish an Information Security channel to ensure the security of data transmission; the other is to confirm the authenticity of the website.
Differences between HTTPS and HTTP
1. for HTTPS protocol, you need to apply for a certificate from the ca. Generally, there are few free certificates and you need to pay the fee. 2. HTTP is Hypertext Transfer Protocol, information is transmitted in plaintext, and HTTPS is a secure SSL encrypted transmission protocol. 3. HTTP and HTTPS use completely different connection methods, with different ports. The former is 80, and the latter is 443. 4. The HTTP connection is simple and stateless. the HTTPS protocol is a network protocol built by the SSL + HTTP protocol for encrypted transmission and identity authentication, which is safer than the HTTP protocol.
Protocol Structure
An HTTP packet consists of a request from the client to the server and a response from the server to the client. The Request Message format is as follows:
Request Line-Common Information header-Request Header-entity header-the request line of the message body starts with a method field, followed by the URL field and HTTP Protocol version field, and ends with CRLF. SP is a separator. In the final CRLF sequence, CF and LF are required. For details about common information headers, request headers and object headers, refer to relevant documents. The Response Message format is as follows: Status line-general information header-Response Header-entity header-the message body status code element consists of three digits, indicating whether the request is understood or satisfied. The Reason Analysis briefly describes the status code of the original text. The status code is used to support automatic operations, and the cause analysis is used for users. The client does not need to check or display the syntax. For details about the common information headers, the response headers and object headers, refer to relevant documents.
Problems solved by https
I. Questions about trusted hosts.
An https server must apply for a certificate from Ca (certificate authority) to prove the purpose of the server. The client trusts the host only when the certificate is used on the corresponding server. Therefore, the key applications of all banking system websites are HTTPS. The customer trusts the host by trusting the certificate. In fact, this is very inefficient, but banks are more focused on security. This does not make any sense to us. Our servers adopt certificates, whether published by ourselves or from the public, and their clients are themselves, so we certainly trust this server. Ii. Data leaks and tampering during communication
Ii. Data leaks and tampering during communication
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. This is the same as that in section 1.1.
B) All communications between the server and the client are encrypted.
I. Specifically, the client generates a symmetric key and exchanges the key through the server certificate, that is, the handshake process in the general sense.
Ii. All subsequent information exchanges will be encrypted. Even if a third party intercepts the service, it makes no sense because it does not have a key. Of course, tampering is meaningless.
2. If you have a few requirements on the client, the client must also have a certificate.
A) The client certificate is similar to a ca-authenticated identity in addition to the user name and password. Because the personal certificate is generally not simulated by others, so that you can further confirm your identity.
B) at present, this is the practice of Professional edition of a few individual banks. The specific certificate may be using a USB flash disk (that is, U shield) as a backup carrier.
Overview
Its security protection relies on the correct implementation of the browser and the support of server software and actual encryption algorithms.
A common misunderstanding is that "bank users Use https online: they can fully protect their bank card numbers from being stolen ." In fact, the encrypted connection with the server can protect the bank card number, only the connection between the user and the server itself. The server itself cannot be absolutely secure, which has even been exploited by attackers. A common example is a phishing attack that imitates the domain name of a bank. A few rare attacks occur when the website transmits customer data. Attackers attempt to eavesdrop on the transmitted data.
Commercial websites are expected to quickly introduce new special processing programs to the financial gateway as soon as possible, and only retain the transfer code (transaction number ). However, they often store bank card numbers in the same database. In rare cases, databases and servers may be attacked and damaged by unauthorized users. Before TLS 1.1
This section is only applicable to conditions before TLS 1.1. Because SSL is located at the next layer of HTTP and does not understand higher-level protocols, generally, the SSL server can only issue certificates to specific IP/port combinations. This means that it often cannot be combined with HTTP to form HTTPS on a virtual host (based on a domain name.
This point has been updated by the upcoming TLS 1.1-a fully supported domain name-based virtual host.
SSL Introduction
SSL (Secure Socket Layer)
Developed for Netscape to ensure the security of data transmission over the Internet, encryption ensures that data is not intercepted or eavesdropped during network transmission. At present, the general specification is 40 bits, while the United States has released a 128 bits higher security standard, but the exit is restricted. Only the I. e. or Netscape Browser later than version 3.0 supports SSL.
The current version is 3.0. It has been widely used for identity authentication and encrypted data transmission between Web browsers and servers.
The SSL protocol is located between the TCP/IP protocol and various application layer protocols to provide security support for data communication. The SSL protocol can be divided into two layers: SSL record protocol (SSL record Protocol): it is built on a reliable transmission protocol (such as TCP, provides data encapsulation, compression, encryption, and other basic functions for high-level protocols. SSL handshake protocol: It is built on the SSL record protocol and used before the actual data transmission starts, both parties perform identity authentication, negotiate encryption algorithms, and exchange encryption keys.
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 data theft;
3) maintain data integrity and ensure that data is not changed during transmission.
SSL protocol workflow:
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 to generate a new master key based on the customer's information, if necessary, the server will contain the information required to generate the CMK when responding to the customer's "hello" information. 3) the customer generates a CMK Based on the server response information received, the CMK is encrypted with the public key of the server and then transmitted to the server. 4) The server restores the CMK and returns the CMK authentication information to the customer to authenticate the server. User Authentication phase:
Before that, the server has passed the customer authentication, which completes the customer authentication. The authenticated server sends a question to the customer, and the customer returns the question signed by (number) and the Public Key to provide the server with authentication.
From the services provided by the SSL protocol and their workflow, we can see that the foundation of the SSL protocol is the merchant's commitment to the confidentiality of consumer information, which is conducive to the merchant and is not conducive to the consumer. In the early stage of e-commerce, most enterprises that operate e-commerce are large companies with high reputation, so this problem has not been fully exposed. However, with the development of e-commerce, various small and medium enterprises are also involved, which leads to the problem of single authentication in the electronic payment process becoming more and more prominent. Although SSL3.0 uses digital signatures and digital certificates to verify the identity of both the browser and the web server, the SSL protocol still has some problems, such, the SSL protocol can only provide mutual authentication between the client and the server in the transaction. In electronic transactions involving multiple parties, the secure transmission and trust relationship between the parties cannot be coordinated. In this case, visa and
MasterCard's two major credit card organizations have developed the SET protocol, which provides global standards for online credit card payment.
Handshake process of the SSL protocol
To better understand and understand the SSL protocol, we will introduce the handshake protocol of the SSL protocol. SSL uses both public key encryption and symmetric encryption. Although symmetric encryption is faster than public key encryption, public key encryption provides better identity authentication. The SSL handshake protocol is very effective for customers and servers to complete identity authentication. The main process is as follows:
① The client browser sends the version number of the client SSL protocol, the type of encryption algorithm, the random number generated, and various information required for communication between other servers and clients to the server.
② The server sends the version number, type of encryption algorithm, random number, and other related information of the SSL protocol to the client, and the server also sends its own certificate to the client.
③ The client uses the information sent from the server to verify the server's legitimacy. The server's legitimacy includes: whether the certificate expires, and whether the CA that issues the server certificate is reliable, whether the public key of the issuer certificate can properly unbind the "digital signature of the issuer" of the server certificate, and whether the domain name on the server certificate matches the actual Domain Name of the server. If the legality verification fails, the communication will be disconnected. If the legality verification passes, the fourth step will continue.
④ The user end generates a random "symmetric password" for subsequent communication, and then encrypts it with the server's public key (the server's public key is obtained from the server certificate in step 2, then, pass the encrypted "pre-master password" to the server.
⑤ If the server requires the customer's identity authentication (optional during the handshake), the user can create a random number and then sign the data, send the random number containing the signature together with the customer's own certificate and the encrypted "pre-master password" to the server.
⑥ If the server requires the customer's identity authentication, the server must check the validity of the customer's certificate and signature random number. The specific validity verification process includes: whether the customer's certificate is valid on the date of use, whether the CA that provides the certificate is reliable, whether the public key of the CA can properly unbind the digital signature of the CA that issues the certificate, and check whether the certificate is in the Certificate Revocation List (CRL. If the verification fails, the communication will be interrupted immediately. If the verification passes, the server will unbind the encrypted "pre-master password" with its own private key ", then, execute a series of steps to generate the master communication password (the client will generate the same master communication password in the same way ).
7. The server and client use the same master password as the "Call password". A symmetric key is used for encryption and decryption of secure data communication over the SSL protocol. At the same time, data communication integrity must be completed during SSL communication to prevent any changes in data communication.
The producer client sends a message to the server, indicating that the master password in Step 7 will be used for subsequent data communication as a symmetric key, and notifying the Server client that the handshake process is complete.
The slave server sends a message to the client, indicating that the master password in Step 7 will be used for subsequent data communication as a symmetric key, and notifying the client server end of the handshake process.
The handshake part of the SSL protocol ends, and the data communication of the SSL Secure Channel begins. The customer and the server start to use the same symmetric key for data communication, and the communication integrity is verified.