Using proxy certificates to ensure secure operation between the user's customers and cloud applications.

Abstract

The disclosed technology teaches how an inspection proxy operates regarding encrypted sessions between users within an organization that are serviced by the inspection proxy and cloud-based services that the users access. The method includes providing an inspection proxy that includes an intermediate certificate authority (CA) that holds a certificate recognized by a browser operated by a user within the organization as having the authority to sign end-entity certificates by being chained with a root certificate recognized by the browser.

Description

Technical Field

[0001] [Cross-reference] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 459,519, entitled "Using Proxy Certificates For Operating Securely Between Users’ Customers And Cloud Apps", filed on April 14, 2023 (Attorney Docket No. NSKO 1063-1). [Incorporation by Reference]

[0002] The following materials are incorporated herein by reference.

[0003] Federal Information Processing Standard (FIPS) Publication 140-2, "Security Requirements for Cryptographic Modules", issued on May 25, 2001.

[0004] U.S. Patent Application No. 14 / 198,499, entitled "Security for Network Delivered Services", filed on March 5, 2014 (Attorney Docket No. NSKO 1000-2) (now U.S. Patent No. 9,398,102, issued on July 19, 2016).

[0005] U.S. Patent Application No. 14 / 198,508, entitled "Security for Network Delivered Services", filed on March 5, 2014 (Attorney Docket No. NSKO 1000-3) (now U.S. Patent No. 9,270,765, issued on February 23, 2016).

[0006] U.S. Patent Application No. 14 / 835,640, titled "Systems and Methods of Monitoring and Controlling Enterprise Information Stored on A Cloud Computing Service (CCS)" (Patent Reference Number NSKO 1001-2), filed on August 25, 2015 (currently U.S. Patent No. 9,928,377, issued on March 27, 2018).

[0007] U.S. Patent Application No. 15 / 368,240 (Agent Reference Number NSKO 1003-2), filed on December 2, 2016, entitled "Systems and Methods of Enforcing Multi-Part Policies on Data-Deficient Transactions of Cloud Computing Services" (currently U.S. Patent No. 10,826,940, issued on November 3, 2020). This U.S. Patent Application claims the interests of U.S. Provisional Application No. 62 / 307,305 (Agent Reference Number NSKO 1003-1), filed on March 11, 2016, entitled "Systems and Methods of Enforcing Multi-Part Policies on Data-Deficient Transactions of Cloud Computing Services".

[0008] U.S. Patent Application No. 15 / 368,246, titled "Middle Ware Security Layer for Cloud Computing Services" (Patent Reference Number NSKO 1003-3), filed on December 2, 2016 (now U.S. Patent No. 11,019,101, issued on May 25, 2021).

[0009] “Data Loss Prevention and Monitoring in the Cloud,” Netskope, Inc.

[0010] “The 5 Steps to Cloud Confidence”, Netskope, Inc.

[0011] "Netskope Active Cloud DLP", Netskope, Inc.

[0012] “Repave the Cloud-Data Breach Collision Course,” Netskope, Inc.

[0013] “Netskope Cloud Confidence Index(TM)”, Netskope, Inc. Company.

[0014] The disclosed technology generally relates to cloud-based data security, and more specifically, to acting as a proxy between a customer's users and cloud-based services when session encryption is based on root certificates signed by a public key infrastructure (PKI) certificate authority that is natively recognized by the browser. [Background technology]

[0015] The subject matter described in this section should not be considered prior art simply because it is mentioned in this section. Similarly, the issues mentioned in this section, or the issues related to the subject matter provided as background, should not be considered to have been previously recognized in the prior art. The subject matter in this section merely represents various approaches, and the approaches themselves may also correspond to implementations of the claimed technology.

[0016] Cloud-based computing and the demand for working anytime, anywhere are two factors accelerating the push towards comprehensive secure access service edge systems that address the need for secure data access from any device, anytime, anywhere.

[0017] Cybercriminals are turning to the cloud as an effective way to evade detection. Cyber ​​threats and patterns of malicious insiders are constantly evolving. Meanwhile, sensitive data is becoming increasingly dispersed and moving to applications that are not necessarily authorized or adequately protected. Security policies often need to be evaluated in real time for individual users, for example, when users upload or download files, browse websites, or access data in the cloud. Millions of critical decisions that impact the user experience need to be made daily.

[0018] Existing network security architectures were designed with the enterprise data center as the central point for access needs. On the other hand, IT architectures such as cloud and edge computing, as well as the ability to work from anywhere, result in an increase in users, devices, applications, services, and data that reside outside the enterprise rather than within it.

[0019] Few industries have changed as dramatically in recent years as financial services (FINSERV). Today, the vast majority of financial operations are managed digitally. Behind the scenes, banks, credit unions, insurance companies, mortgage companies, and others are working to transform their infrastructure to enhance security and operate more efficiently. Technologies designed to support cloud-based systems are the future of networking and security for improved secure data isolation.

[0020] An opportunity arises to manipulate inspection proxies to intercept encrypted sessions between users within an organization whose services are provided by the inspection proxy and the cloud-based services that those users access. Therefore, an opportunity also arises for proxies to intercept traffic from customer users to cloud-based services in order to improve risk detection.

[0021] In the drawings, like reference numerals generally refer to like parts throughout different views. Also, the drawings are not necessarily to scale; instead, generally emphasis is placed on illustrating the principles of the disclosed technology. In the following description, various implementations of the disclosed technology are described with reference to the following drawings.

Brief Description of the Drawings

[0022] [Figure 1] Illustrates a schematic diagram at the architecture level of a system for providing a proxy intermediate certification authority according to one implementation of the disclosed technology. [Figure 2] Shows a schematic diagram at the architecture level of a point of presence (PoP) of the data plane. [Figure 3] Shows a schematic diagram at the architecture level of a point of presence (PoP) of the management plane. [Figure 4] Illustrates an example of the hierarchical structure of TLS certificates, separated by region for the United States and the EU. [Figure 5] Illustrates a high-level block diagram of the interaction between a point of presence (PoP) of the management plane and a point of presence (PoP) of the data plane. [Figure 6] Illustrates how each proxy stores the key pair of the intermediate CA in the proxy memory. [Figure 7] Illustrates a proxy certificate signing request (CSR) sent to a customer's hardware security module (HSM). [Figure 8] Is a schematic diagram of a method for signing a customer certificate according to an example of a TLS certificate hierarchy including a proxy. [Figure 9] Illustrates an example of a certificate for a cloud-based service. [Figure 10]Illustrates a message flow diagram for operating an inspection proxy for an encrypted session between a user and a cloud-based service according to one implementation of the disclosed technology. [Figure 11] It is a simplified block diagram of a computer system that can be used to provide a proxy intermediate certification authority according to one implementation of the disclosed technology. **DETAILED DESCRIPTION OF THE INVENTION**

[0023] The following detailed description is made with reference to the figures. Exemplary implementations are described, which are for illustrative purposes of the disclosed technology and not for limiting its scope, which is defined by the claims. Those skilled in the art will recognize various equivalent variations of the following description.

[0024] Banks, credit unions, insurance companies, mortgage companies, etc. use TLS / SSL certificates in digital banking to protect customers' assets. Browsers utilize a trusted set of certification authorities. In one example, when no proxy is used for communication from the browser to bankamerica.com, bankamerica.com returns an X.509 certificate signed by a trusted institution. The X.509 certificate binds identification information to a public key using an electronic signature. The certificate contains identification information (host name, organization, or individual) and a public key (RSA, Digital Signature Algorithm (DSA), ECDSA, ed25519, etc.), and is signed by a Certification Authority (CA) or self-signed. When the certificate is signed by a trusted CA or verified by other means, the person possessing the certificate can use the public key contained in the certificate to establish secure communication with the other party or verify a document digitally signed with the corresponding private key.

[0025] Because today's financial operations are managed digitally, financial technologies and other systems leverage network security providers to protect customer data from countless security risks. Network security providers utilize proxies. Browsers map to the proxy, and proxies map to applications. In this scenario, the proxy creates its own CA and inserts that trusted CA into the browser's trusted CA list. Then, as a parallel example, when a user accesses bankamerica.com, the proxy CA signs a certificate proving that the proxy is bankamerica.com, establishing trust.

[0026] Customers are concerned about the protection of the CA used to sign certificates. For a proxy to be able to intercept TLS / SSL connections, the proxy must convince the client that it is trustworthy. The following summarizes aspects of the TLS / SSL security protocol.

