CN111181912B - Browser identifier processing method and device, electronic equipment and storage medium - Google Patents

Browser identifier processing method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN111181912B
CN111181912B CN201910796788.4A CN201910796788A CN111181912B CN 111181912 B CN111181912 B CN 111181912B CN 201910796788 A CN201910796788 A CN 201910796788A CN 111181912 B CN111181912 B CN 111181912B
Authority
CN
China
Prior art keywords
browser
identifier
sample
target
identification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910796788.4A
Other languages
Chinese (zh)
Other versions
CN111181912A (en
Inventor
宗旋
杨勇
张�杰
廖晨
李龙
欧阳婷
黄楠驹
邓辉瑶
郑力枪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910796788.4A priority Critical patent/CN111181912B/en
Publication of CN111181912A publication Critical patent/CN111181912A/en
Application granted granted Critical
Publication of CN111181912B publication Critical patent/CN111181912B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Abstract

The invention provides a browser identifier processing method, a browser identifier processing device, electronic equipment and a storage medium; the method comprises the following steps: receiving a handshake message which is sent by a target browser and used for requesting to establish a secure connection with a server; analyzing the field data encapsulated by the handshake message to obtain the characteristics of multiple types of the target browser; sorting the characteristics of the multiple types of the target browser, and combining the sorted characteristics into an identifier corresponding to the target browser; matching the identification of the target browser with the identification in an identification library; and responding to the handshake message of the target browser according to the matching result. By the method and the device, the accurate and reliable browser identification can be generated to manage the safe connection behavior of the browser.

Description

Browser identifier processing method and device, electronic equipment and storage medium
Technical Field
The present invention relates to communications technologies, and in particular, to a method and an apparatus for processing a browser identifier, an electronic device, and a storage medium.
Background
The development of the internet, especially the mobile internet, has the advantages that the application of the browser is increasingly wide, users can log in various domain names (such as various domain names for work, entertainment, study and the like) through the browser to obtain services, and the convenience of the users is greatly improved. Authentication problems are inevitably involved during login and use of the browser, such as authentication during login, authentication when sensitive functions (e.g. payment services) are used in the browser.
However, the huge amount of used browsers causes considerable difficulty in identifying each browser by the background server, and in particular, the browsers can forge information for identification, which further affects the accuracy and reliability of browser identification.
Disclosure of Invention
Embodiments of the present invention provide a method and an apparatus for processing a browser identifier, an electronic device, and a storage medium, which can form an accurate and reliable browser identifier to manage a secure connection behavior of a browser.
The technical scheme of the embodiment of the invention is realized as follows:
the embodiment of the invention provides a processing method of secure connection, which comprises the following steps:
receiving a handshake message which is sent by a target browser and used for requesting to establish a secure connection with a server;
analyzing the field data encapsulated by the handshake message to obtain the characteristics of multiple types of the target browser;
sorting the characteristics of the multiple types of the target browser, and combining the sorted characteristics into an identifier corresponding to the target browser;
matching the identification of the target browser with the identification in an identification library;
and responding to the handshake message of the target browser according to the matching result.
An embodiment of the present invention provides a processing apparatus for secure connection, including:
a secure connection module to:
receiving a handshake message which is sent by a target browser and used for requesting to establish a secure connection with a server; matching the identification of the target browser with the identification in an identification library; responding to the handshake message of the target browser according to the matching result;
the identifier management module is configured to:
analyzing the field data encapsulated by the handshake message to obtain the characteristics of multiple types of the target browser; the identification management module is used for sequencing the characteristics of the multiple types of the target browser and combining the sequenced characteristics into an identification corresponding to the target browser.
In the foregoing solution, the identifier management module is further configured to: the following field data encapsulated by the handshake message are analyzed: the number of the protocol version number used by the target browser, the maximum protocol version number supported by the target browser, the encrypted sockets used by the target browser, the number of the encrypted sockets, the number of the extension fields and the number of the extension types;
and extracting corresponding information from the analyzed field data as the characteristics of the target browser.
In the foregoing solution, the identifier management module is further configured to: sequencing the encryption algorithms included in the encrypted sockets of the target browser according to the coding length of the encryption algorithms;
filtering domain name features from the extension field of the target browser, and sequencing the rest features in the extension field according to type values;
arranging the following characteristics of the target browser in sequence: using a protocol version number, a maximum protocol version number supported, the ciphered sockets ordered, the number of ciphered sockets, the extension fields ordered and the number of extension types.
In the foregoing solution, the identifier management module is further configured to: connecting the multiple types of features of the target browser into character strings;
and mapping the character string into a hash value with a specific length to serve as an identifier corresponding to the target browser.
In the foregoing solution, the secure connection module is further configured to: when the identification of the target browser is matched with the white list in the identification library, finishing a handshake process with the target browser to negotiate an encryption algorithm and a key used in the safe connection data transmission process;
and when the identification of the target browser is matched with the blacklist in the identification library, sending a handshake failure message to the target browser.
In the foregoing solution, the secure connection module is further configured to: when the identification of the target browser is matched with the white list in the identification library and a key is obtained through negotiation, encrypting verification data through the key and sending the verification data to the target browser;
receiving a verification code sent by the target browser, wherein the verification code is obtained by collecting verification operation after the target browser decrypts and executes verification data;
when the verification code is decrypted by the secret key and verified, the target browser is authorized.
In the foregoing solution, the identifier management module is further configured to: acquiring the identifier of each sample browser according to handshake messages which are sent by a plurality of sample browsers and used for establishing secure connection;
determining the type of the sample browser as a normal browser or an abnormal browser;
and when the sample browser belongs to a normal browser, storing the identifier of the normal browser into a white list of the identifier library, and when the sample browser belongs to an abnormal browser, storing the identifier of the abnormal browser into a black list in the identifier library.
In the foregoing solution, the identifier management module is further configured to: analyzing field data encapsulated by the handshake messages sent by the sample browser to obtain characteristics of multiple types of the sample browser;
and sequencing the characteristics of the multiple types of the sample browser in a mode consistent with that of sequencing the characteristics of the multiple types of the target browser, and combining the sequenced characteristics into an identifier corresponding to the sample browser.
In the foregoing solution, the identifier management module is further configured to: determining the distribution densities of the different types of sample browsers, determining the sample browser corresponding to the type with the distribution density smaller than a type distribution density threshold value as an abnormal browser, and determining the sample browser corresponding to the type with the distribution density larger than the type distribution density as a normal browser; and/or
Determining the distribution density of the sample browsers with different versions, determining the sample browser corresponding to the version with the distribution density smaller than the threshold value of the distribution density of the version as an abnormal browser, and determining the sample browser corresponding to the type with the distribution density larger than the distribution density of the version as a normal browser.
In the foregoing solution, the identifier management module is further configured to: when inquiring that the network has any one of the new protocol version and the release information of the encryption algorithm, starting the operation of collecting the identifiers of the sample browser, and stopping the operation of collecting the identifiers of the sample browser when collecting enough updated identifiers to enable the proportion of the updated identifiers in the identifier library to exceed the update proportion threshold value or the quantity of the collected updated identifiers to exceed the update quantity threshold value.
In the foregoing solution, the identifier management module is further configured to: and starting the operation of the identification of the acquisition sample browser during the period that the load is lower than the load threshold value, and stopping the operation of the identification of the acquisition sample browser during the period that the load is higher than the load threshold value.
In the foregoing solution, the identifier management module is further configured to: detecting the type and/or version of a source browser sending a handshake message for establishing a secure connection, and identifying the source browser as a sample browser when the number of identifications of sample browsers of corresponding types and/or versions in the identification library does not accord with a uniform distribution condition.
An embodiment of the present invention provides an electronic device, including:
a memory for storing executable instructions;
and the processor is used for realizing the method for processing the browser identifier provided by the embodiment of the invention when the executable instruction stored in the memory is executed.
The embodiment of the invention provides a storage medium, which stores executable instructions and is used for causing a processor to execute so as to realize the method for processing the browser identifier provided by the embodiment of the invention.
The embodiment of the invention has the following beneficial effects:
the utilization of the handshake information is a thus reliable property for establishing a secure connection, so that a correspondingly formed identification can reliably characterize the browser; the diversity of the identification is realized by utilizing the combination of a plurality of characteristics of the handshake information, so that the diversity of the identification can be realized, and the browser can be accurately represented; and then the browser can be reliably and accurately identified to manage the request behavior of the secure connection of the browser.
Drawings
FIG. 1 is an alternative architectural diagram of a browser identification processing system 100 provided by embodiments of the present invention;
fig. 2 is a schematic diagram of an exemplary structure of a server 200 according to an embodiment of the present invention;
fig. 3 is an alternative flowchart of a method for processing a browser identifier according to an embodiment of the present invention;
fig. 4 is an alternative flowchart of a method for processing a browser identifier according to an embodiment of the present invention;
FIG. 5 is a schematic flow chart of an alternative process of handshaking between a target browser and a server according to an embodiment of the present invention;
FIG. 6 is a schematic flow chart of an alternative process for collecting a browser fingerprint by a server according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of a circersuite field extracted by parsing a Client Hello message according to an embodiment of the present invention;
fig. 8A is a schematic view of a scenario in which a browser requesting a secure connection is identified as a browser according to an embodiment of the present invention;
fig. 8B is a schematic view of a scenario in which a browser requesting a secure connection is identified as a non-browser according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail with reference to the accompanying drawings, the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.
In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.
Before further detailed description of the embodiments of the present invention, terms and expressions mentioned in the embodiments of the present invention are explained, and the terms and expressions mentioned in the embodiments of the present invention are applied to the following explanations.
1) The normal browser is an application downloaded and installed through a normal distribution channel of the browser for obtaining a service from various domain names of the internet, for example, various application programs supporting an internet protocol such as a transmission control protocol/internet protocol (TCP/IP), including: a browser, a social network browser with a built-in browser core (interpreter of web page code, executor, and rendering engine of web page), etc.
2) An abnormal browser, i.e., a "non-browser", is network communication software capable of supporting secure connection, such as automaton software (ahocorasick), which can be used by hackers in an illegal way, and its access to a server belongs to "abnormal access", which may cause data leakage or damage of the server, belonging to a category that should be restricted.
3) The secure connection is a network connection for transmitting encrypted data between application programs (such as a browser of a terminal and a server program of a server), and is used for transmitting the encrypted data to an opposite side by the browser and the server, so that data leakage caused by interception by a third party is avoided.
4) The marks, also called digital fingerprints or fingerprints, are used to distinguish characters of different browsers, and the lengths of the marks may be variable, that is, the lengths of the marks of different browsers are not exactly the same, or the lengths of the marks may be equal, that is, the marks of all browsers use the same length. For example, when the identifier takes a length of 10 bits (bit), it can be used to distinguish 1024 (2)10) A different browser.
5) An identification repository, also called fingerprint repository, is a database for storing the identification of the browser.
6) The Transport Layer Security (TLS) protocol, which is one of the standards of the TCP/IP protocol family, is used to provide an implementation mechanism for confidentiality and data integrity between two programs (e.g., a browser program and a server program), wherein procedures for establishing an HTTPS connection are agreed, including negotiation of a protocol version, an encryption algorithm, a random number for forming a key, and the like.
Referring to fig. 1, fig. 1 is an alternative architecture schematic diagram of a browser identifier processing system 100 according to an embodiment of the present invention, and an exemplary application of a browser identifier processing scheme according to an embodiment of the present invention is described with reference to the structure shown in fig. 1.
The terminal 400 runs a browser 410 (browser 410-1 in terminal 400-1, browser 410-2 in terminal 400-2 are exemplarily shown), and the browser 410 is capable of logging in domain names of various services, such as social networking, online video, and instant messaging services. The browser 410 is connected to the server 200 via the network 300, and the network 300 may be a wide area network or a local area network, or a combination of both.
As an example, the connection between the browser 410 and the server 200 is a Secure connection, such as a connection based on a Hypertext Transfer security (HTTPS) Protocol, the Secure connection is abstracted as an encrypted socket, the socket binds an Internet Protocol (IP) address and a port number of the browser 410/server 200, and the browser 410/server 200 initializes the connection through a handshake process including determining an identity of a counterpart and negotiating a random number for generating a key, and the like. The secure connection represents a combination of an address and a port in the fourth layer of the TCP, the browser 410/server 200 binds the combination of the address and the port of the browser 410/server 200 to the combination of the address and the port of the other party, and when data is transmitted through the secure connection, the browser 410/server 200 monitors that the port allocated for the secure connection receives encrypted data from the other party and transmits the encrypted data to the port of the other party through the port.
The browser identification process of the server 200 includes a sample collection stage of identification and a matching stage of identification, which are described below.
In the identified sample collection phase, the server 200 recognizes the browser that is sent to the server 200 to establish the secure connection as a sample browser, for example, when the browser 410-1 in the terminal 400-1 and the browser 410-2 in the terminal 400-2 both send handshake messages to the server 200, both the browser 410-1 and the browser 410-2 are recognized as sample browsers, and the identifiers of the sample browsers are collected according to the handshake messages sent by the sample browsers and stored in the identifier library 500.
In some embodiments, the server 200 may classify the browser identifications in the identification repository 500, for example, into a white list and a black list, the browser corresponding to the identification of the white list (i.e., normal browser) will be allowed to establish a secure connection with the server 200, and the browser corresponding to the identification of the black list (i.e., abnormal browser) will be denied to establish a secure connection with the server 200.
In the matching stage of the identifiers, when the server 200 recognizes the browser which is sent to the server 200 for establishing the secure connection as the target browser, for example, the browser 410-1 in the terminal 400-1 and the browser 410-2 in the terminal 400-2 both send the handshake message to the server 200, both the browser 410-1 and the browser 410-2 are recognized as the target browser, the identifiers are extracted from the handshake message sent by the target browser in the same manner as the identifiers are collected from the sample browser, the identifiers are matched with the identifiers of the sample library 500, and the handshake message of the target browser is responded according to the matching result.
In some embodiments, the server 200 may match the identification of the target browser with the identification in the identification library 500, for example, when the identification of the target browser matches with a white list in the identification library, the server 200 identifies the target browser as a normal browser, and completes a subsequent handshake process with the target browser to establish a secure connection; when the identity of the target browser matches the blacklist in the identity repository, the server 200 identifies the target browser as an anomalous browser, sending a denial message to notify that a secure connection cannot be established.
An exemplary application scenario of the browser identification process provided by the embodiment of the present invention is described below.
In an application scenario in which a Web (Web) server verifies a login service domain name of a browser, the browser 410 needs to convert a guest identity into a user identity for login, and therefore sends a handshake message to the server 200, the handshake message is used to request a secure connection to be established with the server 200, the server 200 collects an identifier from the handshake message sent by the browser 410, matches the collected identifier of the browser 410 with the identifier library 500, if the identifier is matched with a white list, completes a handshake process with the browser 410 to establish the secure connection, sends verification data to the browser 410 through the secure connection, executes the verification data in the verification interface by the browser 410, and sends an execution result of the verification data (i.e., a verification code input by the user in the verification interface) and login information (including a user account number and a password) to the server 200; if a blacklist is matched, browser 410 is identified as an anomalous browser, and a rejection message of the handshake is sent to browser 410.
The verification data executed in the verification interface is used for performing the living body detection, and may take various forms. For example, a picture of random characters, so that the user enters the recognized characters in the verification interface of the browser 410 as a verification code; or a random arithmetic problem, so that the user inputs the operation result in the verification interface of the browser 410 as a verification code; the prompt information of the operation can be slid/clicked, so that the user can input the prompted sliding/clicking operation as a verification code in the verification interface of the browser 410; and may also be voice data, so that the user inputs a voice recognition result as a verification code through the browser 410,
continuing to explain the application scenario, the server 200 verifies the verification code submitted by the browser 410, if the verification code matches the correct verification code corresponding to the issued verification data, the verification is successful, and whether the user account of the browser 410 is a legal registered user is continuously verified according to the login information. If the verification is successful, the browser 410 is authorized to log in, the user is updated to be in a login state, and login page data of the user account, such as personal homepage data, is issued to the browser. If the verification codes are not matched successfully, new verification data are continuously issued to the browser until the verification of both the verification codes and the login information is successful, or the verification frequency threshold of the verification codes is reached (for example, 5 times in 1 minute), and the login of the browser based on the user account is limited, for example, the user account is frozen, and the login of the user account in a certain subsequent time (for example, 24 hours) is shielded.
In another application scenario using the sensitive functions of the login-state browser, the service domain name currently logged in by the browser 410 includes sensitive functions related to property and data security, such as an electronic payment function, an account logout function, and a batch data deletion function (e.g., batch deletion of contacts) in a social network browser, but the sensitive functions may be any functions that need protection and are customized by the user. After the identity of the guest is converted into the login state, the browser 410 can release the secure connection with the server 200, establish a non-encrypted connection by performing handshake operation with the server 200 again, establish an unencrypted network connection by an HTTP request, when the user logs in the browser 410 and needs to use a sensitive function, in order to improve the security, the browser 410 sends a handshake message for establishing the secure connection to the server 200 again to establish the secure connection, receives authentication data issued by the server 200, executes the authentication data in the interface of the browser 410 to display the authentication interface, obtains an authentication code input by the user in the authentication interface, sends the authentication code to the server 200 for authentication through the secure connection, and authorizes the browser 410 to run the sensitive function to ensure the security when the server 200 confirms that the authentication passes.
An exemplary structure of the server 200 is described below, and referring to fig. 2, fig. 2 is a schematic diagram of an exemplary structure of the server 200 according to an embodiment of the present invention, which includes: the at least one processor 210, the memory 250, the at least one network interface 220, and in some embodiments, the user interface 230. The various components in server 200 are coupled together by a bus system 240. It is understood that the bus system 240 is used to enable communications among the components. The bus system 240 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 240 in fig. 2.
The Processor 210 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.
The user interface 230 includes one or more output devices 231, including one or more speakers and/or one or more visual display screens, that enable the presentation of media content. The user interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.
The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 250 optionally includes one or more storage devices physically located remotely from processor 210.
The memory 250 includes volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). The memory 250 described in embodiments of the invention is intended to comprise any suitable type of memory.
In some embodiments, memory 250 is capable of storing data, examples of which include programs, modules, and data structures, or a subset or superset thereof, to support various operations, as exemplified below.
An operating system 251 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;
a network communication module 252 for communicating to other computing devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;
a presentation module 253 to enable presentation of information (e.g., a user interface for operating peripherals and displaying content and information) via one or more output devices 231 (e.g., a display screen, speakers, etc.) associated with the user interface 230;
an input processing module 254 for detecting one or more user inputs or interactions from one of the one or more input devices 232 and translating the detected inputs or interactions.
In some embodiments, the processing device for secure connection provided by the embodiment of the present invention may be implemented in software, and fig. 2 shows a processing device 255 for browser identification stored in a memory 250, which may be software in the form of programs and plug-ins, and includes the following software modules: a secure connection module 2551 and an identity management module 2552, which are logical and therefore can be arbitrarily combined or further split depending on the functionality implemented. The functions of the respective modules will be explained below.
In other embodiments, the processing Device for secure connection provided by the embodiments of the present invention may be implemented in hardware, and as an example, the processing Device provided by the embodiments of the present invention may be a processor in the form of a hardware decoding processor, which is programmed to execute the processing method for browser identifier provided by the embodiments of the present invention, for example, the processor in the form of the hardware decoding processor may employ one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.
The exemplary application and implementation of the system, the apparatus, and the server for processing the browser identifier according to the embodiments of the present invention will be described in detail.
Referring to fig. 3, fig. 3 is an optional schematic flowchart of a browser identifier processing method according to an embodiment of the present invention, and an implementation scheme of a server collecting a browser identifier in a browser identifier collection phase will be described with reference to fig. 3.
In step 101, the server starts a collection operation of the identifier of the browser.
In some embodiments, the identifier collection phase has specific on and off occasions, and the server may periodically turn on the operation of collecting the browser identifier to update the identifier in the identifier library based on the collected browser identifier. For example, the server may turn on the identified collection operation during each day's idle hours (load below load threshold) and exit the identified collection phase to stop the identified collection operation during each day's busy hours (load above load threshold), thereby fully utilizing the server's computing resources and avoiding the server's performance of responding to the browser's services.
In other embodiments, since the server collects the identifier based on the handshake message of the sample browser, the collection operation of the identifier may be started with the version update of the payload data of the handshake message, and the timing for stopping collecting the identifier of the browser may be selected according to the degree of update of the identifier in the identifier library.
As an example, the server may periodically or implement release information for detecting whether the network has a new protocol version number and an encryption algorithm and/or the like, and since the protocol version number and the encryption algorithm are loads of handshake messages for establishing a secure connection and the server collects the identifier of the browser from the handshake messages, when the server inquires that there is release information of any one of a new protocol version and an encryption algorithm in the network, the server enters an identifier collection stage to start a collection operation of the identifier, so that an effective identifier can be collected in time according to updates of the protocol version and the encryption algorithm. When a sufficient number of updated identifications are collected, for example, the proportion of the updated identifications in the identification library exceeds an update proportion threshold value, or the number of the collected updated identifications exceeds an update number threshold value, the identification collection stage is exited to stop the operation of collecting the identifications of the sample browser, so that the computing resources of the server are saved to the maximum extent.
In step 102, the server receives a handshake message sent by the browser for establishing a secure connection with the server, and identifies the browser as a sample browser.
In some embodiments, when the server is in the identification collection phase and receives a handshake message of a browser for establishing a secure connection in the identification collection phase, the browser sending the handshake message (hereinafter referred to as a source browser) is identified as a sample browser, so that a sufficient number of identifications of the sample browsers can be collected as soon as possible.
In other embodiments, the server may perform a type and/or version check on a source browser sending a handshake message for establishing the secure connection, and identify the source browser as a sample browser when the number of identifications identifying corresponding types and/or versions of sample browsers in the library does not meet the uniform distribution condition.
As an example of type detection, when a server is in an identifier collection stage and receives a handshake message for establishing a secure connection, a source browser sending the handshake message is subjected to type detection, whether a sufficient number (for example, exceeding a sample number threshold) of identifiers of sample browsers of the same type have been collected in an identifier library is determined, if yes, collection of the identifier of the source browser is abandoned, and if not, the source browser is recognized as the sample browser to collect corresponding identifiers in subsequent steps, so that the identifiers of different types of browsers in the identifier library are distributed uniformly, and thus, different types of browsers can be comprehensively recognized.
As an example of version detection, when a server is in an identifier collection phase and receives a handshake message for establishing a secure connection by a user, performing version detection on a source browser of the same type, determining whether a sufficient number of identifiers of browsers of the same version have been collected, for example, whether a sufficient number (for example, exceeding a sample number threshold) of identifiers of social network browsers of the same type have been collected, if so, discarding the collection of the identifiers of the source browser, and if not, identifying the source browser as a sample browser for subsequent identifier collection, so that the identifiers of browsers of the same type and different versions in an identifier library are distributed uniformly, and browsers of the same type and different versions can be identified comprehensively.
In step 103, the server parses the field data encapsulated by the handshake message to obtain the characteristics of the multiple types of sample browsers.
In some embodiments, taking an HTTPS-based secure connection as an example, when a sample browser needs to establish an HTTPS-based secure connection with a server, according to the TLS protocol, a handshake message sent by the sample browser needs to be encapsulated with the following field data: the protocol (i.e., encrypted communication protocol) version number used by the sample browser; the maximum protocol version number supported by the sample browser; the encrypted socket used by the sample browser comprises a series of encryption algorithms supported by the sample browser; the number of encrypted sockets; an extension field; the number of extension types; extracting corresponding information from the analyzed field data as the characteristics of the target browser; and the server obtains the field data by analyzing the package of the handshake message, so that the characteristics of the sample browser corresponding to each field data are obtained.
In step 104, the server ranks the plurality of types of features of the sample browser.
In some embodiments, the server sorts the plurality of types of features of the sample browser according to a set sorting rule, and the sorting rule stipulates the sorting order of the plurality of types of features.
For example, the multiple types of ranking order may be: the protocol version number, the maximum protocol version number supported, the crypto sockets, the number of crypto sockets, the extension field, and the number of extension types are used. Of course, the order of arrangement is not limited to the above examples, and any two types of ordering may be interchanged in position.
In other embodiments, the sorting rule specifies a manner of sorting a plurality of pieces of information included in some types of features, for example, a secure socket includes a plurality of encryption algorithms supported by a sample browser, and the sorting rule may specify that the plurality of encryption algorithms in the secure socket are sorted in an ascending order or a descending order of the encoding lengths of the encryption algorithms, so that, for the same browser, the identifiers collected in the identifier collection stage or the identifier matching stage are always consistent, thereby enabling accurate identification of the same browser.
In still other embodiments, the sorting rule further provides a mechanism for filtering the information filled with randomness in some features before sorting the features of the multiple types, for example, a mechanism for filtering the domain name features of the extension field is provided, so that consistency of identifiers collected by handshaking sent successively by the same browser is ensured, and an effect of accurately identifying the same browser is achieved.
It is to be understood that the above ordering manners agreed by the ordering rules may be adopted alternatively or in total, and an exemplary ordering for the features collected from the handshake messages of the sample browser may be, for example: the encryption algorithm numbers included in the encryption sockets of the target browser are sequenced according to the length of the encryption algorithm codes; filtering domain name features from an extension field of a target browser, and sequencing the remaining features in the extension field according to type values; arranging the following characteristics of the target browser in sequence: the protocol version number, the maximum protocol version number supported, the ordered ciphered sockets, the number of ciphered sockets, the ordered extension fields and the number of extension types are used.
In step 105, the server combines the ranked features into an identification of the corresponding sample browser.
In some embodiments, the ranked plurality of types of features of the sample browser are concatenated into a string, with the string being the identity of the sample browser.
In other embodiments, after the server connects the sorted features of the multiple types of the sample browser into the character string, since the length of the character string inevitably differs according to the type of the target browser, this will cause the identifier matching operation in the identifier matching stage to consume a large amount of computing resources, and for this case, the server may convert the character string into a hash value of a specific length through a hash function, for example, into a hash value of 128-bit length through a 128-bit hash function, or into a hash value of 64-bit length through a 64-bit hash function, so as to significantly save the computing resources consumed by the identifier matching operation in the identifier matching stage.
In step 106, the server stores the identity of the sample browser in an identity repository.
In some embodiments, the identifiers of the sample browser may be arranged in an ordered manner with the position of the characters in a character table (e.g., a table of ordered arrangements of numbers and letters) to improve the matching efficiency of the identifier matching stage.
For example, assume that the arrangement order of characters in the character table is: the numbers 0-9, the lower case letters a-Z, the upper case letters a-Z. The identifiers of the 4 sample browsers are sequentially: sBKiGwBD, UXhPT5HL, 5zmQft2F, and IkhQWSIm. The sequence in the tag library is: 5zmQft2F, sBKiGwBD, IkhQWSIm and UXhPT5 HL.
In some embodiments, after the identities of the server sample browser are stored in the identity repository, the identities in the identity repository may be classified into normal browsers and abnormal browsers periodically or aperiodically in step 107, and when the sample browser belongs to a normal browser, the identities of the normal browsers are stored in a white list of the identity repository in step 108, and the identified browsers in the white list are allowed to establish a secure connection with the server; and when the sample browser belongs to the abnormal browser, storing the identifier of the abnormal browser into a blacklist in an identifier library, wherein the browser corresponding to the identifier in the blacklist is refused to establish a secure connection with the server.
In some embodiments, in which the sample browsers are classified into normal browsers and abnormal browsers, the server determines distribution densities of different types of sample browsers, determines a sample browser corresponding to a type having a distribution density smaller than a type distribution density threshold as an abnormal browser, and determines a sample browser corresponding to a type having a distribution density larger than a type distribution density as a normal browser.
Taking three different types of sample browsers T1, T2 and T3 as examples, respectively counting the distribution densities of the three types of sample browsers in the identification library, and if the distribution density of the T1 type of sample browser is smaller than a distribution density threshold value, determining that the T1 type of sample browser belongs to an abnormal browser.
In other embodiments of classifying the sample browser into a normal browser and an abnormal browser, the server may determine the sample browser corresponding to the version with the distribution density smaller than the threshold of the distribution density of the version as the abnormal browser, and determine the sample browser corresponding to the type with the distribution density larger than the distribution density of the version as the normal browser.
Taking the same sample browser with three versions of V1, V2 and V3 as an example, respectively counting the distribution densities of the three versions in the identification library, and if the distribution density of the sample browser of the V1 version is smaller than a distribution density threshold value, determining that the sample browser of the V1 version belongs to an abnormal browser.
In some embodiments, the server may also perform a validity management operation on the identifiers in the identifier repository in step 109, thereby ensuring the validity of the identifiers in the identifier repository.
For example, when the server stores the collected identifier in the identifier library, the collection time of the identifier may be recorded in the identifier library, a uniform expiration time (for example, 30 days after collection) is set, or differentiated expiration times are set for different versions of different types of browsers and the same type of browser, the expiration time is negatively correlated with the issued time of the browser and positively correlated with the number of active users of the browser, and the identifier is deleted after the expiration time arrives.
The following is a continued description of a scheme in which the server performs normal/abnormal browser recognition based on the identifier of the browser in the identifier matching stage, and controls the behavior of the secure connection of the browser according to the recognition result. It should be pointed out that the identifier collection stage and the identifier stage do not have a mutual exclusion relationship on the time axis, and the two stages can be crossed, completely overlapped or completely separated, for example, the identifier collection can be performed for a period of time to make available identifiers in the identifier library, and then the operations of identifier collection and identifier matching are performed simultaneously, so that the identifiers in the identifier library are continuously enriched on one hand, and on the other hand, the browser can be timely identified and the safe connection behavior of the browser can be controlled based on the identifier library; or, firstly, acquiring the identifiers for a period of time to enable enough identifiers to be available in the identifier library, then stopping acquisition, carrying out matching operation based on the identifiers in the identifier library to identify the browser, and controlling the safe connection behavior of the browser according to the identification result.
The processing that the server acquires the identifier of the sample browser in the identifier acquisition stage and stores the identifier in the identifier library has been described so far, and a scheme that the server identifies the target browser based on the identifier library in the identifier matching stage and controls the behavior of the secure connection of the target browser according to the identification result is described below.
Referring to fig. 4, fig. 4 is an optional flowchart of a method for processing a browser identifier according to an embodiment of the present invention, and the following exemplary application scenarios of the server are described in conjunction with the steps shown in fig. 4: when the target browser needs to establish a secure connection with the server to request the server to issue verification data, the verification data is executed to present a verification interface, a verification code input by a user on the verification interface is submitted to the server to request the server to authorize login or authorize use of sensitive services in the target browser, the server identifies the target browser in a mode of matching the acquired identification of the target browser with an identification library, and the secure connection behavior of the target browser is controlled according to the identification result of a normal browser or an abnormal browser.
In step 201, when the target browser needs to be switched to the login state, or when the target browser in the login state needs to run a sensitive service, a handshake message for establishing a secure connection is sent to the server.
Taking the example that the target browser needs to be switched to the login state, the target browser presents a login interface to receive login information (including a user account and a password) input by a user, and the target browser needs to implement a verification interface in the login interface to perform living body detection.
Taking the target browser operating in the login state (i.e. the target browser has logged in the server based on the user account and the password) as an example, after the target browser logs in the server, the connection between the target browser and the server may be switched to an unencrypted connection (i.e. an insecure connection, such as an HTTP-based connection), when the user needs to use a sensitive function (e.g. an electronic payment function, an account logout function, a batch data deletion function, etc.) in the target browser, the target browser needs to execute authentication data to implement an authentication interface, for this reason, the server sends a handshake message to request to reestablish a secure connection with the server, and the secure connection is used to receive the authentication data issued by the server.
In step 202, the server parses the field data encapsulated by the handshake message to obtain the characteristics of multiple types of the target browser.
In some embodiments, the server parses out the following field data encapsulated by the handshake message: the number of the protocol version number used by the target browser, the maximum protocol version number supported by the target browser, the encrypted sockets used by the target browser, the number of the encrypted sockets, the number of the extension fields and the number of the extension types; and extracting corresponding information from the analyzed field data as the characteristics of the target browser. The technical details of parsing the handshake message, which are not exhaustive, can be understood with reference to the foregoing step 103.
In step 203, the server ranks the plurality of types of features of the target browser.
In some embodiments, the server sorts the features of the multiple types of the target browser based on a consistent sorting manner in the identifier collection phase, that is, the server sorts the features of the multiple types according to a sorting order of the features of the multiple types agreed by a sorting rule. Due to the fact that the sorting mode which is consistent with the identification collecting stage is adopted for sorting, for the same browser, the consistency of the identification formed by the identification collecting stage and the identification matching stage aiming at the handshake collecting is guaranteed, and therefore the browser can be accurately identified.
In step 204, the server combines the sorted features into an identifier of the corresponding target browser.
In some embodiments, the server concatenates the sorted multiple types of features of the target browser into a string, with the string as the browser's identification. In other embodiments, after the server concatenates the sorted multiple types of features of the target browser into a string, the string is converted into a hash value of a specific length by a hash function to reduce the computational resources of the subsequent identification matching operation.
In step 205, the server matches the identifier of the target browser with the identifiers in the white list and the black list in the identifier library, and if the identifier matches the black list, which indicates that the target browser is an abnormal browser (e.g., a non-browser such as automaton software), in step 206, a handshake failure message is sent to the target browser to refuse to establish a secure connection with the target browser.
If the white list is matched in step 205, the server completes a handshake procedure with the target browser to negotiate an encryption algorithm used in the secure connection data transmission procedure and a random number for generating a key in step 207, and generates the key using the random number as a key seed.
The following describes, by way of example, steps of when the target browser sends a handshake message in step 201, and the server completes a subsequent handshake process with the target browser through step 207, referring to fig. 5, where fig. 5 is an optional flowchart of the handshake process between the target browser and the server according to the embodiment of the present invention, and is described with reference to the steps shown in fig. 5.
In step 2071, the server receives a handshake message (Client Hello message) sent by the target browser.
The handshake message sent by the target browser includes information such as a Random number (denoted as Random1) generated by the target browser, encrypted sockets supported by the browser (Support peripherals), a protocol Version number being used (SSL Version), a maximum protocol Version number supported, an extension field, and an extension field type.
In step 2072, the server sends a handshake message to the target browser.
The handshake message sent by the server selects a supported encryption algorithm from the socket supported by the target browser, i.e. a specific algorithm for subsequent encryption and digest generation, and further includes a Random number (denoted as Random2) generated by the server.
In step 2073, the server will send the certificate to the target browser.
The server first sends the server's certificate to the target browser, and then in turn sends the certificate of the certificate authority for the server's certificate.
In step 2074, the target browser verifies the identity of the server according to the received certificate, generates a new Random number (denoted as Random3) and encrypts to generate a preliminary master Key (PreMaster Key).
The target browser firstly uses the certificate of the certification authority to verify the integer legality of the server, and takes out the public Key in the certificate of the server after the verification is passed, so as to generate a Random number Random3, and the Random number Random3 is encrypted by using the public Key to obtain a PreMaster Key.
In step 2075, the target browser sends the generated preliminary master Key PreMaster Key to the server.
In step 2076, the server decrypts the provisioning key with the private key to obtain the Random number Random3 generated by the target browser.
To this end, the target browser and the server each hold three Random numbers Random1, Random2, and Random 3.
In step 2077, the target browser and the server use the same algorithm to calculate the key from the three held random numbers.
For example, the target browser and the server calculate three random numbers based on the same encryption algorithm (i.e., the algorithm selected by the server in step 2072) to obtain the key.
In step 2078, the target browser encrypts the handshake message received by the server in step 2071 with a key and transmits the encrypted handshake message to the server.
The browser generates a digest of the handshake message received by the server in step 2071, encrypts the digest with the key generated in step 2077, and transmits the digest to the server.
In step 2079, the server decrypts the received encrypted handshake message and, if the decryption is successful, confirms that the keys generated in step 2077 are consistent.
In step 20710, the server encrypts the handshake message transmitted in step 2072 with a key and transmits the encrypted handshake message to the server.
The server generates a digest of the handshake message transmitted in step 2072, encrypts the digest with the key generated in step 2077, and transmits the encrypted digest to the target browser.
In step 20711, the target browser decrypts the received encrypted handshake message using the key generated in step 2077, and if the decryption is successful, confirms that the keys generated in step 2077 are consistent.
The target browser and the server have completed the key agreement process, and the subsequent key is used to encrypt the data to be transmitted and to decrypt the received encrypted data.
Continuing with the description of step 206 and step 207 above, when it is determined that the identifier of the target browser matches the white list in the identifier library through step 206 and a random number of the key is obtained through negotiation in step 207 and the key is generated according to the random number, the target browser sends a verification data request to the server in step 208, and the server responds to the verification data request, encrypts the verification data through the key, and sends the encrypted verification data to the target browser in step 209.
In step 210, the target browser decrypts the verification data according to the key and executes the verification data to form a verification interface, wherein the verification interface can adopt the above various forms of in vivo detection; in step 211, the target browser sends the verification code input by the user on the verification interface to the server for verification, and it is understood that the login data may also be sent to the server through the secure connection for the login scenario of the target browser.
In step 212, the server compares the verification code with a correct verification code corresponding to the issued verification data, if the verification code is consistent with the correct verification code, the server judges the application scene in step 213, if the verification is judged to belong to the application scene logged in by the target browser, the login information submitted by the target browser is continuously verified, if the verification is successful, the target browser is set to be in a login state based on the submitted login information in step 214A so as to authorize the login of the target browser, otherwise, error information is returned to the target browser; if it is determined in step 213 that the application scenario belonging to the target browser running the sensitive service, the target browser is authorized to use the sensitive service in step 214B.
And when the comparison in the step 212 is inconsistent, returning to the step 209 to issue new verification data to the target browser through the secure connection until the verification is successful according to the verification code submitted by the target browser, and correspondingly executing the step 214A or the step 214B, when the number of continuous verification failures reaches the threshold of the number of verification times, sending a handshake failure message to the target browser in a step 215 to refuse to establish the secure connection with the target browser. In addition, a freezing time (e.g. one hour of day) for shielding the handshake message responding to the target browser may be set, and the handshake message within the freezing time of the target browser will not be responded by the server to avoid malicious user login or use of sensitive services by malicious users.
In the following, taking a scenario of issuing a verification code of a server as an example, when the server issues the verification code to a browser, it is necessary to identify whether the browser is a browser or a non-browser, such as automaton software, and only issue the verification code to the browser, and refuse to issue the verification code to the non-browser is described as an example. And the browser and the server acquire the fingerprint of the browser to form a fingerprint library based on the handshake process of the TLS.
The related technicians provide a fingerprint identification implementation method of a crawler system built in a browser, which comprises the following steps: the browser sends a request command to the server; the server sends response information to the browser; the browser generates the fingerprint information from the basic attribute information of the browser according to the fingerprint information generation logic and sends the fingerprint information to the server; when the server judges that the corresponding browser is in the blacklist of the server according to the fingerprint information, the sending of the response content corresponding to the request command is stopped; and the crawler system modifies the basic attribute information of at least one browser, and the browser generates new fingerprint information and sends the new fingerprint information to the server.
The related art generates fingerprint information by using the basic attribute information of the browser, and cannot adapt to the condition that data is tampered: 1. all information collected by the browser can be forged, so that fingerprint information is wrong; 2. the basic attribute information is not complete enough, so that the generated fingerprint information has conflict.
In view of the above problem, referring to fig. 6, fig. 6 is an optional flowchart of the server for collecting the browser fingerprint according to the embodiment of the present invention, which is described below with reference to fig. 6.
In step 301, when each browser initiates a handshake message of an HTTPS request to a link of a server, the server extracts data of a handshake message (Client Hello message) packet from TCP layer data, and according to the RFC protocol, a TLS packet whose first byte is 22 and third byte is 1 in the TCP layer data is a packet of the handshake message.
In step 302, according to the encapsulation structure of the data packet of the handshake message, the following features are extracted from the data packet of the handshake message: protocol version number (protocol version) used by the browser, maximum version number (ClientHello _ protocol version) supported by the browser, encrypted socket (CipherSuite), number of encrypted sockets, and number of extension types.
In step 303, the server sorts the socket and extension fields.
For the CipherSuite field, refer to fig. 7, and fig. 7 is a schematic structural diagram of the CipherSuite field extracted by parsing the Client Hello message according to the embodiment of the present invention, where the CipherSuite field is composed of a plurality of encryption algorithms, and since there is no order in data of the CipherSuite field, the encryption algorithms indicated by numbers of every four bytes are sorted in an ascending order according to a length of an encoding of the encryption algorithm (the encoding is 16 systems).
For an extension field, which contains multiple extension types, each extension includes three fields: type (integer), length (number length) and content, thus being a character string, filtering out content (representing domain name value) with a type value of 0, avoiding the situation that fingerprints generated based on the same browser client hello package are inconsistent, and sequencing the rest of content according to the order of the type value from small to large.
In step 304, the server concatenates all the features of the handshake message (including protocol version number, ordered sockets, and extension fields) into a string, forms a browser fingerprint of the handshake message that sent the HTTPS request, and stores the browser fingerprint in the fingerprint repository.
In step 305, the server determines whether all the fingerprints of the browsers have been collected, if so, the process is ended, otherwise, the process returns to step 301 to continue collecting the fingerprint of the next browser.
Through the fingerprint library of the browser formed in the steps 301 to 305, the fingerprints extracted from the handshake message which subsequently receives the HTTPS request can be compared, if the comparison is consistent, the HTTPS request of the normal browser is determined, otherwise, the HTTPS request of the non-browser is determined, and when the server is provided with the HTTPS request which only responds to the normal browser, the identified HTTPS request of the non-browser is considered to belong to a malicious request and is rejected, so that the access traffic to the server is guided to the browser as an access path.
In some embodiments, the server may establish a white list in the fingerprint repository, where HTTPS requests for browsers located in the white list will be responded to and HTTPS requests for browsers located in the black list will be denied.
As an example of establishing the white list, the server may be distributed according to the types of the browsers (the browsers may carry the type user-agent of the browsers in the header of the data packet sending the handshake message), for example, using a browser with a smaller proportion (smaller than a proportion threshold value) and an old version (lower than a stubborn threshold value), a black list based on the fingerprints of the corresponding browsers may be established; using a proportionally high (proportion greater than proportion threshold), version new (version number greater than version number threshold) browser may build a whitelist based on the corresponding browser fingerprint.
Of course, there may be other ways to detect normal/abnormal browsers to collect corresponding fingerprints, for example, running various types of browser samples on different machines, collecting behavior data in normal use environments, and extracting behavior features as a basis for subsequently distinguishing normal/abnormal browsers; as another example, based on the data of the user, a normal user/abnormal user is identified, and a white list/black list of the browser fingerprint of the corresponding user is established.
The browser-based fingerprint library illustrates the following application scenarios: the robot software simulation browser (the browser can be a browser, and can also be various other browsers with built-in browser cores, such as a social network browser) exists at present, attempts are made to cheat a server to perform authentication through an authentication code of the server so as to perform secure connection with the server, potential threats are caused to data security of both the server and a user due to various extended functions of a third party possibly being implanted in the robot software, and the request behavior of using a non-browser to replace the secure connection of the browser is forbidden, so that great significance is brought to the security and technical upgrading of services.
Continuing with the example of fig. 1, the above-mentioned identifier library of browser fingerprints formed by the server 200 illustrates a scheme for distinguishing a browser from a non-browser and limiting a request behavior of a secure connection of the non-browser.
Referring first to fig. 8A, fig. 8A is a schematic view of a scenario in which a browser requesting a secure connection is identified as a browser according to an embodiment of the present invention, and in an identifier collection phase, a server 200 collects corresponding identifiers for browsers of multiple samples (each terminal 400 runs one sample browser) and stores an identifier library 500. In the identification matching stage, when the browser 410-1 operated by the terminal 400-1 accesses a service domain name, the terminal needs to switch to a login state, a handshake message of a security request is sent to the server 200, the server 200 extracts the identification of the browser 410-1 according to the received handshake message, and matches the identification in the identification library 500, because the server 200 adopts the same fingerprint acquisition mode (including the sorting mode of the features in the handshake message, the sequence of the algorithms in the encrypted sockets, the sequence of the contents in the extension fields, and the random factors such as the domain name are filtered) in the identification acquisition stage and the identification matching stage, the server 200 can match the identification of the browser 410-1 in the identification library 500, so that the browser is identified as a normal browser, and the browser 410-1 completes the handshake process to encrypt the algorithms and the keys in a protocol, the encrypted authentication data is sent to the browser 410-1 for the browser to execute the authentication data to realize an authentication interface, the login information and the authentication code are submitted to the server 200 for authentication, and when the server 200 passes the authentication, the authorization of the server 200 is obtained to enter the login state of the requested service domain name.
Referring to fig. 8B again, fig. 8B is a schematic view of a scenario in which a browser requesting security connection is recognized as a non-browser according to an embodiment of the present invention, and taking an example in which an automaton software sends a handshake message of a security request to the server 200, the server 200 acquires a corresponding identifier through the handshake message, and matches the identifier in the identifier library 500, because the automaton software is not an object acquired by an identifier in an identifier acquisition stage, the identifier cannot be stored in the identifier library 500, so that the server 200 fails to match, the automaton software is recognized as an abnormal client, and a handshake rejection message and an error cause (a non-browser environment login service domain name) are sent to the automaton software, so that a user is transferred to a browser environment login.
As can be seen from the above example, the identifier extracted from the handshake message of the browser can effectively limit the request behavior of the secure connection of the abnormal browser, ensure the security and technology upgrade of the service of the server, and effectively guide the abnormal access traffic of the server to the normal access traffic.
Continuing with the exemplary structure of the browser identification processing device 255 as a software module provided by the present invention, in some embodiments, as shown in fig. 2, the software module stored in the securely connected processing device 255 of the memory 250 may include: a secure connection module 2551 for: receiving a handshake message which is sent by a target browser and used for requesting to establish a secure connection with a server; matching the identification of the target browser with the identification in the identification library; responding to the handshake message of the target browser according to the matching result; an identity management module 2552 to: analyzing field data encapsulated by the handshake messages to obtain characteristics of multiple types of the target browser; and sequencing the characteristics of the multiple types of the target browser, and combining the sequenced characteristics into an identifier corresponding to the target browser.
In some embodiments, the identity management module 2552 is further configured to: the following field data encapsulated by the handshake message are parsed out: the number of the protocol version number used by the target browser, the maximum protocol version number supported by the target browser, the encrypted sockets used by the target browser, the number of the encrypted sockets, the number of the extension fields and the number of the extension types; and extracting corresponding information from the analyzed field data as the characteristics of the target browser.
In some embodiments, the identity management module 2552 is further configured to: sequencing the encryption algorithms included in the encrypted sockets of the target browser according to the length of the encryption algorithm codes; filtering domain name features from an extension field of a target browser, and sequencing the remaining features in the extension field according to type values; arranging the following characteristics of the target browser in sequence: the protocol version number, the maximum protocol version number supported, the ordered ciphered sockets, the number of ciphered sockets, the ordered extension fields and the number of extension types are used.
In some embodiments, the identity management module 2552 is further configured to: connecting a plurality of types of features of a target browser into a character string; and mapping the character string into a hash value with a specific length to serve as an identifier of the corresponding target browser.
In some embodiments, secure connection module 2551, is further configured to: when the identification of the target browser is matched with the white list in the identification library, finishing a handshake process with the target browser to negotiate an encryption algorithm and a key used in a safe connection data transmission process; and when the identification of the target browser is matched with the blacklist in the identification library, sending a handshake failure message to the target browser.
In some embodiments, secure connection module 2551, is further configured to: when the identification of the target browser is matched with a white list in an identification library and a key is obtained through negotiation, encrypting verification data through the key and sending the verification data to the target browser; receiving a verification code sent by a target browser, wherein the verification code is obtained by collecting verification operation after the target browser decrypts and executes verification data; when the verification code is decrypted by the secret key and the verification is passed, the target browser is authorized.
In some embodiments, the identity management module 2552 is further configured to: acquiring the identifier of each sample browser according to handshake messages which are sent by a plurality of sample browsers and used for establishing secure connection; determining the type of a sample browser as a normal browser or an abnormal browser; and when the sample browser belongs to the normal browser, storing the identifier of the normal browser into a white list of an identifier library, and when the sample browser belongs to the abnormal browser, storing the identifier of the abnormal browser into a black list in the identifier library.
In some embodiments, the identity management module 2552 is further configured to: analyzing field data encapsulated by the handshake messages sent by the sample browser to obtain characteristics of multiple types of the sample browser; and sequencing the characteristics of the multiple types of the sample browser in a mode consistent with that of sequencing the characteristics of the multiple types of the target browser, and combining the sequenced characteristics into an identifier corresponding to the sample browser.
In some embodiments, the identity management module 2552 is further configured to: determining the distribution density of different types of sample browsers, determining the sample browser corresponding to the type with the distribution density smaller than a type distribution density threshold value as an abnormal browser, and determining the sample browser corresponding to the type with the distribution density larger than the type distribution density as a normal browser; and/or determining the distribution density of sample browsers of different versions, determining the sample browser corresponding to the version with the distribution density smaller than the threshold value of the distribution density of the version as an abnormal browser, and determining the sample browser corresponding to the type with the distribution density larger than the distribution density of the version as a normal browser.
In some embodiments, the identity management module 2552 is further configured to: when inquiring that the network has any one of the new protocol version and the release information of the encryption algorithm, starting the operation of collecting the identifier of the sample browser, and stopping the operation of collecting the identifier of the sample browser when collecting enough updated identifiers to enable the proportion of the updated identifiers in the identifier library to exceed the update proportion threshold value or the quantity of the collected updated identifiers to exceed the update quantity threshold value.
In some embodiments, the identity management module 2552 is further configured to: and starting the operation of acquiring the identifier of the sample browser during the period that the load is lower than the load threshold, and stopping the operation of acquiring the identifier of the sample browser during the period that the load is higher than the load threshold.
In some embodiments, the identity management module 2552 is further configured to: and detecting the type and/or version of a source browser sending a handshake message for establishing the secure connection, and identifying the source browser as a sample browser when the number of identifications of the sample browsers of corresponding types and/or versions in the identification library does not accord with a uniform distribution condition.
Embodiments of the present invention also provide a storage medium storing executable instructions, where the executable instructions are stored, and when executed by a processor, will cause the processor to execute a method for providing a browser identifier according to an embodiment of the present invention, for example, a method for processing a browser identifier as shown in fig. 3 or fig. 4.
In some embodiments, the storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.
In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other module suitable for use in a computing environment.
By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).
By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.
In summary, according to the embodiments of the present invention, in order to solve the problem that the browsers using HTTPS requests all involve handshake messages, fingerprints are collected from the handshake messages, so that the problem that all information collected by the browsers can be forged, which causes fingerprint information errors, is solved, and the problem that generated fingerprint information conflicts due to incomplete basic attribute information of the browsers is solved.
The above description is only an example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims (15)

