Shulou(Shulou.com)06/02 Report--

HTTPS introduction

People use Web transactions to handle some very important things. If there is no strong security guarantee, people will not be able to shop online or use banking business at ease. If access is not strictly restricted, the company cannot place important documents on the Web server. Web needs a secure form of HTTP

The previous blog discussed some lightweight methods for providing authentication (basic authentication and digest authentication) and message integrity checking (digest qop= "auth-int"). These methods are useful for many network transactions, but not powerful enough for large-scale shopping, banking transactions, or access to confidential data. These more important transactions require a combination of HTTP and digital encryption to ensure security

The secure version of HTTP should be efficient, portable and easy to manage, not only to adapt to the changing situation, but also to meet the requirements of society and government. We need a HTTP security technology that provides the following functions: server authentication (clients know they are talking to real rather than fake servers); client authentication (servers know they are talking to real rather than fake clients); integrity (client and server data will not be modified) Encryption (client-server conversations are private without fear of eavesdropping); efficiency (an algorithm that runs fast enough for low-end clients and servers to use); universality (almost all clients and servers support these protocols); administrative scalability (anyone anywhere can communicate securely immediately) Adaptability (able to support the best-known security methods at present); social feasibility (to meet the political and cultural needs of society)

HTTPS is the most popular form of HTTP security. It was pioneered by Netscape and is supported by all major browsers and servers. The URL of the HTTPS scheme begins with https://, instead of http://, so you can tell that a Web page is accessed through HTTPS instead of HTTP

When using HTTPS, all HTTP request and response data is encrypted before it is sent to the network. HTTPS provides a transport-level cryptographic security layer under HTTP-either SSL or its successor-Transport layer Security (Transport Layer Security,TLS). Because SSL and TLS are very similar, the term SSL and TLS are generally used loosely in terms SSL and TLS.

Most of the difficult encoding and decoding work is done in the SSL library, so Web clients and servers do not need to modify their protocol processing logic too much when using secure HTTP. In most cases, you only need to replace the TCP call with the SSL input / output call and add a few other calls to configure and manage the security information

Digital encryption

Before discussing HTTPS in detail, let's introduce some background knowledge of the encryption and coding techniques used by SSL and HTTPS. It mainly includes passwords-algorithms that encode text so that voyeurs cannot recognize them; keys-digital parameters that change password behavior; symmetric key encryption systems-algorithms that use the same key for encoding / decoding; asymmetric key encryption systems-algorithms that use different keys for encoding / decoding; public key encryption systems-a system that enables millions of computers to send secret messages easily. Digital signature-checksum used to verify that the message has not been forged or tampered with; digital certificate-identification information verified and issued by a trusted organization

Cryptography is a mechanism and skill for encoding / decoding messages. People have been sending secret messages in an encrypted way for thousands of years. But what cryptography can do is not only to encrypt messages to prevent good people from reading them, but also to prevent tampering with messages, and we can even use cryptography to prove that a message or transaction is actually written by you, just like the handwritten signature of a check or the embossed wax on an envelope.

[password]

Cryptography is based on a secret code called cipher. A password is a set of coding scheme-a combination of a special message encoding method and a corresponding decoding method to be used later. The original message before encryption is usually called plaintext (plaintext or cleartext). The encoded message after using the password is usually called ciphertext (ciphertext).

Passwords have been used to generate confidential information for thousands of years. Legend has it that Julius Caesar (Julius Caesar) used a three-character rotation code in which each character in the message was replaced by a character after three positions in the alphabet. In the modern alphabet, "A" should be replaced by "D", "B" should be replaced by "E", and so on

Encode the message "meet me at the pier at midnight" into the ciphertext "phhwphdwwkhslhudwplgqljkw" with a rot3 (rotate 3 character) password. By decoding and rotating and shifting 3 characters in the alphabet, the ciphertext can be decrypted back to the original plaintext.

At first, people need to encode and decode themselves, so at first the password is a fairly simple algorithm. Because passwords are simple, people can encode and decode them with paper, pens and codebooks, but smart people can also "crack" these passwords quite easily.

With the development of technology, people began to build machines that can encode and decode messages quickly and accurately with much more complex passwords. These cipher machines can not only do some simple rotation, but also replace characters, change the order of characters, and slice messages, making it more difficult to crack the code.

Coding algorithms and encoders can fall into the wrong hands, so most machines have plates that can be set to a large number of different values to change the way passwords work. Even if the machine is stolen, without the correct dial setting (key value), × × will not work.