[0027] Transport Layer Security (TLS), an evolution of Secure Sockets Layer (SSL), is an encryption-based internet security protocol that encrypts data transmitted over the web for communication between web applications, such as web browsers that load websites, and servers. TLS / SSL initiates an authentication handshake between two communicating devices, ensuring that both devices are truly what they claim to be. TLS / SSL also digitally signs the data to provide data integrity, verifying that the data has not been tampered with before reaching its intended recipient.

[0028] For a website or application to use TLS, a TLS certificate must be installed on the origin server to perform authentication and data encryption functions. First, the certificate can help authenticate and verify the identity of the host or site. A TLS certificate contains information about the authenticity of details about the host or site's identity. Therefore, when you click the displayed padlock icon or check the trust mark, the details of the certificate chain prove where the certificate originated. Second, the certificate enables the encryption of information exchanged through the website. If the data in transmission is encrypted, sensitive information exchanged through the website cannot be intercepted and read by anyone other than the intended recipient.

[0029] A Certificate Authority (CA), also known as a Master CA in this specification, is an entity that issues digital certificates, such as DigiCert (one of 100 different Certificate Authorities). A CA issues TLS certificates to individuals or companies that own domains. This certificate contains important information about who owns the domain, along with the server's public key, both of which are crucial for verifying the server's identity. TLS / SSL certificates are most reliable when issued by a trusted CA that adheres to strict rules and policies regarding who can and cannot receive them. Therefore, obtaining a valid TLS / SSL certificate from a trusted CA provides a higher level of confidence. A digital certificate proves ownership of a public key by the entity listed on the certificate. Once a CA signs a TLS / SSL certificate, or another entity verifies them, the certificate's owner can use the public key to establish a secure connection with others or use the corresponding private key to verify documents digitally signed by someone else.

[0030] A network proxy for SSL connections must be able to decrypt and inspect the traffic. To enable inspection of traffic within an SSL connection, the proxy must act on behalf of the server, ensuring that the user's browser accepts that the proxy certificate is valid (i.e., signed by a trusted tier at the endpoint). The disclosed solution provides a proxy intermediate certificate authority on behalf of the customer, which is authorized (by the customer's intermediate CA authority) to sign subordinate certificates and holds a CA certificate chained with a certificate approved by the customer as the root certificate. In one implementation, if the organization's browser is used by users within the organization, that organization has an organizational CA responsible for generating the organizational CA certificate as the root certificate chained with the intermediate CA certificate. In another implementation, the organizational browser is configured to trust an entity CA certificate generated by an entity separate from and not managed by the organization. This entity operates the inspection proxy for the encrypted sessions established by the inspection proxy, and the root certificate in this implementation is the entity CA certificate. The proxy intermediate certificate authority also holds the private key used to sign subordinate certificates.

[0031] The distribution of private keys is generally a difficult risk to defend against for data security, and is equally true for the provision of financial technology (FinTech) by financial services. Public keys are publicly available. Existing network security services hold private keys within proxies so that they can perform data decryption. If private keys are compromised, anyone can impersonate a customer on sites like salesforce.com or Google.com, potentially compromising security because CAs sign with trusted private keys.

[0032] Furthermore, existing data security solutions utilize data centers and multiple proxies within each data center. In one example, 50 data centers each have 8 to 10 proxies, resulting in up to 500 proxies within the system, each creating its own CA. In one implementation, the data center may even be physically located in Hong Kong, a special administrative region of China.

[0033] Existing digital banking security protocols use long-term validity periods of up to three years for Certificate Agencies (CAs), and a breach of these CAs creates a long-term vulnerability.

[0034] The disclosed solution utilizes short-term valid certificate signing requests (CSRs), which are valid for very short periods, such as one week. Furthermore, the disclosed solution stores the private key required to sign the CSR solely within a hardware security module (HSM), thus never crossing the "network boundary" (a secure hardware boundary). If information moves beyond the scope of one HSM processing unit to another, it crosses the boundary. Even with an HSM, potential security threats from insiders still exist.

[0035] The disclosed technology solves the technical problem of operating the inspection proxy for encrypted sessions between users within an organization who receive services through the inspection proxy and the cloud-based services that the users access. Below is an example of a system that provides an inspection proxy that includes an intermediate certificate authority (CA) that holds a Certificate Authority (CA) certificate that a browser operated by a user within an organization recognizes as having the authority to sign end-entity certificates.

[0036] Here, the organization may also be referred to as the tenant. The browser operated by the user may be referred to by the browser itself as the organization browser, tenant browser, or browser, or by the user as the user or client. Throughout the description of the diagrams, certain terms have been replaced with synonyms considering the specific context, thereby making the details clearer. Nevertheless, the disclosed technology should be understood to generally refer to entities (which are different from and not controlled by the organization) that operate at least one inspection proxy between the organization browser and client (i.e., the user) and cloud-based resources. Here, the organization browser is used by users within the organization, and the organization has an organization CA. [architecture]

[0037] Figure 1 shows a schematic architectural diagram of system (100) for providing a proxy intermediate certificate authority. System (100) also includes the ability to interoperate with single sign-on (SSO) solutions and / or corporate identity directories. As Figure 1 is an architectural diagram, certain details are intentionally omitted to enhance clarity of explanation. A detailed explanation of Figure 1 is structured as follows: First, the elements of the diagram are described, followed by a description of their interconnections. Next, the use of the elements in the system is described in more detail.

[0038] The system (100) includes an organizational network (102), a data center (152) including a Secure Access Service Edge (SASE) system (153) with a security stack (154), a Netskope Cloud Access Security Broker (N-CASB) (155), and cloud-based services (108). The SASE system (153) includes network security functionality N-CASB (155), as well as a fusion of Secure Web Gateway (SWG), Zero Trust Network Access (ZTNA), Virtual Private Network (VPN), and Software-Defined Wide Area Networking (SD-WAN) functionality (omitted for clarity). The organizational network (102) includes computers (112a-n), tablets (122a-n), and mobile devices (132a-n). The system (100) includes multiple organizational networks (104) for multiple subscribers, also known as multi-tenant networks, and multiple data centers (156) for a security service provider. In other organizational networks, users of the organization may utilize additional devices. Cloud services (108) include cloud-based application hosting services (118), webmail services (128), video, messaging, and voice call services (138), streaming services (148), file transfer services (158), and cloud-based storage services (168). Data centers (152) connect to organizational networks (102) and cloud-based services (108) via public networks (145). Netscope Cloud Access Security Broker (N-CASB) (155) between cloud service consumers and cloud service providers intercepts this in combination with enterprise security policies when cloud-based resources are accessed.

[0039] Continuing the explanation of Figure 1, each security layer of the security stack (154) can detect problems. The enhanced Netskope Cloud Access Security Broker (N-CASB) (155) controls access and activity in authorized and unauthorized cloud applications, protects sensitive data and prevents its loss, and protects against internal and external threats, in addition to securely handling P2P traffic over BT, FTP, and UDP-based streaming protocols, as well as Skype, voice, video, and messaging multimedia communication sessions over SIP, and web traffic over other protocols. The N-CASB (155) includes an active analyzer (165) and an introspective analyzer (175) that identify users of the system and set policies for applications. The introspective analyzer (175) interacts directly with cloud-based services (108) to inspect data at rest. In polling mode, the introspective analyzer (175) calls cloud-based services using API connectors to traverse data inherent in the cloud-based services and check for changes. For example, the Box® storage application provides a management API called the Box Contents API®, which provides organizational account visibility for all users, including audit logs of Box folders. By inspecting this API, it is possible to determine whether any sensitive files were downloaded after a specific date when credentials were compromised. The Introspective Analyzer (175) polls this API to detect any changes made to any account. If a change is detected, the Box Events API® is polled to detect detailed data changes. In a callback model, the Introspective Analyzer (175) is registered with a cloud-based service via an API connector to be notified of any important events.For example, the Introspective Analyzer (175) can use the Microsoft Office 365 Webhooks API (trademark) to determine when a file was shared externally. The Introspective Analyzer (175) also has deep API inspection (DAPII), deep packet inspection (DPI), and login inspection capabilities, and includes a DLP engine that applies various content inspection techniques to files stored in cloud-based services, determining which documents and files are highly sensitive based on policies and rules stored within the storage (186). The results of the Introspective Analyzer (175) inspection generate per-user and per-file data. For further information regarding the functions of active analyzers and introspective analyzers, see, for example, the commonly owned U.S. Patent No. 9,398,102 (NSKO 1000-2), No. 9,270,765 (NSKO 1000-3), No. 9,928,377 (NSKO 1001-2), and U.S. Patent Application No. 15 / 368,246 (NSKO 1003-3).