1. A method for processing browser identification is characterized by comprising the following steps:
receiving a handshake message which is sent by a target browser and used for requesting to establish a secure connection with a server;
when the version of the load data of the handshake message is updated, acquiring a browser identifier, updating the identifier in an identifier library based on the acquired browser identifier, and stopping acquiring the browser identifier according to the updating degree of the identifier in the identifier library;
analyzing the field data encapsulated by the handshake message to obtain the characteristics of multiple types of the target browser;
sorting the characteristics of the multiple types of the target browser, and combining the sorted characteristics into an identifier corresponding to the target browser;
matching the identification of the target browser with the identification in the identification library;
and when the identification of the target browser is matched with the white list in the identification library, finishing a handshake process with the target browser to negotiate a key used in the safe connection data transmission process.
2. The method of claim 1, wherein the parsing field data encapsulated by the handshake message to obtain a plurality of types of features of the target browser comprises:
the following field data encapsulated by the handshake message are analyzed: the number of the protocol version number used by the target browser, the maximum protocol version number supported by the target browser, the encrypted sockets used by the target browser, the number of the encrypted sockets, the number of the extension fields and the number of the extension types;
and extracting corresponding information from the analyzed field data as the characteristics of the target browser.
3. The method of claim 1, wherein the ranking the plurality of types of features of the target browser comprises:
sequencing the encryption algorithms included in the encrypted sockets of the target browser according to the coding length of the encryption algorithms;
filtering domain name features from the extension field of the target browser, and sequencing the rest features in the extension field according to type values;
arranging the following characteristics of the target browser in sequence: using a protocol version number, a maximum protocol version number supported, the ciphered sockets ordered, the number of ciphered sockets, the extension fields ordered and the number of extension types.
4. The method of claim 1, wherein the combining the ranked features into the identifier corresponding to the target browser comprises:
connecting the multiple types of features of the target browser into character strings;
and mapping the character string into a hash value with a specific length to serve as an identifier corresponding to the target browser.
5. The method of claim 1, further comprising:
and when the identification of the target browser is matched with the blacklist in the identification library, sending a handshake failure message to the target browser.
6. The method of claim 5, further comprising:
when the identification of the target browser is matched with the white list in the identification library and a key is obtained through negotiation, encrypting verification data through the key and sending the verification data to the target browser;
receiving a verification code sent by the target browser, wherein the verification code is obtained by collecting verification operation after the target browser decrypts and executes verification data;
when the verification code is decrypted by the secret key and verified, the target browser is authorized.
7. The method according to any one of claims 1 to 6, wherein before receiving the handshake message sent by the target browser for establishing a secure connection with a server, the method further comprises: acquiring the identifier of each sample browser according to handshake messages which are sent by a plurality of sample browsers and used for establishing secure connection;
determining the type of the sample browser as a normal browser or an abnormal browser;
and when the sample browser belongs to a normal browser, storing the identifier of the normal browser into a white list of the identifier library, and when the sample browser belongs to an abnormal browser, storing the identifier of the abnormal browser into a black list in the identifier library.
8. The method of claim 7, wherein determining the identity of each sample browser according to the handshake messages sent by the plurality of sample browsers for establishing the secure connection comprises:
analyzing field data encapsulated by the handshake messages sent by the sample browser to obtain characteristics of multiple types of the sample browser;
and sequencing the characteristics of the multiple types of the sample browser in a mode consistent with that of sequencing the characteristics of the multiple types of the target browser, and combining the sequenced characteristics into an identifier corresponding to the sample browser.
9. The method of claim 7, wherein the determining the type of the sample browser as a normal browser or an abnormal browser comprises:
determining the distribution densities of the different types of sample browsers, determining the sample browser corresponding to the type with the distribution density smaller than a type distribution density threshold value as an abnormal browser, and determining the sample browser corresponding to the type with the distribution density larger than the type distribution density as a normal browser; and/or
Determining the distribution density of the sample browsers with different versions, determining the sample browser corresponding to the version with the distribution density smaller than the threshold value of the distribution density of the version as an abnormal browser, and determining the sample browser corresponding to the type with the distribution density larger than the distribution density of the version as a normal browser.
10. The method of claim 7, wherein prior to collecting the identification of each sample browser, the method further comprises:
when inquiring that the network has any one of the new protocol version and the release information of the encryption algorithm, starting the operation of collecting the identifiers of the sample browser, and stopping the operation of collecting the identifiers of the sample browser when collecting enough updated identifiers to enable the proportion of the updated identifiers in the identifier library to exceed the update proportion threshold value or the quantity of the collected updated identifiers to exceed the update quantity threshold value.
11. The method of claim 7, wherein prior to collecting the identification of each sample browser, the method further comprises:
and starting the operation of the identification of the acquisition sample browser during the period that the load is lower than the load threshold value, and stopping the operation of the identification of the acquisition sample browser during the period that the load is higher than the load threshold value.
12. The method of claim 7, wherein prior to collecting the identification of each sample browser, the method further comprises:
detecting the type and/or version of a source browser sending a handshake message for establishing a secure connection, and identifying the source browser as a sample browser when the number of identifications of sample browsers of corresponding types and/or versions in the identification library does not accord with a uniform distribution condition.
13. A securely connected processing device, comprising:
a secure connection module to:
receiving a handshake message which is sent by a target browser and used for requesting to establish a secure connection with a server; matching the identification of the target browser with the identification in an identification library; when the identification of the target browser is matched with the white list in the identification library, finishing a handshake process with the target browser to negotiate a key used in the safe connection data transmission process;
the identifier management module is configured to:
when the version of the load data of the handshake message is updated, starting the collection operation of the browser identifier so as to update the identifier in the identifier library based on the collected browser identifier; determining the time for stopping collecting the browser identification according to the updating degree of the identification in the identification library; analyzing the field data encapsulated by the handshake message to obtain the characteristics of multiple types of the target browser; and sequencing the characteristics of the multiple types of the target browser, and combining the sequenced characteristics into an identifier corresponding to the target browser.
14. An electronic device, comprising:
a memory for storing executable instructions;
a processor, configured to implement the method for processing the browser identifier according to any one of claims 1 to 12 when executing the executable instructions stored in the memory.
15. A storage medium having stored thereon executable instructions for causing a processor to perform a method of processing a browser identifier as claimed in any one of claims 1 to 12 when executed.
CN201910796788.4A 2019-08-27 2019-08-27 Browser identifier processing method and device, electronic equipment and storage medium Active CN111181912B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910796788.4A CN111181912B (en) 2019-08-27 2019-08-27 Browser identifier processing method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910796788.4A CN111181912B (en) 2019-08-27 2019-08-27 Browser identifier processing method and device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN111181912A CN111181912A (en) 2020-05-19
CN111181912B true CN111181912B (en) 2021-10-15