These password parameters are called key. The decryption process can only be carried out correctly by entering the correct key in the cryptographic machine. A password key makes a password machine look like multiple virtual password machines, each with a different key value, so its behavior is different.

The following figure shows an example of a password that uses a key. The encryption algorithm is a common "cyclic shift N character" password. The value of N is controlled by the key. If the same input message "meet me at the pier at midnight" is transmitted through the same coding machine, different outputs will be produced according to the different key values. Now, basically all encryption algorithms use keys.

[numeric password]

With the advent of digital computing, there have been two major developments: liberating from the speed and functional limitations of mechanical equipment, making complex coding / decoding algorithms possible, and supporting super-large keys. In this way, trillions of virtual encryption algorithms can be generated from one encryption algorithm, and different algorithms can be distinguished by different key values. The longer the key, the more coding combinations, and the more difficult it is to crack the code by randomly guessing the key.

Compared with the dial settings in metal keys or mechanical equipment, digital keys are just numbers. These digital key values are inputs to the encoding / decoding algorithm. Coding algorithms are functions that read a piece of data and encode / decode it according to the algorithm and key value.

Given a plaintext message P, an encoding function E and a digital encoding key e, an encoded ciphertext C can be generated. Through the decoding function D and the decoding key d, the ciphertext C can be decoded into the original plaintext P. Of course, the encoding / decoding functions are inverse functions of each other, and the decoding of P will return to the original message P.

Symmetric key

Many digital encryption algorithms are called symmetric key (symmetric-key) encryption because they are encoded with the same key value as when decoding. Let's call it key k.

In symmetric key encryption technology, the sender and receiver have to share the same key k before they can communicate. The sender encrypts the message with a shared key and sends the resulting ciphertext to the receiver. The receiver receives the ciphertext and applies the decryption function and the same shared key to it to recover the original plaintext.

Popular symmetric key encryption algorithms include DES, Triple-DES, RC2 and RC4

It is important to keep the secret state of the key. In many cases, the encoding / decoding algorithm is well known, so the key is the only secret.

A good encryption algorithm forces people to try every possible key before they can crack the code. Using violence to try all key values is called enumeration (emmieration attack). If there are only a few possible key values, unscrupulous people can finally crack the code by traversing all values by force. But if there are a large number of possible key values, it may take him days, years, or even infinitely long time to traverse all the keys to find the one that can crack the password.

The number of available key values depends on the number of bits in the key and how many of the possible keys are valid. In the case of symmetric key encryption, usually all key values are valid. An 8-bit key has only 256 possible key values, and a 40-bit key can have 2 to 40 possible key values (about 1 trillion keys)

In traditional symmetric key encryption techniques, a 40-bit key is secure enough for small, less important transactions. But today's high-speed workstations can crack it, and these workstations can do billions of calculations per second.

In contrast, for symmetric key encryption, a 128-bit key is considered to be very powerful. In fact, long keys have a very important impact on password security, and the US government has even imposed export controls on encryption software that use long keys to prevent potentially hostile organizations from creating secret codes that the National Security Agency (National Security Agency, NSA) itself cannot crack.

One of the disadvantages of symmetric key encryption is that the sender and receiver must have a shared secret key before talking to each other.

If you want to have a private conversation with Joe, probably because you want to customize some woodworking tools after watching a home improvement show on public television, establish a private secret key between you and www.joes-hardware.com before safely ordering anything. You need a way to generate a secret key and remember it. You and Joe's hardware store, and everyone else on the Internet, have to generate and remember thousands of keys.

For example, Alice (A), Bob (B) and Chris (C) all want to talk to Joe's hardware store (J). A, B and C all have to establish their own secret keys with J. A may require a key Ka,B may require a key Kb,C may require a key Kc. Each pair of communication entities needs its own private key. If there were N nodes, each node would have a secure conversation with all the other nodes, and there would probably be a total of N secret keys: it would be an administrative nightmare.

Public key

Instead of using a separate encryption / decryption key for each pair of hosts, public key encryption uses two asymmetric keys: one to encode the host message and the other to decode the host message. The encoding key is well known (which is the origin of the name public key encryption), but only the host knows the private decryption key. In this way, everyone can find the public key of a particular host, and the establishment of the key becomes easier. But the decoding key is confidential, so only the receiver can decode the message sent to it.

[note] most public key job hunting is actually done through digital certificates.