[0040] Further explanation of Figure 1, N-CASB(155) further includes a monitor(184) which includes an extraction engine(171), a classification engine(172), a security engine(173), a management plane(174), and a data plane(180). The storage(186) included in N-CASB(155) also includes content policies(187), content profiles(188), content inspection rules(189), corporate data(197), client information(198), and user identification information(199). Corporate data(197) may include, but is not limited to, organizational data, including intellectual property, confidential financials, strategic plans, customer lists, personally identifiable information (PII) belonging to customers or employees, patient health data, source code, trade secrets, reservation information, partner agreements, corporate plans, merger and acquisition documents, and other confidential data. In particular, the term “corporate data” refers to documents, files, folders, web pages, collections of web pages, images, or any other text-based documents. User identification refers to an indicator provided to a client device by a network security system in the form of a token, a unique identifier such as a UUID, or a public key certificate. In some cases, user identification can be linked to a specific user and a specific device, and therefore the same individual may have different user identification on a mobile phone and a computer. User identification can be linked to an entry or corporate identity directory, but is distinct from that. In one implementation, a cryptographic certificate signed by the network security system is used as user identification. In other implementations, user identification is unique only to the user and can be identical across devices.

[0041] Further description of the system (100) in Figure 1, the embodiment can also interoperate with single sign-on (SSO) solutions and / or corporate identity directories (e.g., Microsoft's Active Directory (AD)). Such embodiments may use custom attributes to allow policies to be defined within the directory, for example, at either the group level or the user level. The hosting service configured by the system is also configured to require traffic through the system. This can be done by setting IP range restrictions within the hosting service to the system's IP range and / or through integration between the system and the SSO system. For example, integration with an SSO solution can enforce client presence requirements before authorizing sign-on. In other embodiments, a “proxy account” with the SaaS vendor may be used, for example, a dedicated account held by the system that holds the sole credentials for signing in to the service. In other embodiments, the client may encrypt the sign-on credentials before passing the login to the hosting service, meaning that the networking security system “owns” the password.

[0042] The storage (186) shown in Figure 1 can store information from one or more tenants in a common database image table to form an on-demand database service (ODDS), which can be implemented in many ways, such as a multi-tenant database system (MTDS). The database image can contain one or more database objects. In other implementations, the database can be a relational database management system (RDBMS), an object-oriented database management system (OODBMS), a distributed file system (DFS), a non-schema database, or any other data storage system or computing device. In some implementations, the collected metadata is processed and / or normalized. In some cases, the metadata includes structured data, and the functionality targets specific data structures provided by the cloud service (108). Unstructured data, such as free text, can also be provided by the cloud service (108) and target the cloud service (108) again. Both structured and unstructured data can be aggregated by the introspective analyzer (175). For example, assembled metadata can be stored in a semi-structured data format, such as JSON (JavaScript Object Notation), BSON (Binary JSON), XML, Protobuf, Avro, or Thrift objects, which consist of string fields (or columns) and corresponding values ​​of potentially different types, such as numbers, strings, arrays, and objects. JSON objects can be nested, and fields can have multiple values, such as arrays and nested arrays, in other implementations.These JSON objects are stored in schema-less or NoSQL key-value metadata stores (178) such as Apache Cassandra™, Google's Bigtable™, HBase™, Voldemort™, CouchDB™, MongoDB™, Redis™, Riak™, Neo4j™, etc., which store the parsed JSON objects using keyspaces equivalent to databases in SQL. Each keyspace is similar to a table and is divided into column families, which consist of sets of rows and columns.

[0043] In one implementation, the introspective analyzer (175) includes a metadata parser (omitted for clarity) that analyzes the input metadata to identify keywords, events, user IDs, locations, demographics, file types, timestamps, etc., in the received data. Parsing is the process of breaking down and analyzing a stream of text into keywords or other meaningful elements referred to as “targetable parameters.” In one implementation, the list of target parameters becomes input for further processing, such as parsing by a matching engine (not shown) or text mining. Parsing extracts meaning from the available metadata. In one implementation, tokenization acts as the first step in parsing to identify granular elements (e.g., tokens) in the stream of metadata, but parsing then proceeds to determine the meaning and / or type of information being referenced using the context in which the tokens were found. Because the metadata analyzed by the introspective analyzer (175) is not homogeneous (for example, many different sources exist in many different formats), certain implementations use at least one metadata parser per cloud service, and in some cases more than one. In other implementations, the introspective analyzer (175) uses a monitor (184) to inspect the cloud service and assemble content metadata. In one use case, the identification of sensitive documents is based on prior inspection of the documents. Users can manually tag documents as highly sensitive, and this manual tagging updates the document metadata in the cloud service. Document metadata can then be retrieved from the cloud service using a publicly available API and used as an indicator of sensitivity.

[0044] Continuing the explanation of Figure 1, the system (100) can include any number of cloud-based services (108), namely, point-to-point streaming services, hosting services, cloud applications, cloud stores, cloud collaboration and messaging platforms, and cloud customer relationship management (CRM) platforms. Services can include peer-to-peer (P2P) file sharing via protocols for portal traffic such as BitTorrent (BT), User Data Protocol (UDP) streaming, and File Transfer Protocol (FTP); voice, video, and messaging multimedia communication sessions, e.g., instant messaging over Internet Protocol (IP), and mobile phone calls over LTE (VoLTE) via Session Initiation Protocol (SIP) and Skype. Services can handle internet traffic, cloud application data, and Generic Routing Encapsulation (GRE) data. Network services or applications can be web-based (e.g., accessed via Unified Resource Location Specifier (URL)) or native, e.g., synchronous clients. Examples include Software as a Service (SaaS) offerings, Platform as a Service (PaaS) offerings, and Infrastructure as a Service (IaaS) offerings, as well as internal enterprise applications exposed via URLs. Common examples of cloud-based services today include Salesforce.com®, Box®, Dropbox®, Google Apps®, Amazon AWS®, Microsoft Office 365®, Workday®, Oracle on Demand®, Taleo®, Yammer®, Jive®, and Concur®.

[0045] In the interconnection of the elements of the system (100), the network (145) connects computers (112a-n), tablets (122a-n), mobile devices (132a-n), cloud-based hosting services (118), webmail services (128), video, messaging and voice call services (138), streaming services (148), file transfer services (158), cloud-based storage services (168), and N-CASB (155) to communicate. The communication path can be point-to-point over public and / or private networks. Communication can be conducted over various networks, e.g., private networks, VPNs, MPLS circuits, or the internet, and can use appropriate application programming interfaces (APIs) and data exchange formats, e.g., REST, JSON, XML, SOAP, and / or JMS. All communications can be encrypted. This communication generally takes place over networks such as LANs (Local Area Networks), WANs (Wide Area Networks), telephone networks (Public Switched Telephone Network (PSTN), Session Initiation Protocol (SIP), wireless networks, point-to-point networks, star networks, token ring networks, hub networks), and the internet (including mobile internet), using protocols such as EDGE, 3G, 4G LTE, Wi-Fi, and WiMAX. Furthermore, various authorization and authentication techniques, such as username / password, OAuth, Kerberos, SecureID, and digital certificates, can be used to protect the communication.

[0046] Continuing the description of the system architecture in Figure 1, N-CASB(155) includes monitors (184) and storage (186) which may include one or more computers and computer systems coupled to communicate with each other. They may also be one or more virtual computing and / or storage resources. For example, monitors (184) may be one or more Amazon EC2 instances, and storage (186) may be Amazon S3® storage. Rather than implementing N-CASB(155) directly on physical computers or traditional virtual machines, other computing as a service platforms such as Rackspace, Heroku, or Force.com from Salesforce can be used. Furthermore, one or more engines may be used, and one or more points of presence (POPs) may be established to implement security features. The engines or system components in Figure 1 are implemented by software running on various types of computing devices. Examples of devices include workstations, servers, computing clusters, blade servers, and server farms, or any other data processing systems or computing devices. Engines may be coupled to databases in a communicative manner via different network connections. For example, the extraction engine (171) can be connected via a network (or multiple network) (145) (e.g., the Internet), the classification engine (172) can be connected via a direct network link, and the security engine (173) can be connected via yet another network connection. In the disclosed technology, the data plane (180) POP is hosted on the client's premises or located within a virtual private network controlled by the client.

[0047] N-CASB(155) provides various functions via a management plane (174) and a data plane (180). The data plane (180) includes, in one implementation, an extraction engine (171), a classification engine (172), and a security engine (173). Other functions, such as a control plane, can also be provided. These functions together provide a secure interface between cloud services (108) and the organizational network (102). While the term "network security system" is used to describe N-CASB(155), more generally, the system provides not only security but also application visibility and control functions. In one example, 35,000 cloud applications reside in a library that crosses servers used by computers (112a-n), tablets (122a-n), and mobile devices (132a-n) within the organizational network (102).

[0048] Computers (112a-n), tablets (122a-n), and mobile devices (132a-n) within the organizational network (102) include, in one implementation, a management client having a web browser with a secure web delivery interface provided by N-CASB (155) for defining and managing content policies (187). Because N-CASB (155) is a multi-tenant system, in some implementations, users of the management client can only modify content policies (187) associated with their organization. In some implementations, an API can be provided for programmatically defining and / or updating policies. In such implementations, the management client may include one or more servers, for example, a server that is an enterprise identity directory such as Microsoft Active Directory (AD), or a server that implements an open Lightweight Directory Access Protocol (LDAP) to push updates, and / or a server that responds to pull requests for updates to content policies (187). Both systems can coexist; for example, some companies can use a corporate identity directory to automate user identification within their organization while simultaneously using a web interface to tailor policies to user needs. Management clients are assigned roles, and access to N-CASB(155) data is controlled based on these roles (e.g., read-only versus read / write).

[0049] In addition to periodically generating user-specific and file-specific data and persisting it in the metadata store (178), the active analyzer and introspective analyzer (not shown) also apply security policies to cloud traffic. For further information regarding the functionality of the Active Analyzer and Introspective Analyzer, please refer to, for example, the commonly owned U.S. Patent No. 9,398,102 (NSKO 1000-2), No. 9,270,765 (NSKO 1000-3), No. 9,928,377 (NSKO 1001-2), U.S. Patent Application No. 15 / 368,246 (NSKO 1003-3), Cheng, Ithal, Narayanaswamy and Malmskog, "Cloud Security For Dummies, Netskope Special Edition, John Wiley & Sons, Inc., 2015", Netskope, Inc., "Netskope Introspection", Netskope, Inc., "Data Loss Prevention and Monitoring in the Cloud", Netskope, Inc., "Cloud Data Loss Prevention Reference Architecture", and Netskope, Inc., "The 5 Steps to Cloud You can refer to "Confidence," Netskope, Inc.'s "The Netskope Active Platform," Netskope, Inc.'s "The Netskope Advantage: Three 'Must-Have' Requirements for Cloud Access Security Brokers," Netskope, Inc.'s "The 15 Critical CASB Use Cases," Netskope, Inc.'s "Netskope Active Cloud DLP," Netskope, Inc.'s "Repave the Cloud-Data Breach Collision Course," and Netskope, Inc.'s "Netskope Cloud Confidence Index (trademark)."These are incorporated herein by reference, as if they were fully described herein, for all purposes.

[0050] In the case of system (100), the control plane may be used together with, or instead of, the management plane (174) and the data plane (180). The specific division of functions between these groups is an implementation choice. Similarly, functions may be highly distributed across several points of presence (POPs) to improve locality, performance, and / or security. In one implementation, the data plane is located on-premises or on a virtual private network, and the management plane of the network security system is located in a cloud service or with the enterprise network, as described herein. In other secure network implementations, POPs may be distributed in different ways.

[0051] Although the system (100) is described herein with reference to specific blocks, it should be understood that these blocks are defined for illustrative purposes only and do not imply a specific physical arrangement of component parts. Furthermore, blocks do not need to correspond to physically different components. To the extent that physically different components are used, the connections between components can be wired and / or wireless as needed. Different elements or components can be combined into a single software module, and multiple software modules can run on the same processor.

[0052] Furthermore, this technology can be implemented using two or more separate and different computer implementation systems that cooperate and communicate with each other. This technology can be implemented in a variety of ways, such as a process, method, apparatus, system, device, computer-readable medium such as a computer-readable storage medium storing computer-readable instructions or computer program code, or a computer program product comprising a computer-usable medium in which computer-readable program code is embodied. The disclosed technologies can be implemented in connection with any computer implementation of a system, including, for example, a database system or relational database implementation, such as an Oracle®-compatible database implementation, an IBM DB2 Enterprise Server®-compatible relational database implementation, a MySQL® or PostgreSQL®-compatible relational database implementation, or a Microsoft SQL Server®-compatible relational database implementation, or a NoSQL non-relational database implementation, such as a Vampire®-compatible non-relational database implementation, an Apache Cassandra®-compatible non-relational database implementation, a BigTable®-compatible non-relational database implementation, or an HBase® or DynamoDB®-compatible non-relational database implementation.In addition, the disclosed technologies can be implemented using various programming models, such as MapReduce®, bulk synchronous programming, MPI primitives, or different scalable batch and stream management systems, such as Amazon Web Services (AWS)®, such as Amazon Elasticsearch Service®, and Amazon Kinesis®, Apache Storm®, Apache Spark®, Apache Kafka®, Apache Flink®, Truviso®, IBM Info-Sphere®, Borealis®, and Yahoo!S4®.

[0053] Figure 2 shows a schematic diagram of the architecture level of a data plane point of presence (POP). Figure 2 includes a data plane point of presence (205) (indicated by dashed and dotted lines) connected to networks A (252) and B (258). These may be the same network or different networks. Network A (252) is also connected to client devices such as mobile devices (132) and computers (112). Network B (258) is connected to cloud services (208). The functionality of the data plane is implemented according to one embodiment using multiple computers, storage, and network equipment spanning multiple POPs such as the data plane POP (205). Elements of the data plane POP (205) include a firewall (244), a secure tunnel gateway (234), a load balancer (245), multiple proxies (236, 256, and 266) (each inspection proxy executes policies according to its current configuration), and an outbound network address translation element - NAT (246). This architecture can be further extended, for example, by adding multiple firewalls. Inspection proxies (236, 256, 266) implement specific policies, such as drop, reset, redirect, and request (or entire flow), and also generate log messages. In this document, the terms "proxy" and "inspection proxy" are used synonymously and should be interpreted as such.

[0054] The data plane POP (205) also includes a configuration agent (224) for receiving configuration and policy information from the management plane, an event queue (225) for recording and / or storing events sent to the management plane, and a monitoring agent (226) for monitoring the performance and status of the data plane POP (205). These items generally communicate and combine with one or more management plane POPs, e.g., the management plane POP (305) shown later in Figure 3, and other elements of the data plane (not shown to focus on data flow). Similarly, the configuration system is also not shown here. The difference between configuration and policy is that configuration information is information provided by the operator of the network security system, e.g., how many data plane POPs to activate, which version of inspection proxy software to load, etc., while policy information is information provided by the system's administrative user, e.g., the company's IT personnel.

[0055] Figure 2 also shows an example of a secure tunnel (232) used by a mobile device (132) and other mobile clients. In contrast, data from a computer (112) is routed directly from the firewall (244) to the load balancer (245). Depending on the client type, some use a secure tunnel (used here for mobile devices), while others do not (used here for computers without a secure tunnel).

[0056] Figure 3 shows a schematic diagram of the management plane point of presence (PoP) at the architectural level. Figure 3 includes the management plane POP (305) for implementing management plane functions. Some implementations have only one management plane POP, while others have multiple POPs. The interrelationship and communication with the data plane POP (205) are shown by large double arrows in Figure 3. Communication between the management client (384) and client devices (112, 122, 132) and the management plane POP (305) is similarly represented.

[0057] The management plane POP (305) includes summary data (332), raw event data (334), configuration (336), policies (187), a web management interface (362), provisioning services (366), configuration services (328), event storage services (326), monitoring services (324), and a report generator (322). These services act as a bridge between the management plane and the data plane; the configuration service (328) communicates with the configuration agent (224), the event storage service (326) communicates with the event queue (225), and the monitoring service (324) communicates with the configuration agent (224). The report generator (322) is a management plane-only item in this embodiment and combines raw event data (334) to generate summary data (332) for reporting. The web management interface (362) enables management and reporting via a web browser. The provisioning service (366) provides the appropriate client to the client device for configuration. The provisioning service (366) may also be responsible for providing policy updates to the client devices (112, 122, 132). In other implementations, the event storage service (326) and / or monitoring service (324) may accept data directly from cloud services and / or other sources for unified logging and reporting.

[0058] The data plane point of presence (205) and the management plane point of presence (305) are described herein with reference to specific blocks, but it should be understood that these blocks are defined for illustrative purposes only and are not intended to require a specific physical arrangement of component parts. Furthermore, these blocks do not need to correspond to physically different components. To the extent that physically different components are used, the connections between components (e.g., connections for data communication) can be wired and / or wireless as needed. Different elements or components can be combined into a single software module, and multiple software modules can run on the same hardware.

[0059] Figure 4 shows an example of a TLS certificate hierarchy (400) separated by region for the United States (402) and the EU (406). A Public Key Infrastructure (PKI) is a set of roles, policies, hardware, software, and procedures necessary to create, manage, distribute, use, store, and revoke digital certificates, and to manage public-key cryptography. PKI Certificate Authorities create CA digital certificates. The trust anchor for digital certificates is the Organizational Certificate Authority (402, 406). Multiple intermediate CAs branch off from these Organizational CAs in a parent-child relationship with the Organizational CA as the root. The Organizational CA can be stored in a secure HSM, as described below. Child CAs are authenticated by their corresponding parent CAs and trusted back to the Organizational CA. Intermediate Organizational or Tenant Certificate Authorities (422, 424, 426, 428) are intermediate CAs subordinate to the Organizational CA. They can provide certificates to users, computers, and other services that issue certificates to other CAs in the CA hierarchy. In the example of a TLS certificate hierarchy (400), an intermediate certificate authority (422) issues a user certificate authority (442), which in turn issues a CA for user 1 (462) and a CA for user 2 (464). In other implementations, such as federal security, further hierarchy levels may be used.

[0060] The private key of an intermediate CA is highly confidential. In a conventional technology scenario, the intermediate CA's private key signs application certificates via a private network. In an example with 50 data centers distributed worldwide, each with 8-10 proxies, the private key is sent to each proxy via the private network. Fintech customers find this unacceptable. Furthermore, the typical validity period of a certificate is currently three years, which is sufficient time for a compromised certificate to be used to exploit customer data.

[0061] The disclosed technology creates an intermediate proxy to prevent the private key from crossing the network boundary. The new intermediate proxy generates a proxy certificate with a configurable validity period. In the disclosed hierarchy, the intermediate certificate authority (422) issues Proxy 1 CA (444), which in turn issues a CA for App 1 CA (466) and a CA for App 2 CA (468). The intermediate proxy dynamically generates Proxy 1 CA (444), which can be configured to have a short validity period, for example, about a week, as described in this example. If the certificate is compromised, it can be revoked. [Interaction between the management plane and the data plane]

[0062] Figure 5 shows a high-level block diagram (500) of the interaction between the management plane and data plane points of presence (PoPs) in a disclosed system where each inspection proxy creates its own CA with private and public keys. The management plane (502) functions as a key management server and has a Netskope hardware security module (HSM) (532) that holds the Organization Certificate Authority (CA) (402, 406). The management plane (502) also has a proxy certificate broker (524) and a provisioning service (366). Data plane PoP1 (508) has PoP1 proxy A (518) and PoP1 proxy B (528), and data plane PoP2 (548) has PoP2 proxy A (558) and PoP2 proxy B (568).

[0063] An HSM(532) is a tamper-proof physical computing device that protects and manages digital keys and can perform encryption and decryption functions for digital signatures, strong authentication, and other cryptographic functions. The HSM(532) holds the private keys of the organization's CA and the intermediate CA. The HSM(532) handles a single operation per tenant from the provisioning service(366).

[0064] Continuing the explanation of Figure 5, when a new tenant is created, the provisioning service (366) generates an intermediate CA key pair and sends a Certificate Signing Request (CSR) (542) with a configurable validity period and the intermediate CA key pair to the HSM (532) for signing. The CSR or a derivative of the CSR is signed at the HSM (532). Next, the provisioning service (366) sends the public key and the signed intermediate CA certificate (555) to each of the four PoP proxies: PoP1 proxy A (518), PoP1 proxy B (528), PoP2 proxy A (558), and PoP2 proxy B (568). As an example, in an implementation with 50 data centers, each with 8 to 10 proxies, the provisioning service (366) sends the public key and the signed intermediate CA certificate to each of the hundreds of proxies that make up the inspection proxy set. As will be explained next, each inspection proxy creates its own public and private key pair in memory. In other words, each inspection proxy will have its own private key (not the same private key stored in the HSM). By using this disclosed technology, even if one private key is compromised, only a portion of the traffic will be compromised.

[0065] Figure 6 illustrates an inspection proxy that stores domain-specific CA key pairs in proxy memory. Each proxy (518, 528, 558, 568) must have its key pair signed by a trusted authority. Each proxy (518, 528, 558, 568) sends a separate, short-lived CSR to the proxy certificate broker (524) for its domain-specific CA (645). In one example, the configurable validity period can be one week. In another, the validity period can be set to one day, one month, or one year, or to a different time within a range limited to one day, one week, one month, or one year.

[0066] To continue the explanation, the private key stored within the HSM(532) is necessary to sign a different short-lived CSR for each proxy, and this private key remains within the cryptographic boundary of the physical memory of the HSM processing unit, inside the HSM(532). By using the disclosed technology, the proxy certificate broker (524) sends the proxy CSR(632) to the HSM(532) for signing. The HSM(532) sends the signed certificate back to the proxy, which uses it to securely access applications such as obtaining Salesforce certificates and Box certificates. A few hours or a day before the signed certificate expires, a new short-lived certificate is obtained using the same process. That is, each proxy generates a new public-private key pair and generates a CSR that the proxy sends to the proxy certificate broker. The proxy certificate broker sends the CSR to the HSM, requests a signature, and sends the signed certificate and new public key back to the proxy for use for the next week. Therefore, the validity period of each key pair is very short.

[0067] KMIP (Key Management Interoperability Protocol) is an extensible communication protocol that defines a message format for manipulating cryptographic keys on a key management server. This simplifies the management of cryptographic keys and makes data encryption easier.

[0068] Figure 7 illustrates a proxy certificate signing request (CSR) sent to a customer's hardware security module (HSM). As shown in System (600), the key pairs of the proxies (518, 528, 558, 568) are signed by a trusted authority in System (700). Each proxy (518, 528, 558, 568) sends a separate short-term valid CSR to a domain-specific CA (645) to the proxy certificate broker (524). For example, the configurable validity period can be one week. In other cases, the validity period can be set to one month or one year, or other periods or ranges over those periods. In addition to the Netskope HSM (532), the implementation shown in System (700) also includes a separate customer HSM (732) that can store tenant CA key pairs. The implementation described herein refers to the processes shown in black and white, in addition to the aforementioned implementation of System (600) shown in gray.

[0069] Continuing the description of the system (700), the private key stored in the HSM (732) is used to sign a separate, short-lived CSR for each proxy, and this private key remains within the HSM (732), i.e., within the cryptographic boundary of the physical memory of the HSM processing unit. In one example of the disclosed technology, the proxy certificate broker (524) sends the proxy CSR (632) to the HSM (732) for signing. The HSM (732) sends the signed certificate back to the proxy, which then uses it to securely access the application.

[0070] Figure 8 is a schematic diagram of how customer certificates are signed using an example of a TLS certificate hierarchy including proxies. Figure 8 includes customer certificates from the first customer certificate (802) to the Nth customer certificate (806). Customer certificate 1 (802) is signed by proxy 1 (822), which has its own key pair. Customer certificate 2 (802) is signed by proxy 2 (826), which also has its own key pair. Both proxy 1 (822) and proxy 2 (826) send their respective CSRs (along with their respective proxy public keys) to the tenant certificate authority (844), which has its own key pair. The trust anchor for the digital certificate is the root certificate authority (864) (i.e., the organization certificate authority), and the intermediate certificate authority (844) sends its CSR (along with its tenant public key) to the said root certificate authority. The organization CA is held in a secure HSM, as described above. The organization certificate then sends its signed certificate to this. This chain is similar to the explanation and implementation in Figure 4, but uses a proxy CA for the application instead of an intermediate CA. [Example of certificate path]

[0071] Figure 9 illustrates an example of a certificate for a cloud-based service. For a particular cloud-based service, the TLS certificate chain may include a tenant certificate authority (844) (i.e., an intermediate certificate authority), proxy 1 (822) (i.e., a proxy domain-specific certificate authority), and a root certificate authority (864). The certificate (900A) is signed by the root certificate authority (864) with respect to the intermediate certificate authority (844) and includes intermediate certificate authority attributes (922) (identification data such as hostname, or organization or individual), issuer attributes (whether the certificate is signed by a CA or self-signed), validity attributes (962) (date and time of issuance and expiration of the certificate), and cryptographic attributes (982) (public key, key agreement protocol, etc.). In addition, the certificate (900B) is signed by the tenant certificate authority (844) with respect to the proxy intermediate certificate authority (822) and includes intermediate certificate authority attributes (924) (identification data such as hostname, entity, or individual), issuer attributes (whether the certificate is signed by the master CA or self-signed), validity period attributes (964) (issue date and time of the certificate and expiration date), and encryption attributes (984) (public key, key agreement protocol, etc.). Finally, the certificate (900C) is self-signed with respect to the root certificate authority (864) and includes customer intermediate certificate authority attributes (926) (identification data such as hostname, organization, or individual), issuer attributes (whether the certificate is signed by the master CA or self-signed), validity period attributes (966) (issue date and time of the certificate and expiration date), and encryption attributes (986) (public key, key agreement protocol, etc.). The TLS chain may have additional CAs compared to the example illustrated in Figure 9. [Message flow]

[0072] Figure 10 illustrates a message flow diagram for operating an inspection proxy over an encrypted session between a user and a cloud-based service, according to one implementation of the disclosed technology. The system includes customer service (1002) (user's CA (1012) and Netskope's HSM root key pair (532)), Netskope provisioning (366), Netskope proxy certificate broker (524), PoP proxy(s) (1006), and cloud service (1008).

[0073] Continuing the explanation of Figure 10, the user's CA (1012) sends an access request to the cloud service (1014) to the Netskope provisioning service (366). In response, the Netskope provisioning service (366) generates a request for a CSR and a signed CSR (1024) and sends it to Netskope's HSM (532). In some implementations of the disclosed method, the HSM (532) that stores the customer's root key pair may be replaced with a separate customer HSM (732) according to the implementation shown in Figure 7. Netskope's HSM (532) stores the intermediate CA key pair (1022) and returns the public key along with the signed CSR (1032). Next, the Netskope provisioning service (366) provides the signed intermediate CA certificate and the newly generated public key (1036) to the PoP proxy (1006). Each PoP proxy (1006) contains a different intermediate proxy CA key pair for each proxy (1038). The PoP proxy(s)(1006) returns a short-lived CSR for the individual proxy to the domain-specific CA(1046) to the Netskope proxy certificate broker(524). The Netskope proxy certificate broker(524) sends the proxy CSR with the domain-specific CA to the HSM root key pair(532) for signing. The signed proxy CSR is returned by the HSM(532) to the Netskope provisioning service(366), which routes the signed proxy CSR back to the PoP proxy(s)(1006). This provides the user with an encrypted session to access the cloud service(1086), and the session(1088) is relayed between the PoP proxy(s)(1006) and the cloud service(1008). The PoP proxy(s)(1006) is responsible for inspecting the traffic(1087). [Computer System]

[0074] Figure 11 is a simplified block diagram of a computer system (1100) that can be used to provide a proxy intermediate certificate authority. The system (1100) can also be used to generate certificates used by a proxy intervening between a cloud-based service and a user system. The computer system (1100) includes at least one central processing unit (CPU) (1172) that communicates with a number of peripheral devices via a bus subsystem (1155) and a Secure Access Service Edge (SASE) system (153) for providing the network security services described herein. These peripheral devices may include, for example, a storage subsystem (1111) including a memory device and file storage subsystem (1136), a user interface input device (1138), a user interface output device (1176), and a network interface subsystem (1174). These input and output devices enable user interaction with the computer system (1100). The network interface subsystem (1174) provides an interface to an external network, including interfaces to corresponding interface devices in other computer systems.

[0075] In one implementation configuration, the Secure Access Service Edge (SASE) system (153) in Figure 1 is linked to a storage subsystem (1111) and a user interface input device (1138) for communication.

[0076] User interface input devices (1138) may include pointing devices such as keyboards, mice, trackballs, touchpads, or graphic tablets, audio input devices such as scanners, touchscreens integrated into displays, speech recognition systems and microphones, and other types of input devices. In general, the use of the term “input device” is intended to include all possible types of devices and methods for inputting information into a computer system (1100).

[0077] A user interface output device (1176) may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. A display subsystem may include a flat panel device such as an LED display, a cathode ray tube (CRT), or a liquid crystal display (LCD), a projection device, or any other mechanism for creating a visible image. A display subsystem may also provide a non-visual display such as an audio output device. In general, the use of the term “output device” is intended to include all possible types of devices and methods for outputting information from a computer system (1100) to a user or another machine or computer system.

[0078] The storage subsystem (1111) stores programming and data structures that provide some or all of the functionality of the modules and methods described herein. The subsystem (1178) may be a graphics processing unit (GPU) or a field-programmable gate array (FPGA).

[0079] The memory subsystem (1122) used within the storage subsystem (1111) may include a number of memories, including main random access memory (RAM) (1132) for storing instructions and data during program execution, and read-only memory (ROM) (1134) for storing fixed instructions. The file storage subsystem (1136) may provide persistent storage for program and data files and may include hard disk drives, floppy disk drives with associated removable media, CD-ROM drives, optical drives, or removable media cartridges. Modules implementing the functionality of a particular implementation can be stored by the file storage subsystem (1136) within the storage subsystem (1111) or in other machines accessible by the processor.

[0080] The bus subsystem (1155) provides a mechanism for various components and subsystems of the computer system (1100) to communicate with each other as intended. Although the bus subsystem (1155) is schematically shown as a single bus, alternative implementations of the bus subsystem may use multiple buses.

[0081] The computer system (1100) itself can be of various types, including personal computers, portable computers, workstations, computer terminals, network computers, televisions, mainframes, server farms, a widely distributed set of loosely networked computers, or any other data processing systems or user devices. Due to the constantly changing nature of computers and networks, the description of the computer system (1100) shown in Figure 11 is intended to be merely a specific example illustrating a preferred embodiment of the present invention. Many other configurations of the computer system (1100) are possible, having more or fewer components than the computer system shown in Figure 11. [Specific implementation form]

[0082] Several specific implementation forms and characteristics for providing a domain-specific proxy intermediate certificate authority are described in detail below. This intermediate certificate authority belongs to a provider different from the organization on which the user relies. The intermediate certificate authority can use root certificates provided by the organization or root certificates provided by the provider. A single-layer or multi-layer intermediate certificate authority can be implemented using either an organization-provided root approach or a provider-provided root approach. These four alternatives are described below. They share many optional characteristics and will not be described repeatedly for each implementation. <1. Organization Root Certificate, 1-Layer Description>

[0083] The use of an intermediate CA proxy is described in the context of a single-layer proxy. First, it describes how to trust an organization's CA certificates in a chain. Next, it describes how an organization trusts a provider's root CA certificate and configures its browser accordingly. One method disclosed involves a separate, non-organizational entity operating the inspection proxy for encrypted sessions established by the inspection proxy between users within the organization who are serviced by the inspection proxy and the cloud-based services accessed by those users. This method further involves providing an inspection proxy that includes an intermediate domain-specific CA, which holds a Certificate Authority (CA) certificate that the operating browser operated by the user within the organization recognizes as having the authority to sign end-entity certificates, by chaining it with a root certificate recognized by the browser. In certain implementations, the root certificate is associated with the organization's CA. In other implementations, the root certificate is associated with an entity operating the inspection proxy, which is separate from and not controlled by the organization (e.g., Netskope provisioning service).

[0084] Many implementations of the disclosed method involve the inspection proxy receiving a public key and organizational certificate from the organization's CA. As a result, a trust chain is established between the inspection proxy and the organization's CA. The inspection proxy then initializes the intermediate CA certificate by generating an intermediate public and private key pair, sends the unsigned intermediate CA certificate to the organization's CA via a certificate signing request, and receives a signed intermediate CA certificate in response, which is chained with the organization's CA's root certificate. The inspection proxy then receives a request from the organization's browser (or browser, or user) to establish a session to access cloud-based resources in a specific domain. Here, the inspection proxy does not yet hold a domain-specific certificate trusted by the organization's browser for this domain. The inspection proxy uses the intermediate key to sign the domain-specific certificate and generates a domain-specific certificate for the domain, which includes chaining the domain-specific certificate with the organization's CA certificate. As a result, the inspection proxy can now behave as a domain using a domain-specific certificate during a session with the organization browser, and can relay traffic between the organization browser and the domain, including decrypting session traffic received from the organization browser and encrypting session traffic sent to the organization browser. At least some of the session traffic relayed during a session will be inspected by the inspection proxy, and rules supplied by the organization will be applied to separate entities.

[0085] The methods described in this section and the following sections may include one or more of the features described below and / or in connection with the additionally disclosed methods. For brevity, the combinations of features disclosed in this application are not listed individually, nor are they repeated for each basic set of features. Readers will understand how the features identified by this method can be easily combined with the basic set of features identified as implementations.

[0086] Domain-specific certificates can have a set validity period, which can be short, such as 3 or 7 days. After a short validity period, or if a violation is detected, the certificate will expire and be revoked, ensuring secure access.

[0087] The organization browser can receive a domain-specific certificate, recognize that it is signed and chained with the organization's CA certificate, trust the domain-specific certificate, and establish a session with the inspection proxy acting as the domain.

[0088] The intermediate secret key can be stored in the proxy memory of the inspection proxy, rather than on disk memory.

[0089] Some implementations of the disclosed method include the use of the intermediate secret key by a single instance of the inspection proxy and not sharing it with other instances of the inspection proxy, and in other implementations, this idea can be extended so that the intermediate secret key is not shared with the master CA either.

[0090] The Method and the following Methods and each optional feature may also be implemented as a Product or System. A Product is a non-transient, computer-readable medium holding computer instructions that, when executed on hardware, cause the hardware to perform or execute an operation of any Method. A relevant implementation recognized in some jurisdictions is a computer program that performs an operation of any Method. A System includes hardware coupled to memory holding computer instructions that, when executed on hardware, cause the hardware to perform or execute an operation of any Method. For the sake of brevity, the individual Methods and Method Steps will not be repeated for these Products and Systems. Extensions of the Method to Products and Systems are illustrated in the following claims. <21 Provider Root Certificate, 1-Layer Explanation>

[0091] Some implementations of the disclosed method further include the inspection proxy domain-specific certificate authority being authorized by the intermediate certificate authority to sign subordinate certificates.

[0092] In many implementations, an entity separate from the organization and not managed by the organization operates an inspection proxy for encrypted sessions established between the organization browser and cloud-based resources via the inspection proxy. In this case, the organization browser is used by users within the organization and is configured to trust the entity's CA certificate. The certificate chain in these implementations follows a similar process, although it has the entity's CA certificate as its root instead of the organization's CA certificate.

[0093] This method further involves the inspection proxy receiving a public key and organizational certificate from the organization's CA. As a result, a trust chain is established between the inspection proxy and the organization's CA. Next, the inspection proxy initializes the intermediate CA certificate by generating an intermediate public and private key pair, sends the unsigned intermediate CA certificate to the organization's CA via a certificate signing request, and receives a signed intermediate CA certificate in response, which chains with the organization's CA's root certificate. Next, the inspection proxy receives a request from the organization's browser (or browser, or user) to establish a session to access cloud-based resources in a specific domain. Here, the inspection proxy does not yet possess a domain-specific certificate trusted by the organization's browser for this domain. The inspection proxy uses the intermediate key to sign a domain-specific certificate and generates a domain-specific certificate for the domain, including the fact that the domain-specific certificate chains with the organization's CA certificate. As a result, the inspection proxy can now act as a domain using the domain-specific certificate during the session with the organization's browser, relaying traffic between the organization's browser and the domain, including decrypting session traffic received from the organization's browser and encrypting session traffic sent to the organization's browser. At least some session traffic relayed during a session is inspected by the inspection proxy, and rules provided by the organization are applied to separate entities.

[0094] As described above, the methods described in this section and the following sections may include one or more of the features described below and / or in connection with the additionally disclosed methods. For brevity, the combinations of features disclosed in this application are not listed individually, nor are they repeated for each basic set of features.

[0095] Domain-specific certificates can have a set validity period, which can be short, such as 3 or 7 days. After a short validity period, or if a violation is detected, the certificate will expire and be revoked, ensuring secure access.

[0096] The organization's browser can receive a domain-specific certificate, recognize that it is signed and chained with the organization's CA certificate, trust the domain-specific certificate, and establish a session with the inspection proxy impersonating the domain.

[0097] The intermediate secret key can be stored in the proxy memory of the inspection proxy, rather than on disk memory.

[0098] Some implementations of the disclosed method include the use of the intermediate secret key by a single instance of the inspection proxy and not sharing it with other instances of the inspection proxy, and in other implementations, this idea can be extended so that the intermediate secret key is not shared with the master CA either.

[0099] In one implementation, the method further includes the organization browser receiving a domain-specific certificate, recognizing that it is signed and chained with an entity CA certificate, trusting the domain-specific certificate, and establishing a session with an inspection proxy acting as the domain. <1 Organizational root, multiple layers>

[0100] A multi-layer approach to intermediate CA proxies can reduce the burden on the root CA agency, regardless of whether the root is operated by the organization or the proxy provider. For example, a large multinational organization may have 500 proxy instances worldwide to serve it. Requests from all 500 proxy instances to the organization's own CA agency could easily overburden the organization's CA agency. Therefore, the proxy provider can build a hierarchical trust chain, creating additional links within that chain so that only one or a relatively small number of top-level provider CA agencies are chained with the organization's CA agency.

[0101] First, we will describe how the organization's CA certificates are trusted in a chain. Next, we will describe how the organization trusts the provider's root CA certificate and configures its browser accordingly. In some implementations of the disclosed multi-layer method, numerous instances of inspection proxies for cryptographic sessions are initialized, resulting in a session being established through at least 100 and not exceeding 1,000,000 instances of inspection proxies, which connect the organization browser to cloud-based resources. The organization browser is used by users within the organization who possess the organization's CA certificate. An entity separate from and not managed by the organization provides at least one master CA (e.g., a Netskope master CA with a longer validity period signed by the organization CA) and numerous instances of inspection proxies. For each inspection proxy, the intermediate CA certificate is initialized by generating an intermediate public and private key pair, sending the unsigned intermediate CA certificate to the organization CA when submitting a certificate signing request, and receiving a signed intermediate CA certificate in response, which is chained with the organization CA certificate.

[0102] Next, each inspection proxy generates its own domain-specific certificate for the domain, which involves signing its own domain-specific certificate using its respective intermediate secret key, and chaining each domain-specific certificate with the organization's CA certificate. This allows each inspection proxy to behave as a specific domain using its domain-specific certificate during a session with the organization's browser, and to relay traffic between the organization's browser and that specific domain. Traffic relaying may include at least one of decrypting session traffic received from the organization's browser and encrypting session traffic sent to the organization's browser. At least some of the session traffic relayed during a session is inspected by each inspection proxy, with organization-provided rules applied to separate entities.

[0103] In one implementation of the disclosed method, the master certification authority certificate has a validity period at the time it is signed by the organization CA, which is at least 10 times the second validity period of each intermediate certification CA certificate. In another implementation, the master CA certificate, once signed by the organization CA, has a first validity period that is at least 4 times the second validity period of each intermediate CA certificate when it is signed by the CA. In yet another implementation, the master CA certificate, once signed by the organization CA, has a first validity period between one week and one year, and each intermediate CA certificate, once signed by the organization CA, has a second validity period that does not exceed the validity period of the organization CA certificate and does not exceed one month.

[0104] One implementation of the disclosed method further includes each organization browser receiving its respective domain-specific certificate, recognizing that it is signed and chained with the organization's CA certificate, trusting its respective domain-specific certificate, and establishing a session with the respective inspection proxy acting as the domain. <19 Provider Route, Multiple Layers>

[0105] In a particular implementation, an entity separate from and not managed by the organization operates the inspection proxy for encrypted sessions, resulting in the inspection proxy being one of fewer than 1,000,000 instances out of 100 instances of the inspection proxy. The organization browser is used by users within the organization who have the organization's CA certificate. An entity separate from and not managed by the organization provides at least one master CA (e.g., a Netskope master CA with a longer validity period signed by the organization CA) and numerous instances of the inspection proxy. For the inspection proxy, the intermediate CA certificate is initialized by generating an intermediate public and private key pair, sending the unsigned intermediate CA certificate to the organization CA when submitting a certificate signing request, and receiving a signed intermediate CA certificate chained with the organization CA certificate in response.

[0106] Next, each inspection proxy generates its own domain-specific certificate for the domain, which involves signing the respective domain-specific certificate using its respective intermediate secret key, and chaining the respective domain-specific certificate with the organization's CA certificate. This allows the inspection proxy to behave as a specific domain using its respective domain-specific certificate during a session with the organization's browser, and to relay traffic between the organization's browser and that specific domain. Relaying traffic may include at least one of decrypting session traffic received from the organization's browser and encrypting session traffic sent to the organization's browser. At least some of the session traffic relayed during a session is inspected by the inspection proxy, and rules provided by the organization are applied to separate entities.

[0107] Some implementations of the disclosed method further include a customer HSM or security broker HSM that holds the private keys used by the certificate signing authority.

[0108] In one disclosed implementation, the method described in this section further includes the inspection proxy intercepting traffic between the user and the cloud-based service.

[0109] Some implementations of the disclosed method further include sending a certificate request for a site-specific signed certificate to an inspection proxy intermediate certificate authority to enable the inspection proxy to behave as if it were responding from a URL of a cloud-based service. In this implementation, the disclosed method further includes the inspection proxy receiving a signed site-specific certificate from the inspection proxy intermediate certificate authority that enables the inspection proxy to behave as if it were responding to a user from a URL of a cloud-based service.

[0110] Other implementations of the methods described in this section may include a tangible, non-transient, computer-readable storage medium that stores program instructions loaded into memory, which, when executed on a processor, cause the processor to perform any of the methods described above. Yet another implementation of the methods described in this section includes a device that includes memory and one or more processors capable of operating to execute computer instructions stored in memory, thereby enabling any of the methods described above.

[0111] Any data structures and code described or referenced above are stored on computer-readable storage media, which may be any device or medium capable of storing code and / or data for use by a computer system, according to many implementations. This includes, but is not limited to, volatile memory, non-volatile memory, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), disk drives, magnetic tapes, CDs (Compact Discs), DVDs (Digital Versatile Discs or Digital Video Discs), and other media currently known or to be developed that can store computer-readable media.

