Abstract: A controller can securely publish an application of a tenant by securely extending a network fabric into the networks of the tenant with virtual private networks and NAT. After a tenant deploys an application into one or more networks of the tenant, the tenant can indicate select applications to publish. The network controller assigns a network address from the routable address space of the network fabric to the application and a network address aggregate to each application connector that will front an instance of the application, which securely extends the network fabric into the tenant network. The network controller configures NAT rules in the network fabric and on the application connector to create a route for traffic of the application through the network fabric to the application instance using a fully qualified domain name assigned to the application without exposing a private network address of the application instance and preserving security of other resource on the tenant network.

Abstract: Each tenant of a secure web gateway (SWG) is issued a secret key. A user accesses a unique secret key derived from the tenant's secret key and loads the secret key into an application which generates time-based one time passwords (TOTPs). When the SWG receives a connection request from a client and cannot decrypt the network traffic, the SWG challenges the client request and indicates an authentication scheme to be used. The client obtains user credentials, constructs a response to the challenge based on the authentication scheme, and issues a connection request to the SWG which indicates the response. The SWG determines an expected response based on a locally generated TOTP and the secret key of the corresponding tenant. If the expected response matches the provided response, the SWG authenticates the user, allows the connection request, and whitelists the client for a period longer than the lifetime of the TOTP.

Abstract: For connection establishment, a system allocates memory that will be occupied by the data and handshake sub-protocol infrastructure that facilitates establishing a TLS connection. After connection establishment, the system allocates memory space for the data and record sub-protocol infrastructure that facilitates the asynchronous communication of application traffic. The memory space for the TLS session (i.e., the communication information separate from the handshake) has a substantially smaller footprint than the memory space for the TLS handshake. The TLS handshake memory space can be released and recycled for other connections while application communications use the smaller memory space allocated and populated with the TLS session data and infrastructure.

Abstract: Each tenant of a secure web gateway (SWG) is issued a secret key. A user accesses a unique secret key derived from the tenant's secret key and loads the secret key into an application which generates time-based one time passwords (TOTPs). When the SWG receives a connection request from a client and cannot decrypt the network traffic, the SWG challenges the client request and indicates an authentication scheme to be used. The client obtains user credentials, constructs a response to the challenge based on the authentication scheme, and issues a connection request to the SWG which indicates the response. The SWG determines an expected response based on a locally generated TOTP and the secret key of the corresponding tenant. If the expected response matches the provided response, the SWG authenticates the user, allows the connection request, and whitelists the client for a period longer than the lifetime of the TOTP.

Abstract: A controller can securely publish an application of a tenant by securely extending a network fabric into the networks of the tenant with virtual private networks and NAT. After a tenant deploys an application into one or more networks of the tenant, the tenant can indicate select applications to publish. The network controller assigns a network address from the routable address space of the network fabric to the application and a network address aggregate to each application connector that will front an instance of the application, which securely extends the network fabric into the tenant network. The network controller configures NAT rules in the network fabric and on the application connector to create a route for traffic of the application through the network fabric to the application instance using a fully qualified domain name assigned to the application without exposing a private network address of the application instance and preserving security of other resource on the tenant network.

Abstract: Each tenant of a secure web gateway (SWG) is issued a secret key. A user accesses a unique secret key derived from the tenant's secret key and loads the secret key into an application which generates time-based one time passwords (TOTPs). When the SWG receives a connection request from a client and cannot decrypt the network traffic, the SWG challenges the client request and indicates an authentication scheme to be used. The client obtains user credentials, constructs a response to the challenge based on the authentication scheme, and issues a connection request to the SWG which indicates the response. The SWG determines an expected response based on a locally generated TOTP and the secret key of the corresponding tenant. If the expected response matches the provided response, the SWG authenticates the user, allows the connection request, and whitelists the client for a period longer than the lifetime of the TOTP.

Abstract: For connection establishment, a system allocates memory that will be occupied by the data and handshake sub-protocol infrastructure that facilitates establishing a TLS connection. After connection establishment, the system allocates memory space for the data and record sub-protocol infrastructure that facilitates the asynchronous communication of application traffic. The memory space for the TLS session (i.e., the communication information separate from the handshake) has a substantially smaller footprint than the memory space for the TLS handshake. The TLS handshake memory space can be released and recycled for other connections while application communications use the smaller memory space allocated and populated with the TLS session data and infrastructure.