Chapter 7. HTTPS for Web Security
HTTP mainly has these deficiencies, examples are as follows.
The communication uses plain text (not encrypted), and the content may be eavesdropped.
The identity of the communicating party is not verified, so it may be masqueraded.
The integrity of the message cannot be proved, so it may have been tampered with.
These problems don't just arise with HTTP, but with other unencrypted protocols as well. Besides that, HTTP itself has many disadvantages. Moreover, there are deficiencies in the actual application of some specific web servers and specific web browsers (it can also be said to be vulnerabilities or security holes). In addition, web applications developed with programming languages such as Java and PHP There may also be security holes.
If you want to ask why it is a disadvantage to not encrypt the communication, it is because, according to the working mechanism of the TCP/IP protocol family, the communication content may be peeped on all communication lines. The so-called Internet is composed of networks that can connect to the whole world. No matter where the server in the world is communicating with the client, some network equipment, optical cables, computers, etc. on this communication line cannot be personal property, so it is not ruled out that there will be malicious peeping behavior in a certain link . Even encrypted communications can be viewed, just like unencrypted communications. It just means that if the communication is encrypted, it may be impossible for people to decipher the meaning of the message information, but the encrypted message information itself will still be seen.
Eavesdropping on communications on the same segment is not difficult. Just collect the data packets (frames) flowing on the Internet. The analysis of the collected data packets can be handed over to those packet capture (Packet Capture) or sniffer (Sniffer) tools.
Wireshark is a widely used packet capture tool. It can obtain the content of the request and response of the HTTP protocol and parse it. A series of things like sending a request using the GET method, returning a 200 OK response, and viewing the entire content of the HTTP response message can be done.
Encryption processing to prevent eavesdropping
Among the several countermeasures that everyone is studying to prevent eavesdropping and protect information, encryption technology is the most popular. There can be several encrypted objects.
Encryption of Communications One approach is to encrypt communications. There is no encryption mechanism in the HTTP protocol, but it can be used in combination with SSL (Secure Socket Layer, Secure Socket Layer) or TLS (Transport Layer Security, Security Layer Transport Protocol) to encrypt HTTP communication content.
After establishing a secure communication line with SSL, HTTP communication can be performed on this line. HTTP used in combination with SSL is called HTTPS (HTTPSecure, Hypertext Transfer Security Protocol) or HTTP over SSL.
Encryption of Content
There is also a way to encrypt the content itself that is involved in the communication. Since there is no encryption mechanism in the HTTP protocol, the content transmitted by the HTTP protocol itself is encrypted. That is, the content contained in the HTTP message is encrypted. In this case, the client needs to encrypt the HTTP message before sending the request.
Indeed, in order to achieve effective content encryption, the premise is that both the client and the server are required to have encryption and decryption mechanisms. Mainly used in Web services. One thing must be noticed, because this method is different from SSL or TLS to encrypt the entire communication line, so the content still has the risk of being tampered with. We'll explain that later.
The implementation of the HTTP protocol itself is very simple. No matter who sends the request, it will return a response. Therefore, if the communication party is not confirmed, there will be the following hidden dangers. There is no way to determine whether the web server to which the request was sent was the one that returned the response as it was actually intended. Possibly a masquerading web server. There is no way to determine whether the client to which the response was returned was the one that received the response as it was actually intended. Possibly a masquerading client. It cannot be determined whether the other party being communicated has access rights. Because important information is saved on some web servers, only the permission to send specific users to communicate is desired.
It is impossible to determine where and by whom the request came from. Even meaningless requests are accepted. DoS attacks (Denial of Service, denial of service attacks) under massive requests cannot be prevented.
Identifying the opponent's certificate
While it is not possible to identify the communicating party using the HTTP protocol, it is possible if using SSL. Not only does SSL provide encryption, but it also uses a means known as a certificate that
can be used to identify a party. Certificates are issued by trusted third-party organizations to prove that servers and clients actually exist. In addition, forging certificates is extremely difficult from a technical point of view. Therefore, as long as the certificate held by the communicating party (server or client) can be confirmed, the real intention of the communicating party can be judged.
By using a certificate, to prove that the communicating party is the expected server. This also reduces the risk of personal information leakage for the individual user. In addition, the client can complete the confirmation of personal identity by holding the certificate, and it can also be used in the authentication process of the Web site.
The so-called completeness refers to the accuracy of the information. Failure to prove its integrity usually means that it is impossible to determine whether the information is accurate.
The received content may be wrong.
Since the HTTP protocol cannot prove the integrity of the communication message, there is no way for the content of the request or response to be tampered with during the period after the request or response is sent until it is received by the other party. Learned. In other words, there is no way to be sure that the request/response sent and the request/response received are the same back and forth.
For example, when downloading content from a certain Web site, it is impossible to determine whether the file downloaded by the client is consistent with the file stored on the server. The content of the file may have been tampered with other content during transmission. Even if the content does change, the receiving client will not be aware of it. Like this, an attack in which an attacker intercepts and tampers with a request or response during transmission is called a Man-in-the-Middle attack (MITM).
How to prevent tampering
Although there is a method to determine the integrity of the message using the HTTP protocol, it is not convenient and reliable in fact. The most commonly used methods are hash value verification methods such as MD5 and SHA-1, and digital signature methods used to confirm files.
Web sites that provide file download services will also provide corresponding digital signatures created with PGP (PrettyGood Privacy) and hash values generated by the MD5 algorithm. PGP is a digital signature used to prove the creation of a file, and MD5 is a hash value generated by a one-way function. No matter which method is used, the user who manipulates the client needs to personally check and verify whether the downloaded file is the file on the original server. The browser cannot automatically check for the user. Unfortunately, with these methods, it is still impossible to guarantee that the confirmation result is correct. Because PGP and MD5 are rewritten, the user has no way to realize it. In order to effectively prevent these disadvantages, it is necessary to use HTTPS. SSL provides authentication and encryption processing and digest functions. It is very difficult to ensure integrity with HTTP alone, so it is used in combination with other protocols to achieve this goal. In the next section we introduce the related content of HTTPS.
If you use unencrypted plaintext during HTTP protocol communication, such as entering a credit card number into a Web page, if the communication line is tapped, the credit card number will be exposed. In addition, for HTTP, whether it is a server or a client, there is no way to confirm the communication party. Because it is very likely that you are not actually communicating with the originally expected communication party. And it is also necessary to consider the possibility that the received message has been tampered with during the communication. In order to solve the above-mentioned problems uniformly, mechanisms such as encryption processing and authentication need to be added to HTTP. We call HTTP with added encryption and authentication mechanisms HTTPS (HTTP Secure).
HTTPS communication is often used on web login pages, shopping payment screens, etc. When communicating using HTTPS, use https:// instead of http://. Also, when a browser accesses a Web site where HTTPS communication is enabled, a lock mark will appear in the address bar of the browser. The display method for HTTPS may vary depending on the browser.
HTTPS is not a new protocol at the application layer. Only the HTTP communication interface part is replaced by SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols. Normally, HTTP communicates directly with TCP. When using SSL, it evolves to communicate with SSL first, and then communicate with SSL and TCP. In short, the so-called HTTPS is actually HTTP wrapped in the shell of the SSL protocol.
With the adoption of SSL, HTTP has the encryption, certificates, and integrity protection features of HTTPS. SSL is a protocol independent of HTTP, so not only the HTTP protocol, but also other protocols such as SMTP and Telnet running on the application layer can be used with the SSL protocol. It can be said that SSL is the most widely used network security technology in the world today.
Before explaining SSL, let's first understand the encryption method. SSL uses an encryption method called public-key cryptography. In modern encryption methods, the encryption algorithm is public, but the key is kept secret. In this way, the security of the encryption method is maintained. Encryption and decryption both use keys. The password cannot be decrypted without the key, and conversely, anyone with the key can decrypt it. If the key is obtained by an attacker, the encryption is meaningless.
Dilemma of shared key encryption
The method of using the same key for encryption and decryption is called shared key encryption (Common key crypto system), also known as symmetric key encryption.
When encrypting with a shared key, the key must also be sent to the other party. How can it be handed over safely? When the key is forwarded on the Internet, if the communication is intercepted, the key can fall into the hands of the attacker, and the meaning of encryption is lost. Also, try to keep the received key securely.
Public key encryption using two keys
Public key encryption solves the difficulty of shared key encryption well. Public key encryption uses a pair of asymmetric keys. One is called a private key and the other is called a public key. As the name implies, the private key cannot be known to anyone else, while the public key can be released at will, and anyone can get it.
Using the public key encryption method, the party sending the ciphertext uses the other party's public key for encryption, and the other party uses its own private key to decrypt the encrypted information after receiving it. In this way, there is no need to send the private key used for decryption, and there is no need to worry about the key being eavesdropped and stolen by an attacker. In addition, it is very difficult to restore the original text of the information based on the cipher text and the public key, because the decryption process is to evaluate the discrete logarithm, which is not easy to do. Taking a step back, if a very large integer can be factored quickly, then there is still hope for password cracking. But it is unrealistic based on the current technology.
HTTPS uses a hybrid encryption mechanism
HTTPS uses a hybrid encryption mechanism that uses both shared key encryption and public key encryption. If keys can be exchanged securely, it may be possible to consider communicating using only public key encryption. However, public key encryption is slower to process than shared key encryption. Therefore, we should make full use of their respective advantages and combine multiple methods for communication. The public key encryption method is used in the key exchange link, and the shared key encryption method is used in the subsequent phase of establishing communication and exchanging messages.
Unfortunately, there are still some problems with public key encryption. That is, it is impossible to prove that the public key itself is a genuine public key. For example, when preparing to establish communication under public key encryption with a certain server, how to prove that the received public key is the public key issued by the originally expected server. Perhaps during the transmission of the public key, the real public key has been replaced by an attacker. In order to solve the above problems, public key certificates issued by digital certificate certification authorities (CA, Certificate Authority) and related agencies can be used. The digital certificate certification authority is in the position of a third party trusted by both the client and the server. Verisign (VeriSign) is one of the well-known digital certificate certification agencies. Let's introduce the business process of the digital certificate certification authority. First, the operator of the server applies for a public key to the digital certificate certification authority. After identifying the identity of the applicant, the digital certificate certification authority will digitally sign the applied public key, then distribute the signed public key, and put the public key into the public key certificate and bind it to the Together. The server will send this public key certificate issued by the digital certificate certification authority to the client for public key encrypted communication. Public key certificates can also be called digital certificates or certificates directly. The client receiving the certificate can use the public key of the digital certificate certification authority to verify the digital signature on that certificate. Once the verification is passed, the client can confirm two things: 1. The public key of the authentication server It is a real and effective digital certificate certification authority. Second, the server's public key is trustworthy. Here the public key of the certification authority must be securely transferred to the client. When using the communication method, how to transfer it safely is a very difficult thing. Therefore, when most browser developers release a version, they will embed the public key of the commonly used certification authority inside in advance.
One function of the certificate is to prove whether the server as the communication party is standardized, and the other function is to confirm whether the enterprise operating behind the other party's server really exists. The certificate with this feature is the EV SSL certificate (Extended Validation SSLCertificate). EV SSL certificates are issued based on international standard certification guidelines. It strictly stipulates the verification policy for the authenticity of the operating organization, so the certified Web site can obtain a higher degree of recognition. The background color of the address bar of the browser of the website holding the EV SSL certificate is green, which can be distinguished visually at a glance. Also, on the left side of the address bar, the name of the organization recorded in the SSL certificate and the name of the certification authority that issued the certificate are displayed.
The original intention of the above mechanism is to prevent users from being attacked by phishing (Phishing), but in terms of effect, there is still a question mark. Many users may not know the knowledge about EV SSL certificate, so they don't pay much attention to it.
Client certificates are also available in HTTPS. Client authentication with client certificates proves that the server is always communicating with the expected client, and its role is exactly the same as that of server certificates. However, client certificates still have several problems. One of the problem points is the acquisition and issuance of certificates. To obtain a certificate, the user has to install the client certificate by himself. However, since the client certificate is purchased for a fee, and each certificate corresponds to each user, it means that the fee equal to the number of users needs to be paid. In addition, allowing users with different levels of knowledge to install certificates themselves is full of challenges. The status quo is that highly secure certificate authorities can issue client certificates but only for special purpose business. For example, those services that can support the payment of client certificates. For example, a bank's online banking uses client certificates. When logging into the online banking, not only the user is required to confirm the input of ID and password, but also the user's client certificate is required to confirm whether the user accesses the online banking from a specific terminal.
Another problem with the client certificate is that, after all, the client certificate can only be used to prove the actual existence of the client, but not to prove the authenticity of the user himself. That is to say, as long as you have the right to use the computer with the client certificate installed, it means you have the right to use the client certificate at the same time.
The reason why it is feasible to intervene in the certification authority in the SSL mechanism is because it is based on the premise that its credit is absolutely reliable. However, in July 2011, a certification authority in the Netherlands called DigiNotar was hacked illegally and issued fake certificates for websites such as google.com and twitter.com. This incident fundamentally shakes the credibility of SSL. Because the fake certificate has a digital signature of a formal certification authority, the browser will determine that the certificate is legitimate. When a fake certificate is used as a server masquerade, the user cannot detect it at all. Although there is a certificate revocation list (Certificate Revocation List, CRL) mechanism that can invalidate the certificate, and a countermeasure to remove the Root Certificate Authority (Root Certificate Authority, RCA) from the client, it will take some time before it becomes effective, and in this period It is not known how many users' interests will suffer losses within a certain period of time.
If you use the OpenSSL open source program, everyone can build their own certification authority to issue server certificates for themselves. But that server certificate is not available as a certificate on the internet, doesn't seem to help. An independently constructed certification authority is called a self-certification authority, and a "useless" certificate issued by a self-certification authority is also jokingly called a self-signed certificate. When a browser accesses the server, it displays warning messages such as "The security of the connection could not be confirmed" or "There is a problem with this website's security certificate"
A server certificate issued by a self-certifying authority doesn't work because it doesn't eliminate the possibility of masquerading. The effect that a self-certification agency can produce is at most the degree to which it declares "I am ○○" to the outside world. Even if a self-signed certificate is used, after SSL encryption, you may occasionally see a prompt that the communication is in a secure state, but that is also problematic. Because even if the communication is encrypted, it cannot be ruled out that it is maintaining communication with a fake server that has been disguised. Only when a trusted third-party organization intervenes in the certification can the public key issued by the certification authority implanted in the browser be used to prove the authenticity of the server. Intermediate CA certificates may become self-certified Certificates from trusted CAs are pre-installed in most browsers, but intermediate CA certificates are also pre-planted in a small number of browsers. For the server certificate issued by the intermediate certification authority, some browsers will treat it as a formal certificate, and some browsers will treat it as a self-signed certificate.
To better understand HTTPS, let's observe the communication steps of HTTPS.
Step 1: The client starts SSL communication by sending a Client Hello message. The message contains the specified version of SSL supported by the client, and the list of Cipher Suite (encryption algorithm used, key length, etc.).
Step 2: When the server can perform SSL communication, it will respond with a Server Hello message. Like the client, the SSL version and encryption components are included in the message. The server's encrypted component content is filtered from the received client encrypted component.
Step 3: Afterwards, the server sends a Certificate message. The message contains the public key certificate.
Step 4: Finally, the server sends a Server Hello Done message to notify the client, and the initial phase of the SSL handshake negotiation is over.
Step 5: After the first SSL handshake ends, the client responds with a Client Key Exchange message. The message contains a random password string called Pre-mastersecret used in communication encryption. This message has been encrypted with the public key from step 3.
Step 6: Then the client continues to send the Change Cipher Spec message. This message will prompt the server, and the communication after this message will be encrypted with the Pre-master secret key.
Step 7: The client sends a Finished message. This message contains the overall check value of all messages connected so far. Whether this handshake negotiation can be successful depends on whether the server can correctly decrypt the message as a criterion.
Step 8: The server also sends a Change Cipher Spec message.
Step 9: The server also sends a Finished message.
Step 10: After the Finished message exchange between the server and the client is completed, the SSL connection is established. Of course, communication will be protected by SSL. From here, the communication of the application layer protocol starts, that is, the HTTP request is sent.
Step 11: Application layer protocol communication, that is, sending HTTP response.
Step 12: Finally disconnected by the client. When disconnecting, send close_notify message. Some omissions have been made in the above figure. After this step, a TCP FIN message is sent to close the communication with TCP.
In the above process, when the application layer sends data, a message digest called MAC (Message Authentication Code) will be attached. MAC can detect whether the message has been tampered with, thus protecting the integrity of the message.
HTTPS uses two protocols, SSL (Secure Socket Layer) and TLS (Transport Layer Security). The SSL technology was first advocated by the browser developer Netscape Communications Corporation, and has developed versions before SSL3.0. At present, the dominance has been transferred to the hands of IETF (InternetEngineering Task Force, Internet Engineering Task Force). The IETF takes SSL3.0 as the benchmark, and later developed TLS1.0, TLS1.1 and TLS1.2. TSL is a protocol developed based on SSL, which is sometimes collectively referred to as SSL. The current mainstream versions are SSL3.0 and TLS1.0. Since the SSL1.0 protocol was found to have problems at the beginning of its design, it was not actually put into use. SSL2.0 was also found to be problematic, so many browsers directly abolished this version of the protocol.
HTTPS also has some problems, that is, when using SSL, its processing speed will be slower.
There are two types of slow SSL. One refers to slow communication. The other is that the processing speed is slowed down due to the massive consumption of resources such as CPU and memory. Network load can be 2 to 100 times slower than using HTTP. In addition to connecting with TCP and sending HTTP requests and responses, SSL communication must be performed, so the overall processing traffic will inevitably increase. Another point is that SSL must be encrypted. Both the server and the client need to perform encryption and decryption operations. Therefore, as a result, it will consume more hardware resources of the server and client than HTTP, resulting in increased load. There is no fundamental solution to the slowdown, we use (dedicated server) hardware such as SSL accelerators to improve the problem. The hardware is dedicated to SSL communication, and compared with software, it can increase the computing speed of SSL several times. Use the SSL accelerator only for SSL processing to share the load. Why not always use HTTPS Since HTTPS is so safe and reliable, why don't all Web sites use HTTPS all the time? One reason for this is because encrypted communication consumes more CPU and memory resources than plain text communication. If each communication is encrypted, it will consume a lot of resources, and when it is spread on a computer, the number of requests that can be processed will definitely decrease accordingly.
Therefore, HTTP communication is used for non-sensitive information, and HTTPS encrypted communication is used only when sensitive data such as personal information is included. Especially whenever those heavily visited Web sites are encrypted, the load they bear cannot be underestimated. When encrypting, not all content is encrypted, but only when information hiding is required, so as to save resources.
In addition, one of the reasons is to save the cost of purchasing certificates. Certificates are required for HTTPS communication. The certificate used must be purchased from a certification authority (CA). Certificate prices may vary slightly depending on the certification body. Usually, a one-year authorization requires tens of thousands of yen (now 10,000 yen is equivalent to about 600 RMB). Those services and some personal websites that are not cost-effective to purchase certificates may only choose to use HTTP as a communication method.
Chapter 8 Authentication for Confirming the Identity of Accessing Users
Certain web pages only want to be browsed by specific people, or simply only visible to the person himself. In order to achieve this goal, the authentication function is indispensable. Let's learn about the authentication mechanism together.
The computer itself cannot determine the identity of the user sitting in front of the monitor. Furthermore, it is impossible to confirm who is on the other end of the network. It can be seen that in order to find out who is accessing the server, the client of the other party has to report himself. However, even if the other party who is accessing the server claims to be ueno, it is impossible to talk about whether the identity is true. In order to confirm whether ueno himself really has the authority to access the system, it is necessary to check "information only known to the registrant himself" and "information only available to the registrant himself
". The checked information usually refers to the following.
Password: A string of information that only you will know.
Dynamic token: only the one-time password displayed in the device held by the person.
Digital certificate: Information held only by the person (terminal).
Biometric authentication: biometric information such as fingerprints and irises.
IC card, etc.: Only information held by the person himself/herself.
However, even if the other party is a fake user, as long as it can pass the user verification, the computer will default to the behavior of the user. Therefore, the password to control confidential information must never be obtained by others, let alone easily cracked.
Authentication methods used by HTTP
The authentication methods used by HTTP/1.1 are as follows.
BASIC authentication (basic authentication)
DIGEST authentication (digest authentication)
SSL client authentication
FormBase authentication (form-based authentication)
In addition, there is Windows unified authentication (Keberos authentication, NTLM authentication), but this book will not explain it.
BASIC authentication (basic authentication) is an authentication method defined since HTTP/1.0. Even now, some websites still use this authentication method. It is an authentication method between the Web server and the communication client. Authentication steps of BASIC authentication
Step 1: When the requested resource requires BASIC authentication, the server will return a response with the WWW-Authenticate header field along with the status code 401Authorization Required. This field contains authentication method (BASIC) and Request-URI security domain string (realm).
Step 2: The client receiving the status code 401 needs to send the user ID and password to the server in order to pass the BASIC authentication. The content of the sent string is composed of user ID and password, which are connected by a colon (:) and then processed by Base64 encoding. Assuming that the user ID is guest and the password is guest, the concatenation will form a string like guest:guest. Then after Base64 encoding, the final result is Z3Vlc3Q6Z3Vlc3Q=. After writing this string into the header field Authorization, send the request. When the user agent is a browser, the user only needs to enter the user ID and password, and then the browser will automatically complete the conversion to Base64 encoding.
Step 3: After receiving the request including the header field Authorization, the server will verify the correctness of the authentication information. If the verification is passed, a response containing the Request-URI resource is returned. Although the BASIC authentication adopts the Base64 encoding method, it is not encrypted. It does not require any additional information to decode it. In other words, since the plaintext is decoded to be the user ID and password, during the process of BASIC authentication on non-encrypted communication lines such as HTTP, if someone eavesdrops, the possibility of being stolen is extremely high. In addition, when you want to perform BASIC authentication again, general browsers cannot implement the authentication logout operation, which is also one of the problems. BASIC authentication is not convenient and flexible enough to use, and it does not meet the security level expected by most Web sites, so it is not commonly used.
To make up for the weakness of BASIC authentication, there has been DIGEST authentication since HTTP/1.1. DIGEST authentication also uses the challenge/response method (challenge/response), but does not send plain text passwords directly like BASIC authentication. The so-called challenge-response method means that one party will first send an authentication request to the other party, and then use the challenge code received from the other party to calculate and generate a response code. Finally, return the response code to the other party for authentication. Because what is sent to the other party is only the response summary and the calculation result generated by the challenge code, so compared with BASIC authentication, the possibility of password leakage is reduced. Certification steps for DIGEST certification
Step 1: When requesting a resource that requires authentication, the server will return a response with the WWW-Authenticate header field along with the status code 401 Authorization Required. This field contains the temporary challenge code (random number, nonce) required for challenge-response authentication. The first field WWW-Authenticate must contain the information of realm and nonce. The client is authenticated by sending these two values back to the server. The nonce is an arbitrary random string generated each time a 401 response is returned. The string is generally recommended to be composed of Base64-encoded hexadecimal numbers, but the actual content depends on the specific implementation of the server.
Step 2: The client that receives the 401 status code returns a response that includes the header field Authorization information that is necessary for DIGEST authentication. The header field Authorization must contain field information of username, realm, nonce, uri and response. Among them, realm and nonce are the fields in the response received from the server before. username is the user name that can be authenticated within the limited range of realm. uri (digest-uri) is the value of Request-URI, but considering that the value of Request-URI may be modified after being forwarded by the proxy, a copy will be copied and saved in uri in advance. response can also be called Request-Digest, which stores the password string after MD5 operation to form a response code. For other entities in the response, please refer to the request header field Authorization in Chapter 6. In addition, the calculation rules related to Request-Digest are more complicated, and interested readers may wish to study RFC2617 in depth.
Step 3: The server that receives the request including the header field Authorization will confirm the correctness of the authentication information. After passing the authentication, a response containing the Request-URI resource is returned. And at this time, some relevant information about successful authentication will be written in the header field Authentication-Info. DIGEST authentication provides a higher level of security than BASIC authentication, but is still weak compared to HTTPS client authentication. DIGEST authentication provides a protection mechanism against password eavesdropping, but there is no protection mechanism against user masquerading. DIGEST certification, like BASIC certification, is not so convenient and flexible to use, and still falls short of the high security level pursued by most Web sites. Therefore, its scope of application is also limited.
From the perspective of the authentication method using the user ID and password, as long as the contents of the two are correct, it is the person's act that can be authenticated. But if user IDs and passwords are stolen, there is a good chance they can be impersonated by a third party. Using SSL client authentication can avoid this situation. SSL client authentication is a way to complete authentication through HTTPS client certificates. With client certificate (explained in the HTTPS chapter) authentication, the server can confirm whether the access is from a logged-in client.
8.4.1 Authentication steps of SSL client authentication
In order to achieve the purpose of SSL client authentication, the client certificate needs to be distributed to the client in advance, and the client must install this certificate.
Step 1: After receiving a request to authenticate resources, the server will send a CertificateRequest message, requesting the client to provide a client certificate.
Step 2: After the user selects the client certificate to be sent, the client will send the client certificate information to the server in the form of Client Certificate message.
Step 3: After the server verifies the client certificate, it can receive the client's public key in the certificate, and then start HTTPS encrypted communication
In most cases, SSL client authentication does not rely solely on certificates to complete authentication, and is generally used in combination with form-based authentication (explained later) to form a two-factor authentication (Two-factor authentication). The so-called two-factor authentication refers to an authentication method that not only requires the password as a factor in the authentication process, but also requires the applicant to provide other information held by the applicant as another factor, which is used in combination with it. In other words, the SSL client certificate of the first authentication factor is used to authenticate the client computer, and the password of the second authentication factor is used to confirm that it is the user himself. After passing the two-factor authentication, it can be confirmed that the user himself is using the correct computer to access the server.
Necessary fees for SSL client authentication
A client certificate is required to use SSL client authentication. The client certificate needs to pay a certain fee to use. The cost mentioned here refers to the cost of purchasing the client certificate from the certification authority, and the cost incurred by the server operator to ensure the safe operation of the certification authority built by itself. The cost of issuing client certificates by each certification authority is different, and the annual cost is about tens of thousands to hundreds of thousands of yen when it is evenly allocated to one certificate. Server operators can also set up their own certification bodies
, but corresponding costs will be incurred to maintain safe operations.
Form-based authentication methods are not defined in the HTTP protocol. The client will send the login information (Credential) to the Web application on the server, and authenticate according to the verification result of the login information. Depending on the actual installation of the web application, the provided user interface and authentication method are also different. In most cases, after entering the login information such as the user ID (usually an arbitrary character string or email address) and password that have been logged in beforehand, it is sent to the web application, and based on the authentication result, it is determined whether the authentication is successful.
Due to the convenience of use and security issues, the BASIC authentication and DIGEST authentication provided by the HTTP protocol standard are hardly used. In addition, although SSL client authentication has a high level of security, it has not yet been widely used due to problems such as introduction and maintenance costs. For example, for SSH and FTP protocols, the authentication between the server and the client is in compliance with the standard specification, and meets the most basic functional requirements of the security use level, so the authentication of these protocols can be used directly. But for the authentication function of the Web site, there is no standard specification that can satisfy its security use level, so the form-based authentication method implemented by each Web application has to be used. Forms authentication, which does not have a common standard specification, will be implemented differently on each Web site. If it is a form authentication implemented with full consideration of security performance, it can have a high level of security. However, it is not uncommon to see Web sites that have problems in the implementation of form authentication.
The standard specification based on form authentication has not yet been finalized, and cookies are generally used to manage Session (session). Form-based authentication itself is authenticated by matching the user ID and password sent by the client with the previously logged-in information through the server-side Web application. However, since HTTP is a stateless protocol, the status of previously authenticated users cannot be saved at the protocol level. That is, state management cannot be realized, so even when the user continues to access next time, he cannot be distinguished from other users. So we will use Cookie to manage Session to make up for the state management function that does not exist in the HTTP protocol.
Step 1: The client puts the login information such as user ID and password into the entity part of the message, and usually sends the request to the server by POST method. In this case, HTTPS communication is used to display the HTML form screen and transmit user input data.
Step 2: The server will issue a Session ID to identify the user. Authentication is performed by verifying the login information sent from the client, and then the user's authentication status is bound to the Session ID and recorded on the server. When returning a response to the client, the SessionID (eg PHPSESSID=028a8c...) will be written in the header field Set-Cookie. You can think of the Session ID as an equivalent number used to distinguish different users. However, if the Session ID is stolen by a third party, the other party can pretend to be your identity to perform malicious operations. Therefore, the Session ID must be prevented from being stolen or guessed. In order to achieve this, the Session ID should use an unpredictable string, and the server also needs to manage the validity period to ensure its security. In addition, in order to reduce the losses caused by cross-site scripting attacks (XSS), it is recommended to add the httponly attribute to the cookie in advance.
Step 3: After the client receives the Session ID sent from the server, it will save it locally as a Cookie. The next time a request is sent to the server, the browser will automatically send the cookie, so the Session ID will also be sent to the server. The server can identify the user and its authentication status by verifying the received Session ID. In addition to the application examples described above, there are other cases where different methods are applied. In addition, not only is there no standardized method for the login information and authentication process based on form authentication, but there is also no standardization for how the server should save the login information such as the password submitted by the user. Usually, a safe storage method is to first add additional information to the password by adding salt (salt) 1, and then use a hash (hash) function to calculate the hash value and save it. But we also often see the practice of directly saving plaintext passwords, and this practice has the risk of causing password disclosure.