In the following figure, node X can make its encryption key ex public. Now, anyone who wants to send a message to node X can use the same public key, because each host is assigned an encoding key that can be used by everyone, so public key encryption avoids the Numbern expansion of the number of pairwise keys in symmetric key encryption.

Although everyone can encode the message sent to X with the same key, no one can decode the message except X, because only X has the private key dx. Separating the key allows everyone to encode the message, but only its owner can decode the message. In this way, it is easier for each node to securely send messages to the server, because they only need to find the public key of the server.

Through public key encryption technology, all computer users around the world can use security protocols. It is very important to develop a standardized public key technology package, so the creation of large-scale public key architecture (Public-Key Infrastructure, PKI) standards has been going on for many years

[RSA]

The common challenge for all public key asymmetric encryption systems is to ensure that even if someone has all the following clues, it is impossible to calculate the secret private key: the public key (which is public and available to everyone); a small piece of intercepted ciphertext (which can be obtained by sniffing the network); a message and the ciphertext associated with it (can be obtained by running an encrypted device on any piece of text)

RSA algorithm is a popular public key encryption system that meets all these conditions. It was invented in MIT and later commercialized by RSA data Security. Even with the public key, any piece of plaintext, the relevant ciphertext obtained by encoding the plaintext with the public key, the RSA algorithm itself, and even the source code implemented by RSA, the difficulty of cracking the code to find the corresponding private key is still equivalent to the difficulty of prime factorization of a large number, which is considered to be one of the most difficult problems in all computer science. Therefore, if we find a way to quickly decompose a large number into a prime factor, we will not only be able to * the Swiss bank account system, but also win the Turing Award.

The details of RSA encryption technology include a lot of tedious mathematical problems. You don't need to have a doctorate in number theory. There are plenty of libraries that can be used to execute RSA algorithms.

Anyone who knows its public key can send a secure message to a public server, so the asymmetric public key encryption system is very useful. Two nodes do not need to exchange private keys for secure communication

But the calculation of the public key encryption grate method may be very slow. In fact, it uses a mixture of symmetric and asymmetric strategies. For example, a more common practice is to establish a secure communication between two nodes through a convenient public key encryption technology, and then use that secure channel to generate and send a temporary random symmetric key. encrypt the rest of the data through faster symmetric encryption

Digital signature

So far, we have discussed various key encryption techniques for encrypting / decrypting confidential messages using symmetric and asymmetric keys.

In addition to encrypting / decrypting the message, the message can also be signed (sign) with an encryption system to indicate who wrote the message and to prove that the message has not been tampered with. This technique is called digital signature (digital signing).

A digital signature is a special encrypted check code attached to a message. The use of digital signature has the following two advantages: 1, the signature can prove that the author wrote this message. Only the author has the most confidential private key, so only the author can calculate these checksums. The checksum is like a personal "signature" from the author; 2. The signature can prevent the message from being tampered with. If a malicious person modifies the message during transmission, the checksum no longer matches. Since checksums can only be generated by private keys kept secret by the author, the author cannot forge the correct checkcode for the tampered message.

Digital signatures are usually generated by asymmetric public key technology. Because only the owner knows his private key, the author's private key can be used as a "fingerprint"

The following figure illustrates how node A sends a message to node B and signs it

First, node An extracts the variable-length message into a fixed-length digest; then, node An applies a "signature" function to the digest, which takes the user's private key as a parameter. Because only the user knows the private key, the correct signature function indicates that the signer is the owner; once the signature is calculated, node An appends it to the end of the message and sends both the message and the signature to B. at the receiving end, if node B needs to make sure that the message is indeed written by node An and has not been tampered with, node B can check the signature. Node B receives the signature with private key scrambling code and applies the inverse function using the public key. If the unpacked digest does not match node B's own digest version, either the message is tampered with during transmission, or the sender does not have node A's private key, that is to say, it is not node A.

Digital certificate

Digital certificates are called "ID cards" on the Internet. They contain a set of information, all of which are issued digitally by an official "certification authority". Basic digital certificates usually contain some common content in paper ID, such as: the name of the object (person, server, organization, etc.); expiration time; certificate publisher (who guarantees the certificate); digital signature from the certificate publisher

Digital certificates usually also include the public key of the object, as well as descriptive information about the object and the signature algorithm used. Anyone can create a digital certificate, but not everyone can get respected signing rights to guarantee certificate information and issue certificates with their private keys. A typical certificate structure is shown in the following figure

[X.509V3 Certificate]

There is no single global standard for digital certificates. Just as not all printed ID cards contain the same information in the same location, digital certificates come in many slightly different forms. Most of the certificates in use today store their information in a standard format, X.509V3. X.509V3 certificates provide a standard way to standardize certificate information into resolvable fields. Different types of certificates have different field values, but most follow the X.509 v3 structure. The field information in the X.509 certificate is described in the following table

There are several signatures based on X.509 certificates, including Web server certificate, client email certificate, software code signing certificate and certificate authority certificate

[certification]

After a secure Web transaction is established through HTTPS, modern browsers automatically obtain the digital certificate of the connected server. If the server does not have a certificate, the secure connection fails. The server certificate contains a number of fields, including: the name and hostname of the Web site; the public key of the Web site; the name of the signing authority; and the signature from the signing authority

The browser checks the signing authority when it receives the certificate. If this organization is a very authoritative public signature agency, the browser may already know its public key, because the browser will pre-install a lot of signing authority certificates. The following figure illustrates how to verify the integrity of a certificate through its digital signature

If you know nothing about the signature authority, the browser cannot determine whether the signature authority should be trusted, and it usually displays a dialog box to the user to see if he trusts the signature issuer. The signature publisher may be a local IT department or software vendor

HTTPS details

HTTPS is the most common secure version of HTTP. It has been widely used, and HTTPS is available on all major commercial browsers and servers. HTTPS combines the HTTP protocol with a powerful set of symmetric, asymmetric, and certificate-based encryption technologies, making HTTPS not only secure, but also flexible and easy to manage on the disordered, decentralized global Internet.

HTTPS accelerates the growth of Internet applications and has become the main driving force for the rapid growth of Web-based e-commerce. HTTPS is also very important in the security management of distributed Web applications in the WAN.

HTTPS is the HTTP that is sent at the secure transport layer. Instead of sending unencrypted HTTP messages to TCP and transmitting them over the worldwide Internet, HTTPS sends HTTP messages to a security layer to encrypt them before sending them to TCP

The HTTP security layer is implemented through SSL and its modern alternative protocol TLS. We follow the common usage and use the term SSL to refer to SSL or TLS

Secure HTTP is optional. Therefore, when making a request to the Web server, we need a way to tell the Web server to execute the security protocol version of HTTP, which is implemented in URL's scenario.

Typically, the URL scheme for a non-secure HTTP is prefixed with http, as follows:

Http://www.joes-hardware.com/index.html

In the secure HTTPS protocol, the scheme for URL is prefixed with https, as follows:

Https://cajun-shop.securesites.com/Merchant2/merchant.mv?Store_Code=AGCGS

When a client (such as a Web browser) is asked to perform a transaction on a Web resource, it examines URL's scheme: if URL's scheme is http, the client opens a connection to server port 80 (by default) and sends it the old HTTP command If URL's scheme is https, the client will open a connection to server port 443 (by default), then "shake hands" with the server, exchange some SSL security parameters with the server in binary format, and attach the encrypted HTTP command

SSL is a binary protocol, unlike HTTP, where traffic is carried on another port (SSL is usually carried on port 443). If both SSL and HTTP traffic arrives on port 80, most Web servers understand binary SSL traffic as the wrong HTTP and close the connection. Further integration of security services into the HTTP layer eliminates the need to use multiple destination ports, which in practice does not cause serious problems

Here's how SSL establishes a connection with a secure server.

In an unencrypted HTTP, the client opens a TCP connection to Web server port 80, sends a request message, receives a response message, and closes the connection

This process is slightly more complicated in HTTPS due to the existence of the SSL security layer. In HTTPS, the client first opens a connection to Web server port 443, the default port for secure HTTP. Once the TCP connection is established, the client and server initialize the SSL layer, communicate the encryption parameters, and exchange keys. After the handshake is complete, the SSL initialization is complete, and the client can send the request message to the security layer. Encrypt these messages before sending them to TCP

Before sending encrypted HTTP messages, the client and server perform a SSL handshake, during which they exchange protocol version numbers, select a password that both sides know, authenticate the identity of both ends, and generate a temporary session key to encrypt the channel.

Before transmitting any encrypted HTTP data over the network, SSL has sent a set of handshake data to establish a communication connection

The following figure is a simplified version of the SSL handshake. Depending on how SSL is used, the handshake process may be a little more complicated, but that's the general idea.

[server Certificate]