Family

ID=70657067

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910796788.4A Active CN111181912B (en) 2019-08-27 2019-08-27 Browser identifier processing method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN111181912B (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112100603B (en) * 2020-09-15 2022-06-14 福建天晴在线互动科技有限公司 Website combined graph verification code defense method and system
CN113556343B (en) * 2021-07-21 2022-01-11 江南信安（北京）科技有限公司 DDoS attack defense method and device based on browser fingerprint identification
CN114491318B (en) * 2021-12-16 2023-09-01 北京百度网讯科技有限公司 Determination method, device, equipment and storage medium of target information
CN114448706A (en) * 2022-02-08 2022-05-06 恒安嘉新（北京）科技股份公司 Single package authorization method and device, electronic equipment and storage medium
US20230421580A1 (en) * 2022-06-28 2023-12-28 Microsoft Technology Licensing, Llc Detecting and mitigating abusive network activity based on versioned browser usage

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571485A (en) * 2011-12-14 2012-07-11 上海交通大学 Method for identifying robot user on micro-blog platform
CN104580172A (en) * 2014-12-24 2015-04-29 北京奇虎科技有限公司 Data communication method and device based on https (hypertext transfer protocol over secure socket layer)
CN105553983A (en) * 2015-12-17 2016-05-04 北京海泰方圆科技股份有限公司 Webpage data protection method
CN107171906A (en) * 2017-05-19 2017-09-15 上海为然环保科技有限公司 A kind of intelligent domestic system of mobile terminal control
CN107835155A (en) * 2017-10-11 2018-03-23 飞天诚信科技股份有限公司 A kind of double authentication protection methods and device
CN109688210A (en) * 2018-12-14 2019-04-26 平安城市建设科技(深圳)有限公司 Track method, apparatus, server and the storage medium of user information
CN109995576A (en) * 2019-02-13 2019-07-09 平安科技（深圳）有限公司 Recognition methods, device and the storage medium of equipment for surfing the net, computer equipment

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103248631B (en) * 2013-05-27 2016-05-25 百度在线网络技术（北京）有限公司 Method, system and the browser of browser-cross identifying user identity
US20180047018A1 (en) * 2016-08-15 2018-02-15 Capital One Services, Llc Browser extension for field detection and automatic population and submission
CN108540509B (en) * 2017-03-01 2022-06-21 腾讯科技（深圳）有限公司 Processing method and device of terminal browser, server and intelligent terminal

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571485A (en) * 2011-12-14 2012-07-11 上海交通大学 Method for identifying robot user on micro-blog platform
CN104580172A (en) * 2014-12-24 2015-04-29 北京奇虎科技有限公司 Data communication method and device based on https (hypertext transfer protocol over secure socket layer)
CN105553983A (en) * 2015-12-17 2016-05-04 北京海泰方圆科技股份有限公司 Webpage data protection method
CN107171906A (en) * 2017-05-19 2017-09-15 上海为然环保科技有限公司 A kind of intelligent domestic system of mobile terminal control
CN107835155A (en) * 2017-10-11 2018-03-23 飞天诚信科技股份有限公司 A kind of double authentication protection methods and device
CN109688210A (en) * 2018-12-14 2019-04-26 平安城市建设科技(深圳)有限公司 Track method, apparatus, server and the storage medium of user information
CN109995576A (en) * 2019-02-13 2019-07-09 平安科技（深圳）有限公司 Recognition methods, device and the storage medium of equipment for surfing the net, computer equipment

Also Published As

Publication number Publication date
CN111181912A (en) 2020-05-19

Similar Documents

Publication Publication Date Title
CN111181912B (en) Browser identifier processing method and device, electronic equipment and storage medium
CN107770182A (en) The date storage method and home gateway of home gateway
CN112235266B (en) Data processing method, device, equipment and storage medium
CN108322416B (en) Security authentication implementation method, device and system
CN108616540B (en) Platform authentication method and system based on cross-platform encryption algorithm and declarative filtering authentication
CN110912877B (en) Data transmitting and receiving method and device based on IEC61850 model in transformer substation
CN113127914A (en) Electric power Internet of things data security protection method
CN116471109B (en) Data transmission method, system, first end and control equipment
CN114157434A (en) Login verification method and device, electronic equipment and storage medium
CN110858834B (en) User information transmission method, device, system and computer readable storage medium
CN110943992B (en) Entrance authentication system, method, device, computer equipment and storage medium
CN105577657A (en) SSL/TLS algorithm suite expansion method
CN110602133B (en) Intelligent contract processing method, block chain management device and storage medium
CN112073963A (en) Communication interaction data transmission method and device
CN113965425A (en) Access method, device and equipment of Internet of things equipment and computer readable storage medium
US20130283363A1 (en) Secure data transfer over an arbitrary public or private transport
CN116633725A (en) All-channel access gateway
US20150281187A1 (en) Key transmitting method and key transmitting system
US20220182229A1 (en) Protected protocol for industrial control systems that fits large organizations
CN112738751B (en) Wireless sensor access authentication method, device and system
CN112953711B (en) Database security connection system and method
CN110572352A (en) intelligent distribution network security access platform and implementation method thereof
CN108809927A (en) Identity identifying method and device
CN111049798B (en) Information processing method and device and computer readable storage medium
CN113810422A (en) Emqx browser architecture-based secure connection method for data of internet of things platform device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant