This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
How SSL compression works
SSL compression has access to the clear-text data of the connection, because the server-side appliance acts as a security delegate of the endpoint servers. This behavior is possible because the server-side appliance is configured with copies of the servers’ security credentials (private keys and certificates), allowing it to act on the servers’ behalf. To the client, this behavior is equivalent to communicating directly with the endpoint server.
Because the appliance is working as a security delegate of the server, most configuration is on the server-side appliance. The client-side appliance (or plug-in) acts as a satellite of the server-side appliance and does not require per-server configuration.
The server-side and client-side appliances share session status through an SSL signaling connection. All accelerated connections between the two appliances are sent over SSL data connections, whether the original connections were encrypted or not.
Note: SSL compression does not necessarily encrypt all link traffic. Traffic that was originally encrypted remains encrypted, but unencrypted traffic is not always encrypted. The appliances do not attempt to encrypt unaccelerated traffic. Because there is no absolute guarantee that any given connection will be accelerated (various events prevent acceleration), there is no guarantee that the appliances will encrypt a given unencrypted connection.
SSL compression operates in one of two modes: transparent proxy or split proxy. These two modes support slightly different SSL features. You select the mode that provides the features a given application requires.
Which SSL proxy mode to use—Use SSL transparent proxy mode only if you require true client authentication (that is, authentication that correctly identifies the individual endpoint client) and you do not require Diffie-Hellman, Temp RSA, TLS session tickets, SSL version 2, or session renegotiation. Use SSL split proxy for all other deployments.
SSL transparent proxy
In SSL transparent proxy mode (not to be confused with transparent mode on the Citrix SD-WAN WANOP Plug-in), the server-side appliance masquerades as the server. The server’s credentials (certificate-key pair) are installed on the server-side appliance so that it can act on the server’s behalf. The server-side appliance then configures the client-side appliance to handle the client end of the connection. The server’s credentials are not installed on the client-side appliance.
True client authentication is supported in this mode, but Temp RSA and Diffie-Hellman are not. SSL transparent proxy mode is suited for applications that require client authentication, but only if none of the following features are required: Diffie-Hellman, Temp RSA, TLS session tickets, SSL version 2. Also, session renegotiation must not be attempted, or the connection terminates.
No configuration is required on the client-side appliance (other than configuring a secure peering relationship with the server-side appliance), and no configuration is required on the client, which treats the connection exactly as if it were communicating directly with the server.
SSL split proxy
SSL split proxy mode is preferred in most instances, because it supports Temp RSA and Diffie-Hellman, which many applications require. In SSL split proxy mode, the server-side appliance masquerades as a server to the client, and as a client to the server. You install server credentials (a certificate-key pair) on the server-side appliance to allow it to act on the server’s behalf.
Split proxy mode also supports proxied client authentication if you install optional client credentials, which are presented to the endpoint server application if it requests client authentication. These client credentials will be presented instead of the actual endpoint client’s credentials. (Use transparent proxy if the endpoint client credentials are required by the application.)
Because true client authentication is not supported in this mode, the server cannot authenticate the actual endpoint client. If the server-side appliance is not configured with client credentials, all attempts by the server-side application at client authentication fail. If the server-side appliance is configured with client credentials, all requests for client authentication will be answered with these credentials, regardless of the identity of the actual client.
No configuration is required on the client-side appliance (other than configuring a secure peering relationship with the server-side appliance), and no configuration is required on the client, which treats the connection as if it were communicating directly with the server. The server credentials on the server-side appliance are not installed on the client-side appliance.
To support multiple servers, multiple private certificate-key pairs can be installed on the appliance, one per SSL profile. Special SSL rules in the service class definitions match up servers to SSL profiles, and thus SSL profiles to credentials.
In SSL split proxy mode, the CA certificates and certificate-key pairs and CA certificates do not actually have to match those of the servers, though they can. Due to the nature of a split proxy, the server-side appliance can be use credentials that are acceptable to the client application (valid credentials issued by a trusted authority). Note that, in the case of HTTPS connections, Web browsers issue a warning if the common name does not match the domain name in the URL. In general, using copies of the server’s credentials is the more trouble-free option.
Share
Share
In this article
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.