SSL supports two-way authentication, carrying the server certificate back to the client, and then sending the client's certificate back to the server. Now, client certificates are not often used when browsing, and most users don't even have their own client certificates. The server can require the use of a client certificate, but this rarely happens in practice

On the other hand, secure HTTPS transactions always require the use of server certificates. When performing security transactions on a Web server, such as submitting credit card information, you always want to be talking to the organization you think you are. A server certificate issued by a well-known authority can help you evaluate your trust in the server before sending a credit card or personal information

The server certificate is an X.509 v3 derived certificate that displays the name, address, server DNS domain name, and other information of the organization. You and the client software you use can check the certificate to ensure that all information is trusted.

SSL itself does not require users to check the Web server certificate, but most modern browsers simply check the integrity of the certificate and provide users with further thorough means. A Web server certificate validation algorithm proposed by Netscape is the basis of most browser validation technologies. The verification steps are as follows:

1. Date detection

First, the browser checks the start and end dates of the certificate to ensure that the certificate is still valid. If the certificate expires or has not been activated, the certificate validation fails and the browser displays an error message

2. Credibility detection of signature issuer

Each certificate is issued by some certification authority (CA) that guarantees the server. Certificates have different levels, and each certificate requires a different level of background verification. For example, if you apply for an e-commerce server certificate, you usually need to provide a legal certificate of business

Anyone can generate certificates, but some CA are very well-known organizations that use a very clear process to verify the identity of certificate applicants and the legitimacy of business practices. Therefore, the browser comes with a trusted list of signing authorities. If the browser receives a certificate issued by an unknown (possibly malicious) authority, it usually displays a warning message. Some certificates are carried to a valid signature path of the trusted CA, and browsers may choose to accept all such certificates. In other words, if a trusted CA issues a certificate for Sam's signature Store and Sam's signature Store issues a site certificate, the browser may accept it as a certificate exported from a valid CA path

3. Signature detection

Once it is determined that the signature authorization is trusted, the browser uses the public key of the signature authority for the signature and compares it with the check code to see the integrity of the certificate

4. Site identity detection

To prevent the server from copying other people's certificates or blocking other people's traffic, most browsers try to verify that the domain name in the certificate matches the domain name of the server they are talking to. Server certificates usually contain a domain name, but some CA create certificates that contain a list of server names or wildcard domain names for a group or group of servers. If the host name does not match the identifier in the certificate, the user-oriented client either notifies the user or terminates the connection with an error message indicating that the certificate is incorrect

SSL is a complex binary protocol. Unless you are a password expert, you should not send raw SSL traffic directly. Fortunately, writing SSL clients and servers is not very difficult with some commercial or open source libraries

OpenSSL is the most common open source implementation of SSL and TLS. The OpenSSL project, developed in collaboration with a number of volunteers, aims to develop a strong, fully functional commercial toolset to implement the SSL and TLS protocols and a fully functional general encryption library

[agent]

Clients usually use a Web proxy server to access the Web server on their behalf. For example, many companies place an agent on the security boundaries of the corporate network and the public Internet. An agent is the only device on a firewall router that allows HTTP traffic exchange, and it may perform virus detection or other content control work

But as long as the client starts encrypting the data sent to the server with the server's public key, the agent can no longer read the HTTP header, so the agent will not know where to direct the request

In order for HTTPS to work with the agent, several modifications are made to tell the agent where to connect. A commonly used technology is the HTTPS SSL tunneling protocol. Using HTTPS tunneling protocol, the client first informs the agent of the secure host and port it wants to connect to. This is told in clear text before the encryption starts, so the agent can understand the message

HTTP sends endpoint information in clear text through a new extension method called CONNECT. The CONNECT method tells the agent to open a connection to the desired host and port number. After this work is completed, the data is transferred directly in the form of a tunnel between the client and the server. The CONNECT method is a single-line text command that provides the hostname and port number of the secure raw server separated by colons. Host:port is followed by a space and a HTTP version string, followed by CRLF. This is followed by zero or more HTTP request first lines, followed by a blank line. After the blank line, if the handshake process for establishing the connection completes successfully, you can start to transfer SSL data

CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/1.IN

After a blank line in the request, the client waits for a response from the agent. The agent evaluates the request to ensure that it is valid and that the user has the right to request such a connection. If all goes well, the agent establishes a connection to the target server. If successful, send a 200 Connection Established response to the client

HTTP/1.0 200 Connection establishedProxy-agent: Netscape-Proxy/1.1

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.