HTTP authentication principle and HTTPS workflow

First, HTTP Authentication principle

HTTP defines two official certifications: Basic authentication and Digest authentication, both of which follow the same process:

1 Client initiated GET request

2 Server Response 401 Unauthorized,www-authenticate specify authentication algorithm, realm specifies security domain

3 Client re-initiation request, authorization specify user name and password information

4 Server Authentication succeeded, response 200, optional authentication-info

"Basic Certification"

Package "User name: Password" and use Base-64 encoding

Disadvantage: Password is easy to spy, you can hijack the code after the user name, password information, and then sent to the server for authentication, can be combined with the SSL certificate, hide the user name password;

"Digest Authentication"

No password is sent in clear text, the server responds with a random string nonce when the 2nd step above, and the client sends a response digest =md5 (HA1:nonce:HA2), where HA1=MD5 (Username:realm:password), HA2=MD5 ( Method:digesturi). The use of MD5 encryption in HTTP Digest authentication is to achieve "irreversible", that is, when the output is known, it should be quite difficult to determine the original input.

If the password itself is too simple, it may be possible to find the corresponding output by trying all possible inputs (exhaustive attack), or even by using a dictionary or an appropriate lookup table to speed up the search.

"HTTP Digest Authentication Security Enhancements"

1 The password is not used directly in the digest, but HA1 = MD5 (Username:realm:password). This allows some implementations (such as JBoss Digestauth) to store only HA1 instead of plaintext passwords.

2 The client random number nonce was introduced in RFC 2617, which would enable the client to prevent the selection of plaintext attacks (otherwise, something like Rainbow table would be a threat to the Digest authentication architecture).

3 server random number nonce is allowed to contain timestamps. The server can therefore check the nonce of random numbers submitted by the client to prevent replay attacks.

4 servers can also maintain a list of the most recently issued or used server random number nonce to prevent reuse.

"HTTP Digest access authentication disadvantage"

1 Many of the security options in RFC 2617 are optional. If the server does not specify a quality of protection (QOP), the client will operate in an earlier RFC 2069 mode that reduces security.

2 Digest access authentication is susceptible to man-in-the-middle attacks. For example, a man-in-the-middle attacker could tell the client to use basic access authentication or an earlier RFC 2069 digest to access the authentication mode.

Further, digest access authentication does not provide any mechanism to help clients verify the identity of the server. Some servers require passwords to be stored in reversible encryption algorithms. However, it is possible to only store a digest of the user name, realm, and password. It prevents the use of a strong password hash function (such as bcrypt) to store the password (because a digest of the password, or user name, realm, and password is required to be recoverable).

Second, HTTPS work flow

"HTTPS"

Combining HTTP with the same set of certificate-based encryption technology, SSL between HTTP and TCP, responsible for the encryption and decryption of HTTP messages;

If the URL is HTTPS, the client opens a connection to the server 443 port, exchanging SSL security parameters in binary format with the server handshake, and attaching the encrypted HTTP command;

The SSL protocol can be divided into two tiers:

(1) SSL recording Protocol (SSL record Protocol): It is based on a reliable transport protocol (such as TCP) to provide high-level protocol data encapsulation, compression, encryption and other basic functions of support.

(2) SSL Handshake Protocol (SSL handshake Protocol): It is based on the SSL logging Protocol, which is used to authenticate, negotiate cryptographic algorithms, exchange encryption keys, etc. before the actual data transfer begins.

"Server certification Phase"

1) The client sends a start message "Hello" to the server to start a new session connection;

2) The server determines whether a new master key needs to be generated based on the customer's information and, if necessary, the server will contain the information required to generate the master key in response to the customer's "Hello" information;

3) The customer generates a master key based on the received server response information and encrypts the server's public key to the server;

4) The server recovers the master key and returns it to the client to authenticate the server with a master key.

"User authentication Phase"

The certified server sends a question to the customer, and the customer returns a (digital) signature question and its public key, thereby providing authentication to the server.

"Handshake Process"

SSL protocol uses both public-key cryptography and symmetric encryption technology, although symmetric encryption technology is faster than public-key cryptography, but public key cryptography provides better authentication technology.

The ① client's browser transmits the version number of the client SSL protocol to the server, the type of cryptographic algorithm, and the resulting random number.

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

③ the client uses the information sent by the server to verify the legality of the server, whether the certificate expires, whether the CA that issued the server certificate is reliable, and whether the public key of the publisher certificate correctly unlocks the "digital signature of the publisher" of the server certificate

The ④ client randomly generates a "symmetric password" for subsequent communication, which is then encrypted with the server's public key and passed to the server.

⑦ server and client use the same master password, which is the symmetric key used for secure data communication of SSL protocol encryption and decryption communication

"HTTPS tunnel"

When a connection is established, the client uses the server's public key to encrypt the sending data, the agent cannot read the HTTP header, and does not know where to turn the request;

HTTPS SSL Tunneling protocol allows the client to tell the proxy to connect to the server and port, that is, through the Connect method to send the endpoint information in plaintext, the agent to establish a TCP connection with the server, the client directly use this tunnel to communicate with the server;

Tunneling: Sending non-HTTP traffic over an HTTP connection

"Explanation of the above related terms"

(1) Key: Change the password behavior of the digital parameters;

Symmetric key encryption: encoding, decoding using the same key, communication between the two parties must have a shared secret key before the dialogue, the cracker needs to traverse every possible key;

Public key encryption: Use two asymmetric keys, respectively, for encoding and decoding, the former is public, the latter is only local host storage; RSA is the public key encryption system invented by MIT;

(2) Digital signature

That is, the encrypted checksum can prevent the message from being tampered with;

1 A to extract the variable length message into a fixed-length digest, the signature function (using the user's private key as parameters), the signature is appended to the end of the message;

2 B to receive the message when the signature is checked, using the public key for the inverse function, if the post-unpacking digest and the plaintext Digest does not match, indicating that the message was tampered with or did not use a's private key;

(3) Digital certificate

Include: object name; expiration time; certificate publisher; public key; digital signature; Most certificates use the V3 format;

After establishing a secure Web transaction through HTTPS, the browser will proactively obtain the server's digital certificate, and if there is no certificate, the secure connection fails;

for more information, go to wosign CA Digital certificate Network to learn more www.wosign. Com

HTTP authentication principle and HTTPS workflow