[0112] The foregoing description is provided to enable the creation and use of the disclosed technology. Various modifications to the disclosed implementations are evident, and the general principles set forth herein may be applied to other implementations and uses without departing from the spirit and scope of the disclosed technology. Accordingly, the disclosed technology should not be limited to the implementations shown, but should be given the broadest scope consistent with the principles and features disclosed herein. The scope of the disclosed technology is defined by the appended claims.

Claims

1. A computer implementation method of an entity separate from and not controlled by an organization, which operates a cloud-based inspection proxy for encrypted sessions between an organization browser and clients (collectively referred to as browsers) and cloud-based resources, established via the cloud-based inspection proxy, wherein the organization browser is used by users within the organization, the organization has an organization certification authority (CA), and the method operates the inspection proxy, The organization CA receives a public key and organizational certificate from the aforementioned organization CA to establish a trust chain between the cloud-based inspection proxy and the aforementioned organization CA, The process involves initializing an intermediate CA certificate by generating an intermediate public key and private key pair, sending an unsigned intermediate CA certificate to the organization CA by sending a certificate signing request, and receiving a signed intermediate CA certificate in response that is chained with the root CA certificate of the organization CA. The inspection proxy receives a request from the organization browser and establishes a session to access cloud-based resources in the domain, provided that the inspection proxy does not yet possess a domain-specific certificate trusted by the organization browser for the domain. The process of generating a domain-specific certificate for the domain includes signing the domain-specific certificate using the intermediate private key and chaining the domain-specific certificate with the organization certificate, During the session with the said organization browser, behave as the said domain using the said domain-specific certificate, Relaying traffic between the organization browser and the domain, including decrypting and encrypting session traffic between the organization browser and the domain, By applying the rules supplied by the aforementioned organization to the aforementioned separate entities, the examiner inspects at least some session traffic relayed during the session, Computer implementation methods, including those mentioned above.

2. The computer implementation method according to claim 1, further comprising setting the validity period of the domain-specific certificate to three days or less.

3. The computer implementation method according to claim 1, further comprising setting the validity period of the domain-specific certificate to one week or less.

4. The computer implementation method according to claim 1, further comprising setting the validity period of the signed intermediate CA certificate to one week or less.

5. The computer implementation method according to claim 1, further comprising setting the validity period of the signed intermediate CA certificate to one month or less.

6. The computer implementation method according to claim 1, further comprising the organization browser receiving the domain-specific certificate, recognizing that it is signed and chained with the organization certificate, trusting the domain-specific certificate, and establishing the session with the inspection proxy that is impersonating the domain.

7. The computer implementation method according to claim 1, wherein the intermediate secret key is stored in the proxy memory of the inspection proxy, rather than on disk memory.

8. The computer implementation method according to claim 1, wherein the intermediate secret key is used by a single instance of the inspection proxy and is not shared with other instances of the inspection proxy.

9. The computer implementation method according to claim 7, wherein the intermediate secret key is used by a single instance of the inspection proxy and is not shared with other instances of the inspection proxy.

10. A non-transient computer-readable medium, which, when executed on hardware owned by an entity not controlled by the organization, unlike the organization, holds computer instructions that implement the operation of a cloud-based inspection proxy for encrypted sessions established between the organization browser and clients (collectively referred to as browsers) and cloud-based resources via the cloud-based inspection proxy, wherein the organization browser is used by users within the organization, and the organization has an Organizational Certificate Authority (CA), The organization CA receives a public key and organizational certificate from the aforementioned organization CA to establish a trust chain between the cloud-based inspection proxy and the aforementioned organization CA, The process involves initializing an intermediate CA certificate by generating an intermediate public key and private key pair, sending an unsigned intermediate CA certificate to the organization CA by sending a certificate signing request, and receiving a signed intermediate CA certificate in response that is chained with the root CA certificate of the organization CA. The inspection proxy receives a request from the organization browser and establishes a session to access cloud-based resources in the domain, provided that the inspection proxy does not yet possess a domain-specific certificate trusted by the organization browser for the domain. The process of generating a domain-specific certificate for the domain includes signing the domain-specific certificate using the intermediate private key, and the domain-specific certificate being chained with the organization CA certificate, During the session with the said organization browser, behave as the said domain using the said domain-specific certificate, Relaying traffic between the organization browser and the domain, including decrypting and encrypting session traffic between the organization browser and the domain, Applying the rules provided by the aforementioned organization to the aforementioned separate entities to inspect at least some session traffic relayed during the session, A non-transient, computer-readable medium that implements the operation including [specific actions].

11. The non-transient computer-readable medium according to claim 10, further comprising an instruction to perform the operation of setting the validity period of the domain-specific certificate to three days or less.

12. A non-transient computer-readable medium according to claim 10, further comprising instructions for implementing the operation of setting the validity period of the domain-specific certificate to one week or less.

13. A non-transient computer-readable medium according to claim 10, further comprising instructions for implementing the operation of setting the validity period of the signed intermediate CA certificate to one week or less.

14. A non-transient computer-readable medium according to claim 10, further comprising instructions for implementing the operation of setting the validity period of the signed intermediate CA certificate to one month or less.

15. A non-transient computer-readable medium according to claim 10, further comprising instructions for implementing the operation of the organization browser receiving the domain-specific certificate, recognizing that it is signed and chained with the organization CA certificate, trusting the domain-specific certificate, and establishing the session with the inspection proxy that is impersonating the domain.

16. The non-transient computer-readable medium according to claim 10, wherein the intermediate secret key is stored in the proxy memory of the inspection proxy rather than on disk memory.

17. The non-transient computer-readable medium according to claim 10, wherein the intermediate secret key is used by a single instance of the inspection proxy and is not shared with other instances of the inspection proxy.

18. The non-transient computer-readable medium according to claim 16, wherein the intermediate secret key is used by a single instance of the inspection proxy and is not shared with other instances of the inspection proxy.

19. A system comprising processor hardware configured to be coupled to the non-transient computer-readable medium described in claim 10 and to implement the instructions.

20. A system comprising processor hardware configured to be coupled to the non-transient computer-readable medium described in claim 11 and to execute the instructions.

Images